Effective C# 原則48：瞭解更多的工具和資源(譯)

Effective C# 原則48：瞭解更多的工具和資源  
Item 48: Learn About Tools and Resources

對於C#以及.Net來說這是激動人心的時候。這些工具目前還是比較新的，整個社區都在學習如何使用這些工具。一些資源可以協助你提高你的知識，以及為.Net和C#建立一個更大的知識社區。這些工具是我每天都向C#開發人員推薦的。關於C#實踐的全部內容還在寫作當中，跟進它們而且不斷瞭解相關的內容。

第一個應該在每一個C#開發人員的工具箱的工具是NUnit, 它可以在www.nunit.org網站上找到。NUnit是一個自動進行單元測試的工具，功能和JUnit很像。和其它大多數開發人員一樣，我討厭寫測試代碼並且自己測試。NUnit讓這些進程都變得很高效，在你有規律的使用這些工具後，可以保證你會習慣測試你所有的C#類。不管什麼時候當我建立了一個類庫工程時，我都會添加一個NUnit測試工程，而且把自動產生的測試做為一部分添加進來。我添加一個以建立和運行測試的配置，這樣可以在每次編譯時間進行測試。然後，我可以轉換活動的配置來控制是否要讓單元測試做為正規程式的一部份存在。預設情況下，我運行它們。當我須要進行UI測試時，我會轉換到另一個配置上。

在附帶的使用NUnit時，你可以通過檢測NUnit的原始碼學到一些有意思的技術。NUnit使用一些進階的反射習慣來載入和測試你的程式集。它使用特性來尋找測試包，測試案例，以及每個測試案例的期望結果(參見原則42)。這是一個非常不錯的例子，可以告訴你如何使用這些技術來建立可以自己動態配置的工具，而且它可以廣泛的應用。

接來下是FXCop，這是一個免費的工具，可以從GotDotNet(www.gotdotnet.com)上得到。FXCop 分析你的程式集裡的IL，看它是否與實踐的原則相違背，以及報告這些違例的地方。每一個原則都有一個可靠的公制規範，以及使用這一原則的原因。如本書裡所有推薦的原則一樣，一些文檔中有一個關於某一原則的簡短理由。你可以斷定這些實際的問題是否遵守這些建議。同樣你也可以配置是否把每一個原則都應用到項目中。我並不贊成FXCop 中的一些原則，而且我在本書前面已經說明了原因。然而，像NUnit一樣，FXCop 可以成為你建立的正規程式的一部分。每次編譯後，可以有一個編譯後步驟，可以用FXCop 來分析你選擇的原則。圖6.1展示了一個從FXCop裡輸出的例子。儘管一些推薦並不是我喜歡的(例如有一個是讓每一個程式集應該是讓COM見的)，但它確實是一個有用的工具，因為它讓你思考很多你已經預設的決定。

圖6.1,FXCop分析的一個項目：
Figure 6.1. FXCop analyzing a project.

[View full size image]

ILDasm是一個IL反組譯碼器，在本書不同的地方，我已經示範了一些IL代碼，它們就是編譯器為不同的C#結構產生的。儘管我不相信很多人會在有進階語言存在的情況下，還選擇寫IL代碼，但你應該熟悉它。知道從不同的C#結構上產生的IL代碼，可以協助你成為一個更好的開發人員。你可以為你自己的程式集檢測IL代碼，或者是.Net架構裡的程式集。這就是使用ILDAsm，而且它是和.Net架構的SDK一起發布的。IL對於所有開發人員來說都是可用的。ILDAsm可以讓你看到你的程式集的中繼語言。不管怎樣，這是一個好的方法來學習.Net架構程式集，這也是得到的原始資料。

