Seven Hints of Design Smells

This week I have decided to read about “Design Smells” from Bartek’s Coding Blog. So, while   this blog is rather short, the reason why I have chosen this one in particular is because recently in my studies, my biggest question that how do people figure out the errors of a design without testing or even refactoring. I want to understand the logical thinking in recognizing the errors that point to a wrong design.

This blog post basically goes over seven hints of design smells that points to places that the code is not going as intended. These seven hints are rigidity, fragility, immobility, viscosity, needlessly complexity, needlessly complexity, and opacity.  For rigidity and fragility, they point to the belief of a simple change will fix everything but other unexpected things can happen and the code can fall into pieces. Immobility and viscosity, on the other hand, point to “moving” and using codes to be improving the design but preserving it while implementing new features might be difficult. Needlessly complexity and repetition are easy to understand. They point to implementing something complex and copy and paste that is not needed at all. As for the last hint, Opacity, points to making a code clear and easy to understand.

So, based on the blog post with the insights I find behind it, I would say this was a simple but interesting blog to read. The author explained each of the seven hints with a simple take of every day programming work while giving the literal term along with it. From my experience in finding something wrong in a design, it’s usually testing which takes a considerable amount of time depending on how much writing there is into it. If there are unrelated errors occurring within testing, then it would be where I will try to figure out which part of it is the source of the problem and then try to debug it as much as possible.

From this blog about design smells, what I learned is that to avoid conflicted attention described by the hints, there should be consideration always in preserving the original design codes. The ideas that I have been taught is while it might be inconsistent to use the codes like that, there is no need to be “afraid” in both using general codes for future reference and bending the original design a little to improve the programming process. Learning the ideas from this blog shows me that for future practice, I should try to find features implemented in designs and trace down codes that give a complexity on the urge of repeating itself. That way, I can try to get the simple thinking of identifying problems without having to recreating codes like that. With this knowledge, I hope to assist others with great analyzing and fix codes better than I used to.

-Dennis Tran


Link to blog:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s