[書摘]《敏捷軟件開發: 原則、模式與實踐》第一部分:敏捷開發

面向對象設計的原則

• 單一職責
• 開放-封閉
• Liskov替換原則
• 依賴倒置原則
• 接口隔離原則
• 重用發佈等價原則
• 共同封閉原則
• 共同重用原則
• 無環依賴原則
• 穩定以來原則
• 穩定抽象原則

人的重要性

• 交付產品的關鍵因素是人，而不是過程。（敏捷 Agile）
• 人與人之間的交互式複雜的，而且其效果歷來都是難以預期，但倒是工做中最爲重要的方面。
  ------ Tom DeMacro 和 Timothy Lister《人件》
• 有凝聚力的團隊將具備最強大的軟件開發力量。

敏捷軟件開發宣言

咱們一直在實踐中探尋更好的軟件開發方法，身體力行的同時也幫助他人。由此咱們創建了以下價值觀：

個體和互動 高於 流程和工具
工做的軟件 高於 詳盡的文檔
客戶合做 高於 合同談判
響應變化 高於 遵循計劃

也就是說，儘管右項有其價值，咱們更重視左項的價值。

• 個體和互動 高於 流程和工具

  • 合做、溝通以及交互能力要比單純的編程能力更重要。
  • 適合的工具也很重要：編譯器、IDE、源碼控制系統（git?）
  • 首先致力於構建團隊，而後再讓團隊基於須要來配置環境。

• 工做的軟件 高於 詳盡的文檔

  • 文檔應當是短小而且主題突出的。應該僅論述系統的高層結構和歸納的設計原理。
  • 給新成員知識傳遞最好的文檔是代碼和團隊。

• 客戶合做 高於 合同談判

  • 成功的項目須要有序、頻繁的客戶反饋
  • 讓軟件的客戶和開發團隊密切地一塊兒工做，並常常地提供反饋。

• 響應變化 高於 遵循計劃

  • 確保計劃是靈活的而且易於適應商務和技術方面的變化。

  • 較好的計劃策略：

    • 爲下兩週作詳細的計劃
    • 爲下三個月作粗略的計劃
    • 再之後就作極爲粗糙的計劃

敏捷宣言12條原則

敏捷實踐12 條原則，它們是敏捷實踐區別於重型過程的特徵所在。

• 咱們最優先要作的是經過儘早的、持續的交付有價值的軟件來使客戶滿意。
• 即便到了開發的後期，也歡迎改變需求。敏捷過程利用變化來爲客戶創造競爭優點。
• 常常性地交付能夠工做的軟件，交付的間隔能夠從幾個星期到幾個月，交付的時間間隔越短越好。
• 在整個項目開發期間，商務人員和開發人員必須每天都工做在一塊兒。
• 圍繞被激勵起來的個體來構建項目。給他們提供所需的環境和支持，而且信任他們可以完成工做。
• 在團隊內部，最具備效果而且富有效率的傳遞信息的方法，就是面對面的交談。
• 工做的軟件是首要的進度度量標準。
• 敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該可以保持一個長期的、恆定的開發速度。
• 不斷地關注優秀的技能和好的設計會加強敏捷能力。
• 簡單——使未完成的工做最大化的藝術——是根本的。
• 最好的構架、需求和設計出自於自組織的團隊。
• 每隔必定時間，團隊會在如何才能更有效地工做方面進行檢討，而後相應地對本身的行爲進行調整。

極限編程實踐

極限編程（eXtreme Programming，簡稱XP）是敏捷方法中最著名的一個。它由一系列簡單卻互相以來的實踐組成。這些實踐結合在一塊兒造成了一個勝於部分結合的總體。

• 客戶做爲團隊成員。

• 用戶素材

  • 它是一個計劃工具，客戶可使用它並根據它的優先級和估算代價來安排實現該需求的實踐。
• 短交付週期

• 驗收測試

  • 能夠以客戶指定的驗收測的形式來捕獲有關用戶素材的細節。

• 結隊編程

  • 全部產品代碼都是由結隊的程序員使用同一臺電腦共同完成的。

• 測試驅動的開發方法

  • 編寫全部產品代碼的目的都是爲了使失敗的單元測試可以經過。面向對象設計的原則在進行這種解除耦合方面具備巨大的幫助做用。

• 集體全部權

  • 沒有程序員對任何一個特定的模塊或技術單獨負責，每一個人都參與各個方面的工做。

• 持續集成

  • XP團隊天天會進行屢次系統構建，他們會從新建立整個系統。

• 可持續的開發速度

  • XP團隊必需要以一種可持續的速度前進，必需要有意識地保持穩定、適中的速度。
  • XP的規則是不容許團隊加班工做。在版本發佈前的一個星期是該規則的唯一例外。

• 開放的工做空間

  • 在充滿積極討論的屋裏工做，生產率非但不會下降，反而會成倍地提升。

• 計劃遊戲

  • 計劃遊戲的本質是劃分業務人員和開發人員之間的職責。業務人員(客戶)決定特性的重要性，開發人員決定實現一個特性所花費的代價。
• 簡單的設計

• 重構

  • 重構就是在不改變代碼行爲的前提下，對其進行一系列小的改造，旨在改進系統結構的實踐活動。
  • 每一個改造都是微不足道的，可是這些全部的改造迭加在一塊兒，就造成了對系統設計和架構顯著的改進。
  • 每次重構進行完後，必須運行單元測試，保證重構沒有形成任何破壞，而後再去作下一次重構。並且，重構是持續進行的。

• 隱喻

  • 隱喻是將整個系統聯繫在一塊兒的全局視圖，它是系統的將來景象，是它使全部單獨模塊的位置和外觀變得明顯直觀。

