| As mentioned earlier, the best approach to troubleshooting ColdFusion problems (and indeed any development problems) is to prevent them from ever occurring in the first place. Bugs are inevitable. As the size of an application grows, so does the likelihood of a bug being introduced. As an application developer, you need to have two goals in mind: Develop 100 percent bug-free code. In the event that your code isn't 100 percent bug-free, make sure it's easy to debug.
As an application developer myself, I know that these are lofty goals. The reality of it is that application development almost always takes longer than planned, and sacrifices have to be made if release dates are to be met. Code quality is usually the first thing that gets sacrificed. Sooner or later these sacrifices will come back to haunt you. Then come the long debugging sessions, rapid code fixes, software upgrades, and possibly even data conversion. Then, because the rapidly patched code often introduces bugs of its own, the whole cycle starts again. Although there is no surefire way of preventing all bugs, some guidelines and coding practices can both help prevent many of them and make finding them easier when they do occur. Here are my 10 Commandments of ColdFusion Development: Plan Before You Code. We've all done it, and probably more than once. ColdFusion makes it so easy to start coding that you're often tempted to start projects by firing up an editor and creating CFM files. That's a bad thing indeed. Nothing is more harmful to your development efforts than failing to plan properly, and you should be spending more time planning than codingand I don't mean planning your IPO and subsequent retirement. Planning involves thinking through every aspect of your application, from database design to UI considerations, from resource management to schedules and deliverables, and from feature lists with implementation details to language and presentation. You'd never build a house without detailed blueprints (well, you might try, but you'd never get the necessary permits to start work), and building an application is no different. I'm constantly amazed by the number of applications I'm asked to look at that have no supporting documentation. And these aren't just from small development shops; I'm talking about some of the largest and most respected corporations. Scalability problems? I wouldn't doubt it. I'd actually be amazed if such an application ever did scale. You can't expect an application that grew in spite of its developers to scale. Nor can you expect it to be bug free, manageable, or delivered on time. Yes, I know that detailed planning takes time, time none of us have. But in the long run you'll come out ahead. Organize Your Application. An extension of planning your application is organizing it (along with any other applications). Applications are made up of lots of little bits and pieces, and keeping them organized is imperative. This includes directory structures and determining where common files should go, moving images to their own directory (or server), breaking long files into smaller, more manageable (and more reusable) ones, and even ensuring consistent organization among different applications. Going back to the prior commandment, Plan Before You Code, all organization should be documented in detail as part of that plan. Set Coding Standards. This is an interesting one, and one I get asked about often. Macromedia hasn't published formal recommendations on coding standards, nor in my opinion should they. Macromedia's job is to create killer tools and products for developers, and our job is to use them however works best for us. I don't believe that a single set of coding standards would work for all developers. At the same time, I don't believe any developer should be writing code that doesn't adhere to a standardany standard. Coding standards include everything from file-naming and directory-naming conventions to variable-naming conventions, to code organization and ordering within your source, to error handling, to componentization, and much more. For example, if all variables that contain dates begin with dt, for example, then references to a variable named dtOrderDate become self-explanatory. The purpose of coding standards is to ensure some level of consistency in your code. Whether it's to allow other developers to understand and work with your code, or simply so that you'll know what the heck you did (and why) six months down the line, coding standards provide a mechanism to create code that describes and explains itself. There is no right or wrong coding standard, as long as it is used. The only thing wrong about coding standards isn't using one. Comment Your Code. This is an obvious one, but apparently few of us have the time to pay attention to the obvious. So, I'll say it once again: All code must be commented. (For the record, I'd fire an employee on the spot for turning in code that wasn't commented; that's how serious an offense I believe this one to be.) Every source code file needs a descriptive header listing a description, the author information, the creation date, a chronological list of changes, any dependencies and assumptions, and any other relevant information. In addition, every conditional statement, every loop, every set of variable assignments, and every include or component reference must be commented with a simple statement explaining what is being done and why. It's a pain, I know. But the next time you (or anyone else) have to work with the code, you'll appreciate the effort immeasurably. And you might even be able to safely make code changes without breaking things in the process. Never Make Changes on a Live Server. This is another obvious one, but one worth stating anyway. All development and testing must occur on servers established for just that purpose. Yes, this means you'll need additional hardware, but the cost of a new box is nothing compared to the cost of bringing down your application because that little change wasn't as little as you expected. Write your code, test it, debug it as necessary, deploy it to a testing server, test it some more, and test it some more, and then finally deploy it to your live production server. And don't repeat this process too often. Instead of uploading slightly changed versions of your application every day, collect the changes, test them some more, and deploy them monthly, or weekly, or whenever works best for you. The key here is that your production server is sacred; don't touch it at all unless you have toand the less frequently, the better. And never, ever, make changes on live servers, even minor ones. Nothing is ever as minor and as isolated as it seems, and there is no change that is worth crashing a server over. Functionality First, Then Features. This is yet another obvious one, and a common beginner's mistake. Yes, writing fancy DHTML menu-generation code is far more fun that writing data-entry validation routines, but the latter is far more important to the success of your application. Concentrate on creating a complete working application; then pretty it up as necessary. Do so and increase the chance that you'll finish on schedule for a change. The final result might not be as cool as you'd like, but there is something to be said for an application that actually works, even an uncool one. Furthermore, (as explained in the next commandment) debugging logic problems is difficult when the code is cluttered with fancy formatting and features. Build and Test Incrementally. Testing and debugging complete applications is difficult. The bigger an application is, the more components are used, and the more developers working on a project, the harder debugging and testing anything is. When you develop core components of your application, test them. Write little test routines, hard-code, or smoke-and-mirror as necessary, but however you do it, do it. Every component you write must have its own test utility. Feel free to use unit testing tools or solutions if they help, or create your own. Obviously, you'll have to test your complete application when you're finished and some problems won't come to light until then, but the more you can test code blocks in isolation, the better. Never Reinvent the Wheel, and Plan Not To. This is one I have written about extensively. Write code with reuse in mind, and reuse code whenever possible. When designing your code, put in the extra time up front to ensure it isn't hard-coded or highly task specific unless it absolutely has to be. The benefits? Being able to reuse existing code shortens your development time. You stand a far greater chance of creating bug-free code when you use components that have already been used and tested. Plus, if you do make subsequent fixes and corrections, all code that uses the improved components benefit. This has a lot of benefits and no downside whatsoever. Use All the Tools at Your Disposal, Not Just ColdFusion. ColdFusion applications usually aren't stand-alone entities. They rely on database servers, mail servers, etc. In addition, ColdFusion can leverage Web Services, Java, COM, CORBA, C/C++ code, and more. Use these tools, as many as necessary, and always try to select the best one for a specific job. The best ColdFusion applications aren't the ones written purely in ColdFusion; they are the ones that leverage the best technologies for the job, all held together by ColdFusion. Implement Version Control and Source Code Tracking. Source code changes, and changes are dangerous. As your applications grow, so does the need for tracking changes and source code control. Select a version control package that works for you, and use it. Key features to look for are the ability to lock files (so no one else edits a file while you edit itif that does happen, someone's changes will be lost), the ability to view change history (what changed, by whom, and when), the ability to roll back complete applications (so that when the latest upgrade bombs you can easily roll back an entire application to a prior known state), the ability to create and check file dependencies (so you'll know what other code is affected by changes you make), and reporting. In addition, if you can integrate the product with Macromedia Dreamweaver, that's even better. The bottom line: I don't care which product you use, just use one.
Chapter 22, "Building Reusable Components," teaches the basics of code reuse and creating your own components. Chapter 38, "Development Methodologies," introduces several independent coding methodologies and standards, including the most popular one: Fusebox. |