英文原文：Implementing Automated Governance for Coding Standards

　　作者：Mark Figley 譯者：羅小平 

　　多數(shù)大型開發(fā)組織都有一套自己的編碼和實踐規(guī)范。但是對這些團隊而言，光是將這些規(guī)范文檔化，并保證實時更新，就是一個巨大的挑戰(zhàn)。此外，在工作中長期、忠實地執(zhí)行這些規(guī)范和標準，難度就更大。我們團隊在這些方面做了積極探索，在整個構(gòu)建過程（build process）中實現(xiàn)了代碼規(guī)范的自動化監(jiān)管。

　　積極主動、未雨綢繆是工作取得好成果的重要保證。即使在很成熟的組織中，建立了代碼復(fù)審流程，審查結(jié)果也能直接反饋給責任人，但如果復(fù)審是在事后進行，仍然存在很大風險。因為這個時候，錯誤已成現(xiàn)實，很可能已經(jīng)進入測試和產(chǎn)品環(huán)境，從而造成實質(zhì)性損失；而這時候再回頭修改，開發(fā)人員也有抵觸情緒，缺乏積極性。從我們的經(jīng)驗看，構(gòu)建過程必須自始至終處于受控之中，在所有的軟件開發(fā)過程中，對應(yīng)的代碼審查工作都應(yīng)該自動完成。只有這樣，錯誤代碼才能在第一時間消除，從而避免到最后階段采取回溯式審查方法所產(chǎn)生的成本高昂和開發(fā)人員抵觸等問題。不帶任何感情色彩的自動化系統(tǒng)可實時向開發(fā)人員反饋Web頁形式的報告，幫助他們解決可能存在的問題；而且通過反復(fù)提醒，也可以讓開發(fā)人員被動熟悉新的編程規(guī)范。

　　中心化的構(gòu)建過程管理

　　為保證我們的上述策略真正落到實處，必須做好兩項工作：

1. 構(gòu)建過程必須是基于服務(wù)端的、中心化管理的。我們曾在Ant腳本基礎(chǔ)上自行開發(fā)了一個構(gòu)建管理系統(tǒng)（Build Management System，BMS），因為那時候像AntHill、Maven等產(chǎn)品還沒有發(fā)展成熟。如果是現(xiàn)在，我肯定會選擇第三方的BMS，而不是自己從頭做起。自己開發(fā)，方便實現(xiàn)一些特殊的定制化需求，但現(xiàn)在很多第三方BMS都有功能集成能力。
2. 必須樹立這樣的觀念：深度使用BMS，是團隊大幅提高代碼質(zhì)量的唯一途徑。我這不是搞教條，在這個問題上，其實別無選擇。如果開發(fā)人員可以繞過監(jiān)管系統(tǒng)，直接將Java類文件FTP傳送到服務(wù)器，那么我們正在這里討論的解決方案的有效性就大打折扣了。我們應(yīng)該控制對服務(wù)器上相關(guān)目錄的訪問，只將寫入權(quán)限授予負責運行JVM過程（即我們的構(gòu)建系統(tǒng)的宿主）的帳戶，這樣，開發(fā)人員必須通過BMS，才能將代碼傳遞到生產(chǎn)和測試環(huán)境。這樣一個過程，有連個顯而易見的好處：（1）保證在測試和生產(chǎn)環(huán)境中的源代碼控制；（2）確保在這些環(huán)境的所有代碼都通過了自動化的軟件審查。

　　工具化的軟件自動審查

　　我們使用的代碼自動審查工具是Parasoft的Jtest，當然還有很多工具可以完成類似功能。總的來說，Jtest是一個有效的管理工具，不過也存在一些問題。比如在使用之前，必須搭建一個基礎(chǔ)運行環(huán)境；另外，它并不是一個黑盒式的解決方案，這也是背離我們希望的。Jtest包括靜態(tài)分析和動態(tài)分析。其動態(tài)分析功能比較強大，不過這已超出了本文的討論范圍。

　　4年前，我們團隊因為數(shù)據(jù)庫連接未關(guān)閉問題焦頭爛額。資源未能在try/catch/finally塊中得到正確清理（大家是否感覺很熟悉？），因此引入了Jtest。在當時，Rod Johnson大仙（譯者注：Spring框架和《Expert One-on-One J2EE Development without EJB》的作者）還沒有下凡，沒有給我們帶來JdbcTemplate，因此很多公司都還在與此問題奮戰(zhàn)。而解決這類問題，恰是Jtest的強項。其運作原理是：分析Java類的結(jié)構(gòu)和內(nèi)容，檢查它們與既定規(guī)則的匹配程度。比如規(guī)則可能是這樣的：若在某個方法體中創(chuàng)建或從連接池中取得了數(shù)據(jù)庫連接，那么必須保證存在一個try/catch/finally塊，且在finally塊中關(guān)閉了連接，或?qū)⑦B接放回了連接池。4年前，我們就利用Jtest設(shè)立了這樣一個規(guī)則，將其嚴重程度定位一級，并在構(gòu)建系統(tǒng)中設(shè)置：當Jtest錯誤出現(xiàn)時，構(gòu)建過程自動暫停當前工作。這個系統(tǒng)工作得很好，數(shù)據(jù)庫連接問題再也沒有出現(xiàn)過。

