All too often we get our code
working and then move on to the next problem without giving sufficient thought to making
that code easy for the next person to read.
Robert C. Martin, Clean Code
This quote summarizes the entire article, but let us dissertate more about the subject, shall we?
What's the point?
What's the point in building software? For our employers, it is the final application, and how cost-effective the current/upcoming features are/will be implemented.
And what about us, developers? I'm sure there will be many different answers, but I will point out a new perspective on working with development.
I've seen many programmers that too often see themselves working in a poorly designed application, and complaining about the almost impossible task of giving it maintenance. What comes? Why is that scenario so common? Simple answer: we may not be caring enough about our code.
Software design
In the old days of software development, developers had less knowledge available on how to properly design an application, which, as a consequence, led to a massive number of unmaintainable legacy projects. However, another consequence of their effort is the documentation of several good practices and tools in order to build objectively good software. Some examples would be principles and patterns.
Some may disagree, but I would strongly advise new developers to learn SOLID and at least the most used patterns out there, as this knowledge will force you to make better decisions about how to design your code.
Cost of change
All that being said, let's talk about one main consequence of designing an application: cost of change.
When the project is in the first steps, it does not really matter, since the codebase is still small, and one could easily remember where everything is, and how everything is "connected". The problem arises when the business grows, and requirements keep coming.
In this scenario, if the application has a bad design, all starts to crumble. Any small requirement, that should take only a few minutes, is now taking you weeks, since one little change in one class breaks absolutely everything. With this, all requirements come with a high cost, one that could be avoided in the first place, with, guess what, good design and best practices.
Care about your code
What does all that have to do with caring about my code?
As the first quote really well stated, we would too often care more about "just solving the problem" or "completing the task" than the process of doing them. Ignore everything about design, principles and patterns if you will, but start to care more about how you solve the problem; what is the best way to complete this task?
If we care more about the future person that will have to give this piece of code maintenance (which could very well be yourself), our code suddenly becomes better, when it comes to readability and changeability. Applications that are easy to change are a pleasure to write and a joy to extend.
Your application needs to work right now just once; it must be easy to change forever.
This quality of easy changeability reveals the craft of programming. Achieving it takes
knowledge, skill, and a bit of artistic creativity
Sandi Metz, Practical Object-Oriented Design
Top comments (0)