MaintainableDesign

"is an easily maintainable design and implementation."

"The reward for work well done is the opportunity to do more." - Jonas Salk

Probably still one of the most overlooked areas in our designs. Will the code be easily maintainable? Will a business requirement later be trivial to implement within the code, months later. Will the developer, or a new developer be able to maintain the code just as easily?

A maintainable design:
  • Balances a minimal design with a maintainable design
  • Is one where the design categorizes enough implementation detail so that it separates code. The more separate parts, the smaller those parts will be. But there is a sweet spot for each solution. You need to be granular, but too granular and you will have conflicted with MinimalDesign.
  • Reduces code complexity
    • Complexity of code comes from the ‘distinguishing of objects’
    • High maintenance of code increases with the number of distinct objects, but low maintenance does not necessarily come from less distinct objects



    Intent

    We need to have code, maintainable throughout development cycles. Code can become complex and difficult quickly, and having an agile system, is partly because we can change it quickly.



    Motivation

    Changing code for new requirements or a bug fix, can be done with dynamic code (ExtensibleDesign and AgileDesign) and also with static methods such as physically changing the code files. This kind of change, should be made as easy as possible.



    Solution

    The solution to having quicker turnarounds on bug fixes, reducing time it takes for code to be understood and to avoid confusion in code regarding methods and classes, and perhaps the intent of those, we need to make code maintainable.

    Review

    As in MinimalDesign, code reviewing is a good way of having someone help you make code maintainable. A code reviewer can be a peer and/or an official process, but this principle is purely to say that code reviewing, if done correctly can be helpful.

    Conventions, Standards and Patterns

    It is much easier to read complex code, if it contains elements you are familiar with. Having the same variable prefixes, the same standards, you already begin to make things more understandable if you are familiar with the standard. A company with maintainable code will always have coding standards, but rarely does unmaintainable code come from having coding standards.

    Design Patterns can dramatically increase maintainability if all developers in a team understand it. Having developers on the same page is always good practice and Design Patterns can be a facilitator.

    Applicable Patterns

    Factory Method (GoF)
    Builder (GoF)
    Template Method
    Proxy (GoF)
    Chain of Responsibility (GoF)
    Visitor (GoF)
    Creator (Grasp) The Single Responsibility Principle (SOLID)
    The Open Closed Principle (SOLID)
    Develop Overall Model (FDD)
    Build Feature List (FDD)
    Design By Feature (br/>

    Conflicts
    ReachableDesign
    Compliments
    MinimalDesign, AgileDesign, ReachableDesign, ExtensibleDesign
    Ammerse Principles