Fortunately, making our systems testable pushes us toward a design where our classes are small and single purpose. It’s just easier to test classes that conform to the SRP. The more tests we write, the more we’ll continue to push toward things that are simpler to test. So making sure our system is fully testable helps us create better designs.
I have heard this point many times. I can't say I have ever written anything that is fully testable so I don't know if what the author is saying is true or not. I have seen where writing tests helped me simply my code so I am interested in trying what the author recommends. I saw this really interesting book(Growing Object-Oriented Software, Guided by Tests) on TDD recently. I am going to add it to my short list of books to read.
The majority of the cost of a software project is in long-term maintenance. In order to minimize the potential for defects as we introduce change, it’s critical for us to be able to understand what a system does. As systems become more complex, they take more and more time for a developer to understand, and there is an ever greater opportunity for a misunderstanding. Therefore, code should clearly express the intent of its author. The clearer the author can make the code, the less time others will have to spend understanding it. This will reduce defects and shrink the cost of maintenance.
I am really lucky that all the developers on our team understand this point really well. We are all passionate about refactoring our code. Even though we have mastered the "why", I feel like we are still in the early stages of knowing the "how" part of solving this problem. I am really excited though to see what we come up with. We definitely have a group of people that can solve this problem.
No comments:
Post a Comment