Being involved in the development of an Open Source platform for the last decade, software quality is a topic I am confronted with on a regular basis.
Maintainability (how easily a system can be modified) is one characteristic of software quality. Performance (how fast a system produces its output) is another.
Software quality is a vast topic and you can find a lot of valuable articles on the internet. So why a new article about software quality and why a focus on maintainability? Well the thing is that my team is currently facing challenges regarding team growth.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin E. Conway
I do not claim to have the answers on my own, that is why this is a topic I discuss with developers, other CTOs, and why I read articles and books about it!
Below are my takeaways from the book Building Maintainable Software: Ten Guidelines for future proof code, by Joost Visser.
Note: Software quality requires a lot of discipline and a clear set of priorities. That is why having rather simple guidelines that are easy to implement is very important for developers.
My team members and I are already familiar with most of these guidelines. Guidelines 1, 3, 4, 5, 6, 9 and 10 are already in our daily routines (even if we still have room for improvement).
I must confess that we do not talk about guidelines 2, 7 and 8 often enough. But now that I am aware of this, we will definitely discuss these topics as a team and identify what actions we want to take and prioritize them.
In any case guidelines 1 and 2 are the foundation and should never be overlooked. Whenever a developer identifies any violation in the code base, he/she should apply the Boy Scout rule: leave the code cleaner than you found it. This is where refactoring techniques are handy.
Refactoring techniques every team member must know to make small improvements in code maintainability, when applying guidelines.
The Extract Method refactoring lets you take a code fragment that can be grouped together, move it into a separated method and replace the old code with call to the method. It is very handy to reduce the size of a method by extracting a new method leaving the code base with 2 smaller methods.
How to do it with IntelliJ:
extract method
The Extract Method Object refactoring moves method into a new class, converting all the local variables to its fields, allowing you to decompose the method into other methods on the same object. It is an alternative to the Extract method, and can be used when you have multiple return values in an extracted method.
How to do it with IntelliJ:
extract method object
The Extract Parameter Object refactoring lets you select a set of parameters to a method, and either create a wrapper class for those parameters, or use an existing compatible wrapper class. All calls to the method selected will have their parameters appropriately wrapped, and all usages of the wrapped parameter will be replaced by the appropriate calls on the newly created parameter class.
How to do it with IntelliJ:
Extract parameter object
Better than refactoring, writing clean code from the start! I know it is easier said than done.
The good news is that modern IDE have validation tools to search for code smells. In IntelliJ for instance you should try to activate the Java inspections to enforce the above guidelines.
Java inspection
What about you? How do you manage mainainability in your projects?
Every business deserves a solution that accelerates its success. With Bonitasoft, simplify, automate and transform your business processes. Take the first step towards optimal performance today. Let's talk about it?