今天要講的書是由 David Scott Bernstein 編寫的《Beyond Legacy Code: Nice Practices to Extend the Life (and Value) of Your Software》，中文書名就如題所述，這本書一樣沒有繁中版本，所以我針對簡體書名做了點潤飾，換成了比較在地的用詞。

比起前面幾本書或體悟，多著重在整個流程或是團隊中。這本書更多的是以軟體開發為出發、更以開發者為出發，去探討在軟體工程與技術上，該怎麼去實踐敏捷。這是一個很好的拼圖片，而且是很重要的拼圖片。少了這塊拼圖片，我們就儘管前期能夠敏捷起來，但是難以長就，越到後期就會越來越笨重。就像是新陳代謝變慢、身體退化一樣，再也跑不太起來，就算我們在什麼是敏捷也一樣，陷入了力不重新的地步。而這本書提供的就是我們該如何在平時就鍛鍊我們身體，不讓他退化，你說，這是不是很重要？

九項實踐

這本書對於延續軟體生命和價值，提供了 9 種實踐方式。這些都有助於我們的軟體品質保持年輕，能夠隨著需求敏捷而動。

1. 在問如何做之前先問要做什麼、為什麼要做、為誰而做
2. 小批次建置
3. 持續整合
4. 協作
5. 編寫整潔的程式碼
6. 測試先行
7. 用測試描述行為
8. 最後實作設計
9. 重構遺留的程式碼

遺留的程式碼

敏捷的意思，就代表著反應快。但是若是我們拖著一堆包袱，那再厲害的人，也難以敏捷起來。對於一個開發者來說，遺留的程式碼 （Legacy Code)，就是像這樣的包袱。而遺留的程式碼是指舊的程式碼嗎？顯然不夠精準，舊的程式碼若是夠好維護，也不會成為包袱。那麼有什麼好的定義呢？ Micheael Feathers 大致是這麼說的：

遺留的程式碼，就是任何一個沒有測試的程式碼。

因為沒有測試，我們難以確保修改後能夠保持一致的行為、提早發現錯誤。沒辦法透過測試去暸解當初這個程式碼預期怎樣的行為。沒有測試的程式碼通常也會成長為一個無法測試的程式碼，而無法測試的程式碼也通常會與良好程式碼品質追求的原則相悖。漸漸的、漸漸的，這些程式碼就會難以維護、要撼動的成本極高，就變成遺留的程式碼，成為敏捷團隊難以快速反應的包袱。

我所學習到的

軟體開發是一個社交活動
這是一個很有趣的概念，有違社會對程式設計師的刻板印象：孤僻、不喜歡被打擾。但事實上軟體開發通常就是在處理複雜的問題，而複雜的問題難以只靠一個大腦解決，更多的是讓一群人透過溝通而去共創、去解決這個問題。

在軟體開發中，尤其是在敏捷開發中，我們重視「個人與互動」多於流程與工具。這樣的互動就代表著對話與交流，我想某種程度上也就是社交活動的意思。 XD

使用者故事無法取代需求文件。但它幫助產品複雜人和開發者展開對話，而這些對話取代了需求文件，使用者故事僅僅只是一個觸發的 Placeholder。

敏捷以使用者故事取代需求文件，我們建立使用者故事是為了引發對話，所以敏捷的真正目的是為了讓對話取代需求文件。
這部分與 User Story Mapping 提到的概念相應。但是這裡用 Placeholder 去譬喻我覺得非常貼切，讓我更能像夥伴們去解釋這個概念。

極限編程和 Scrum 都是和尼古丁貼片類似的東西。
迭代真正的目的是讓團隊消除以發布為單位的習慣。
一旦消除這個習慣，你就不再需要時間和子了。
這本書提到我們用迭代的方式進行，事實上季受用時間裡管理範疇，而追根究底，我們關注的是對範疇的管理。我認為這個概念是很有趣的，他重新讓我省思對時間盒的認知與本質，的確就像是敏捷的初衷，我們要小批次建置，而時間盒就讓我們對範疇限縮的標準。有點像是要搭飛機時，我們總會將行李箱放置在櫃檯旁的框框，去看看我們的大小是否超過一樣。

我從這本書其實不止學到這些。但今天的花的時間與字數也差不多了，我要對範疇作管理了，哈哈。有機會再透過更新去豐富本篇內容。