Sunday, November 27, 2005
What's in your build?
A basic build generally consists of clean, compile, and test. However, you can (and should) add more or tweak the build to make life easier and increase the quality of the code you produce. Most people _hate_ working on the build. Build languages are usually painful to work with and optimizing the build isn't very exciting. However, you should be running the build several times a day so each optimization can save you a lot of time over the life of the project.
There are other tools such as CheckStyle and FXCop that are supposed to be helpful. In theory they sound great; however, I've never used either so I didn't include either. Please let me know if you have any suggestions or optimizations I've missed.
- Separate Tests - Create unit tests that test specific responsibilities of individual classes. Create functional tests that test classes working together to achieve a larger goal.
- Database Generation - Use database scripts to generate the database during the build. Optimize the process by only dropping and adding tables, views, etc when the script(s) change. However, clear and reload the sample data on each build to ensure functional tests are hitting consistent data each build.
- Simian - Use Simian to ensure that duplicate code is not slipping into your code base.
- Code Coverage - I admit it, Code Coverage can be misleading. However, managers and business sponsors love charts with reassuring numbers. Additionally, if the team pays little attention to the code coverage number an interesting thing happens. No one attempts to trick the code coverage numbers and they become useful. When the numbers dip below tolerance the tech lead can use the warning to suggest to the team that more focus be given to testing. Note: The tech lead should never mention that the code coverage tool tipped him off or the team may start writing worthless tests that satisfy the code coverage tool, thus rendering it useless.
For .net use NCover (the version that fits your needs) or Clover.net, for Java I believe Clover is the most popular - Modification Compilation - Use a build language that can detect modification dates. Components of your application only need to be recompiled when changes are made to the source files.
There are other tools such as CheckStyle and FXCop that are supposed to be helpful. In theory they sound great; however, I've never used either so I didn't include either. Please let me know if you have any suggestions or optimizations I've missed.
Comments:
<< Home
Checkstyle sounds like a good idea, but my experience with it suggests that making it a part of the build causes more harm than good. For example, I found this gem:
number.substring(0, Integer.parseInt ("3")). Why?
Checkstyle was set up to report magic numbers > 2. The developer in question (a lead !) wanted his code to look clean.
number.substring(0, Integer.parseInt ("3")). Why?
Checkstyle was set up to report magic numbers > 2. The developer in question (a lead !) wanted his code to look clean.
I have used checkstyle to various success. I suppose that having it part of an overnight build might be more useful. Like code coverage, checkstyle can provide intersting metrics (cyclomatic complexity, excessive method lengths, etc). If taken with a grain of salt and embraced by the entire team, it can be a useful feedback mechanism.
It is also well written so that you can write custom checks to detect project-specific anti-patterns that you might want to warn people about
It is also well written so that you can write custom checks to detect project-specific anti-patterns that you might want to warn people about
John,
To be honest, we've had people do similar things and you know what we did? Hit the developer(s) around the head with a ClueByFour.
I think it's a bit of a stretch to blame the tool. For a start, there's no need to enforce the checks in the build.
Why not have the report run on each integration build so that you--as team lead or just nosey parker--can see what lovely turds are being laid in your source code?
Then you can go to the developer and begin the re-education process ala clockwork orange.
Cheers,
Simon
Post a Comment
To be honest, we've had people do similar things and you know what we did? Hit the developer(s) around the head with a ClueByFour.
I think it's a bit of a stretch to blame the tool. For a start, there's no need to enforce the checks in the build.
Why not have the report run on each integration build so that you--as team lead or just nosey parker--can see what lovely turds are being laid in your source code?
Then you can go to the developer and begin the re-education process ala clockwork orange.
Cheers,
Simon
<< Home
