Recently, I have come across a very interesting book called Agile Software Development, Principles, Patterns, and Practices . This book is one of the most important descriptions about Agile methodologies. I’ve read edition from 2002 and although it is 10 years old, the knowledge is very general and can be (and should be!) applied today as well. It is about software design, doing it the right way.
One of its chapters describes something called “design smells”. This is a list of seven hints that point to a wrong design and “rotting” code. Let us review that list:
Have you ever had a simple looking “change” to do in the code that after some investigation appeared to be a huge chain of other changes? You might say “that’s easy, it will take me just several hours to do”. But after some work you realize that it took you not hours but days! We would like to cut those change chains as quick as possible! Such problem can be especially visible when the app is not divided into distinct layers or levels and every module talks with all the others.
After you make a simple change (even if it took you several days instead of hours) other unexpected things can happen. That small piece of modified code could influence in another part of the app and you might be getting very strange errors that seem to be unrelated to the original problem. The code is so “fragile” that it falls into pieces after only a small modification.
We should write our code with the view of using this in some other software. Our code should be “mobile” and usable by others. Unfortunately, it is usually only a theory and in reality things can go in the opposite way. That great class that you’ve just written is so hard to use and difficult to move, that it is easier to rewrite it from scratch. Some code, of course, cannot be moved from app to app - for instance, business logic for a particular problem: in most cases it’s unique. But for sure, you have some utilities, some general code, code that handles basic business rules, etc. that can be and should be used in your future project. If you are “scared” of using code from your previous projects.. that’s not good.
This term relates to ability to preserve the original design of your software while adding new features. It refers to code and tools as well. Is it easy to add a new code in your project?
For example, your original design of the app was amazing… but over time some requirements changed. This makes adding new features painful because you have to bend the rules every time.
It can be also simple as the following problem: if you have some strange source control system and adding new files are complex and needs a lot of time, you will probably make changes only in existing files. You will be “scared” of making new files, even though, you know that making small files (one class per file, for instance) will improve the whole programming process. Same goes for long compilation times,
5. Needless complexity
This sounds quite easy and speaks for itself. Sometimes we would like to predict the future and we write the software in a way that even the most bizarre future feature can be easily implemented. But, it is better to focus only on the existing needs. We have to create great design but not too great and not with so huge effort. Even when you are awesome software developer you will not predict everything. Why do you want to implement super fast version of quick-sort (and spending several days on making that work), when you have only 10 items to sort?
6. Needless repetition
Another simple “smell”. When you are tempted to “copy and paste” something, that should be a sign for you to stop and think your life over once again :) When we have redundant code it is not easy to fix a bug. Instead of making a change only in two lines (in one function for instance), we need to track all the 10k lines of code and search for similar occurrences. Usually it’s fine to copy something once, but the third time please refactor it.
When you want to stay in the company for a long period of time try this: every module that you create make “unreadable”. That way your boss will not fire you, because your team cannot live without you! You can create a myth of being “irreplaceable”. But maybe it is better to write a clean and easy to understand code? On the other side, you can get a code that was written by someone else, and spend several hours of scratching your head and cursing all the time. After a while you make decision that it will be much easier to write the code from scratch.
Those seven hints are very useful and can point to some places in you code where things went not as good as you previously designed. After introducing the list author of the book starts to explain what you can do to avoid that “smells”. This is as simple as making your design and code S.O.L.I.D. :)
I highly suggest to read the book!