雖然在幾乎所有的項目中一些相同的問題不斷重復出現，但是我們仍然缺少明確的方法來解決它們。 在軟件開發的職業生涯中， 我使用了一些方法來解決這些重復出現的困擾我的大部分開發項目的問題，這些方法真正有助于項目執行效率的提升。本文中，我將與各位分享3項項目執行的最佳實踐，其中的某幾個方法有充分的資格可以被認定為模式(pattern)。
·        使用模板代碼
·        編寫高效的開發手冊
·        執行自動化代碼檢查

使用模板代碼

　　開發者可以從參考簡單的業務用例和復雜的業務用例的示例代碼實現中獲得幫助，編寫出有效、高效率的代碼?？紤]下面的一些經常困擾軟件開發項目的因素：
·        技術始終在變化，要找到對于新技術具有使用經驗的有競爭力的技術人員是很困難的事情(譯注： 去做獵頭吧！)。另一方面，開發新手可能不具備編寫有效正確代碼的經驗。模板代碼為開發者的工作提供了良好的參考，使得學習新技術變的相對簡單。
·        學習利用新技術需要時間，而且假如使用不當可能導致一團混亂，因此強迫開發者自己學習新技術不是很好的途徑。 作為替代方法，提供模板代碼作為開發者編碼的參考使得開發者在開發過程中獲得了學習新技術的良好起點。
·        許多項目必須由有限的人員在緊迫的期限內完成。項目團隊中的每個人都不應該重新造輪子。高級技術人員可能在設計階段提供幫助，不過項目進行到實現階段可能就要求程序員自助了。一不留意的小問題，到了發現的時候可能已經造成了混亂。問問自己，使用javadoc工具的時候，有幾次遵循了標準的格式和文檔生成指導方針呢？代碼是否遵循了定義良好的習慣用法和最佳實踐呢？那么如何貫徹這些良好實踐呢？此處，可視的模板代碼能夠提供比技術書籍或者參考手冊更有效的幫助，因此，應該使用模板代碼。
·        許多軟件項目不僅體積龐大，而且分布式地進行開發。有時，項目的執行是同時在世界上的不同地點展開的。作為開發人員你不想看到——當你的項目部分接近完成時，你的代碼的客戶驚異的發現你的代碼沒有滿足他們的需求。應該在開始編寫代碼實現功能前，將示例代碼送給你的客戶評審，并記錄反饋。這些示例代碼不應該僅僅是類似”世界，你好”的程序，應該具有代表性，與實際編寫的代碼很接近。
·        通常開發者都有一堆參考手冊、標準、程序框架等資料，可以在項目中通過它們來獲得幫助。但是，即使已經完成了設計工作，編碼的風格也不是顯而易見的，難以遵守。可視的模板代碼可以提供這方面的幫助。除非開發者可以看到真實的代碼例程，否則他們對當前項目的解釋彼此間可能有些許的出入。 一個簡單功能由多個開發者來實現，其實現方式可能是不同的，甚至可能沒有一個與推薦的模擬最佳實現的方式相同。

模板代碼的實現

　　首先，召集一組專家(技術上的和業務上的)從目標項目的問題域中甄別出簡單用例和復雜用例各一個，并在現有設計的基礎上分別實現這兩個用例。這樣，項目組就擁有了自己的模板代碼。下面列出了一些編寫模板代碼的小技巧
·        模板代碼中應該包含立即可用的編譯和部署腳本。否則，在開發的構建階段解決這些問題又要浪費不少時間。
·        項目的基本目錄結構應該預備完畢，并且包含了欲在項目中使用的各種庫。
·        模板代碼應該遵循項目中使用的命名規范、代碼風格、其它標準以及應用框架的要求。
·        模板代碼中應該使用定義良好的Javadoc模板(比如、基于Eclipse的Javadoc模板)，以幫助開發人員編寫javadoc注釋。編寫良好的javadoc注釋是很重要的，通常這些注釋可能是代碼維護和再開發團隊的唯一可用的文檔。
·        程序語言中明確的編碼慣用法應該在模板代碼中使用，這有助于開發者編寫有效的代碼。
·        模板代碼應該明確定義使用開發框架的標準方法。對于新的開發者來說，在項目的初始構建階段編寫基于特定框架的實現類是很困難的任務。示例代碼有助于新的開發者理解框架等概念。即使框架有許多文檔，利用框架進行有效率的開發也并不都是很輕易。
·        模板代碼應該展示如何利用JUnit或其他測試框架編寫測試用例(test cases)。
·        客戶的技術團隊應該評審這些模板代碼，這樣他們對于在項目構建階段結束時的代碼質量具有更明確的熟悉，而不會在最后時刻感到意外。
·        模板代碼應該從頭到尾的涵蓋用例，比如從表示層到數據層。
·        對于模板代碼的各種細枝末節應該進行一次詳盡的介紹，使得開發者熟悉它們。開發者應該理解在架構的每個層次需要做那些工作、使用了(或者可能使用)那些編碼慣用法和最佳實踐，以及為什么使用它們。

