{"id":320,"date":"2020-03-24T14:42:00","date_gmt":"2020-03-24T14:42:00","guid":{"rendered":"https:\/\/www.simplybusiness.co.uk\/refactoring-using-crc\/"},"modified":"2024-05-28T12:40:35","modified_gmt":"2024-05-28T12:40:35","slug":"refactoring-using-crc","status":"publish","type":"post","link":"https:\/\/www.simplybusiness.co.uk\/about-us\/tech\/2020\/03\/refactoring-using-crc","title":{"rendered":"Breaking up monoliths using CRC cards"},"content":{"rendered":"\n

Class Responsibility Collaborator (CRC) cards can provide a lightweight and Agile tool for refactoring and developing software design hypotheses. In this post, we explore how one of our product delivery teams used this object-oriented design technique to refactor more productively.<\/p>\n\n\n\n

A rationale for CRC cards<\/h2>\n\n\n\n

Scenario<\/h3>\n\n\n\n

The Alchemists, one of the product delivery teams at Simply Business, recently completed a major project to refactor part of our monolithic codebase for our insurance brokerage service. The project involved determining which quotes and leads should be transferred to a third-party and when. Part of the development work to implement this scenario had already been carried out on our core Rails application. However, as this no longer aligned with our technology strategy of breaking up our large codebase into components, the team was faced with how best to refactor the code.<\/p>\n\n\n\n

Migration and microsteps<\/h3>\n\n\n\n

We began by working on an architectural decision record (ADR)<\/a> to define how to restructure the code and migrate it to one of our core gems – ‘Opportunity Knocks’ (hereafter referred to as ‘OK’). The refactoring work to move this code from the core application to the component was not trivial so we used the idea of ‘microsteps’ (World’s Best Intro to Test Driven Development – Joe Rainsberger<\/a>) to move the code out gradually and eventually converge on the architecture envisioned in the ADR.<\/p>\n\n\n\n

Visualising the big picture<\/h3>\n\n\n\n

One thing lacking, though, was a sense of the bigger picture – something the team was quick to point out. So when Tim Mackinnon<\/a> visited our London office, we were inspired to try out a technique used to teach object-oriented design in the 1980s – Class Responsibility Collaborator (CRC) cards.<\/p>\n\n\n\n

Developed by Ward Cunningham and Kent Beck, CRC cards are what may now be considered old-fashioned index cards, used to represent objects or classes. At the top of the card, the developer writes the name of the class that will solve a particular problem. On the left is an itemised list of responsibilities the class has, and on the right is a list of collaborators (other classes) that will help fulfil some of those responsibilities. Ward’s Wiki<\/a> has more information on the CRC technique.<\/p>\n\n\n\n

Learning and experimenting<\/h2>\n\n\n\n

Getting started<\/h3>\n\n\n\n

We began by writing CRC cards for our design as it currently stood and realised many immediate benefits; for example, difficulty in describing the responsibilities of some classes clearly and concisely.<\/p>\n\n\n\n

We posted each card on our whiteboard, grouping classes and their collaborators together, which gave us the lay of the land fairly quickly. We then experimented with moving cards from the core application (Chopin) section of the whiteboard to the component (OK), to see if they made sense there.<\/p>\n\n\n\n

This was great, because the cost of hypothesising and reasoning was almost zero. It enhanced the team’s agility, and uncovered potential difficulties in moving a particular class. All of this led to critical conversations with teammates, and was possible without us writing a single line of code!<\/p>\n\n\n\n

Identifying refactoring opportunities<\/h2>\n\n\n\n

By using the CRC technique, we discovered some refactoring opportunities too: class naming, lots of collaborators and extracting classes, which we’ll discuss further.<\/p>\n\n\n\n

Class naming<\/h3>\n\n\n\n

One class stood out in particular: TransferService<\/code>. Its responsibilities were to:<\/p>\n\n\n\n