31–40 of 346 posts
The best advice I can give is DO NOT start a stop the world rewrite! and to look at the SOLID pattern and implement it using the STABLE strategy.
-Smell your code -Tiny changes first -Augment your tests -Back up -Leave it better than you found it -Expect good reasons
Full credit to Sarah Mei
https://markheath.net/post/stable-tactics-for-writing-solid-...
Is it buggy? Is it insecure? Is it slow? If the answers to those questions are no. Then you the problem and you should look for employment elsewhere. You are unhappy in that job, and you rewriting the codebase would potentially make the above questions answer to a YES, inflicting damages in the company. Now, if the above questions have yes as an answer. Talk to your manager, explain how it won't scale, how it is hack…
Somebody fathered a legacy codebase.
2. Relate your impressions to the person in charge: "The code doesn't seem to follow best practice and appears fragile. You think there may be technical debt that needs to be addressed sooner than later."
3. Until you're confident enough that you can pitch a comprehensive redesign and rewrite, wait for the person in charge to direct you towards specific repairs. When they direct you towards these specific repairs, they will anticipate regressions and instability. They'll see you as working through issues, not causing them.
4. Repeat step 2 periodically and with greater detail until you're ready to make the pitch in Step 3. Don't rush it.
The alternate solution: leave and let somebody else deal with the problem. Some people are comfortable working around fragile and wonky code; some people get really stressed out. You don't need to work in a job that's going to perpetually stress you out.
No matter how insane a code base looks, (unless it is totally inoperable) it is meeting a lot of conditions that are more important than whatever you are fixing but won't be recognized as important until you break them.
Those conditions built up over time and were changed irrationally by business decisions and hit or miss communication. A lot of demoralizing for anyone who was trying to keep standards while meeting requests.. Don't beat up the past maintainers for a past you can't know in much detail.
Maintaining old code can be fun though and is a more interesting puzzle game than most new development. Just try to stay emotionally neutral and unattached to anything about the code besides the specific challenges as they need tackling.
Is it buggy? Is it insecure? Is it slow? If the answers to those questions are no. Then you the problem and you should look for employment elsewhere. You are unhappy in that job, and you rewriting the codebase would potentially make the above questions answer to a YES, inflicting damages in the company. Now, if the above questions have yes as an answer. Talk to your manager, explain how it won't scale, how it is hack…
Next pick a component which is particularly problematic, or which is a focus of business attention at the moment. Look at which lines/conditions are covered by the tests – are the critical parts of the code, especially the success cases, being covered? If not, write tests for them. (Covering error cases is less critical, although user errors – bad user input – are more important to cover than things like IO or network errors.) Don't get hung up on a numeric target – which bits of code are being covered is more important than a number.
Once your test suite covers the important parts of that component, start slowly refactoring it and cleaning it up. Then, once you are satisfied it is in a better state, choose another component to move on to.
Of course, that assumes you can get your management on board with you doing the above. But if they aren't keen, you could try to phrase it as "Can I spend 20% of my time improving quality, and the other 80% on new features and fixing reported bugs?"
middle ground would be to write blackbox style tests and make them portable to the next revision of the codebase.
don't say that last person was a bad at coding, you won't benefit from saying that.
But keep this in your mind; if you make their life harder by your rewriting, then they will very likely make yours painful later on. Bring gradual, safe but immediate improvements and gain other's trust first. Then thing will get much easier next time, even someone else could do the job for you!