Microsoft has just released the latest CTP for their SQL Server 2008 suite of products. Grab your copy here:
http://www.microsoft.com/downloads/details.aspx?FamilyId=3BF4C5CA-B905-4EBC-8901-1D4C1D1DA884&displaylang=en
This CTP promises to have a lot more features implemented, including a more complete version of the Reporting Services standalone designer tool. The SSRS team has overhauled the UI and included the Office 2007's ribbon interface, making this a very sexy UI for end-users who wish to create reports in a ad-hoc fashion.
I'll be testing this CTP, and will try to post some of the new features on this blog as soon as I can, so stay "tuned".
Monday, November 19, 2007
Thursday, November 01, 2007
Thoughts on Code Analysis and Reviews
Code reviews can play an important part in the software development process. Static code analysis tools like FxCop and NDepend can do a great job of telling the developer what might be wrong with the code or any possible pressure points.
They can be customized to include most development standards and rules that a company has adopted, ranging from capitalization rules, all the way to thresholds for cyclomatic complexity (measure of how complex the code path is). Also, if your company uses a Continuous Integration (CI) approach to building and packaging software bits, then these tools can be integrated into the process to prevent code that doesn't meet the defined rules and standards from entering the build process, and possibly notifying the build manager and developer.
These tools can be more unforgiving, especially if you're not totally familiar with the errors it is "taught" to catch, whether in logic flow or in design patterns. That's why a "manual" or personal code-review can be extremely valuable when used in tandem with these tools.
In a lot of companies that perform regular code reviews, these sessions become a finger-pointing, frustrating experience for most people. Usually the managers will bring dev team into a room with a projector and some pizza, and will start pulling up random code to be reviewed by all on the big screen. Some people may find some of the criticism to their work offensive, and it can become very destructive to the team.
A better approach that I have seen is to teach the developers to send a review request of their code to a peer/co-worker directly via email. This usually leads to one or both of two things:
(A) the developers can learn something new or improved in a non-demeaning way, or
(B) they may become personal heroes, since by looking at someone's code during a review, peers may find a solution to another problem they may have been trying to address.
I would recommend implementing manual/personal code reviews as a team-building exercise, as well as to promote better coding practices among the dev team. And then introduce static code analysis with TFS/FxCop, NDepend, etc., as part of the source code check-in process, and/or during the build process.
Catching bad code or errors early on in the dev process costs a lot less than later on after the software has been built and/or possibly released.
They can be customized to include most development standards and rules that a company has adopted, ranging from capitalization rules, all the way to thresholds for cyclomatic complexity (measure of how complex the code path is). Also, if your company uses a Continuous Integration (CI) approach to building and packaging software bits, then these tools can be integrated into the process to prevent code that doesn't meet the defined rules and standards from entering the build process, and possibly notifying the build manager and developer.
These tools can be more unforgiving, especially if you're not totally familiar with the errors it is "taught" to catch, whether in logic flow or in design patterns. That's why a "manual" or personal code-review can be extremely valuable when used in tandem with these tools.
In a lot of companies that perform regular code reviews, these sessions become a finger-pointing, frustrating experience for most people. Usually the managers will bring dev team into a room with a projector and some pizza, and will start pulling up random code to be reviewed by all on the big screen. Some people may find some of the criticism to their work offensive, and it can become very destructive to the team.
A better approach that I have seen is to teach the developers to send a review request of their code to a peer/co-worker directly via email. This usually leads to one or both of two things:
(A) the developers can learn something new or improved in a non-demeaning way, or
(B) they may become personal heroes, since by looking at someone's code during a review, peers may find a solution to another problem they may have been trying to address.
I would recommend implementing manual/personal code reviews as a team-building exercise, as well as to promote better coding practices among the dev team. And then introduce static code analysis with TFS/FxCop, NDepend, etc., as part of the source code check-in process, and/or during the build process.
Catching bad code or errors early on in the dev process costs a lot less than later on after the software has been built and/or possibly released.
Subscribe to:
Posts (Atom)