Well, I wanted to avoid analogies to architecture and buildings, but this seems like such a good place for one, but, I'm sure you can figure out the rest of what I can say! So why say it? Well, sometimes it's important to pour a thought down on paper so it becomes a bit more concrete (no pun intended). If you only have wrappers, your team (or just you) is left to build the application in whatever way their experiences (or lack thereof) have taught them. In the end (if you even get to the end), you've got a collection of different styles, approaches, and solutions that have no consistency. This is hard to debug, hard to maintain, and hard to extend. And you when you're done, you almost certainly don't want to repeat the experience. A framework that enforces a methodology, on the other hand, tells each programmer how to do important things like interface with other objects/components/technologies, how to manage and persist data, and how to avoid crossing application layers (as examples). The resulting application is easy to debug, easy to maintain, and very flexible.
Code Reviews
Code reviews are fine, but they're misapplied if you use them to fix coding consistency issues. It's like health--you want to be proactive in preventing disease (dis-ease, ha ha ha), rather than taking a handful of pills after you get sick. So, code reviews should be used to prevent sickness rather than to cure a sick implementation. This means, a code review should always look at whether the framework methodology is being applied properly, is itself appropriate, and that the code is, in other ways, handling its requirements correctly.
Unit Testing
If your methodology includes unit testing (and thus a framework to support this methodology), the issue of meeting requirements becomes preventative--the unit tests prevent the code from becoming sick in the first place. However, unit tests can be a lot like the new age idea of using magnets to cure arthritis--they can be quite useless. And I'm not going to write about good unit tests here--you can read my articles on unit testing if you're interested.
Agile Methods
OK, touchy subject with very opinionated people in all camps. So, I'm going to skirt around the issue and say only that agile methods talk about how to manage a project more than they talk about how to design the objects or implement the actual code. This is why they're not much help, in my opinion. What I've found is that just about every job, customer, or article requires a unique approach. There is no cookie-cutter method for working with a customer, figuring out what the application needs to do, and managing the process of implementation. There is, however, considerable re-use achievable in how each application is designed, and the framework and wrappers that are used to reduce implementation time. Agile methods on the other hand are really good as ideas you can use to work with the customer or other people in the company.
What About Creativity?
This argument (which, believe it or not, I've heard many times) holds no water for me. A two year old can be creative with paint and a canvas, but you won't get the Mona Lisa. An trained artist uses a method which allows him to channel his creative forces into creating his work within the confines of the chosen method. Even Jackson Pollock had a method to his paintings, although they do look a bit like what a two year old would do. The point is, a good methodology actually frees you from the mundane task of figuring out basic things, so you can apply your creativity in better user interface design, better performing functions, smoother user experience by using threads, etc. The result is something aesthetically pleasing to the user. As a programmer, I can immediately tell you when a product did not have a good framework methodology because it is clunky, clumsy, rough in performance, and most likely, buggy (and the biggest indicator of all--it got delivered a year later than promised). Are you listening, Microsoft?
An Example: The Document-View Architecture
What would it take for the document-view architecture to be a true framework? In my opinion, this would require an automatic coupling between GUI controls and the document. The programmer need only specify issues such as data lifetime, the control representing the data, and the document (or documents!) containing the data. The framework would then handle all persistence issues, data translation between the representation of data in the document and the representation of the data in the view, and would do so without requiring any coding. A document-view implementation at this level wraps data translation, provides an architecture for coupling data with documents, and enforces a methodology by implementing and hiding the coupling between the GUI control and the document.
What Does The Rest Of The World Say?
A framework is a set of common and prefabricated software building blocks that programmers can use, extend or customize for specific computing solutions. With frameworks developers do not have to start from scratch each time they write an application. Frameworks are built from collection of objects so both the design and code of the framework may be reused. - JavaFramework.
A skeleton of an application into which developers plug in their code and provides most of the common functionality. -- E. Gamma, et al., "Design Patterns", Addison-Wesley, 1995
Well, now that's a radically different definition, and in my thinking certainly incorporates the idea of a methodology, if for no other reason than because the "skeleton" has to define how developers plug in their code and how they interface with the common functionality provided by the "skeleton". Implied here (but not necessarily) may also be how the code intercommunicates.
No comments:
Post a Comment