????? 軟件開發并非易事，項目執行本身需要許多模式和最佳實踐，從而節省寶貴時間。本文介紹了解決日常軟件項目執行問題的三個最佳實踐。
即便我們的大多數項目可能面臨類似的問題，我們還是缺少明確的方法來解決它們。在軟件開發的職業生涯期間，筆者使用了一些方法來解決困擾大部分開發項目的重復出現的問題，這些方法確實有助于有效地執行項目。筆者在文中介紹了項目執行方面的三個最佳實踐，其中幾個可以認為是成熟的模式：
● 使用模板代碼；
● 編寫高效的開發手冊；
● 執行自動化代碼檢查。
使用模板代碼
示例代碼可以幫助開發人員編寫非常高效的代碼。經常困擾軟件開發項目的因素有以下一些。
技術在變化。事實證明，很難找到在新技術方面頗有經驗的能夠勝任的技術人員。另外，開發新手可能缺乏編寫高效代碼的經驗。模板代碼則為開發人員提供了良好的參考點（reference point），從而簡化了學習新技術的過程。
學習及使用新技術需要時間，如果處理不當，可能會導致一片混亂。因此可以為開發人員提供模板代碼，作為編寫代碼所用的參考點，從而在開發方面盡快上手，而不是迫使開發人員自己學習新技術。
許多項目人手有限，而且必須在很緊迫的期限內完成。參與項目的每個人都不應該從事重復性工作。高級技術人員在設計階段也許可以幫得上，不過等到實際實施時，程序員通常只能靠自己了。細小的問題可能會被忽略，到后來卻發現已經造成了混亂。Javadoc有幾次遵循了標準化的格式和指導準則？代碼有幾次遵循了明確定義的習慣方法和最佳實踐？可視化框架（visual framing）比技術書籍或者參考手冊更有效，因此，模板代碼能夠助一臂之力。
許多軟件項目不但很龐大，而且分散在各地。有時候，項目在世界上不同地方開展。如果項目眼看就要完成，誰都不希望客戶驚訝地發現代碼沒有滿足他們的預期目標。應該早在開始構造軟件之前，就將示例代碼發送給客戶評審，并且記錄反饋意見。這些示例代碼應當切合實際、具有代表性，而不只是“Hello World”這樣的程序。
開發人員通常都有一大堆參考手冊、標準和框架，幫助自己順利完成項目。但是，即使已經在設計當中，編碼習慣方法也不是顯而易見的。可視化框架可以提供幫助。除非開發人員有實際的代碼示例，否則他們對于擬議項目的解釋可能會略有不同。一個項目有可能用不同方式來實現，示例代碼可以實現特定的編碼習慣方法，從而提供幫助。
為了編寫示例代碼，需要召集一隊專家（技術專家和功能專家），從待開發應用軟件的問題領域確認簡單及復雜的用例。并且基于現有設計，請這些專家提出實現方法即模板。下面筆者列出了編寫這部分代碼的一些技巧：
● 代碼應當包含立即可用的構建和部署腳本。否則，時間就會白白浪費在構造階段解決這些問題上。
● 項目的基本目錄結構應當為開發人員備好，基本目錄結構可能含有項目中使用的各種庫。
● 模板代碼應當遵循將在項目中使用的命名規范、編碼風格、標準和框架。
● 模板代碼應當遵循明確定義的Javadoc模板（譬如基于Eclipse的Javadoc模板），這種模板可以讓開發人員知道如何編寫Javadoc。編寫良好的Javadoc很重要，這是因為它們通常是現有代碼的維護和改進團隊惟一可以使用的文檔。
● 編程語言中明確定義的編碼習慣方法應當用于模板代碼，這有助于開發人員編寫高效代碼。
● 模板代碼應當定義使用框架的標準方法。對開發新手來說，在最初的構造階段編寫針對特定框架的實現類可能是件困難的任務。示例代碼有助于理解這些概念。即使某個框架方面有許多文檔資料，要弄清楚如何有效編寫代碼也并不總是件易事。
● 模板代碼還應當展示如何使用JUnit或者其他測試框架編寫測試用例。
● 為了避免客戶最后大吃一驚，客戶的技術團隊也應當檢查這些代碼，這樣他們更清楚在構造階段結束后獲得的代碼質量。
● 模板代碼應當包括端到端的用例，也就是從表示層到數據層。
● 應當詳細介紹模板代碼，好讓開發人員熟悉它們的細節。開發人員應當明白每一層需要做哪些工作，還要知道使用了（或者可以使用）哪些編碼習慣方法和最佳實踐以及原因。
有效的開發手冊
假設我們必須執行一個龐大的項目，經常需要30人到50人。不是所有的開發人員都掌握了要用到的技術和標準。一個項目可能涉及不同的技術及專有框架，它們可能用于將來的Java Enterprise Edition項目。如何在開發人員之間轉移這么龐大的知識量是一大難題。這里有一些事項需要注意：
許多大項目的開發時間很長（一兩年）。一個不爭的事實是：軟件行業的人員流失率相當高。這是基本事實，也是一個挑戰。招聘新人可能很容易，但是轉移知識卻是項艱巨任務，要是項目時間緊張，更是如此。
一些開發人員可能不具備預期的技能水平。如今，及時找到技能嫻熟的開發人員相當困難。如果項目期限很急，這些開發新手就沒有時間去學習那些厚厚的技術書籍或者參考手冊。有些人可能非常聰明、能干，會另外抽出時間去學習及運用這些概念，但不能保證所有人都是如此。
維護一個剛完工的軟件項目也是一大難題。開發周期結束后，客戶的IT團隊可能會自己維護代碼。對這些人來說，熟悉技術架構、對架構進行改動可能是一項重大任務。除非轉移知識的方式有了明確規定，否則IT團隊在一開始仔細查閱代碼和設計文檔時可能會經常碰壁。
開發手冊應當能解決上面提到的問題。那么，我們如何編寫有效的開發手冊呢？
以下是編寫有效的開發手冊的一些技巧:
● 開發手冊應當包含構建開發環境所必要的所有相關信息。
● 語句應當簡潔、易讀。如果閱讀的人發現手冊讀起來費解，這是編寫者而不是閱讀者的失敗。
● 開發手冊應當包含大量示例。示例可以清楚地表明手冊內容。
● 請一位不熟悉項目中所用技術的開發人員來檢查手冊。這樣一來，如果手冊內容讓人困惑或者含糊不清，可以在其他人使用之前寫清楚。
● 作為低層設計階段的一部分，手冊應當準備好。而且在構造階段開始時，手冊可隨時供人使用。
● 手冊應當包括多少信息？如何在信息過多和信息過少之間求得平衡？開發人員不喜歡讀厚厚的手冊。但同時，開發手冊中不能遺漏必要的信息，以免許多地方含糊不清。要認真考慮開發人員的實際需求，而不是單單考慮可以提供的所有信息。在編寫手冊時應當使用簡單直觀、逐步漸進的方法。
● 開發手冊應當界面直觀，而不是內容分散、凌亂。手冊內容的組織方式應當與現實中開發項目時需要閱讀信息的先后步驟一致。譬如說，在Java企業項目中，開發人員首先會構建開發環境，然后開始為表示層和應用數據層編寫代碼。手冊應當遵循這樣流程的步驟。
● 確保手冊不會讓開發人員覺得困惑。譬如說，如果開發人員在編寫Struts動作類時需要使用特定的XDoclet標記，他就應當明白項目中使用的標記、意義及使用方法。如果想了解詳細信息，他總是可以參閱參考手冊。
下面我們看一個Java企業項目所用的實際開發手冊是什么樣的，它應當包括以下細節：
● 構建細節：每當開發新手加入項目，他必須構建開發環境，之后才能開始工作。別以為開發人員明白項目大大小小的細節。譬如說，要是項目結合使用Eclipse和Weblogic來創建Web應用，開發新手甚至可能不清楚Eclipse或者Weblogic為何物。因此，構建細節應當是開發手冊的第一部分。只要稍具Java基本知識的開發新手應當能夠很容易按手冊構建開發環境。
● 表示層細節：開發人員在處理用例時，通常從表示層開始著手。應當在開發手冊中給出創建表示組件的特定步驟。譬如說，如果某項目使用Struts作為表示框架，手冊中應當包含定義編寫動作類和表單類的步驟。如果項目使用XDoclet來創建struts-config.xml及其他配置文件，手冊中也應當包含這些步驟。還應當包含Java服務器頁面（JSP）方面的類似步驟。按照模型－視圖－控制器模式，JSP頁面不應當含有任何Java邏輯。但是對初學或者中級開發人員來說，如何使用JSP標準標記庫（JSTL）來真正做到這點可能是個比較大的問題。手冊中用一些實際示例表明如何在JSP頁面中使用JSTL也有所幫助。
● 業務層細節：業務邏輯可以用無狀態Enterprise JavaBeans組件、基于Spring的組件或者簡單的普通Java對象來編寫。手冊提供了項目中使用的業務組件的框架代碼以及實際示例。
● 數據層細節：手冊為編寫Java數據庫連接性（JDBC）、Hibernate或者基于框架的其他任何數據訪問對象（DAO）提供指導準則，然后包含項目中使用的步驟及最佳實踐，這最終取決于項目使用的持久性機制。
● 其他細節：手冊提供了有關內部/外部組件的信息，不管J2EE項目中使用哪一層。有可能包含日志、電子郵件組件、審查和安全等信息。另外，在項目后期階段，手冊可能包含介紹如何擴展一些業務需求的章節。譬如說，如果使用了批處理框架，如何對其進行擴展獲得新的批處理等。
自動化代碼檢查
代碼檢查是另一個問題。如果大批量地生成代碼，就需要不斷檢查代碼。即使可能已經為代碼檢查定義了一套規則，還是有許多問題沒有辦法在這些規則中加以描述及限制。根據個人的能力和經驗，每個人都有自己的代碼檢查方式。另外，有些問題很小，無法逐行檢查。如果需要檢查的代碼很多，這些小問題可能會在某個地方被忽略。如果錯誤隱藏在集成開發環境（IDE）本身里面該怎么辦？有些工具有助于查找這些問題，用不著手動查找。
● Eclipse IDE的設置
有時候，IDE設置可以提供幫助。譬如說，可以修改Eclipse IDE里面的參數選項。萬一代碼出現了問題，可以顯示警告。圖1是在Eclipse中改變參數選項的示例。
圖1 Eclipse Javadoc設置
如果仔細看一下，就會發現Eclipse會在IDE本身里面顯示警告，這樣開發人員就可以改正。萬一項目標準很嚴格，就會顯示錯誤，迫使開發人員改正問題。
● Jlint
同樣，名為Jlint的一個工具可結合Eclipse使用，查找代碼中的細小問題。可以采用以下步驟來使用Jlint：
首先，下載jlint插件和二進制代碼，把二進制代碼解壓縮到C:\lint文件。另外把插件解壓縮到Eclipse插件目錄。
然后，運行Eclipse, 進入“窗口”菜單，先后選擇“參數選項”、Java和Jlint，把Jlint位置設為C:\jlint\jlint.exe。
最后，用鼠標右鍵點擊“資源”視圖中的Eclipse項目，然后選擇Jlint。工作區構建完畢后，就會出現黃色的警告標記。
圖2 是Eclipse中有關Jlint設置的示例。
圖2 Eclipse Jlint配置
● Lint4j
如果不依靠IDE，可以使用Lint4j的Ant腳本來發現代碼中的問題。需要為這個腳本指定以下參數：
lint4j.dist.dir：安裝lint4j發布包的目錄
packages：Lint4j檢查的Java軟件包
ignorePackages: lint4j忽略的Java軟件包
以下是Jlint的Ant構建腳本的示例：
< ?xml version="1.0"?>
< project name="Lint4j" default="lint4j" basedir=".">
< property name="lint4j.dist.dir" value="C:/tools/lint4j-0.8.2"/>
< property name="lint4j.level" value="5"/>
< property name="lint4j.exact" value="false"/>
< taskdef name="lint4j" classname="com.jutils.lint4j.ant.Lint4jAntTask">
< classpath>
< pathelement location="${lint4j.dist.dir}/jars/lint4j.jar" />
< /classpath>
< /taskdef>
< target name="lint4j" description="Run Lint4j on your source">
< lint4j ignorePackages="" packages="com.domain.*" level="${lint4j.level}" exact="${lint4j.exact}">
< sourcepath>
< dirset dir=".">
< include name="**/src" />
< /dirset>
< /sourcepath>
< classpath>
< pathelement location="C:/bea/weblogic81/server/lib/weblogic.jar" />
< fileset dir=".">
< include name="**/*.jar" />
< include name="**/*.zip" />
< /fileset>
< fileset dir="ejblib">
< include name="**/*.jar" />
< /fileset>
< fileset dir="lib">
< include name="**/*.jar" />
< /fileset>
< /classpath>
< formatters>
< formatter type="text" />
< formatter type="text" toFile="./target/lint4j.log"/>
< /formatters>
< /lint4j>
< /target>
< /project>
● Checkstyle
代碼檢查的另一個工具是CheckStyle，它遵循Java開發高手普遍采用的重要的Java編碼準則來檢查代碼。它也可以結合Ant腳本使用。CheckStyle的選項配置起來具有很大的靈活性，可用來支持幾乎任何編碼標準。提供的示例配置文件支持Sun的編碼規范。這個Ant腳本可以讓代碼檢查同編譯過程一起完成，以便開發人員了解這些錯誤，并加以改正。
結論
軟件開發項目中通常面臨的問題大多數是重復出現的。在如今充滿競爭的世界——縮短開發時間、降低開發成本的壓力很大，所以沒有時間為每個項目重新設計解決方案。
本文沒有提供解決所有軟件執行問題的辦法，它只是向前邁出了一步。本文旨在演示了使用最佳實踐作為軟件開發的高效工具。事先知道這些軟件執行方面的最佳實踐和模式，就可以準備好解決項目生命周期過程中可能出現的任何障礙。這也讓項目經理、架構師和開發人員能夠把精力集中在“實際”的開發，而不是應對意料不到的情況。（沈建苗 編譯）
鏈接:模板代碼的好處
● 開發人員獲得了開始編寫代碼的參考資料。
● 客戶與開發人員就代碼的預期質量達成共識，從而避免了通常因雙方誤解而出現的那些問題。
● 開發人員擁有了開始編寫代碼的框架代碼（skeleton）。
● 開發人員更容易掌握框架以及將使用的任何外部API或者組件，提高了工作效率。
● 開發人員用不著不斷從事重復性工作。大多數最佳實踐和編碼習慣方法都擺在了他們面前，這再次可以提高工作效率。
（計算機世界報 2006年09月25日 第37期 B29、B30）