Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Code is Like a Public Toilet

DZone's Guide to

Code is Like a Public Toilet

Whenever you fix some code in a legacy application you should not leave bigger mess behind you than the mess was when you arrived. But no one follows this rule

· Java Zone
Free Resource

Microservices! They are everywhere, or at least, the term is. When should you use a microservice architecture? What factors should be considered when making that decision? Do the benefits outweigh the costs? Why is everyone so excited about them, anyway?  Brought to you in partnership with IBM.

We, developers, work with legacy code. There are only two types of code: legacy or dead. Before your code dies it becomes legacy unless it was born dead. Legacy code must be dealt with and legacy code is never perfect. Was it perfect when it was created? Perhaps it was. A piece of code can erode because of change of the environment. This environment can be other code, integration interfaces, developer experience. The code that looked okay one day may seem to be disgusting next day or a year later. The code that one team created may just not seem okay to another team. There may be something “real” issue that the industry generally agrees today as bad practice like having 5000 lines god objects, or some discussable things like having many return statements in an otherwise readable and neatly written method. One group may agree to use a variable retval and have one return statement, other schools do not care so long as long other readability issues are not present.

There is one thing that all schools agree: whenever you fix some code in a legacy application you should not leave bigger mess behind you than the mess was when you arrived. What is more: you are encouraged to clean the code up. If there is a bug in a method you fix write a unit test for the fix. If there were no unit tests for the method or class then create. If the method is a mess refactor it (but before that you create unit tests). If the method uses some other methods do not be shy to modify the other method so that their cooperation is cleaner. Do not be shy to modify the argument list, method signature. And if you do that you are also obligated to clean up the mess there as well.

You see the analogy implied in the title. Sometimes when drive is not that strong I just turn around without hesitation and hope that the next place I will find will be less abominable. I am talking about code. But sometimes I just can not do that. After all I am a programmer, that is my job: create good quality code from what is available. If the source is requirement definition we have to deal with those. If we have use case definitions, or vague user stories we go agile and do the best. If the source is mess, we clean up.

That is the life of a coder.

Discover how the Watson team is further developing SDKs in Java, Node.js, Python, iOS, and Android to access these services and make programming easy. Brought to you in partnership with IBM.

Topics:
software quality ,maintenance ,ruby ,php ,javascript ,python ,c#

Published at DZone with permission of Peter Verhas, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}