文章目錄
Code
類的實現(理想情況下,還包括完整的單元測試)要按照從耦合度最低到耦合度最高的順序來完成.
TDD
邏輯就是讓人充滿信心地得出錯誤結論的方法
TDD的有點
- 使程序員獲得滿足感從而更始終如一的堅持編寫測試
如果先編寫測試,我們會感覺在面前存在具有價值的挑戰和問題- 有助於澄清接口和行爲的細節
如果你在測試代碼中編寫了…你就必須要思考方法名稱,返回值,參數和行爲等公共視圖的細節
…
從上面第二條可以看出,在方法聲明還未明確的時候就需要單元測試.
需要注意的關鍵點是,我們沒有先爲Sale編寫所有的單元測試,我們只編寫了一個測試方法,在Sale類中實現該方法並確保通過測試,然後再反覆這一過程.
創建測試固件
按照約定命名爲fixture
通常定義爲實例字段而不是局部變量
Refactor
UML藍圖
在建模日之前,使用UML工具進行逆向工程,從代碼生成UML圖-包,類和交互圖.然後,對於感興趣的部分,用繪圖機在大型繪圖紙上打印出來.將其掛在建模室牆上比較高的地方,這樣在建模日時,開發人員就可以參考這些圖形,在上面畫草圖,同時在它們下面白板或膠片上畫草圖.
附上書中推薦的一個UML工具列表網站,但是裏面的工具都有些老.
繼續編碼
使用UP的過程成熟的標誌是,知道何時創建制品能夠帶來顯著價值,或者是當遇到呆板的"完成作業"式的步驟時能夠較好的略過.
準則當有下列情況時,創建超類的概念子類
- 子類具有我們感興趣的額外屬性
- 子類具有我們感興趣的額外關聯
- 對子類概念的影響,處理,反應和操作與超類或其他子類有顯著的差異.
準則將超類聲明爲抽象類
架構分析
定義
架構分析是指在功能性需求的語境中識別和解決非功能性需求
在UP中,架構性因素被記錄在補充規格說明(Supplementary Specification)中,解決這些需求的架構性決策被記錄在軟件架構文檔SAD中.UP不是瀑布,因此SAD不是在開始編程之前就完全創建好的.相反,代碼穩定之後,架構才完全穩定,這時SAD文檔記錄了系統的實際情況,可幫助其他人學習和了解
架構圖不是架構結果的精確表示,而是架構師思想的表達
質量
對性能以及平均故障間隔時間等的量化描述已經廣爲人知,質量場景擴展了這些思想,並鼓勵人們用可度量的陳述記錄所有因素
質量場景是形如<刺激><可度量響應>的簡短陳述.例如:
當銷售完成,調用遠程稅金計算器服務計算稅金時,在平均負載條件的生產環境下,大部分會在2秒之內完成
當NextGen Beta測試的志願者報告一個bug時,應在一個工作日內電話回覆
選擇你的戰鬥
factor table
FURPS
- functional
- usablity
- reliability
- performance
- supportability
H/M/L
- H
- M
- L
將各種架構上考慮的情況加以說明,並給出困難或風險的評級
藝術
收集和組織有關的架構性因素,可以稱爲架構的科學.根據相互依賴情況,優先級,權衡考慮等,做出解決這些因素的決定,可以稱爲*架構的藝術
現在不考慮做出架構選擇的原則,幾乎所有的方法都建議保存與重要問題和決定有關的信息
當然,上面的記錄不只是決定,好包括動機(架構師自己也會遺忘)和其他可供選擇的方案
post-compiler & aspect-oriented
後編譯器(在常規的編譯器之後執行的"編譯器")在後蓋後的…開發者只能看到僅包含"乾淨"的業務邏輯的類
另一種方法是諸如AspectJ這樣技術
引導架構決策的優先級
- 強制性約束
強制性的安全和法律規定 - 業務目標
商業價值等 - 所有其他目標
敏捷
計劃依次迭代
- 確定迭代的時間長度.迭代的結束時間一旦確定,就不應改變—這是時間定量的實踐.但是,可以通過減少本次迭代的工作範圍來滿足該結束時間
- 召集迭代計劃會議.這通常在上一次迭代完成而下一次迭代尚未開始時進行.在理想情況下,主要涉衆都應該參加:顧客(營銷人員,最終用戶),開發者,首席架構師和項目經理等
- 列出本次迭代的潛在目標並標記優先級
通常由客戶(代表業務目標)和首席架構師(代表技術目標)共同確定 - 每個成員爲本次迭代編制個人資源預算(以小時/天爲單位)
- 對於某一目標,在計劃中對其進行較爲詳細的描述,並分解其對應的問題.接着進行頭腦風暴
- 反覆進行第5步直到確定足夠多的工作
可以看出來,架構師的價值不在於解決問題,而是指明方向
Phase Plan & Iteration Plan
可以讓外部涉衆看到一個宏觀計劃(例如三個月),開發團隊對此作出承諾.但是,微觀的組織應該留給團隊的適應性判斷
UP是用例驅動,這意味着工作是圍繞用例的實現來組織的
通常用例有過多的可選場景,因此無法再一次迭代中全部完成,
準則
在每次迭代完成之後,使用版本控制工具爲這些文件夾中所有元素(包括源代碼)創建帶有標籤並且凍結的檢查點.這樣,每個製品都會有多個版本…以後(在該項目或其他項目中)估計團隊的開發速度時,這些檢查點爲每次迭代所完成的工作量提供了原始數據
何時你會發現自己並沒有理解迭代計劃
- 推測性詳細計劃了所有迭代,並且預訂了每次迭代的任務和目標
期望初始階段或者細化階段第一次迭代中的預算是可靠的,且被用於長期的項目承諾
在早期迭代階段解決容易或者低風險的問題