Tech Tuesday – Minimising technical debt Agile style!
27 September 2016 |
About a 4 minute read
“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. …[Therefore,] making it easy to read makes it easier to write.”
Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
Have you ever looked at code with the attempt to extend functionality or add a new feature? Have you feared the never ending digging, breaking existing functionality, introducing further bugs? The only option left is to abandon the code altogether or add to the ever increasing pile and stench of technical debt?
I have! Many times…
The ‘elephant in the room’, usually begins with bold and sensible endeavors but more often than not ends in horrendous system meltdowns. Consequently, developers who over-engineer will only delay go live, hurt important customer relationships and waste the two most important company’s resources – time and money.
- Write self documenting code.
- Names of variables, functions and classes should be unambiguous, meaningful, and should express purpose.
- Two classes of a similar name will only confuse the reader and waste his or her time.
- Should be small and have only one responsibility (one reason to change).
- Using smaller classes enables better organisation and a more transparent code structure.
- Less is more.
- The fewer the number of arguments passed into a function, the better.
- Should be very small and single-minded.
- If you can extract another function of responsibility from it then it is clearly doing more than one thing!
- They should be loosely coupled and not rely on each other.
- In an ideal world self documenting code shouldn’t require comments.
- If you have to write a comment to explain what the code is actually doing, then you should consider re-writing your code to make it more understandable.
- No one likes clutter.
- For communication and to improve readability of code, formatting is key.
- Ensure your code is neat and consistent
- Adopts the language’s recommended indentation and alignment rules.
Example: Applying vertical openness by using blank lines to separate package declarations, the import statements and functions, can make a big difference visually as it separates the concepts and improves readability
- Testable code is a must.
- Having unit tests and good code coverage doesn’t solve all of your problems.
- Keep things simple and pay attention to the detail.
- Static code analysis is useful to check for dead code, unassigned variables and measuring code complexity. Tools include SonarQube, checkstyle, PMD and FindBugs
Example: Lets say you have an object that refers to or depends on another object – you then have to create both objects to just test the functionality of one of them! Too many dependencies can result in complex code that is hard to maintain and extend, let alone create test cases.
- Handle errors with style.
- Don’t clutter the caller with error codes – throw exceptions as they don’t obscure the logic. But don’t forget to create an informative error message to go with the exception, to provide context about the source and location of the error.
- Returning null creates extra work, and missing one null check can send an application spinning out of control – so instead of returning null, consider throwing an exceptions or returning a special case object
As a developer I spend more time reading code then actually writing, therefore I’m a huge advocate that applying clean code principles on a daily basis is a must!
Embracing clean code can only result in code of good quality; that is readable, maintainable, and extensible – the perfect concoction for maximising the lifespan of software and realising cost efficiencies for the business.
Tech Lead (Reading)
Bring your expert tech knowledge to the table to influence the direction of projects, whilst coaching and your team through engineering best practices.I'm Interested
DevOps Lead (Reading)
Bring your delivery expertise to the table, leading the pack as ambassador on operational requirements, influencing and continuous development.I'm Interested
Programme Lead (Edinburgh)
Bring your expert project knowledge to the table to own delivery of all our initiatives being delivered out of our Delivery Engine.I'm Interested