Source: medium.com
The Big RefactorCategory: Database, Data
Refactoring, made famous (and indeed coined as a technical term) by Martin Fowler in the 1990s, has not usually been considered a particularly pleasant task; particularly when working with legacy codebases. There are many books on how to proceed with refactoring and working with legacy code and they all contain valuable nuggets of information.
Indeed any commentary around potentially splitting the monorepo back into separate component-based repos was met with protests: In short the team had adapted to the monorepo and had adopted development practices that took advantage of this structure.
When undertaking a refactor of something so fundamental to a large enterprise system, there are many opportunities that present themselves along the way: Any of the decisions to go beyond the core goal of splitting apart the large module into smaller modules had to be carefully considered, and in almost all cases the choice was not to do any further cleanup than was necessary to complete the core refactor and ensure that the code still behaved correctly (you did start this process with good tests didn’t you??)
The process of refactoring this code started off fairly simple and the initial idea of small discrete commits that could be cherry-picked back into master as a whole unit of work was something that I was happy with and would have liked to be able to use for the entire process.
Indeed any commentary around potentially splitting the monorepo back into separate component-based repos was met with protests: In short the team had adapted to the monorepo and had adopted development practices that took advantage of this structure.
When undertaking a refactor of something so fundamental to a large enterprise system, there are many opportunities that present themselves along the way: Any of the decisions to go beyond the core goal of splitting apart the large module into smaller modules had to be carefully considered, and in almost all cases the choice was not to do any further cleanup than was necessary to complete the core refactor and ensure that the code still behaved correctly (you did start this process with good tests didn’t you??)
The process of refactoring this code started off fairly simple and the initial idea of small discrete commits that could be cherry-picked back into master as a whole unit of work was something that I was happy with and would have liked to be able to use for the entire process.
Related Articles
Community Partners
DevOps Careers