物件導向原則、設計模式與C#實踐(無暇的程式碼-敏捷完整篇) 練習與筆記

發表於 | | 閱讀次數:

物件導向原則、設計模式與C#實踐(無暇的程式碼-敏捷完整篇) 練習與筆記

書籍介紹

物件導向原則、設計模式與C#實踐(無暇的程式碼-敏捷完整篇)

本書分為四個部分，第一部分詳述了敏捷開發的精神與觀念，第二部分闡述什麼是敏捷設計，主要圍繞在物件導向的設計原則，比較特別的是，作者將他的另一本UML書的章節部分搬移過來這本書中，介紹了UML中幾個重要的圖形，UML是為了要讓程式設計師知道自己的設計是否可行。第三與第四部份將前面兩個章節提過的主題，透過一個大型的程式碼範例來運用，讓你能夠更深入理解這些主題，進而運用在自己的程式設計中，我自己覺得這是一本很值得花時間細讀的書。

敏捷軟體開發宣言

  • 個人與互動 重於 程序與工具
  • 可用的軟體 重於 詳盡的文件
  • 與客戶合作 重於 合約的談判
  • 回應變化 重於 遵循計畫

雖然右邊的項目也有其價值，但我們認為左邊的項目更加重要

個人與互動 重於 程序與工具

  • 人是獲得成功的最關鍵因素
  • 一個優秀的團隊成員可能只具備一般技術水準，但卻是個與他人合作良好的程式設計師
  • 良好的合作(溝通與互動)比程式設計能力更加重要
  • 建構團隊比建構環境重要，要先致力於建構團隊，再來讓團隊基於需要來設置環境

可用的軟體 重於 詳盡的文件

  • 不是不寫文件，而是要寫人類容易讀懂的文件，包含對系統及設計決策依據的描述
  • 文件要短小(不超過20頁)與凸顯主題(系統的最高層結構和概括的設計原理)
  • 對於新的團隊成員，最好的文件是程式碼與團隊
  • 太過於注重文件而非軟體本身，導致進度延遲。直到迫切需要且意義重大時，才撰寫文件(Martin文件第一定律)

與客戶合作 重於 合約的談判

  • 只寫下對軟體的描述，請人在固定時間、固定價格開發，最終都會宣告失敗
  • 成功的專案需要定期且頻繁的客戶回饋，讓團隊與客戶緊密的一起工作，盡可能經常提供回饋

回應變化 重於 遵循計畫

  • 建置計畫時，要確保計劃本身具備足夠靈活性，能夠適應商務和技術面的變化
  • 為下一周做詳盡計畫，下3個月做粗略計畫，再往後只做極為簡略的計畫，保持靈活性

原則

從上面的價值觀，引導出原則

  1. 我們最優先的任務，是透過及早且持續交付有價值的軟體來滿足客戶需求
  • 初期交付的系統包含的功能越少，最終交付品質就越高
  • 交付的越頻繁，最終產品品質就越高

  1. 我們竭誠歡迎客戶改變需求，即使已經到了開發後期。敏捷程序能夠駕馭變更，為客戶創造競爭優勢

  2. 經常交付可以工作的軟體，交付頻率可以從幾個星期到幾個月，而時間間隔則是越短越好

  • 交付滿足客戶需要的軟體
  1. 業務人員與開發人員必須在專案開發的過程中，天天在一起工作
  2. 依靠鬥志高昂的人來建置專案，並給予他們所需的環境與支援，信任他們能夠完成工作
  3. 在團隊內部，效率最高的且效果最佳的傳遞方式，是面對面交談
  4. 可以工作的軟體是進度最主要的量測標準
  5. 敏捷程序提倡可持續的開發，贊助者、開發者和使用者應當總是保持穩定的開發速度
  6. 持續追求卓越的技術和良好的設計，將有助於提高敏捷性
  7. 精簡-將未完成的工作量最大化的技藝，是不可或缺的
  8. 最佳的架構、需求、與設計都源自於能夠自我組織的團隊
  9. 每隔一段固定的時間，團隊會定期檢討如何能更有效率，然後依照檢討結果，適當的調整與修正自己的行為

XP極限程式設計實踐

完整團隊

  • 客戶、管理者、開發人員緊密的在一起工作
  • 客戶是指定義產品特性並安排這些特性優先順序的人或團體

使用者故事(User Stories)

  • 用來輔助正在進行、關於需求的談話，是一種做計劃的工具，客戶可以使用他並根據需求優先順序與預算，進行實現需求的時程規劃

短的交付週期

  • 每兩周交付一次可以工作的軟體
  • Iteration計畫：由一組使用者故事組成
  • 發布計畫：大約是六輪的iteration(12周 或 3個月)

驗收測試

  • 描述了每個需求的細節，用來驗證這些需求是否被正確完成的依據
  • 驗證測試通過後，將這個測試加入驗證集合，不允許測試再度失敗

結對程式設計(Pair Progamming)

  • 兩個程式設計師一個人開發，另一個觀看
  • 可以促進知識在團隊裡傳播
  • 不會降低效率，反而減少缺陷發生的機率

測試驅動開發(TDD)

  • 先撰寫測試程式，再開發產品程式碼使其通過測試
  • 非常有利於重構

集體所有權

  • 每個程式設計師都可以簽出任何模組並改善它，不對單獨的技術與模組負起全責

持續整合(CI)

  • 使用非鎖死特性的程式碼控制工具(分散式版控)
  • 避免程式碼合併時間過長，團隊成員會頻繁簽入模組
  • 合併產生衝突時，要與其他程式設計師協商，一旦整合完成就進行所有測試

可持續的開發速度

  • 團隊保持旺盛精力與敏銳的警覺

開放的工作空間

計畫遊戲

  • 劃分業務和開發之間的職責
  • 業務人員決定特性的重要性
  • 開發人員決定實現一個特性所花的代價

簡單設計

  • 考慮能夠工作的最簡單的事情
  • 在非常確定引入基礎設施會帶來更大的效益時在引入它
  • 不能容忍重複的程式碼

重構

  • 隨著持續開發，程式碼結構會逐漸退化，這時候就需要重構來扭轉這些退化
  • 重構是持續進行的

隱喻

  • 將系統維繫在一起的全域視圖(概觀或藍圖的意思)

物件導向設計原則

  • 單一職責原則：一個類別應該只有一個發生變化的原因
  • 開放封閉原則：對擴充開放，對修改封閉
  • Liskov替換原則：子型態必須能夠替換掉他們的基底型態
  • 依賴反向原則：抽象不應該依賴細節。細節應該依賴抽象
  • 介面隔離原則：不應該強迫客戶程式依賴他們未使用的方法

結語

這本書真的滿多內容的，也有很多可以練習的範例，我自己是大部分都有實作，讓我更能掌握物件導向的設計原則與更了解敏捷開發的精神，是一本值得坐下來花時間看完的書

我附上我自己練習的程式碼，但沒有全部的範例的程式碼，若有需要書中的範例程式碼，請至作者的官方網站下載

AgilePrinciplesPractice