「修改軟體的藝術」 讀書筆記

date: 2017-10-13 17:59:11 title: 「修改軟體的藝術」 讀書筆記

百度腦圖 - 修改軟體的藝術: http://naotu.baidu.com/file/3300eebf1014c10fd4d1a96ad6cf65ac?token=ff8bec2d896c0c61

圖靈社群 - 修改軟體的藝術: http://www.ituring.com.cn/book/1749

修改軟體的藝術：構建易維護程式碼的9條最佳實踐

將理解具象化

優秀軟體是具象化的理解

敏捷 vs 瀑布

遺產 vs 遺留

奏效: 受僱的開發者必須意識到，僅僅言聽計從是不夠的，他們有義務讓交付的軟體持續產生價值

開發者有三種狀態： 已完成 / 未開始 / 快完事了

評估未知

一個充滿外行人的產業

導致低成功率的核心因素： (1) 程式碼變更 (2) bug修復 (3) 複雜度控制

順流直下: 瀑布模型是從製造業和建築行業借鑑而來

需求分析 設計 實現 整合 測試 安裝 維護

為什麼瀑布模型不管用

虛擬世界並不奏效

讓我們建造出來的東西難以改變

開發和測試分離

出錯誤並非我的工作；創造錯誤才是

當“流程”變成“體力勞動”

流程無法支配創造力

敏捷: 希望軟體能擁有即刻適應需求變化的能力

敏捷 Scrum 極限程式設計(Extreme Programming，XP)

敏捷流程核心: 通過持續不斷地及早交付有價值的軟體使客戶滿意

小即是好

並不是急於求成而是循序漸進

藝術與技能的平衡: 開發軟體需要許多的技能和能力，也就是技藝，但是無論學到多少技能都沒辦法解決所有問題

追求技術卓越

遵循實踐（消毒某一特殊器械的行為）和遵循原則（對所有器械進行消毒的理由）的差別

如果想降低軟體持有者的開銷，我們必須關注軟體的構建過程

守、破、離

單一職責原則

開閉原則：軟體實體（類、模組、函式等）應該對擴充套件開放，對修改關閉

原則幫助我們把某件事情通用化，有助於梳理知識體系

實踐必須： 在多數情況下產生價值； 容易學習且容易傳授； 簡單易行——簡單到無需思考

原則指導實踐

壓力對於構建更好的產品毫無幫助

要有一個產品負責人

使用者故事: 做什麼、為什麼做、給誰做

為驗收測試設立明確標準 / 自動化驗收標準

產品負責人的7個策略:

• 成為特定領域專家
• 在開發過程中探索
• 幫助開發者理解為什麼和為了誰
• 描述你想要什麼，而不是怎麼做
• 及時回答問題
• 消除依賴
• 支援重構

編寫出更好使用者故事的7個策略:

• 它當作一個佔位符
• 關注“什麼”
• 把“誰”人格化
• 知道為什麼會有一個功能需求
• 開始時簡單，日後再加強
• 心繫邊界情況
• 使用驗收標準

小批次構建

工作單元應該可以展現出可度量的結果

大小適中，而不僅僅是“小”而已

做出調整

人類無法度量

關鍵路徑的重要性：“懷孕生子需要九個月，無論有多少婦女參與其中。”

範圍、時間、資源（scope,time,resource，STR）

控制釋出節奏

越小越好有四個基本原因：更容易理解；更容易預估；更容易實現；更容易測試

分而治之

之所以會很繁重，是因為兩個原因：要麼是複雜型的，要麼是複合型的

探索未知事物的時候需要做兩件事: 未知變為已知，未知進行封裝

更短的反饋迴路

提高構建速度

對反饋做出響應

建立待辦列表

討論待辦列表的順序而非優先順序

把使用者故事拆分為任務

跳出時間盒子思考

Scrum並不是一個“全有或全無”的提議

要麼有風險，要麼沒有風險。當你有風險的時候，則充滿未知。未知即是風險

範圍控制

降低風險的唯一方式是把使用者故事進行到底，這意味著我們需要對什麼是“完成”有明確的定義

迭代”真正的目的是讓團隊消除以釋出為單位的構建習慣

看板

度量軟體開發的7個策略:

• 度量產生價值的時間
• 度量編碼時間
• 度量缺陷密度
• 度量發現缺陷的時間
• 度量功能的客戶價值
• 度量未交付功能的損失
• 度量反饋迴路的效率

分割使用者故事的7個策略:

• 把複合的故事拆分為元件
• 複雜的故事分割為已知的和未知的
• 對未知持續迭代直至完全理解
• 根據驗收標準分割故事
• 最小化依賴
• 保持目的單一
• 保持故事可測試性

持續整合

處理痛苦的方式有兩種：避免痛苦，或者學著承受

建立專案的心跳

實踐持續部署

自動化構建

儘早整合，頻繁整合

告訴你的開發者每天至少整合一次

測試驅動開發（Test Driven Development，TDD）

軟體應該從第一天起就具備釋出條件

構建敏捷設施的7個策略:

• 用版本庫管理一切
• 一次點選全部構建
• 持續整合
• 為任務定義驗收標準
• 編寫可測試的程式碼
• 保證必要的測試覆蓋率
• 即時修復失敗的構建

消除風險的7個策略:

• 持續整合
• 避免分支
• 自動化測試上下功夫
• 識別風險區域
• 征服未知
• 構建可以體現價值的最小部分
• 頻繁驗證

協作

極限程式設計

開放性的思想

溝通與協作

結對程式設計

夥伴程式設計

穿刺，群戰，圍攻

