All Posts

Small class size is good for software too ?

SRP is likely the most important aspect of clean coding. Bloated classes are difficult to test, hard to understand, difficult to debug, and hard to maintain. The well noted definition of SRP is worth repeating here; a class should have one reason to change. Having a class do only one conceptual thing provides a multitude of benefits.

Single responsibility keeps a class focused and much easier to understand and debug. After all, it has only one thing to do. New functionality should be added via new classes, not adding to existing ones. This can be thought of as separation of concerns as well.

Keeping SRP at the forefront of your coding approach will have far reaching benefits.

Better Design = Fewer Bugs

Bugs love places to hide. This is true for software bugs as well. Likely the single best deterrent of software bugs is clean code design.

Likely bug injection points include:

  1. Incorrect or failed processing of certain test cases.
  2. Incorrect or failed processing for null test cases.
  3. Adding new or changing functionality.
  4. Failure to validate input data or to maintain data integrity.
  5. Failure to follow SRP.

Real Time Refactoring

Code refactoring is essential as software systems are used and improved upon. New requirements, use cases, and technologies will invariably force a development team to refactor applications and components in order to meet the goals of performance, maintainability, test-ability, separation of concerns, and so on.

But how do we as developers plan for this? Do we set aside dedicated time just for refactoring? Do we sneak it in along with our ongoing projects? Either approach can work. If it becomes apparent that upcoming large projects require existing code to be refactored, it’s best to plan to complete the refactoring prior to the project kickoff. Otherwise, if the desired refactoring is small, it can usually be accomplished in stream of ongoing projects.

When you don’t have time for unit tests

When a development project is under strict time constraints, one of the first things I hear is, “I don’t have time to write any tests.” Or, “i’ll write some tests at the end, if I have time.” The presumption here is that automated tests are not critical or foundational or key to well designed code, clean code, good architecture, functional verification, etc. The presumption is that auto tests are “extra”, nice to have, and great if you have the spare time.

The basic flaw with this approach is that you have no way verifying the design OR the functionality of your code. You have no guardrails. Tests force you to design for SRP. Tests allow you to quickly confirm the functionality of the code against multiple test cases simultaneously during development. Tests functionally document your code to everyone else. Tests provide regression confirmation as new code is added, new functionality is added, bugs are fixed, requirements change, etc.