代碼規范的自動化監管(2)

　　實施過程盡可能保守些。我在上面提到過，Jtest包括數百條規則，但在應用初期，我們只實施了兩個第一等級規則。原因很簡單：循序漸進，免得一下子出現太多問題，讓項目經理手忙腳亂、無所適從。

　　實施前做好壓力分析。公布新的第一等級規則前，你應該對問題出現的頻率、修改代碼所造成的時間和財務成本作到心中有數。這一點并不困難——你只需用新規則對現在項目做一次靜態分析，然后考察分析報告。由此可避免第一等級規則實施后，讓整個組織難以為繼，最后又將其降級為第二等級的情況出現。如果分析結果顯示壓力很高，那么可首先確定為第二等級，到以后合適時期再提升等級。實施嚴格的第一等級規則之前，應該反復多次考察，必須確保管理者理解它帶來的沖擊并支持這樣的決定;而一旦實施，就應該堅決執行。

　　充分溝通。和你的團隊就新規則及其價值、實施的原因充分交流溝通。在絕大多數情況下，他們一般都能支持你，但你也不應該讓他們無征兆“驚喜”。

　　盡管我們在實施過程中，還遇到了很多細節問題，但這樣一個主動的、自動化的軟件審查過程給我們的組織帶來了巨大利益。我們的軟件質量得到了提升，而且更重要的是，依靠這樣一個可信賴的系統，無需投入大量精力維護。人工維護過程的工作量非常浩繁。通過合理設計你的支持結構，的確可以在投入成本更低的前提下，給整個組織帶來更高的安全性。

　　作者簡介

　　Mark Figley：擁有8億美元資產的美聯保險公司(AIG United Guaranty)的架構組負責人。

原文轉自：http://kb.cnblogs.com/page/135515/