• 結論

  • 極限變成是一組簡單、具體的實踐，這些實踐結合在一塊兒造成了一個敏捷開發過程。

計劃

• 初始探索

  • 在項目開始時，開發人員和客戶會盡可能肯定出全部真正重要的用戶素材。
  • 隨着項目進展，客戶會不斷編寫新的用戶素材。
  • 素材的編寫會一直持續到項目完成。
  • 開發人員共同對這些素材進行估算。估算是相對的，不是絕對的。

• 探究、分解和速度

  • 任何過大的用戶素材都應該分解成小一點的部分。任何太小的用戶素材都應該和其它小的素材合併。
  • 當分割或合併一個用戶素材後，應該對其從新進行估算。
  • 對一個用戶素材進行分解或者合併的主要緣由爲了使其大小適於被準確地估算。
  • 速度因子將用戶素材的估算點數乘以速度獲得實現該用戶素材的實際開發時間。
  • 計算團隊的開發速度。花費幾天時間去原型化一到兩個用戶素材來了解團隊的速度。

• 發佈計劃

  • 客戶挑選在該發佈中她們想要實現的素材，並大體肯定這些素材的實現順序。
  • 客戶不能選擇與當前開發速度不符的更多的素材。
  • 當開發速度變得更準確一點時，能夠再對發佈計劃進行調整。

• 迭代計劃

  • 迭代期間用戶素材的實現順序屬於技術決策範疇。
  • 一旦迭代開始，客戶就不能再改變該迭代期內須要實現的用戶素材。
  • 即便沒有完成全部的用戶素材，迭代也要在預先指定的日期結束。
  • 經過速度反饋計算來保持計劃與團隊實際情況相同步。

• 任務計劃

  • 在新的迭代開始時，開發人員和客戶共同制定計劃。

    開發人員把用戶素材分解成開發任務，一個任務就是一個開發人員可以在4～16小時（半天～兩天）以內實現的功能。
    開發人員在客戶的幫助下對這些用戶素材進行分析，並儘量徹底地列舉出全部的任務。

  • 迭代中點

    在迭代進行到通常的時候，本次迭代中所安排的半數用戶素材應該被完成。
    若是沒有完成，那麼團隊應該設法從新分配沒有完成的任務和職責，以保證在迭代結束時可以完成全部的用戶素材。
    目標是要完成用戶素材，而不只僅是任務。
    在迭代的中點，但願看到擁有一半素材點數的完整的用戶素材被完成。

• 迭代

  • 每兩週，本次迭代結束，下次迭代開始。
  • 在每次迭代結束時，會給客戶演示當前可運行的程序。
  • 要求客戶對項目程序的外觀、感受和性能進行評價。
  • 客戶會以新的用戶素材的方式提供反饋。

• 結論

  • 經過一次次的迭代和發佈，項目進入了一種能夠預測的、溫馨的開發節奏。
  • 開發人員看到的是基於他們本身估算而且由他們本身度量的開發速度控制的合理的計劃。
  • 管理人員從每次迭代中獲取數據，他們使用這些數據來控制和管理項目。
  • 使用敏捷方法並不意味着涉衆就能夠獲得他們想要的。它只不過意味着他們可以控制着團隊以最小的代價得到最大的商業價值。

測試

• 編寫單元測試是一種驗證行爲，也是一種設計行爲，更是一種編寫文檔的行爲。

• 測試驅動的開發方法

  • 程序中的每一項功能都有對應的測試來驗證他的操做的正確性。
  • 編寫測試可使開發人員使用不一樣的觀察點。
  • 迫使開發人員把程序設計爲可測試的。

  • 測試能夠做爲一種無價的文檔。

    測試就像一套範例，它幫助其餘程序員瞭解如何使用代碼。
    單元測試是可編譯、可運行的有關係統內部結構的文檔。它始終保持最新，不會和產品程序不一樣步。

• 測試促使模塊之間隔離
• 意外得到的解耦合

• 驗收測試的功能

  驗收測試是用來驗證系統知足客戶需求的黑盒測試。
  爲了使系統具備可測試性，就必需要在很高的系統構架層面對系統進行解耦合。

• 結論

  • 驗證是編寫測試的好處之一。
  • 測試時文檔的形式，簡單易懂，準確可靠。

  • 測試還可以對架構和設計進行影響。

重構

• 重構的目的是使每個軟件模塊都具備下列三項職責：

  • 第一個職責是每個軟件模塊運行起來所完成的功能。
  • 第二個職責是每個軟件模塊要應對變化。
  • 第三個職責是每個軟件模塊要和閱讀它的人進行溝通。
• 原則和模式能夠幫助開發人員建立更加靈活和具備適應性的軟件模塊。
• 可是要使軟件模塊易於閱讀和修改，就不只須要原則和模式，還須要紀律約束和開發人員創造美的激情。
• 通常方法名是一個動詞短語，類名是一個名詞短語。

• 多個細小的重構以後，要再所有讀一遍產品代碼。

  由於重構的都是代碼片段，最後再讀一遍能夠看看把這些片段結合在一塊兒是不是一個具備可讀性的總體。

• 重構和單元測試密不可分。

  每次小碎步的重構以後，都要確保產品代碼能正確經過單元測試。

• 爲重構投入的時間和隨後爲本身和他人節省的努力相比起來是很是少的。
• 用重構來保持代碼的清潔。

一次編程實踐

• 讓程序遵循原則的事情，能夠稍後交給重構作。而不須要在最初的設計階段就很當心的讓程序遵循原則。
• 先使程序更易讀。再繼續向程序中添加更多功能。
• 不只產品代碼須要重構，測試代碼也須要重構。
• 經過重構，儘可能使產品代碼的結構更像易讀的僞代碼。
• 最好的設計是首先編寫測試，而後一小步一小步前進時逐漸造成的。