Results 1 to 25 of 42
Thread: Best practices?
Oct 21, 2003, 17:58 #1
- Join Date
- Apr 2003
- 2 Post(s)
- 0 Thread(s)
The main project I am working on has been running in it's present form for about two years. Because of this the development practices have reached a fair level of maturity/stagnation (delete as appropriate). I thought it might be time to review the types of things that we do and to say a few words on those we have found useful.
1) Version control. Essential. We curently use CVS with tagged releases, but don't branch as the overhead for a small team doesn't seem worth it. We are looking at Sub-version at last. Waiting for an RPM install and mature CVS porting script before we risk the changeover.
2) Scripted roll-out. Really nice. Originally just a way of keeping track of all the dependencies and libraries, this has grown to doing a roll-back if the tests fail. This means that failing test code should never go out and makes roll-outs more frequent and less of a trauma.
3) Iterations. Our only management. Originally just a chunk of work with a measured "velocity" this is now planned as fixed two week intervals. The fixed interval makes us more willing to schedule refactoring work. We were a bit too goal oriented before.
4) Shared code ownership. Essential. Anyone is allowed to edit anything and solve any problem.
5) Unit testing. Essential. Allows us to refactor at will and is the enabler for shared ownership. Coding test first is universally preferred now.
5) Stand up design sessions. Desirable. Gets all heads working on a problem. First choice is a whiteboard, second RRC cards and third UML. We should do this more often as we seem to inflict a lot of refactoring on ourselves due to coding too early.
6) UML. For reference. Most of our diagrams are out of date, but we update them when starting something we haven't worked on for a while. They give us a clear starting point. This is our main top level documentation and is about two dozen diagrams in all. Our tool of choice is Dia.
7) Refactoring. Constant. We expect to get things wrong and almost every iteration involves a refactoring task due to an issue raised/created in an earlier iteration. It is good to make time for this beyond doing it while you code.
8) Pair programming. Do this on about 60% of code. We have a small office and so are sharing desks anyway. We are all willing converts to this way of doing things though. Quality rises sharply and productivity is pretty much the same as two individuals.
9) Scripted server set-up. Insufficient. We can build a server with a single script (MySQL, Perl modules, Apache, the lot) in one go, but it just doesn't work for updating them. Investigating an RPM solution, possibly using Ximian's Red Carpet or a modified Apt-RPM tool.
10) Code docs. Marginal. We had a home brew comment parser that is just too slow. As a result it doesn't get used. We have for ever been mindlessly creating the comment blocks ever since. We are going to try PhpDocumentor after porting the comment syntax, but I would be happy to delete the lot.
11) Four day week. For sanity. Pairing is hard work, much more so than working alone. Much more than 35 hours of it and you are completely exhausted. It also means that the developers have time to do pet projects and investigate new ideas.
So how do you do things?