1 – Source Control
Source control benefits every make of developer, from a 1 person shop, small teams, to giant software teams at Google and Microsoft. Developers check out to their local machines, develop, run thru test cases, and finally check in. For 1 this improves quality, developers are less liking to consciously check in buggy code to central repository.
- The advantages of version control:
- Backup of code, its on the developers local machine and on the server
- History of changes, who changed what
- File Difference, what changed
- Library of classes and functions
2 – Test Cases
To make some simple test cases think…What is the web suppose to do? Right down the steps on paper or even dare buy test case management software. The great thing about well written test cases is that anyone can run thru them. I’ve given my wife (who is not so techy) test cases and had her find functionality that had been broken during development. In team environments test cases are essential. Most regression bugs I have seen are caused by developers not being aware of changes to the source code can effect source code else in the code i.e. function parameters changing.
3 – Bug Tracking System / Feature Tracking System
All developers write code that have bugs in it, because developers can’t image all the way end users will break their applications. It happens, and the one thing that will kill the success of a web application is bugs. Web applications are expected to have less bugs then desktop software. For desktop software, clients have to come install new software, make sure proper privileges are set up on the machine, reboot, and so on. Because Web applications are able to be pushed live to a server (or cluster) and bug fixes automatically show up, web applications bugs are easier push out and therefore should be less buggy.
What your bug tracking software must have:
- Integrate with your source control so you can tie bugs with code changes and vice versa
- Allow end users to submit bugs and features that are automatically put in the system
- Workflow, who determines what is a bug, how does this system flow for features. Workflows are great.
- Defect Linking, this bug caused that bug
- What your bug tracking should have:
- IDE Integration, it’s sure nice not to leave your IDE to fix a bug
- Customize, can you change label, add columns
- Release Notes, your system should be able to give you a nice report of what got fixed in version 8.1
- Estimate in hours/ minutes how long bug fixes will take
- LDAP Integration, the more single sign on, the better
- API or SOAP Support, nothing ever does exactly what you want, you can customize thru these
- What your bug tracking software would be nice to have:
- Email notifications
- RSS Bug Feeds
- Running Comments
- Reports, great when doing performance reviews
3 – Staging Environment that mirrors Production Environment
In the .NET world this is pretty easy to do. I don’t believe you can get different versions of .NET 2.0 or MS SQL 2005. However, make sure all patches that applied to the production box make their way to stage. In the LAMP world this is a bigger concern. I’ve seen numerous times where a stage machine will have a different config of php.ini then production. “You mean global variables are turned off?“
4 – Refractor Code Regularly
The question is if you didn’t have bugs would you refactor code at all? The answer should be yes. Writing code is like shooting basketballs. The more you do it the better you get. I look at code I wrote 5 years ago and cringe. This doesn’t mean you keep making code more and more abstract cause that can kill maintainability. Joel’s article about JAVA should really be about code refactoring.
5 – Wiki it
Wiki rocks for web application development documentation. They are great place to cover yourself based on the hit by bus theory.
- Versions Itself
- Great for Lessons Learned
- Discussions, open model for improving software