《解析極限編程——擁抱變化》讀書筆記二

　　此次談談讀了這本書關於開發團隊和項目管理方面的感想。針對開發團隊，XP提出了四個準則：溝通、簡單、反饋、勇氣 。項目中出現的問題無一例外老是出自那些不肯與別人探討重要問題的傢伙身上。溝通不良並非偶然發生的，有不少狀況會致使不良溝通。程序員向管理人員報告了一個壞消息，而管理人員卻遷怒於他。客戶告訴了程序員一些重要的事情，而程序員卻把它看成耳旁風。這些都會在項目中埋下很多的坑，因此XP須要僱傭一位教練，他的工做就是觀察你們何時沒有進行溝通，而後提醒你們。

　　行動及其反饋之間的間隔是學習的關鍵，二者的區別在於爲了勝利而比賽和爲了避免輸而比賽之間。我所見到的大多數開發都是爲了避免輸而比賽，寫了大量文章，開了不少會，每一個人都儘可能按「規章」開發，不是由於它特別有道理，而是由於他們想在最後可以說這不是他們的過錯，他們是遵守過程進行工做的。那麼，回到基本問題，咱們想從代碼中學到什麼呢？最重要的事情是學習。代碼還給了咱們進行簡潔明瞭交流的機會。若是你有一種想法並把它解釋給我聽，我可能很容易發生誤解。可是，若是咱們一塊兒對這想法進行編程，我能在你編寫的邏輯中精確地讀到你的想法。（so，不要說話，和我一塊兒敲鍵盤吧，一片沉寂是最好的氛圍）固然，我瞭解的並非你大腦中的想法，而是它們在外部世界中獲得體現後的樣子。

　　開發團隊中還有一個重要的角色，測試。任何不能度量的事物都是不存在的。一樣，不能使用自動化測試證明的軟件也是不存在的。在測試前，我不相信任何本身編寫的東西。測試提供了一個機會，使我能夠不用考慮如何實現，只考慮我想要什麼，而後測試會告訴我是否實現了我認爲我實現的東西。有的測試出於責任感，有的是應別人要求。

     編程和測試相結合也比只編程快。作測試能節省調試的時間，你不須要花費一個小時來查找錯誤，你能夠在幾分鐘以內找到它，這就是生產率提升的來源。

     開發過程當中還離不開設計，設計就是建立組織系統中的邏輯的結構。好設計的組織邏輯是，對系統中某一部分的更改是不須要對其餘部分進行修改的。好的設計能夠確保系統中的每一部分邏輯有且只有一個「家」。糟糕的設計：一個概念性的修改須要對系統中的不少部分進行更改，若是不破壞現有的功能就沒法添加新的功能。

     所以，好的項目前期須要作大量的設計，有效的溝通，制定良好的計劃，才能夠開始開發，測試結束收尾，發佈項目。