在時間盒子中對未知進行調研

定期程式碼審查和回顧會議

加強學習和知識分享

誨人不倦且不恥下問

結對程式設計的7個策略:

• 嘗試一下，你會喜歡的
• 駕駛員和領航員都要參與其中
• 頻繁交換角色
• 充實工作一天
• 嘗試各種配置
• 讓團隊決定細節
• 跟蹤進度

高效回顧會議的7個策略:

• 找尋小的改進
• 責怪流程而不是人
• 5個為什麼
• 解決根源問題
• 傾聽每個人的聲音
• 給予支援
• 度量進度

編寫整潔的程式碼

CLEAN: Cohesive 內聚 / Loosely Coupled 鬆散耦合 / Encapsulated 封裝 / Assertive 自主 / Nonredundant 沒有冗餘

高質量的程式碼是內聚的

單一的職責

高質量的程式碼是封裝良好的

由外而內程式設計 vs 由內而外程式設計

只暴露解決問題所必需的

高質量的程式碼是自主的

高質量的程式碼是沒有冗餘的

DRY Don't Repeat Yourself

提高程式碼質量的7個策略:

• 明確程式碼質量的定義
• 對基本的實踐達成一致
• 放棄完美主義
• 理解取捨
• 用“什麼”來隱藏“怎麼”
• 良好的命名
• 保持程式碼的可測試性

編寫可維護程式碼的7個策略:

• 確立程式碼的集體所有權
• 積極重構
• 堅持結對程式設計
• 頻繁的程式碼審查
• 學習其他開發者的風格
• 不斷學習軟體開發
• 讀程式碼，寫程式碼，練習編碼

測試先行

測試是標準，測試定義行為。

• 驗收測試 = 客戶測試
• 單元測試 = 開發者測試
• 其他測試 = 質量保證測試

質量保證（Quality Assurance，QA）:

• “元件測試”體現各個組成單元之間的配合情況。
• “功能測試”體現所有組成單元在一起完成整個端到端的行為。
• “場景測試”體現使用者和系統的互動行為。
• “效能測試”驗證這些情形：“這個系統能承受很大的負載嗎？我們進行過獨立測試，但是如果百萬級使用者進行併發請求會怎麼樣？”
• “安全測試”驗證程式碼的脆弱程度。

以行為作為單元

TDD可以提供迅速的反饋

TDD可以為重構提供支援

編寫可測試的程式碼

進行優質驗收測試的7個策略:

• 明確構建目標所產出的價值
• 理解為誰而做以及他們為什麼需要
• 將驗收測試自動化
• 定義邊界用例、異常、次要路徑
• 用例項來充實細節和展示不一致
• 用驗收標準來拆分行為
• 保持每個測試的唯一性

進行優秀單元測試的7個策略:

• 從呼叫者的角度出發
• 用測試定義行為
• 僅僅編寫能體現區別的測試
• 僅僅編寫可以讓測試通過的程式碼
• 用測試來構建行為
• 對程式碼進行重構
• 對測試進行重構

用測試描述行為

測試就是標準

測試需要完整

bug是缺失的測試

工作流測試用所謂的模擬物件（mock）進行測試

使用測試作為標準的7個策略:

• 將測試儀表化
• 使用見名知意helper方法
• 突出重點
• 測試行為，而不是實現
• 用模擬物件測試工作流
• 避免過度描述
• 利用真實的例子

修復bug的7個策略:

• 一開始就避免寫出bug
• 儘早發現bug
• 通過設計讓bug更容易找到
• 問對問題
• 把bug當作失敗的測試
• 利用發現的缺陷修正流程
• 從錯誤中學習

最後實現設計

可變性的阻礙

缺乏封裝

濫用繼承

僵化的實現

內聯程式碼

依賴

可持續性開發

刪除死程式碼

保持名稱更新

集中決策

抽象

對類進行組織

編碼與清理

軟體被閱讀的次數比編寫次數多

意圖導向程式設計

降低圈複雜度

演化式設計

進行演化式設計的7個策略:

• 理解物件導向設計
• 理解設計模式
• 理解測試驅動開發
• 理解重構
• 關注程式碼質量
• 要冷酷無情
• 培養優秀的開發習慣

清理程式碼的7個策略:

• 讓程式碼自我表達
• 為新增測試創造間隙
• 讓方法更內聚
• 讓類更內聚
• 集中決策
• 引入多型
• 封裝構建過程

重構遺留程式碼

重構能降低以下四個方面的成本：

• 日後對程式碼的理解
• 新增單元測試
• 容納新功能
• 日後的重構

技術債和財務債一樣：利息會把你拖垮

通過重構糟糕程式碼來培養良好習慣

推遲那些不可避免的

• 圖釘測試
• 依賴注入
• 系統扼殺

• 抽象分支

• 以支援修改為目的重構

• 以開閉原則為目的重構
• 以提高可修改性為目的重構

第二次做好

助你正確重構程式碼的7個策略:

• 從已有系統中學習
• 循序漸進
• 遺留程式碼中新增測試
• 始終進行重構
• 有更好的理解後對一個實現進行重新設計
• 繼續其他工作前進行清理
• 重構以避免誤入歧途

決定何時進行重構的7個策略:

• 關鍵程式碼維護不善的時候
• 當唯一理解程式碼的人沒空的時候
• 有資訊可以揭示更好的設計的時候
• 修復bug的時候
• 需要新增新功能的時候
• 當需要為遺留程式碼寫文件的時候
• 當重構比重寫容易的時候

在不需要的事情上花錢

我們是軟體開發者，利用現有工具盡我們所能開發最好的軟體