使用模板代碼的好處
·        開發者獲得開始編寫代碼的參考
·        客戶與開發者就項目預期質量達成一致，因而避免了通常由于理解差異產生的各種問題。
·        開發者擁有了開始編碼工作的骨架。
·        開發者更輕易把握并應用項目中使用的開發框架和各種外部API，這有助于提高開發效率。
·        開發者沒有重新造輪子。大部分的最佳開發實踐和編碼慣用法都擺在了他們面前，這也可以提高開發效率。


有效的開發手冊

　　假設我們必須完成一個日常開發人員為30到50人的大項目。不是所有的開發人員都把握了需要使用的技術以及遵循的標準。一個項目可能需要使用很多技術以及私有的開發框架。這些框架可能在以后的Java企業項目中使用。有效的在項目間，開發者之間進行大量知識的轉移是一個大挑戰。知識轉移也涉及到如下的一些問題：
·        很多大型項目的開發持續很長時間(1到2年)。我們必須正視這樣的事實：軟件行業具有相當高的離職率，這是基本的現實也是一個挑戰。雇用新人可能很輕易，但是教授新人項目知識卻又是一項艱巨任務，非凡的，考慮到項目的進展不能停滯不前。
·        一些開發者可能不具有期望的技術水平?，F在，適時的找到把握技術的開發者是很困難的。當項目期限很急時，新的開發者沒有時間去學習厚厚的技術書籍或者參考手冊。一部分人可能工作敏銳、高效，這樣可以騰出額外時間來學習并應用新的技術，但是不能假定所有人都會如此。
·        維護一個構建完畢的軟件項目同樣也是大的挑戰。在開發周期后的代碼維護工作可能是由客戶的IT團隊執行的。對他們來說，熟悉項目的技術架構并且改動代碼以做出改變很困難。假如沒有定義明確的方式來傳遞這些知識，那么在維護階段的初期，客戶IT團隊研讀項目代碼和設計文檔的工作可能會是很沮喪的經歷。

開發手冊應該能夠解決上面提到的問題，但是如何編寫一個有效的開發手冊呢？

編寫開發手冊
下面是一些如何編寫開發手冊的提示：
·        開發手冊應該包含全部與搭建開發環境相關的必要信息
·        開發手冊的語句應該簡明易讀。假如閱讀的人發現手冊很難閱讀，這不是閱讀者、而是手冊編寫者的失敗。
·        開發手冊應該包含大量的示例。示例可以有效地表明手冊的內容。
·        請求一位不熟悉項目中所使用的技術的開發者檢查開發手冊。這樣，假如手冊內包含會造成迷惑或者不明確的內容，可以在其它人使用本手冊前修改這些地方，以使手冊更清楚明確。
·        開發手冊應該在底層設計階段，作為階段任務的一部分完成。當構建階段開始時，開發者可以有效利用本手冊。
·        開發手冊需要包括多少信息呢？如何在信息的多寡中平衡呢？開發者不喜歡厚重的手冊。但是，開發手冊中不能遺漏可以為許多不明確之處提供語境的信息。需要考慮開發者的真正需求，而不是僅僅考慮可以提供的全部信息是什么。使用簡單的、直截了當的、漸進的方式來編寫開發手冊。
·        開發手冊的信息提供方式應該與閱讀者的閱讀直覺相符，而不該是在各處零落地散布著這樣那樣的信息。手冊內容的組織方式應該與現實中開發項目時需要閱讀信息的先后步驟一致。 比如，對于Java企業項目，首先需要搭建開發環境，然后開始表現層和應用數據層的編碼工作。手冊信息也應該以同樣的順序組織。
·        需要明確的是：手冊不能迷惑開發者。比如，開發者在編寫Struts框架下的Action類時需要使用特定的Xdoclet標簽，那么開發者應該很清楚項目中使用的各種XDoclet標簽的意義和使用方式。為了查找更詳盡的信息，開發者總是可以參考開發手冊。

