4 ms·
> Before you make any changes at all write as many end-to-end and integration tests as you can. I don't agree with this. People can't write proper coverage for
by korzun 9y ago
> Before you make any changes at all write as many end-to-end and integration tests as you can.
I don't agree with this. People can't write proper coverage for a code base that they 'fully understand'. You will most likely end up writing tests for very obvious things or low hanging fruits; the unknowns will still seep through at one point or another.
Forget about refactoring code just to comply with your tests and breaking the rest of the architecture in the process. It will pass your 'test' but will fail in production.
What you should be doing is:
1. Perform architecture discovery and documentation (helps you with remembering things).
2. Look over last N commits/deliverables to understand how things are integrating with each other. It's very helpful to know how code evolved over time.
3. Identify your roadmap and what sort of impact it will have on the legacy code.
4. Commit to the roadmap. Understand the scope of the impact for your anything you add/remove. Account for code, integrations, caching, database, and documentation.
5. Don't forget about things like jobs and anything that might be pulling data from your systems.
Identifying what will be changing and adjusting your discovery to accommodate those changes as you go is a better approach from my point of view.
By the time you reach the development phase that touches 5% of architecture, your knowledge of 95% of design will be useless, and in six months you will forget it anyways.
You don't cut a tree with a knife to break a branch.
- markatkinson 9y agoI gasped when I saw this article at the top of HN due to the relevance of it right now in my life. I am currently working on a real monolithic jambalaya that suffers from a lack of documentation, architecture, extreme abstraction, rampant tight coupling and no previous source control. Your point on performing architecture discovery and documentation is spot on. It has really helped me to strip away the mess and understand the flow of the logic and maybe even shine some light on the parts of code that are valuable.
- korzun 9y ago> I gasped when I saw this article at the top of HN due to the relevance of it right now in my life. You are not the only one :)
- xivusr 9y agoThis article is painfully relevant for me. I just reviewed a code base with zero tests, documentation, no inheritance- rampant duplication. It's a simple event tracking system and yet there are 75 models, and over 80 controllers. This was outsourced to a team which coincidentally appears to have close to that many devs working there. The good news is that according to the client "it pretty much works". I know better than to suggest a Big Bang - though it seems so appealing. Documentation and code freeze are my next steps and implementing end to end testing.
- misja111 9y agoI agree with you, I don't know why you were downvoted. In my experience the first and biggest problem when taking over legacy codebases is the lack of knowledge of what features the code is supposed to support. Just starting out with writing integration test has a risk that you end up with even more meaningless code to maintain. Actually, contrary to the advise of the writer, I like to start out with fixing some bugs. I find it a great way to gain some knowledge and it has the added benefit of keeping business stakeholders happy. And while fixing those bugs you can start writing the first integration and unit tests.
- deleted 9y ago[deleted]