Principles and Patterns over Tools and Frameworks
It’s interesting to see what other developers value and/or what topics they are interested in regarding the development of software. I’m going to start doing some internal presentations and live coding sessions at my company for my fellow consultants. I’ve got a pretty long list of possible topics, but I offered up 2 topics today that pertain to some of the work I’m doing on my current project.
- Examples of how to apply some of the core OO principles (i.e. SRP, OCP) in a real world application and some of the patterns that complement them (i.e. Decorator, Proxy, CoR).
- Writing automated web tests using WatiN </ol> Guess which one got the most response? If you guessed #1, you must be working with folks who are passionate about writing clean, maintainable code, regardless of the technology. Consider yourself blessed. As for the rest of us, I’d venture to say #2 would usually be the most “popular” choice among developers. At least that’s the response I’ve received so far.
Of course, learning (and showing) a new automated web testing tool is very cool and can be very useful. I really like the Watix line of web testing frameworks.
But I see much more value in learning how to adhere to some of [“uncle Bob’s” OOD principles](http://www.mattberther.com/2006/10/25/principles-of-ood/) (Robert Martin’s site seems to be down, so that link is from Matt Berther) and how patterns can help us along the way. I see so many bugs that pop up in existing systems that would be so much easier to find and fix if just SRP alone was applied at some level in the code base. And even more likely, many of those bugs probably wouldn’t have existed in the first place. **My recent experience has proven (once again) that the violation of SRP along with code duplication makes a fertile ground for those little “buggers” to grow.**
<SRP tangent>
More and more, when folks ask me why I coded something a certain way, SRP has most likely influenced my decision. I think SRP is one of the most important principles that developers should be applying when they are implementing new features and/or refactoring an existing code base. The principle itself is very easy to learn. **Code should only do one thing.** This can be applied as high up as the logical layer level all the way down to a single line of code. How far you take it is answered in the usual “it depends” response. The difficulty in applying this principle, on the other hand, can vary greatly depending on the code base and the comfort level of the team with other OO principles and the patterns that support them.
</SRP tangent>
Ok, I’m back. So it sounds like I’m going to be doing the WatiN session first, but you better believe I’m going to be stressing the importance of writing good, clean code even for automated web tests. They’re not going to get off that easy. 🙂