Simon Brown，集開發(fā)者、架構師及作家于一身，他認為成功的項目需要的不僅僅是好代碼。在他的演講《好代碼是不夠的》中，Brown討論了項目成功所需的所有元素，從前期設計到操作文檔。

Brown認為好代碼是一個好的開始，但要取得成功，人們需要知道要構建什么、要發(fā)布什么以及它可以運作起來。

要知道構建什么，需要一套需求。收集完需求之后，要有一個“大局觀”，軟件架構代表了當前對該產品的認識。然后，大問題需要被分解成更小的解決方案，其中包含了組件、組件之間的交互以及用到的服務。隨后，估計實現(xiàn)這個解決方案需要多少成本。據(jù)Brown說，所有這一切，從確定需求到做出估算，只要1-2天。這不是一個人的工作，應該是所有直接參與的人共同完成，這樣才能群策群力。

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

接下來的步驟是確定優(yōu)先級。除非是一個小項目，否則不該試圖一步到位構建并發(fā)布整個項目，而是應該確定什么是最重要的，首先完成這部分。這需要完善并挑戰(zhàn)需求范圍，決定實現(xiàn)需求的一個子集，它足以滿足最初設想的愿景的一部分內容。

其次是跟蹤進度。跟蹤進度有不同的方法，例如電子表格或看板。Brown指出，這些方法都是用來了解迭代進行到目前為止的進度完成情況的，它們并不跟蹤已發(fā)布的軟件。

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

• 它能滿足架構需要：功能和非功能性需求、環(huán)境約束和所采用的原則
• 它為代碼提供了一個堅實的基礎，人們可以在此之上進行構建
• 它為解決解決方案中試圖描述的初始業(yè)務問題提供了一個平臺

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

負載測試是這樣實現(xiàn)的，“模擬典型使用場景中的多個用戶，并且環(huán)境越接近生產越好”。原型和負載測試要在項目的早期階段進行，用于驗證架構。

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

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

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

Brown認為還有一個有用的步驟，即使用持續(xù)集成。持續(xù)集成服務器能自動從代碼庫中獲取源代碼、編譯、測試、打包并安裝，在此過程中出現(xiàn)任何錯誤它都會發(fā)出通知。這有助于確保代碼的正確構建，及早發(fā)現(xiàn)問題。