The .Net Code Review Ecosystem
.Net code review tools have been improving over recent years and removing some of the traditional necessity of code review, but not the most valuable aspect. There are static analysis tools like FxCop to automatically review for all the code-deterministic industry standard guidance. There are source analysis tools like Microsoft’s recently released Source Analysis (a.k.a. StyleCop) to review all the source code style choices made. With Continuous Integration and TDD code is reviewed to make sure it builds and meets the expected business scenarios. Products like NDepend have been recently introduced to review code and provide statistical information to help determine if designs are following principles that lead to sustainability. All of these types of tools augment the ecosystem in which we review our software. However, none of them provide any help in one of the most critical aspects of code review - the answer to the question “does this code deliver the best value for the business domain?” Just because code passes FxCop, StyleCop, looks good in NDepend and passes automated tests doesn’t mean it provides the best business value. Those tools are part of a domainless code review ecosystem, they don’t have any insight into any of the businesses we create software for or how well our code serves that domain. The answer to the “best value” question is in some ways subjective, but the most capable people to provide the answer are the coders in that domain using the tacit technical and business knowledge that only they retain. Code reviews are the way to apply and share that tacit knowledge and find the answer to the “best value” question.
Traditional Code Review Style
Traditional code reviews are conversational in style. One person asks for a review and they get any number of responses from any number of people. Each response is usually recorded in note style indicating where the code is, what it’s doing, and how to make it better. There are a lot of transitions in the traditional process; for example transitions of people to and from meetings, transitions in and out of the code to a note taking, reading, or explanation system, transitions from reviewing developer to developer representative to requesting developer and back, etc. In each transition there is waste in the cost of the transition and waste in intent and accuracy lost during the transition.
TeamReview
TeamReview uses Team System and VS.Net’s extensibility features to retain the conversational style of code reviews without the transition waste. With TeamReview team members have the ability to provide their code review feedback without transitioning out of the IDE. That response subsequently becomes directly available to the requester also without transitioning out of the IDE. Code Review feedback is given by highlighting a chunk of code, choosing the “New Code Review Response” option of the TeamReview menu, entering a few fields, and assigning it to another team member. [1] [2] When the requester is ready to review and implement feedback they choose the “Replay Code Review” option of the TeamReview menu, which displays a grid of all the feedback in a new window in the IDE. [3] Clicking on any of the grid rows will open the local copy of the code file and highlight the snippet of reviewed code putting the developer at the exact place where changes are suggested with all the information necessary to act on that suggestion. [4]
The beauty behind this process is that submitting feedback with TeamReview creates a new work item in the Team System project that includes the entered feedback, highlighted code, file name, line numbers, and names of the Project, Namespace, Type, and code member such as the method or property name. [5] The work item is a new work item type, Code Review Response, that is shipped as part of the TeamReview download. [6] [7] As you might have guessed reviewing and acting upon responses with TeamReview’s “Code Review Replay” option is implemented behind the scenes by TeamReview running a TFS query for those items and then displaying them in a grid, followed by using Vs.Net extensibility model to handle select and click events.
Since the review process and the details of the code within that process are stored in Work Items not only do you gain the standard project management capabilities that come with work items you also have the ability to perform code review forensics. For example a query for code review responses that are in an open state is easily added to the Team Queries of the TFS project. Another query could find code projects, namespaces, types, or members that traditionally get the most code review feedback indicating a trend that they may need to be refactored. Another query could find all code review responses for a particular Type to get suggestions about that type’s responsibility and design intent if that type was being redesigned, re-used or extended. A report could determine the lag time between feedback being supplied and being implemented by comparing the work item creation and closed dates.
Conclusion
TeamReview exploits the advantages of Team System and the Vs.net extensibility model to reduce transition waste and surface new value from the code review process. Using Work Items to facilitate the code review process creates a completely in-IDE code review experience, the ability to project-manage the code review tasks, and the opportunity to get new value from the code review process through code review forensics.
For More..
- On how to use TeamReview see TeamReview by Example section on the TeamReview home page
- To download TeamRevew see the current release (1.0.6) of TeamReview
- To setup your TFS Project for TeamReview see the Setup instructions
- To debug or contribute to TeamReview see the debugging instructions
Posts
0 comments:
Post a Comment