This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
We have difficulties to keep our "patterns based code" clean.
We started of well, applying the patterns we selected in our code.
But after some iterations, overhauls, hand-overs and change of implementation partners, things blurred.
Looking for advise on how to properly manage a pattern catalog and the code based upon them, and how to take care that our codebase keeps adhering to our patterns.
I have faced similar issue on the projects I have been working on. Something I realized is "A stitch in time saves nine". This applies to most situations and the sooner the project is re-factored, so much easier things become. With each "iterations, overhauls, hand-overs and change of implementation partners" the more "blurred" things are going to get. In the end you have one humongous project/code-base that is harder to upgrade, maintain ...... I agree re-factoring is going to take a good amount of time but with each passing moment the process is not going to get any easier and on the contrary it will get all the more harder and harder. Weigh all aspects like how long is the project going to be around for, what technologies may it move on to, is the development phase over etc.
A first step is to recognize that there's an issue. And it sounds like you've identified a couple of issues:
1. How do I ensure that my pattern catalog is up to date?
2. How do I keep my code base in synch with my patterns? (While recognizing that both the code and the patterns can change)
For the first, we can think about how we manage the pattern catalog. Is there a review process in place for the pattern? Is there a centralized place that patterns are stored? How are updates to the patterns managed? How is information about updates communicated to the organization? As we make plans for maintaining or updating software that uses patterns, are we accounting for effort associated with updating code associated with the pattern?
For the second issue, a good place to start is to think about the role that automation can play. We can look to use automation in the form of a pattern implementation to generate a solution based on a pattern. In such cases, if the pattern is updated, we can reapply the pattern and synchronize. In cases, where someone has modified the code and deviated from the pattern, we have the option of reapplying the pattern and bringing the solution back into alignment with the pattern. However, the situation may be more complex and we need to first determine whether the pattern needs to be updated, the solution needs to be brought back into alignment, or if the two will remain different and we need to decide if we have a new pattern or a unique and isolated solution.
Another role for automation is pattern detection. Some development environments have the capability to analyze and code base and can recognize the application of a pattern. We can use these capabilities to see and confirm that patterns have been applied and then confirm adherence to the pattern definition.
Moving beyond automation, we can look to traditional approaches such as design and code reviews to further assist us in catching solutions that drift from patterns.
Our solutions and associated code are not static over time. The initial release of the solution may indeed be true to the pattern. However, software often lives much longer than expected, and is updated many times over that lifespan. At any point in time, there are a few reasons as to why there is a divergence between a pattern and how that pattern is represented in a solution:
1. The pattern was not applied correctly.
2. The pattern was applied correctly, but was "enhanced"
3. The solution itself evolves over time, addressing defects, changes in requirements, etc. The updates in the code have led to changes in the solution.