Since my last post, I have been quite busy using my new found knowledge. For the last two months I have been busy working on the project that prompted my company to send me to the ASP .Net training. The developer I had the pleasure of working with is very knowledgeable. He used to work for Microsoft as one of the developers responsible for Windows XP and Windows Server 2003. He was one of those developers that I have Hal Helms mention. One who listens to your ideas with interest even though they are often, simplistic or incorrect. He never once made me feel foolish, but rather guided me to the correct solution while educating me as to why it was correct. This experience, for which I am very grateful, has prompted a couple of changes to the way I develop ColdFusion applications. For many developers, these ideas will be nothing new, perhaps even common sense. But for me it was as if a light bulb had finally turned on.
For large, scalable applications, OO is a must.
I have been using CFCs since they were introduced to ColdFusion because it is good practice to separate the database interaction from the business logic. For convenience sake, I use session scope structures as property holders or pseudo beans, but they lack encapsulation. When it came to OO however, I have lacked the conviction that comes from experience. Plus I work for a company with several other developers that have no experience with OO development and no desire to learn it. So I have been asked to keep my code simple so others are able to maintain it. Frequently I find myself thinking, if maintenance is a concern, wouldn't it make sense to foster OO development? It is clear now, after joining a project that was well under way and being expected to get up to speed quickly that without OO this can be very challenging. The project was coded in C# and it's almost impossible to write good C# code without using OO principles so it was very easy to figure out what was happening by examining the classes and structure. Using OO principles helps to organize the structure of the code, but mostly, it becomes very easy to see what is happening and how it is being done. Then if modifications or updates are needed, it is much more clear where to make the changes. Currently I have a couple of personal ColdFusion based projects that I have started and will be relying on OO principles to guide their development.
Unit testing is not optional.
I have never heard a customer say, “You know Mike, although it fulfills the specifications, this application does more than we need it to. We would like to scale it back, remove some of our features. Can you do that for us?” However I have heard those six most dreaded words, “You know what would be nice?” The customer then lists features that were not included on the specifications. Often, these tasks are ones they never have been able to do before (manually or otherwise), but now seems to be critical to the success of their business. In the past I have had to modify the code, test it by performing most operations that are performed by the customer, fixing errors along the way. It would then be released to the customer with the caution that a bug or two may present itself and to please call. I have never liked doing this because I don't feel it helps to inspire confidence in the reliability of the software or the developer.
The time I spent on the ASP .Net project was largely writing unit tests for the classes. The fact that nearly two moths were spent writing unit tests should be an indication as to the size of the project (learning curve aside). The level of reliability that was required for this project combined with the short cycle time expected for modifications, new features, and updates would have been impossible with out unit test suites. This allowed us to make changes, run the test, fix the issues and release with the confidence that the application would perform as expected. Should a bug be reported, we would write a unit test that would mimic the error and modify the code to fix it. We would then rerun the unit test suite to make sure no other errors were introduced. In other words, unit tests shorten turn around time, insure that specifications are still being met and increase confidence in the software and the developer.
Other changes in the way I approach and develop projects may be coming. For now, these are the two most immediate and significant. In the meantime, I am spending time reading how others have applied OO development principles to ColdFusion.