Seeking Clarification on Refactoring Guidance
I'm writing to make sure I fully understand the guidance on refactoring, as I'm currently reconciling two points that seem a bit contradictory.
On one hand, I understood the advice that if working on a small portion (say, 10-20%) of a large, existing codebase, one should avoid refactoring only that specific section. The rationale was that mixing significantly refactored code with untouched legacy code can lead to problems, implying that if refactoring is undertaken in that area, it should ideally encompass the entire codebase.
On the other hand, there's the principle of "make it a little better each time." The example provided was performing some cleanup on a legacy API when creating a new function that interacts with it. This approach seems to encourage incremental improvements and modernization, acknowledging that dedicating resources to refactor an entire codebase at once isn't always practical.
Could you perhaps elaborate on how to balance these two ideas? I'm trying to understand the threshold or context for when incremental cleanup is appropriate versus when touching code might necessitate a much larger refactoring scope (or perhaps avoiding isolated refactoring altogether).
Discussion
(1 comment)- 0
a month agoTech Lead @ Robinhood, Meta, Course HeroGreat question! The main factor to consider here is the intensity of the change. The thought process here is as follows:
- Low intensity - If it's a low intensity cleanup, then you should go ahead and make the change. Some obvious ones are unnecessary lines of code (Meta's codebase was full of these), bad variable/method names, lack of comments on complicated business logic, and flattening control-flows with early returns. These are very non-controversial small wins that don't fundamentally change how the code flows or reads. An example of a low intensity migration from my past is lambdas from Java 8. After we added support for Java 8 in Instagram, there was a ton of verbose, old-school anonymous object style code lying around. Whenever I would see those while working on a task, I would migrate it to a lambda as it's a non-controversial change that preserves the overall flow/style of the code.
- High intensity - If it's a high intensity cleanup, you need to be wary and more thoughtful about your actions. As I mentioned in the course, if you are making a high intensity change, you should try to follow-through and propagate the change across the entire codebase for consistency's sake. An example of a high intensity change is migrating from MVC to MVVM. These 2 coding architecture styles make the code read entirely differently as you have a different data flow, component structure, etc. It should be extremely annoying to have a codebase that is half/half as you need to gear your brain differently when reading code in each pattern. It would be like reading a book where the first 50 pages are in English, the next 50 are in Spanish, the next 50 are in English, and the final 50 are in Spanish. It's super disorienting.
Related Course
Other Great Discussions