這些只是你正式工具箱中的一部份，但擁有這些工具只是提高你技能的一個方面。大量線上的資源以及交流社區可以讓你參與和學習，以及增加你自己的C#和.net架構知識。首先也是最重要的就是GotDotNet 網站(www.gotdotnet.com)，這是.Net組的官方網站。C#小組在MSDN上有一個網站，目前是在msdn.microsoft.com/vcsharp/ (它偶然在MSDN網站有變動而被重新組織)。如果你的工作主要是基於網路的，試著訪問www.asp.net，這是為ASP.Net組提供的。如果你的工作主要是基於Windows Form的，試著看看www.windowsforms.net，這是Windows Form組的官方網站。這些網站包含很多常規編程的引用和實現，這些可能是你的應用程式中想要的。它們都是還源檔案的組件，所以你可以檢測和修改這些，讓它們成為你想要的。最後也是最重要的位置應該要瞭解就是在MS模式和實踐的網頁。這個網頁目前在 www.microsoft.com/resources/practices/，從這個地方，你可以查到一些常用的設計模式以及一些最好的模式的初始代碼。
而且這個地方經常更新一些新的例子的代碼以及庫，這可能協助你解決常規的編程問題。在寫這些時，你已經可以使用10個不同的應用程式塊來實現一些常規的程式要求，我確信當你閱讀到這些時，這些地方已經有更多的內容了。

我還要推薦一些C#組的FAQ的訂閱：http://blogs.msdn.com/csharpfaq，附帶的在這個上，有幾個C#組的成員用部落格討論一些C#問題。你可以在這裡找到最新的列表： http://msdn.microsoft.com/vcsharp/team/blogs/

如果你學習更多的而且對語言和環境想得到更深入的瞭解，你可以檢測共用的CLI(code-named rotor)。這包含.net架構以及C#編譯器的一些核心內容。你可閱讀這些資料來對C#語言的每一個功能和.Net架構得到更深入的理解。並不是所有的.net商業架構都有可用的共用資料：例如，特殊的Windows代碼並沒有發布共用代碼。然而，這些已經發布了的子集，同樣夠你學習更多的關於CLR和C#語言內部的東西。

C#編譯器已經和共用的CLI資料一起發布，這是用C++寫的，它做為底層的CLR代碼存在。你須要對C++有很深的背景知識，以及對編譯器設計有清楚的認識才能很好的理解它。現代的語言編譯器是複雜的軟體塊，但CLR資料是一個有用的工具，來理解.Net架構的核心功能是如何?的。

這裡只是給出了一個簡單的列表， 我只是在眾多資料中介紹了一個表面。很多資料你都可以多MS上得到，或者其它線上網站，或者是書。你越是多的使用這些工具，你就可以得到越多的知識。整個.Net以及C#社區是在前進的，因為它發展的很快，這些列出的資源也可能不斷的在改變。你可以自己學習和自己寫稿。

============================
   

Item 48: Learn About Tools and Resources
These are exciting times for C# and .NET. These tools are still new enough that the entire community is learning how best to use them. Several resources are available to help you improve your knowledge and build a larger community of knowledge for .NET and C#. These are the tools that I use daily and recommend to other C# developers. The full set of C# best practices is still being written. Keep up, and get involved.

The first tool that should be in every C# developer's toolbox is NUnit, available on the web at www.nunit.org. NUnit is an automated unit-test tool, functionally similar to JUnit. Like most developers, I hate writing tests and testing my code. NUnit makes that process so efficient that using it regularly ensures that you will be in the habit of testing all your C# classes. Whenever I make a class library project, I add an NUnit test project and include executing the tests as part of the automated build. I add new configurations that include build and test, which run the tests on every compile. Then I can switch the active configuration to control whether unit tests are run as part of the regular build process. By default, I run them. I switch to the other configuration when I'm running tests that require the UI.

In addition to using NUnit, you can learn several interesting techniques by examining the NUnit source code. NUnit uses some advanced reflection idioms to load and test your assemblies. It uses attributes to find test suites, test cases, and expected results from each test case (see Item 42). It's a great example of how to use these techniques to build a tool that configures itself dynamically, and it can be used in a wide variety of ways.

