 San Diego, May 25, 2004 – Today I want to cover one or two specific subjects that get lots of attention during this year’s Tech*Ed. Let’s begin talking about Visual Studio Team System. This integral part of Visual Studio 2005 is especially available for large scale software development. The product is designed for operation; increased reliability; quality (early and always); predictability and visibility. In this appearance, Visual Studio is no longer a single product but really it has become a platform with many tools for many different people in different roles within organizations, like infrastructure architects, developers, product managers, solution architects and testers. So far all of these people lived in separated silos. All had their own view about the product status, but probably nobody had an accurate view. Between the different people in an organization there is hardly any project data shared. With Visual Studio Team System this will change dramatically. Everything is centralized around a master database in which lots of documents are stored and shared amongst team members by means of work items. Modeling is done with Visio alike tools, but with the possibility to dynamically add properties, generate code, etc. Very cool is the possibility inside Visual Studio Team Systems to automatically generate unit tests. The development system itself is capable of inspecting newly created code. Another test method that is deeply integrated within Visual Studio Team System is code coverage. After running a code coverage test, the uncovered parts are immediately visible inside source code windows. This is very helpful in those cases where auto generated unit tests don't hit all the code. In that case it is possible to manually add more tests. Besides these kinds of tests, typically executed by the developer, there are performance test capabilities inside the product as well. In case performance issues are found, testers can report back to developers. The developers will not only get graphical data returned from the performance tests, but they also receive the test settings, so they can reproduce the exact same tests after fixing the problem. During the entire life cycle of a project lots of metrics are collected. These metrics can be used to measure the performance of team members, but there are also metrics that can be used to give indications about the quality of the product. Remember that metrics are collected during the entire lifecycle of the product. They even can help decide whether or not a product is ready for shipping.
Another very cool and useful tool is FxCop. This static analysis tool is currently at version 1.30. FxCop is available for free and it is not a bad idea to use it frequently. As a matter of facts, smart device developers will benefit from using FxCop as well for their products. FxCops works on exe’s and dll’s, making use of metadata to find potential problems in an assembly. It can find serious errors, but also gives warnings when for instance naming conventions are not met. The tool is very flexible and completely adjustable to fulfill particular needs. Take a look at the following screen shots to see what FxCop is capable of.
It might be hard to read but this is a screen shot taken of Visual Studio.NET 2003 with a real project in it. Inside a class there is an attempt to create another public class. Syntactically there is no problem with this code. However, after running FxCop it gives a possible error indicating to not nest types or to change the visibility of the inner type.
Thinking about it, this makes sense. When nesting types it is unlikely that you want the inner class to have public visibility. This problem is easily solved by making the inner class private to the outer class.
If you want to know more about FxCop and how to use it in a way to really get the most out of it, take a look at this article. |