　　現(xiàn)在，我們有了Rod和他的JdbcTemplate，但對于那些還沒有轉(zhuǎn)換到Spring的遺留Java應(yīng)用來說，上述規(guī)則仍可發(fā)揮作用。此外，Jtest還可以強制執(zhí)行很多其他結(jié)構(gòu)性標準檢查工作。比如，我們團隊實施日志標準后，就引入了另一項規(guī)則，以杜絕代碼中再出現(xiàn)System.out.println語句的可能。上述這些功能，不過是Jtest的冰山一角。在Jtest魔盒中，規(guī)則多達數(shù)百項，你還可以根據(jù)自己需要創(chuàng)建新的規(guī)則。

　　但現(xiàn)在的一個問題是，Parasoft對服務(wù)端Jtest的支持不夠理想。該公司的主要產(chǎn)品是一個Eclipse插件，此插件負責在IDE內(nèi)部對代碼執(zhí)行靜態(tài)和動態(tài)分析。這不是我所想要的，我需要的是一個基于服務(wù)端的Jtest產(chǎn)品，服務(wù)端環(huán)境可以集成并調(diào)用它的功能。Parasoft認為我們討論的這種最終式的組織控制和監(jiān)管，可以通過購買IDE插件（安裝到所有開發(fā)者的IDE），外加一個中心化的Parasoft報告服務(wù)器實現(xiàn)。但我們發(fā)現(xiàn)事實并非如此。Parasoft不能保證所有開發(fā)人員在將代碼簽入CVS前都會自覺執(zhí)行靜態(tài)檢查。我們沒有辦法控制這類插件，沒有Jtest插件報告“停！在有一級錯誤前你不能簽入”這樣的控制點。因此，這種審查不宜放在客戶端執(zhí)行，而必須有一個中心化的控制點，也就是一個中心化的BMS。我們需要的是服務(wù)端版本的Jtest，由我們自己完成對它的集成（雖然有點麻煩）。

　　當然，我得再次強調(diào)，Jtest不是唯一選擇。Adrian Colyer等人談到過利用ASPectJ完成代碼強制檢查。在中心化的監(jiān)管服務(wù)器上，這樣的功能很容易實現(xiàn)。我不能確定Jtest是否能滿足你的全部要求，不過它有免費的優(yōu)勢。其他同類型產(chǎn)品以及eclipse插件一般能完成Jtest的不同部分功能。如果你想圖省事，可以選擇eclipse中的標準插件JDT，它支持從格式和句法兩個方面對源代碼做標準檢查。

　　實施監(jiān)管的最佳實踐

　　軟件自動化監(jiān)管策略遠比你選擇什么樣的技術(shù)構(gòu)建解決方案更為重要。如下是我們多年來從實踐中總結(jié)的經(jīng)驗教訓：

• 監(jiān)管結(jié)構(gòu)要簡單。我們只有1、2、3共三種等級規(guī)則。違反第一等級規(guī)則時，工作將暫停，項目將無法進入測試和生產(chǎn)階段，直道問題解決。第二等級主要是指一個預(yù)備階段。它告訴開發(fā)人員，在下一個6-12月內(nèi)，此等級的問題會上升到第一等級，因此在此之前應(yīng)該將這些問題解決掉。第三等級問題不具實質(zhì)危害。這個等級只是建議解決某些問題，但在上升到其他等級前，這些問題不會對工作造成影響。
• 實施過程盡可能保守些。我在上面提到過，Jtest包括數(shù)百條規(guī)則，但在應(yīng)用初期，我們只實施了兩個第一等級規(guī)則。原因很簡單：循序漸進，免得一下子出現(xiàn)太多問題，讓項目經(jīng)理手忙腳亂、無所適從。
• 實施前做好壓力分析。公布新的第一等級規(guī)則前，你應(yīng)該對問題出現(xiàn)的頻率、修改代碼所造成的時間和財務(wù)成本作到心中有數(shù)。這一點并不困難——你只需用新規(guī)則對現(xiàn)在項目做一次靜態(tài)分析，然后考察分析報告。由此可避免第一等級規(guī)則實施后，讓整個組織難以為繼，最后又將其降級為第二等級的情況出現(xiàn)。如果分析結(jié)果顯示壓力很高，那么可首先確定為第二等級，到以后合適時期再提升等級。實施嚴格的第一等級規(guī)則之前，應(yīng)該反復(fù)多次考察，必須確保管理者理解它帶來的沖擊并支持這樣的決定；而一旦實施，就應(yīng)該堅決執(zhí)行。
• 充分溝通。和你的團隊就新規(guī)則及其價值、實施的原因充分交流溝通。在絕大多數(shù)情況下，他們一般都能支持你，但你也不應(yīng)該讓他們無征兆“驚喜”。

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

　　作者簡介

　　Mark Figley：擁有8億美元資產(chǎn)的美聯(lián)保險公司（AIG United Guaranty）的架構(gòu)組負責人。

it知識庫：代碼規(guī)范的自動化監(jiān)管，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。