chapter nine

9 Modularity for ML: writing testable and legible code

 

This chapter covers

  • Understanding the dangers associated with monolithic prototype scripts being used for a basis of production code.
  • Identifying difficult-to-test code in large, tightly coupled code bases and understanding the risks to maintainability in the process of debugging them.
  • Learning effective encapsulation and abstraction techniques for ML code bases to reduce complexity and increase testability.
  • Introducing test-driven development for ML to aid in both testing of discrete functionality and in maintainable code architecture.

There are precious few greater soul-crushing emotions than those that are forced upon you when you read a mountain of unintelligible code after being told that you are responsible for fixing, updating, and supporting. The only more demoralizing situation is if you were the one who birthed that code into the world. This isn’t to state that the code doesn’t work. It may run perfectly fine. The fact that code runs isn’t the issue. It’s that a human can’t easily figure out how (or, more disastrously, why) it works.

I believe this very problem was most eloquently put in this quote:

Martin Fowler, 2008

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

9.1       Monolithic scripts and why they are bad 

9.1.1   How monoliths come into being

9.1.2   Walls of text

9.1.3   Considerations for monolithic scripts

9.2       Debugging walls of text

9.3       Modular ML code design

9.4       Test driven development for ML

9.5       Summary