People define quality in software in many ways. Some define quality as software that does what the customer wants. Others define quality as software that runs fast. Still others define quality as software that’s error-free. We all agree these are good things but are they all effects of a single cause, and if so, how do we start to write quality code? Here are seven strategies for increasing code quality.
1. Get crisp on the definition of quality
Quality in software is different than quality in tangible goods. We can’t just mix random ingredients together, throw them in an oven, and expect to get a cake. Understanding the “ingredients” that make up code quality is important. What characteristics should quality code have? Quality code should follow the SOLID principles, be clear, easy to understand, and easy to extend.
2. Share common quality practices
In addition to sharing a common definition of “quality” to create quality software, we must also share common practices. Leveraging the Agile process can help. For example, focusing on building features keeps development centered on giving each method a cohesive purpose.
3. Let go of perfectionism
They say, “the perfect is the enemy of the great.” Most of us know perfection is unobtainable in software and hold no illusions of achieving it. But when we’re unclear as to how our code will be used, even great isn’t good enough. Having clear acceptance criteria can help us build only what’s needed so we can move on without gold-plating features.
4. Understand tradeoffs
Developing software is about making a series of the best tradeoffs for a given situation. Understanding the implications of the tradeoffs we make can help us make better decisions that address the needs of the current situation. We may have to pay a price in one area to gain benefit in another area, and knowing this can help us build a better product overall.
5. Hide “how” with “what”
Encapsulation is a key aspect of software development, and can be defined as hiding the “how” with the “what”. In other words, encapsulate implementation details and present an interface that callers can use to ask for what they want without worrying about how they get it. This gives us the freedom to change implementation details later without breaking our callers.
6. Name things well
The first and most important documentation of any program is the software itself. Name entities and behaviors for what they do, not how they do it. Keep names meaningful and metaphors consistent. This makes software easy to understand and work with. Avoid abbreviations and acronyms, instead spell it out in CamelCase and don’t worry that it’s long, most IDEs have autocomplete so after you type it in the first time you only have to type the first few letters and pick it from a list. Make names descriptive, active, stated in the positive, and reflective of how the system is changed as a result of being called.
7. Keep code testable
Software that is not tested carries a great deal of risk, so testing is important. But beyond verifying that our code works we want to ensure it’s testable because testable code correlates to high quality code and poor quality code is hard to test. If you just focus on testability you’ll write high quality code and what better way to do this than by doing test-first development?
Software quality is not something that just happens, nor can it be created with heavyweight processes like Six-Sigma and Waterfall. Software quality comes from paying attention to the problems we’re addressing and how to model them accurately. This helps us get rid of redundancy by centralizing decisions, keep methods and classes focused, and put behavior in the right place. The result is a code base that is easier to maintain and extend.
Previous Post: « Seven Strategies for Splitting Stories
Next Post: Seven Strategies for Cleaner Code »