Clean Architecture — Design and architecture
A chapter in which Uncle Bob tells us what is design, architecture and why the only way to go fast in coding, is to go well.
About this article
This is a part of my series of articles where I go chapter-by-chapter through the “Clean Architecture” by Robert.C.Martin and share my thoughts, analysis and pieces of knowledge that I’ve gathered.
Design and architecture
First of all, according to Uncle Bob, both design and architecture are completely the same thing, just the words used are different. They both express the idea of a general overview or a blueprint of some sort, which tells anyone who reads it all about both low and high level details of the system being described.
Contrary to the popular believe one doesn’t expresses low and the other high level details, it’s more like they both create one interconnected flow from the top to the bottom and the bottom to the top.
Let’s minimize effort
Most of the time when developers put together any kind of a project, the bigger it gets the harder it becomes to make changes and add any kind of new features. Therefore the goal of a well laid out architecture is to prevent such thing from happening, in other words, to make sure that the effort needed to meet requirements will stay consistently low no matter how big or complex the whole project might become.
If effort is low, and stays low throughout the lifetime of the system, the design is good. If effort grows with each new release, the design is bad. It’s as simple as that.
Slow and steady
Next, the question comes up. How comes that, in many cases, when project grows bigger and bigger and more programmers join the development team the LOC (lines of code) output stays somewhat constant? Shouldn’t it get bigger relatively to the number of developers?
The answer is really simple. When programmers do their jobs in haste, without proper guidance and care for code cleanliness the code base becomes a nightmare. A nightmare so hard to manage and refactor that it makes the costs of new features skyrocket. What’s even worse, more work done most of the time means that this mess gets even bigger! This kind of code swamp makes it almost impossible for anyone to run and deliver new changes quickly.
The solution is to create good, clean and well-designed code architecture before any actual coding. And to never, ever leave code maintenance for later. I’m yet to meet a developer who has never had thought which goes like “I’ll leave it like this for now and come back later to refactor it, it is all right”. That’s the path in developer’s life which leads straight to the heaping mass of steamy mess-code which is hard to read and maintain.
The only way to go fast, it to go well.
Avoid overconfidence
Developers often are overconfident when it comes to their skills. Many think that they are capable of writing good quality code as they go, that they don’t need tests or that they will fix all the mess they’ve created in some near future.
Obviously that’s a big, fat lie. No one is skilled enough to keep track of all the possible logic paths or to foresee all the possible bugs and mistakes. We, the developers, should avoid overconfidence as much as it is possible. Don’t trust yourself when it comes to the quality of your work, trust processes, tests and good architecture.
In every case, the best option is for the development organization to recognize and avoid its own overconfidence and to start taking the quality of its software architecture seriously.
Summary
I encourage you to share your feedback and point of view with me, it’s the best way for all of us to learn and grow. Also, check out the complete book, it’s a really wonderful source of knowledge for any developer. My articles are just a shallow summary of information that can be found in this book, do yourself a favor and read it whole! Next part of this series can be found here.
