艾偉也談項目管理，隻有好代碼的項目能成功嗎？

　　Brown認為好代碼是一個好的開始，但要取得成功，人們需要知道要建構什麼、要釋出什麼以及它可以運作起來。

　　要知道建構什麼，需要一套需求。收集完需求之後，要有一個“大局觀”，軟體架構代表了目前對該産品的認識。然後，大問題需要被分解成更小的解決方案，其中包含了元件、元件之間的互動以及用到的服務。随後，估計實作這個解決方案需要多少成本。據Brown說，所有這一切，從确定需求到做出估算，隻要1-2天。這不是一個人的工作，應該是所有直接參與的人共同完成，這樣才能群策群力。

　　如果做得好，一個輕量級的軟體架構能為項目引入結構——“什麼是元件以及它們如何互相溝通”——與指導方針——“源自文檔模式、模闆和原則”，這能帶來一緻性——“以标準的方法來解決常見問題”——與清晰性——人們能知道自己的方向，因為他有“大局觀”。作為一個反例，Brown提到一個項目，其中使用了三種持久化解決方案：Spring、EJB和Hibernate。這是因為沒有人事先決定使用什麼持久化架構。

　　接下來的步驟是确定優先級。除非是一個小項目，否則不該試圖一步到位建構并釋出整個項目，而是應該确定什麼是最重要的，首先完成這部分。這需要完善并挑戰需求範圍，決定實作需求的一個子集，它足以滿足最初設想的願景的一部分内容。

　　其次是跟蹤進度。跟蹤進度有不同的方法，例如電子表格或看闆。Brown指出，這些方法都是用來了解疊代進行到目前為止的進度完成情況的，它們并不跟蹤已釋出的軟體。

　　架構是否可以運作起來？如果作為結果的解決方案無法如預期那樣運作，那一切都是徒勞的。Brown認為，對于一個可用的解決方案而言，它必須滿足以下要求：

它能滿足架構需要：功能和非功能性需求、環境限制和所采用的原則

它為代碼提供了一個堅實的基礎，人們可以在此之上進行建構

它為解決解決方案中試圖描述的初始業務問題提供了一個平台

　　建構一個原型。無論架構有多偉大，代碼看起來有多漂亮，沒人真正知道系統是否能令人滿意，是否可以擴充。原型正是人們所需要的。原型是對概念的一個驗證，包含系統的垂直切片、主要需求和基礎部分，剛好用于模拟實際運作，通過負載測試将整個系統至于壓力之下。用于原型的代碼後期可用于生産環境，也可丢棄。

　　負載測試是這樣實作的，“模拟典型使用場景中的多個使用者，并且環境越接近生産越好”。原型和負載測試要在項目的早期階段進行，用于驗證架構。

　　源碼控制提供了：源代碼備份、代碼變更日志、恢複到不同版本的機制、經簡化的并行開發方式，使用源碼控制是建構解決方案中的重要一步。

　　自動化測試也是必不可少的一塊。剛加入的新代碼會破壞什麼東西嗎？對項目某個部分的變更可能會對其他部分産生負面影響。為了限制變更可能造成的破壞，單元測試和內建測試是必須的，否則就要在每次變更後手動測試整個系統的功能。要做多少測試呢？Brown認為，100%的測試覆寫率是很難做到的，非常不切實際，他建議80%，覆寫代碼最重要的部分。

　　自動化建構。代碼經過測試後，需要在目标機上進行建構和部署。但很多時候，系統在其他機器上無法進行建構，建構腳本需要保證該系統可在任意目标機上正常建構。

　　Brown認為還有一個有用的步驟，即使用持續內建。持續內建伺服器能自動從代碼庫中擷取源代碼、編譯、測試、打包并安裝，在此過程中出現任何錯誤它都會發出通知。這有助于確定代碼的正确建構，及早發現問題。

　　自動化測試和建構引入了一緻性和可重複性。在多代碼分支上進行并行開發時，自動化就更加有用了。

　　提取配置資訊。系統配置資訊取決于環境，最好将它放在代碼之外進行維護。

　　應用程式的版本應該包含在某處：在中繼資料中、在診斷頁面中、在日志檔案中，這樣人們才能知道自己正在看哪個版本的程式。

　　最後就是操作文檔。如果開發團隊不是支援該軟體的團隊，那麼有些操作文檔是必須的，其中包含的資訊涉及如何使用系統、如何監控系統、如何管理系統以及有問題時如何進行診斷。

　　所有這些有助于創造一個成功産品的元素都包含在下圖中了：