下面我們考慮一個在Java企業項目中的使用的真實地開發手冊應該是什么樣的，它應該包含的信息細節如下：
·        開發環境搭建的細節：當新的開發者加入項目時，必須搭建開發環境，然后才能開始工作。不要認為開發者清楚項目的大小細節。假如項目一起使用了Eclipse和Weblogic開發Web應用，新的開發者可能都不清楚Eclipse或者Weblogic是什么東東。因此，搭建開發環境的細節信息應該是開發手冊的第一部分。具有基本Java知識的新開發者應該很輕易的按照手冊中的這些信息搭建開發環境。
·        表現層的細節：通常，開發者對某個用例的實現從表現層開始。開發手冊中應該包含如何創建表現層組件元素的具體步驟。比如，項目的表現層使用Struts框架，手冊中應該包含如何編寫Action類和Form類的確定步驟。假如項目使用XDoclet來構建Struts配置文件struts-config.xml和其他配置文件，相應的這些步驟也應該包含在內。jsp的相關技術信息也應該如此。應用MVC模式，無論如何不應該在JSP頁面中包含任何Java代碼來實現業務邏輯。但是在實際開發中如何使用JSTL(JSP標準標簽庫)標簽來實現那樣的要求對于初學者或者是中級開發者可能都是很大的難題。開發手冊中包含一些展示如何在JSP頁面中使用JSTL標簽的真實示例可能對這些開發者有些幫助。
·        業務層的細節：業務邏輯可以應用無狀態EJB組件、基于SPRing的組件、或者簡單的原始java對象(plain-old java object)來實現。開發手冊中應包含項目中使用的業務組件代碼的骨架以及業務邏輯實現的實際例程
·        數據層的細節：依靠于項目使用的持久化機制，開發手冊中應該包含JDBC、Hibernate或者任何基于其它框架的DAO(數據訪問對象)的信息，包含項目中如何使用此持久化機制的步驟以及最佳實踐。
·        其它信息：手冊需提供J2EE項目架構各層中使用的各種內部或者外部組件的信息。例如，應該包括日志、郵件、代碼檢查和安全等組件的信息。同樣的，在項目后期，手冊中應該包含一些如何擴展業務需求的章節。比如，項目中使用了批處理框架，那么如何為新的批處理需求擴展它呢？

自動化代碼檢查

　　代碼檢查是另外一項需處理的事項。當代碼大量生成時，持續的代碼檢查是必須的工作。即使已經定義了一套代碼檢查的規則，還是有許多問題沒有辦法在這些規則中描述并加以限制?；趥€人能力和經驗，每個人都有自己的代碼檢查方式。同時，有些問題很微小，無法進行逐行檢查。 假如需要檢查的代碼數量很大，這些微小的問題可能會在一些地方被忽略掉。假如IDE自身產生了錯誤又怎么辦？還好，有些工具可以替代人工代碼檢查來發現這些問題。

Eclipse IDE的設置
有時， 設置IDE的選項可以提供些幫助。比如，你可以配置Eclipse IDE的選項，當代碼中出現問題時顯示警告。下圖是如何在Eclipse中設置Javadoc配置選項的示例。


圖 1. Eclipse Javadoc 設置

選項設置好后，Eclipse會在出現錯誤時顯示警告信息，然后開發者可以修改。假如項目標準很嚴格，IDE的警告將升級為錯誤，開發者必須處理這些問題。

Jlint 代碼檢查工具
類似的，可以在Eclipse中使用Jlint工具以發現代碼中的微小問題。下面是在Eclipse中如何使用JLint的方法和步驟：
·        下載jlint的2進制版本以及相應的Eclipse插件，解壓縮2進制版本到C:/lint目錄，解壓縮插件到Eclipse插件目錄。
·        運行Eclipse, 選擇菜單項Window(窗口)->Preferences(設置)->Java->Jlint，設定jlint.exe的目標位置為C:/jlint/jlint.exe
·        在Eclipse的資源(Resource)視圖中右鍵點擊你的項目，然后選擇jlint選項即可。當一次完整地工作區編譯后，Jlint會在工作區內可能出現問題的地方顯示黃色警告標記。
下圖 顯示了如何在Eclipse中配置Jlint