In This post We will discuss on Design Smells
When you will know your design Rots…when you are experiencing any of the following in your project/ code you are working on.. you should be certain that there is something wrong happening and you really need to look in to it
5. Needless Complexity
6. Needless Repetition
Rigidity is the tendency of the software difficult to change..A design is rigid , if a single change causes a cascade of subsequent changes..
Its like you are developing a system , and you are half way there.. and while adding new features or when you were asked to do a small change in existing system and if you are experiencing it is difficult to do that change because, its impacting most of the things in system and you need to change most of the existing system.you should consider your system is not rigidit
Fragility is the tendency of a program to break in many places when a single change is made..
I would say fragility and rigidity would complement each other… when you are adding a new feature to the system, ideally there should be no impact to existing system.. as we would all agree it is almost impossible :).. BUT there should be minimal or no impact to existing system..then you should consider your system is not Fragile
A design is immobile, when it contains parts that could be useful in other systems, but the effort and the risk involved with separating those parts from system are tooo great. this is unfortunate but very common occurrence
a viscous project is one in which the design of the software is difficult to preserve
when you find any problem in your system,generally we find more than one way to do that change.. one is adhering to design and the other which is not( A Hack ;)). When design preserving methods are harder to implement than hacks.. then your design is viscus
This may happen when developers are way ahead than Requirements..At first this may seem like a good thing to do..
i.e consider you may anticipate future requirements and you will put in elements in system which will be needed later in future, which you might consider a good thing to do. But you should consider that preparing for future changes should keep our code flexible and prevent nightmarish changes later.
unfortunately, the effect is just opposite.by preparing for future contigencies, design becomes littered…some of these preparations may pay off… but many are NOT
6. Needless Repetition
Cut and paste may be useful text-editing operations, but they can be disastrous to your system..
consider this.. suppose you need to convert a calendar date to business date and you thought that this must be somewhere in the system already and you do ctrl+shift+f and copy the code and paste it in your module… it happens that the code which you copied was written by a X developer which he had copied and pasted in his module from seeing in another module which has been developed by Y developer.. and also happens that Y developer copied and pasted that code in his module from another module which is developed by Z developer.. and Z developer had written that module… so there is a lot and lot of same code.. and if need to change that code… consider the nightmare…!!!!
Opacity is the tendency of a module to difficult to understand..to avoid this code should be written in clean, clear and Expressive manner..
its a complete developers responsibility to write clean, clear and expressive code…
when you first write a code, it may seem every thing is clear to you at first.. because you might of immersed in it at an intimate level and you know every detail of whats happening over there…some months later, when you revisit the code and wonder if you had written this code…
To make your system free from opacity… its one’s responsibility to put ourselves in readers shoes and make a concrete effort to make code clean , clear and expressive
Now we have some understanding what are code smells and when can we identify them, let us also understand , why there are code smells.. and why they are accumulated in system..??
Why software Rots..??? Why there are code smells
You will see most of the software rots and code smells in non-agile environments..why mostly in non-agile environments..?
Because Requirements change in a ways that the initial design did not anticipate. and often these changed need to be made quickly and may be made by developers who are not familiar with the original design philosophy..though change to design works, it somehow violates the original design. Bit by Bit, as a changes continue, these violations accumulate making code worse and rotten…
However, we should not blame the changes in requirements for your rotten code.. if you are a software developer and if you have been in this industry, you should already know that requirements are most volatile elements in software projects and they are tend to change.. if our designs are failing owing to constant changes in requirements…its our design and practices that are at fault..and we must somehow need to find a way to make our designs resilient to those changes and practices that protect them from rotting..
what you need to do to keep your system clean
you should be agile… as an agile team thrives on change. team invests little upfront so it is not vesting on aging initial design .you should keep your system as clean as possible and back up your system with lots and lots of unit tests, this keeps design flexible and easy to change.. when you are changing some thing you know you have your tests and rely on them…
in each iteration(sprint) should end with a system whose design is as appropriate(clean) it can be for the requirements in that iteration.