Hello everyone! We’ve been spending a lot of time in the last blog posts understanding what bad code is, how to objectively measure it, and even more, how to refactor a committed crime. And now, the time comes to understand how we can brilliantly craft a well-designed (hopefully?) greenfield project that is easy to maintain, to read, and to extend in the future. The purpose of software engineering is to control complexity not to create…
So, you got to know what are the consequences of bad code (here & here). You also got to understand how you can objectively decide if a particular piece of code is horrible or not (here). Then comes the question: Ok, I have inherited this devilish system. What should I do to improve it aside from nagging to my manager? Luckily, again, the software industry is experienced in dealing with such Brownfield projects. But before…