PHP 也有 Day #50：處理前人的遺產—聊 legacy code

- 什麼是 legacy code
- 重構和重寫的選擇
- 避免寫出新的 legacy code

Transcript

1. 處理前人的遺產 聊 legacy code
2. • 前人的遺產 • 重構 v.s. 重寫 • 開始重構 • 分析現況與進度 • 避免寫出新遺產
3. 前人的遺產
4. 工作不是只有 coding
5. $ whoami • 遊戲公司開發 • 小公司官網開發 • 廣告 DSP 系統開發 • 補習系統開發
6. 什麼是 legacy code
8. 什麼是 legacy code 年代久遠 結構龐大
9. 什麼是 legacy code 經歷很多迭代 幾乎沒有文件
10. 什麼是 legacy code （例外）
11. 當 legacy 品質太差時的二選一
12. 重構 v.s. 重寫
13. 約耳趣談軟體（Joel on Software） • Microsoft Excel PM • Stack Overflow CEO • Trello 作者
14. 約耳趣談軟體 - 你絕對不應該做的事 之一 他們決定把程式從頭重寫過（Netscape）
16. 然後就有了 Mozilla(?
17. 重寫的問題
18. 重寫的問題 風險 開啟專案成本
19. 耗費時間 重寫的問題 市場變動
20. 重寫的好處
21. 自由度 重寫的好處 可測試性
22. 有時候逼不得已 • 換語言（Java to PHP） • 換成不相容的框架（yii1 to laravel） • ⋯⋯etc 除了這些狀況之外，盡可能避免重寫整個專案
23. 確認一下，為什麼要重構？
24. 重構的原因 • 這樣程式碼比較簡潔 • 這樣才是好的工程做法
25. 不要對主管這麼說
26. 主管面對的問題 耗費時間成本 耗費人力成本
27. 重構的原因 • 這樣程式碼比較簡潔 • 這樣才是好的工程做法 • 這樣之後修改更快（減少時間成本） • 這樣之後接手的人更好處理（減少人力成本）
28. 長官聽不懂程式碼品質怎麼辦？
29. 重構的原因 • 這樣之後修改更快（減少時間成本） • 這樣之後接手的人更好處理（減少人力成本） 不要聊程式碼品質
30. 為什麼不聊程式碼品質 作為工程師 撰寫程式碼是你的工作，不是主管的工作
31. 為什麼不聊程式碼品質 同理 作為工程師 維護程式碼品質是你的工作，不是主管的工作
32. 開始重構
34. 開始重構 先寫測試
35. 先寫測試 不要為了重構，結果搞到離職
36. 利用自動測試保護原有功能
37. 可是舊有架構測試很難寫⋯⋯
38. 先補上功能測試 在 legacy 上面加上測試
39. 隨著重構逐漸補上單元測試 在 legacy 上面加上測試
40. 開始重構
42. 開始重構 先補文件
43. 為什麼要先補文件 沒有文件，就算寫得多清楚，後來的人還是不懂 （包括未來的你）
44. 最重要的文件是
45. README.md
46. README.md 檔案位置最明顯
47. README.md 每個人都會看到
48. README.md 要寫 • 專案用途 • 相依元件 • 建置方式 ◦ 本地 ◦ 遠端 • 測試方式
49. 其他文件
50. 不放進 readme.md 的文件 放 repo wiki
51. 不放進 readme.md 的文件 放 docs/ 資料夾
52. 開始重構
53. 分析現況與進度
54. 分析現在的處境有多嚴重
55. 回報重構進度
56. 所謂的重構 就是不會有新功能的
57. 所以 老闆會討厭你
58. 不要為了重構，結果搞到得離職
59. 怎麼辦
60. 逐步改進
61. 逐步改進 維持撰寫新功能（老闆按讚）
62. 逐步改進 重構前人程式（包含測試，文件⋯⋯等）
63. 時間的部分怎麼辦？
64. 提升自己實力 效率不比一般工程師還差
65. 提升自己實力 懂得說「不」
66. 提升自己實力 維持專業
67. 避免寫出新 legacy
68. 避免寫出新 legacy （專案的）資訊並不想要自由
69. 避免寫出新 legacy 開發者並不喜歡寫文件
70. 避免寫出新 legacy 花時間維護文件
71. 避免寫出新 legacy 時常和同事討論文件內容
72. 避免寫出新 legacy 避免將功能塞入單一大專案
73. 避免寫出新 legacy 建立方便修改的小專案
74. 避免寫出新 legacy 時常和同事做 code review
75. 避免寫出新 legacy 多溝通避免資訊遺失
76. • 花時間維護文件 • 時常和同事討論文件內容 • 建立方便修改的小專案 • 時常和同事做 code review 避免寫出新 legacy
78. tl;dr • 冷靜評估重構和重寫的風險與效益 • 重構之前先補測試和文件 • 隨時使用各種工具分析現況，確認重構進度 • 避免寫出新遺產
79. 問答 • legacy code 的常見特徵（共四點） • 重構之前先補（共兩點） • 避免寫出新遺產（共四點）
80. 問答 • legacy code 的常見特徵 ◦ 年代久遠 ◦ 結構龐大 ◦ 經歷很多迭代 ◦ 幾乎沒有文件
81. 問答 • 重構之前先補 ◦ 文件 ◦ 測試
82. 問答 • 避免寫出新遺產 ◦ 花時間維護文件 ◦ 時常和同事討論文件內容 ◦ 建立方便修改的小專案 ◦ 時常和同事做 code review
83. 套件程式討論團
84. @ReccaChaoWebDev
85. 網路技術討論區
86. 投影片網址