為性能和可伸縮性做架構和設計上的Review
部署和體系結構
Use distributed architectures appropriately. Do not introduce distribution unnecessarily.
適當的使用分布式架構，不要在不必要的時候使用分布式（譯注：這個不好把握，主要靠經驗，或者 講一些具體例子大家更容易明白）。
Carefully select appropriate distributed communication mechanisms.
仔細小心的選擇適當的分布式通信機制（譯注：綜合考慮性能，安全，兼容性等來選擇用socket開發 協議，還是用現成的wcf,remoting,web service,web api等）。
Locate components that interact frequently within the same boundary or as close to each other as possible.
頻繁交互的組件應在相同的邊界內或者盡可能的接近。（譯注：翻譯的有些拗口，不明白具體意思， 風行說可能就是就近原則）。
Take infrastructure restrictions into account in your design.
在設計中，把基礎架構的限制考慮在內。（譯注：比較抽象，不懂）。
Consider network bandwidth restrictions.
考慮網絡帶寬的限制。
Identify resource restrictions.
明確資源的限制。
Ensure your design does not prevent you from scaling up.
確保你的設計不會阻止你的橫向擴容（scaling up）。
Ensure your design does not prevent you from scaling out and it uses logical layers, does not unwittingly introduce affinity, and supports load balancing.
確保你的設計不會阻止你的縱向擴容（scaling out），並且他使用業務邏輯層，不無意中引入近親（ 譯注：翻譯可能不對，不懂啥意思），並且支持負載均衡。（譯注：不同的應用可能會有不同的負載策略 ，源IP負載，還是按流量負載，還是7層負載，適用於不同的場合。）
耦合性和內聚性
Ensure your design is loosely coupled.
確保你的設計是松散耦合。
Exhibit appropriate degrees of cohesion in your design and group together logically related entities, such as classes and methods.
在你的設計裡顯示出適當的內聚性，組合邏輯相關的實體，如類和方法（譯注： group together不知 道咋翻譯）。
Restrict use of late binding and only use late binding where it is necessary and appropriate.
避免使用晚期綁定，並且只在必要和適當的時候使用晚期綁定（譯注：晚期綁定只在vb,asp等語言才 有吧，這個不是說用就能用的吧，晚期綁定是一種運行時的行為，所以可能會損耗應用的運行性能）。
通信
Interfaces do not enforce chatty communication.
接口不要定義一些無關的通訊（譯注：這句不會翻譯）。
Ensure your application only makes remote calls where necessary. Impact is minimized by client-side validation, client-side caching, and batching of work.
確保你的應用只在必要的時候使用遠程調用，通過客戶端驗證，緩存和批量作業最小化不利影響。
Optimize remote data exchange.
優化遠程數據交換（譯注：不同具體做法）。
Choose appropriate secure communication mechanisms.
選擇適當的安全通信機制。
Use message queues to decouple component parts of your system.
通過消息隊列解耦你系統的一部分（譯注：component parts不知道指什麼）。
Mitigate the impact of long-running calls by using message queues, "fire-and forget" approaches, and asynchronous method calls.
使用消息隊列減少長時間運行的調用的影響，忘記進接近的，一步的方法調用（譯注：後半句可能理 解的有問題）。
Do not use processes where application domains are more appropriate.
在應用程序域更合適的情況下不要使用進程（譯注：創建進程比創建應用程序域開銷大）。
並發
In your application do not create threads on a per-request basis, and use the common language runtime (CLR) thread pool instead.
在你的應用裡不要為每個基本的請求創建線程，用CLR裡的線程池代替這種做法（譯注：覺得CLR的線 程池不適用的情況可以自己實現線程池）。
Only types that need to be thread-safe are made thread-safe.
只把那些需要線程安全的類標識為線程安全的（譯注：讓一個方法線程安全需要編碼實現，不知道這 裡的types是啥意思，是動詞還是名字）。
Carefully consider lock granularity..
仔細考慮鎖的粒度（譯注：不是鎖的粒度越小越好，太小的話會增加代碼復雜度）。
Ensure your application acquires shared resources and locks late and releases them early to reduce contention.
確保你的應用獲取共享資源和鎖盡量的晚並且盡量早的釋放他們以減少爭用。
Choose appropriate synchronization primitives.
選擇恰當的同步基元（譯注：可能是信號量，臨界區，互斥體等）。
Choose an appropriate transaction isolation level.
選擇恰當的事務隔離級別。
Ensure your application uses asynchronous execution for I/O bound tasks and not for CPU bound tasks.
確保讓你的應用為I/O密集任務使用異步執行，而CPU密集任務就不用異步執行了（譯注：有時候計算 密集任務也需要異步執行以讓當前線程執行其它更重要的任務，這個往往和業務邏輯有關）。
資源管理
Ensure your design supports and makes effective use of pooling.
確保你的設計支持並有效的利用pooling（譯注：不太理解資源管理裡啥是pooling）。
Ensure your application acquires resources late and releases them early.
確保你的應用盡量晚的請求獲取資源並盡量早的釋放他們。
緩存
Use caching for data that is expensive to retrieve, compute, and render.
為那些獲取、計算和呈現比較昂貴的數據使用緩存（譯注：render不知道咋翻譯，有些獲取比較昂貴 ，但要求比較實施的數據可能也不能緩存，但如果並發請求量大的話，你可以緩存一秒，也會很大提高性 能的，或者更新數據的時候同時更新緩存）。
Cache appropriate data such as relatively static Web pages, specific items of output data, stored procedure parameters, and query results.
緩存適當的數據，如相對靜態的網頁，明確的輸出數據的條目，存儲過程參數和查詢結果集等。
Do not use caching for data that is too volatile.
不要緩存那些不太穩定的數據。
Select an appropriate cache location.
選擇一個適當的緩存存取位置（譯注：緩存除了保存在內存上，還能保存在磁盤上，甚至是其它機器 的內存上，如分布式緩存）。
Select an appropriate cache expiration policy.
選擇一個適當的緩存過期策略。
狀態管理
Your design favors stateless components. Or, you considered the negative impact on scalability if you decided to use stateful components.
你的設計應更傾向於無狀態組件，或者如果你考慮了在可擴展性上的負面影響，如果你決定使用狀態 化組件（譯注：有狀態組件在擴容的時候確實比無狀態組件影響大，一般有狀態組件要用哈希、7層負載 或者源IP負載，無狀態組件用按流量負載就行了，前者耗費性能大而且容易出現負載不均的情況。關於如 何避免有狀態組件是個大話題，回頭總結下經驗和大家分享）。
If you use Microsoft? .NET Framework remoting and need to support load balancing, you use single call server-activated objects (SAO).
如果你使用微軟的.NET Remoting並且需要支持負載均衡，你要用single call的服務端激活（SAO）（ 譯注：single call的服務端激活Remoting對象，為每個客戶端調用創建新的服務端對象，不使用這種方 式的話，很可能多次調用使用同一個遠程對象，造成負載不均，個人理解）。
If you use Web services, you also use a message-based stateless programming model.
如果你使用了web服務，你同樣需要使用基於消息的盡量無狀態的編程模型（譯注：webservice也可以 為有狀態的）。
If you use Enterprise Services, also use stateless components to facilitate object pooling.
如果你使用Enterprise Services，也需要用盡量無狀態的組件以便讓池化對象更容易。
Objects that you want to store in state stores support serialization.
那些要保存到狀態的對象需要支持序列化（譯注：因為狀態可能要在各層傳輸）。
Consider the performance impact of view state.
考慮ViewState對性能的不良影響（譯注：ViewState是asp.net的一種維護頁面狀態的機制，如果不要 可以關閉它，可以在不同級別上關閉，如整個應用，某個頁面，甚至某個控件）。
Use statistics relating to the number of concurrent sessions and average session data per user to help choose an appropriate session state store.
根據並發Session相關的統計數據和平均 Session的數據量去選擇一個合適的Session存儲模式（譯注：可自己實現，可在本進程，sqlserver或某 台機器的SessionState服務）。
數據結構和算法
Ensure your design uses appropriate data structures.
確保你的設計使用 合適的數據結構（譯注：這個可能不太好把握，要對比能解決同一問題的不同數據結構的方方面面）。
Use custom collections only where absolutely necessary.
只在絕對必要的時候使用自定義的 集合（譯注：.NET自帶有很多集合類，字典，鏈表，列表等）。
Extend the IEnumerable interface for your custom collections.
如果你需要實現自己的集合請實現IEnumerable接口。
數據訪問
Pass data across the layers by using the most appropriate data format. Carefully consider the performance implications.
使用最合適的數據格式在多層之間傳遞數據， 仔細考慮對性能的影響（譯注：比如為了減輕流量，對數據壓縮，在對端肯定解壓縮的時候要耗費性能， 要權衡好）。
Use stored procedures with the Parameters collection for data access.
為數 據訪問使用參數化集合的存儲過程。
Only process the data that is required.
只處理那些你需 要的數據。
Where appropriate, provide data paging solutions for large result sets.
在適 當的時候，為大結果數據集提供分頁解決方案。
Use Enterprise Services declarative transactions for transactions that span multiple resource managers or where you need to flow transaction context across components.
為跨越多個資源管理者的事務或者當你需要在多個組件間 流動事務上下文的時候使用企業服務來declarative事務（譯注：declarative不知道咋理解）。
If you manipulate binary large objects (BLOBs), use appropriate chunking techniques, and do not repeatedly move the same BLOB.
如果你要控制二進制大對象(BLOBs)，使用恰當的chunking技術，不 要重復的移動相同的二進制大對象。
Consolidate repeated data access code into helper classes.
把重復的數據訪問代碼放到幫助類裡（譯注：Consolidate不知道咋翻譯，整句話的意思可能 是使用統一的數據存取代碼，不要到處寫重復的數據訪問代碼）。
異常處理
Do not use exceptions to control regular application flow.
不要使用異常控制應用的邏輯流 程（譯注：有時候自定義異常可以控制一些業務流程，個人感覺）。
Use well-defined exception handling boundaries.
采用良好定義的異常處理邊界（譯注：不理解，有人說異常處理邊界似乎try{} 大括號裡面的部分）。
Structured exception handling is the preferred error handling mechanism. Do not rely on error codes.
結構化異常處理是更好的錯誤處理機制，不要依賴錯誤碼 （譯注：有些異常類型也有錯誤碼屬性，如SocketException）。
Only catch exceptions for a specific reason and when it is required.
只捕獲那些需要捕獲並且有具體原因的異常。
類設計上的考慮
Classes own the data that they act upon.
類擁有它們操作的數據（譯注： 有些幫助類可能不維護數據，如靜態類）。
Do not use explicit interfaces unnecessarily. Use explicit interfaces for versioning and for polymorphism where you have common functionality across multiple classes.
不要不必要的使用具體的接口，在你版本化或多態化跨越多個類的共同功 能的時候需要時候使用具體的接口（譯注：後半句太長，翻譯的可能不對，explicit不知道這裡咋翻譯， versioning和polymorphism翻譯的也不知道對不對）。
Classes do not contain virtual methods when they are not needed.
類在不必要的時候不要包含虛方法。
Prefer overloaded methods to methods that take variable parameters.
與其用可變參數，更喜歡用重載方法。
