DEV Community

Discussion on: Clean Code, bullshit or common sense?

Collapse
 
610yesnolovely profile image
Harvey Thompson

When faced with a huge messy code base: I adopt the "one test is better than none" philosophy.

  1. If there is no testing framework, take time to add one and make it part of the build process.
  2. Then write a test for the code you are changing and/or the bug you are fixing.
  3. Repeat 2.

This achieves a few things at a fairly low cost:
a) Your code/bug fix should never regress.
b) People may join in your effort as they see the benefit.
c) You may get manager approval and time to write more comprehensive system tests when they see the benefit.

As an example, after doing this for several months an "old-dog-don't-teach-me-new-tricks" started adding tests. A few years later he told me that he could no longer code without writing tests. The system I was working on went from zero tests and no testing framework to 150 tests or so in a few months, and the managers started to brag about how many tests passed and wanted metrics on failures and ... yeah... watch out... you may start a dangerous revolution.

Collapse
 
fefas profile image
Felipe Martins

Hey Harvey!

This result you achieved seems to have been great! Congrats for making business to have interest in test metrics! :)

Depending on the legacy code base, it can be really challenging. An old boss of mine said once, that working with legacy is like trying to untangle a mess of cables.. you have to identify the next and do it one by one.

Anyway, there is no magic solution to solve it. That made me remember the section "The Grand Redesign in the Sky" of the Clean Code book:

"[after redesign the whole system,] the current members are demanding that the new system be redesigned because it’s such a mess."

In other words: re-write the system is no guarantee to have a better system.