Refactoring is easy—as long as you don’t work with other people or touch anybody else’s code. However, when you’re working with a team, you’ll face challenges like making sure the right people are aware of the refactoring and ensuring the work is not interrupted by functionality changes. If you’re working on particularly huge refactors, such as moving features from a monolithic application into their own microservices, then making sure nothing breaks is difficult and important.
Faced with these refactoring challenges, you might even feel like the task is too daunting and decide to give up on it altogether. Fortunately, CodeSee’s Code Automation can help. In this article, we’ll look at how a team might use Code Automation to embark on a full refactoring journey with minimal developer headaches and full awareness of the gotchas they might encounter along the way. When a team pursues the monolith-to-microservices migration—or any refactoring effort, for that matter—pairing code visibility with Code Automation will help make the journey smoother.
Let’s look at how!
The way is treacherous—take this map!
Before we dive into Code Automation, let’s touch upon the role of CodeSee codebase maps for code visibility in your refactoring effort. Developing a plan for a refactor requires a strong understanding of existing code. It also requires knowing where the deepest changes will take place in your codebase. When you’re working with a team, it’s essential to make sure everybody knows where those changes are happening. Otherwise, your team members might unwittingly step all over a large-scale refactoring effort.
With codebase maps, you can see the state of your code and use it to develop a plan for where to focus your efforts. Taking a visual approach to your codebase can make it easier to notice which parts of your code are less coupled to the rest of the repository and provide an opportunity to separate concerns. This is true whether you’re hoping to pull some shared code into a library or whether you’re creating a new microservice.
An example codebase map from CodeSee
CodeSee’s overlays provide insights that can facilitate the process of picking locations for refactoring. Looking at engineering hotspots or assessing the latest activity in your codebase can be a great way to carve out opportunities for simplifying your code to avoid churn on a regular basis.
CodeSee ties your codebase maps directly to your GitHub repository. You can always be certain that the map you’re looking at is reflective of the current state of your code. It also means that if you saved your initial plans for your refactor, you can quickly compare the current state of your code base with your initial state and make sure you’re actually making the desired progress.
Code Automation: Make sure nothing gets missed
A codebase map is a great visualization tool for seeing the state of your application and codebase, but it can’t prevent one of the most painful parts of a refactoring effort: change conflicts. Fortunately, CodeSee has introduced a feature called Code Automation—an incredibly powerful tool for making sure your plans to refactor or introduce microservices proceed as painlessly as possible.
Code Automations are great for curating the code review process, making sure your developers are aware of gotchas and other caveats. While several different types of Code Automations exist, we’ll focus on these five:
- Deprecating old code during and after your refactor
- Assigning reviewers
- Generating checklists
- Enforcing your refactor
- Adding comments
Deprecating old code during and after your refactor
During your refactor you want to be able to alert your colleagues not to use deprecated functions or files. You can create a code automation to trigger when a colleague tries to use the old function or file or pattern. When the old function is being used, you can redirect your colleague to the new pattern to ensure that no one continues to use code you're trying to refactor both while you’re refactoring and after you’re done.
Assigning reviewers
With Code Automations, you can automate the assignment of specific reviewers to a pull request whenever certain sections of the codebase are touched. For example, a team might have a principal engineer who is leading the refactoring effort in a specific folder of the application. Your automation could:
- Post a comment immediately on any pull request related to that code.
- Add that engineer to the reviewer list so the change can’t be merged without their approval.
With this automation in place, you don’t have to worry about making the reminder yourself!
This works with microservices as well. As your teams pull functionality out of the monolith and into a new microservice, you can assign pull requests to the lead engineer overseeing the related microservice. You can move your migration efforts forward with confidence that the right people will be looped in.
Generating checklists
Code Automations also help you to facilitate process by ensuring your developers don’t forget important tasks related to a pull request. Instead of using the same, general template and checklist across all pull requests, you can set up an automation to generate checklists that are specific to certain areas of code.
These checklists might include best practices, gotchas to look out for, or reminders of additional tasks to perform. By generating a checklist for a pull request in which specific areas of your code are touched, you can be sure your team follows the correct methodology for submitting code changes.
Specifically within the context of a refactoring effort, an automatically generated checklist can remind the pull request submitter of things that could be impacted by their code changes. This is incredibly helpful when performing the monolith-to-microservices migration because code impact is not often obvious. Your checklist might provide pointers for your developers to push an initial draft and then remind them of things to check for before finalizing the pull request and adding other reviewers to it.
Enforcing your refactor
Your refactors are only as good as your future ability to maintain them. Enforcement automations allow you to block a PR from being merged if a checklist is incomplete.
CodeSee’s enforcement rules give you more granularity than a GitHub action or a code owners file, ensuring that your entire team follows best practices, patterns, gotchas, and tricky rules in your code without having an infinitely long checklist that your team will ultimately ignore.
By default, checklist enforcement is turned on. (Before you'll see it in CodeSee, a GitHub admin will need to approve permissions.)
If your organization doesn't want to prevent pull requests with incomplete checklists, your admin can turn it off.
Adding comments
Of course, another helpful way to use Code Automations is to add comments on the pull request—based on certain conditions—as soon as the pull request is submitted. This can be especially useful in cases where some policy exists about a particular part of the codebase, and it’s important to make that clear during the review period.
Automated comments can also be helpful for pointing out significant changes that may be coming to a section of a codebase. If engineers are accustomed to adding files in a particular folder, but those files now need to be introduced in a microservice defined in another repository, you could leverage Code Automations and comments to make this clear.
Conclusion
Refactoring among a team can be easy after all. By combining codebase maps for visualization with Code Automation to enhance and tailor your code review process, the monolith-to-microservices migration is no longer daunting.
Assigning reviewers, generating checklists, and adding comments are just some ways you can leverage Code Automation to ensure code changes and code reviews move forward smoothly. We have just covered a starting point for how you can improve any refactoring or microservice migration process. Check out our documentation for Code Automation. This may be the powerful, new feature that boosts team effectiveness and velocity in your next large-scale refactoring!
