Jeremy outlines the basic principles on writing a maintainable code in much more details that I would.
The principal points are:
- software change is inevitable
- planning change with the extensibility points is mediocre
- separation of concerns (see my previous post on decomposition)
The best ready-to-instant-use thing is Maintainable Code Checklist, which I copy here verbatim:
Question Yes comes from… Can I find the code related to the problem or the requested change? Good Naming, High Cohesion, Single Responsibility Principle, Separation of Concerns Can I understand the code? Good Naming, Composed Method, The Principle of Least Surprise, Can You See The Flow of the Code?, Encapsulation Is it easy to change the code? Don't Repeat Yourself, Wormhole Anti-Pattern, Open Closed Principle Can I quickly verify my changes in isolation? Loose Coupling, High Cohesion, Testability Can I make the change with a low risk of breaking existing features? Loose Coupling, High Cohesion, Open Closed Principle, Testability Will I know if and why something is broken? Fail Fast
Leave a Reply
You must be logged in to post a comment.