Why it's Best to Leave Well-Functioning Things Alone
Assuming the code is running smoothly and meeting the SLA set by previous developers, you may not need to make any changes unless there are new feature requests or bugs to fix. While it's important to understand the project, your goal should be to gather enough information on relevant requests to fix the necessary pieces and touch relevant code only. Rewriting the entire project or even trying to understand every detail is not always necessary or efficient.
Strategies for making isolated changes are very different from strategies for understanding or re-architecting whole code bases.
When making small changes to your application, it's best to enter it via an HTTP request and run your server under a debugger. This allows you to closely observe the logic being followed and gain a more profound understanding of the relevant architecture. Using a debugger can be an effective tool for navigating the complexities of your codebase.
Consider making a small change with some code rot.
In some cases, you may find yourself thinking, 'I'm confident this code modification will work, despite being suboptimal from a design perspective.' While this can be a justifiable decision, it's crucial to first confirm that the alteration will indeed function properly. This may entail examining pertinent components to some extent.
It's important to also consider potential security risks – even if the changes appear to be effective in a limited number of test scenarios, it's essential to have a comprehensive understanding of the system to anticipate and avoid disastrous edge cases.
Your early steps should include getting your code under source control and learning the moving parts in production.
Effective source control is crucial, especially when working on unfamiliar codebases. It's essential to keep a detailed record of any changes you make so that you can easily track and manage them. To streamline this process, it's advisable to make cohesive git commits from the outset. This will help you perform tasks such as cherry-picking and subtle rollbacks more efficiently. When creating branches, it's significant to do so thoughtfully, considering the specific changes you've made. Consider segmenting your changes based on their level of safety or significance, such as changes that are deemed safe for production and those made simply for exploration purposes that may be useful for future reference.
In addition to basic considerations like familiarity with the codebase, it's important to take a broader view when making changes. For example, it's crucial to have a thorough understanding of your environment to ensure that you don't inadvertently break anything in production. This may involve utilizing a safe development environment to test your code before deploying it to a live environment. In addition to the software itself, it's essential to account for other key components such as the build system, unit tests, logging, monitoring, and error notification. Neglecting any of these elements can result in issues down the line, such as broken monitoring that goes unnoticed until it's too late. By taking a holistic approach to your changes, you can minimize the risk of errors and ensure that your updates are reliable and effective.
Be prepared to make the case for an expensive redesign or rearchitecture.
As maintenance tasks become increasingly time-consuming or frequent, it's worth considering whether the code you're working with is of poor quality. In such cases, it may be more cost-effective to make the case for replacing it altogether. Rather than tackling the entire codebase at once, identify specific areas that can be rewritten affordably. This might involve isolating individual components, such as the data layer or logging system, and updating them one at a time. By taking a focused approach to rewriting key pieces, you can gradually improve the overall quality of the codebase while minimizing disruption to ongoing development efforts.
Though it may be tempting to start from scratch and rewrite the entire project, this is usually not the best approach. In most cases, it's more effective to identify specific areas of the codebase that are problematic and work on updating them incrementally. This requires a profound understanding of the code and the ability to turn difficult-to-maintain components into more manageable ones. While larger pieces may require more extensive rewrites, it's important to avoid the extreme step of throwing out everything and starting from scratch, as this should be a last resort. In most cases, a focused approach to updating individual components can yield significant improvements in the codebase without disrupting ongoing development efforts.
Top comments (1)
Very interesting post!