Next is FXCop, a free tool available at GotDotNet (www.gotdotnet.com). FXCop analyzes the IL in your assembly against a set of rules and best practices, and reports violations. Each rule has a reliability metric and a reason for the rule. As with all the recommendations in this book, the rule documentation has a brief justification for the advice. You can then determine whether the advice fits your particular problem space. You can also configure whether each rule is applied in your project. I disagree with some of the FXCop rules, and I've said as much earlier in this book. However, like NUnit, FXCop can become part of your regular build process. Each build can have a post-build step that analyzes the code using FXCop with your chosen rules. Figure 6.1 shows a sample output from FXCop. Although some of the recommendations are not to my liking (such as the one that every assembly should be COM visible), it's a useful tool because it makes you think about many decisions you might have made by default.

Figure 6.1. FXCop analyzing a project.

[View full size image]

 

IldAsm is an IL disassembler. In different locations in this book, I've shown the IL that the compiler generates for different C# constructs. Although I don't believe that many people are choosing to write IL in favor of any high-level language, you should be familiar with it. Knowing the IL that gets generated from different C# constructs will help you be a better developer. You can examine the IL for your own assemblies or for assemblies in the .NET Framework by using IldAsm, which comes with the .NET Framework SDK. The IL is available to all developers. IldAsm lets you see the intermediate language for your assemblies. However, a better way to learn about the .NET Framework assemblies you use is to get the source.

Those are the tools that are part of your regular toolbox. But having the tools is only one way to improve your skill. A variety of online resources and communities enables you to participate and learn and increase your knowledge of C# and the .NET Framework. First and foremost is the GotDotNet site (www.gotdotnet.com), the official site of the .NET team. The C# team has a page on the MSDN site, currently located at msdn.microsoft.com/vcsharp/ (it moves occasionally as the MSDN site gets reorganized). If your work is primarily web-based, try www.asp.net, the site for the ASP.NET team. If your work is Windows Formsbased, try www.windowsforms.net, the official site of the Windows forms team. These sites contain reference implementations of many common idioms that you will want to make use of in your applications. They all come with source components, so you can examine and modify them as you need to for your purposes. The last and most important location to become familiar with is the MS Patterns & Practices page. This page is currently located at www.microsoft.com/resources/practices/. From this location, you will find common patterns and starter code for those best practices. This area continues to be updated with more sample code and libraries that will help you solve common programming problems. At this writing, you can use 10 different application blocks to implement common programming requirements; I'm sure there are already more by the time you read this.

I also recommend subscribing to the C# Team FAQ: http://blogs.msdn.com/csharpfaq. In addition to that one, several of the C# team members have blogs where they discuss C# issues. You can find the up-to-date list at http://msdn.microsoft.com/vcsharp/team/blogs/.

If you want to learn more and get an even deeper understanding of the language and the environment, examine the shared source CLI (code-named rotor). This includes the core .NET Framework and a C# compiler. You can read the source code to gain an even deeper understanding of each feature in the C# language and the .NET Framework. Not every assembly in the commercial .NET Framework is available in the shared source version: For example, the Windows-specific code is not delivered with the shared source code. However, what is delivered is a rich subset that you can use to learn much about the inner workings of the CLR and the C# language.

The C# compiler delivered with the shared source CLI is written in C++, as is part of the low-level CLR code. You need to have a strong background in C++ and a strong understanding of compiler design to understand it thoroughly. Modern-language compilers are intricate pieces of software, but the CLR source is a valuable tool to understand how the core features in the .NET Framework are implemented.

This is intentionally a small list. I've only touched the surface of the many resources that are available to you from Microsoft, online at other sites, and in books. The more you use these tools, the more knowledgeable you will be. The entire C# and .NET community is moving forward. Because it's moving forward quickly, the list of resources changes constantly. Learn and contribute yourself.