Day 24 of #100DaysOfCode

System Design that only gets better with Time

Learn how making Testability a priority helps you write better code #CleanCode

Photo by Erik Witsoe on Unsplash

Kent Beck gave four rules to Simple Design which can be used to make well-designed Softwares. He said a software design is simple if it follows these four rules.

1. Run All Tests
2. Contains no duplication
3. Express the intent of Programmer
4. Minimizes the number of Classes and Methods

Testability Should Be Your Priority

Your design must produce a system that acts as intended and everything might work out on paper, but if there is no way to verify that system actually works, then all the efforts made go waste.

A system that cannot be verified cannot be validated and hence shouldn’t be deployed. When you are giving emphasis on testing your system, you would be striving for smaller, single-purpose classes.

The more tests we write, the more we will push towards testable code. Tight coupling is harder to test, Dependency Injection helps makes our codebase more testable, we implement abstractions using Interfaces which help improve our code over time.

Hence, making sure our system is fully testable helps us create better systems over-time.

Introspect • Refactor • Repeat

Now you understand how keeping tests helps us strive for better quality code. Hence every time you add some new piece of code, take some time and reflect how your new code impacts the overall codebase. If it’s not clean, take out time to clean it up.

After your refactoring/cleaning, don’t be afraid that you might have broken something. The fear of refactoring your code might break something goes away as you have tests ready to just run and pinpoint any mistakes.

While you are refactoring, this is your time to show off all the knowledge you have to write

• Expressive
• Modularized
• Abstracted
• High-cohesion
• Loosely-coupled
• Good variable names
• Shrink functions and classes
• Break your functions
• Eliminate duplication
• Eliminate unnecessary code and classes

Some points to always remember if you ‘don’t feel like’ cleaning up:

• Duplicate code is your primary enemy, why spend double the time writing it, refactoring it, testing it, maintaining it? Remove code duplication even at the smallest level!
• To look out for violations of the Single Responsibility Principle, see if a refactored method requires to be shifted to a new/existing class.
• When you are writing your code, you are in a deep understanding of the problem statement, and others who might be maintaining this code in the future might not have the same understanding of the problem. Even you after some time might not have the deep understanding of the problem.

Hence writing code that is easily readable and understandable by others, code which clearly explains the intent of the author will always turn out as a huge return on investment.

The majority cost of a Software project is in the long term maintenance, and in order to minimize the potential for defects as we introduce changes, the reader should clearly understand the intent of the code.

The reader must never be tempted to make any improvements in your code as they might risk breaking more things and hence prolonging the maintenance time and expenses.

Use standard naming conventions like Repository, Adapter, ViewModel and others from popular Design Patterns of your domain, as a suffix to your class names to easily convey what those classes are for.

A nicely written unit test cases act as Documentation by Example. Reading tests should boost somebody’s understanding of our code.

Care is a precious resource. Care for your code.

Thanks for reading, you are breathtaking!