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

Slide 1

Slide 1 text

處理前人的遺產聊 legacy code

Slide 2

Slide 2 text

● 前人的遺產 ● 重構 v.s. 重寫 ● 開始重構 ● 分析現況與進度 ● 避免寫出新遺產

Slide 3

Slide 3 text

前人的遺產

Slide 4

Slide 4 text

工作不是只有 coding

Slide 5

Slide 5 text

$ whoami ● 遊戲公司開發 ● 小公司官網開發 ● 廣告 DSP 系統開發 ● 補習系統開發

Slide 6

Slide 6 text

什麼是 legacy code

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

什麼是 legacy code 年代久遠結構龐大

Slide 9

Slide 9 text

什麼是 legacy code 經歷很多迭代幾乎沒有文件

Slide 10

Slide 10 text

什麼是 legacy code （例外）

Slide 11

Slide 11 text

當 legacy 品質太差時的二選一

Slide 12

Slide 12 text

重構 v.s. 重寫

Slide 13

Slide 13 text

約耳趣談軟體（Joel on Software） ● Microsoft Excel PM ● Stack Overflow CEO ● Trello 作者

Slide 14

Slide 14 text

約耳趣談軟體 - 你絕對不應該做的事之一他們決定把程式從頭重寫過（Netscape）

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

然後就有了 Mozilla(?

Slide 17

Slide 17 text

重寫的問題

Slide 18

Slide 18 text

重寫的問題風險開啟專案成本

Slide 19

Slide 19 text

耗費時間重寫的問題市場變動

Slide 20

Slide 20 text

重寫的好處

Slide 21

Slide 21 text

自由度重寫的好處可測試性

Slide 22

Slide 22 text

有時候逼不得已 ● 換語言（Java to PHP） ● 換成不相容的框架（yii1 to laravel） ● ⋯⋯etc 除了這些狀況之外，盡可能避免重寫整個專案

Slide 23

Slide 23 text

確認一下，為什麼要重構？

Slide 24

Slide 24 text

重構的原因 ● 這樣程式碼比較簡潔 ● 這樣才是好的工程做法

Slide 25

Slide 25 text

不要對主管這麼說

Slide 26

Slide 26 text

主管面對的問題耗費時間成本耗費人力成本

Slide 27

Slide 27 text

重構的原因 ● 這樣程式碼比較簡潔 ● 這樣才是好的工程做法 ● 這樣之後修改更快（減少時間成本） ● 這樣之後接手的人更好處理（減少人力成本）

Slide 28

Slide 28 text

長官聽不懂程式碼品質怎麼辦？

Slide 29

Slide 29 text

重構的原因 ● 這樣之後修改更快（減少時間成本） ● 這樣之後接手的人更好處理（減少人力成本）不要聊程式碼品質

Slide 30

Slide 30 text

為什麼不聊程式碼品質作為工程師撰寫程式碼是你的工作，不是主管的工作

Slide 31

Slide 31 text

為什麼不聊程式碼品質同理作為工程師維護程式碼品質是你的工作，不是主管的工作

Slide 32

Slide 32 text

開始重構

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

開始重構先寫測試

Slide 35

Slide 35 text

先寫測試不要為了重構，結果搞到離職

Slide 36

Slide 36 text

利用自動測試保護原有功能

Slide 37

Slide 37 text

可是舊有架構測試很難寫⋯⋯

Slide 38

Slide 38 text

先補上功能測試在 legacy 上面加上測試

Slide 39

Slide 39 text

隨著重構逐漸補上單元測試在 legacy 上面加上測試

Slide 40

Slide 40 text

開始重構

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

開始重構先補文件

Slide 43

Slide 43 text

為什麼要先補文件沒有文件，就算寫得多清楚，後來的人還是不懂（包括未來的你）

Slide 44

Slide 44 text

最重要的文件是

Slide 45

Slide 45 text

README.md

Slide 46

Slide 46 text

README.md 檔案位置最明顯

Slide 47

Slide 47 text

README.md 每個人都會看到

Slide 48

Slide 48 text

README.md 要寫 ● 專案用途 ● 相依元件 ● 建置方式 ○ 本地 ○ 遠端 ● 測試方式

Slide 49

Slide 49 text

其他文件

Slide 50

Slide 50 text

不放進 readme.md 的文件放 repo wiki

Slide 51

Slide 51 text

不放進 readme.md 的文件放 docs/ 資料夾

Slide 52

Slide 52 text

開始重構

Slide 53

Slide 53 text

分析現況與進度

Slide 54

Slide 54 text

分析現在的處境有多嚴重

Slide 55

Slide 55 text

回報重構進度

Slide 56

Slide 56 text

所謂的重構就是不會有新功能的

Slide 57

Slide 57 text

所以老闆會討厭你

Slide 58

Slide 58 text

不要為了重構，結果搞到得離職

Slide 59

Slide 59 text

怎麼辦

Slide 60

Slide 60 text

逐步改進

Slide 61

Slide 61 text

逐步改進維持撰寫新功能（老闆按讚）

Slide 62

Slide 62 text

逐步改進重構前人程式（包含測試，文件⋯⋯等）

Slide 63

Slide 63 text

時間的部分怎麼辦？

Slide 64

Slide 64 text

提升自己實力效率不比一般工程師還差

Slide 65

Slide 65 text

提升自己實力懂得說「不」

Slide 66

Slide 66 text

提升自己實力維持專業

Slide 67

Slide 67 text

避免寫出新 legacy

Slide 68

Slide 68 text

避免寫出新 legacy （專案的）資訊並不想要自由

Slide 69

Slide 69 text

避免寫出新 legacy 開發者並不喜歡寫文件

Slide 70

Slide 70 text

避免寫出新 legacy 花時間維護文件

Slide 71

Slide 71 text

避免寫出新 legacy 時常和同事討論文件內容

Slide 72

Slide 72 text

避免寫出新 legacy 避免將功能塞入單一大專案

Slide 73

Slide 73 text

避免寫出新 legacy 建立方便修改的小專案

Slide 74

Slide 74 text

避免寫出新 legacy 時常和同事做 code review

Slide 75

Slide 75 text

避免寫出新 legacy 多溝通避免資訊遺失

Slide 76

Slide 76 text

● 花時間維護文件 ● 時常和同事討論文件內容 ● 建立方便修改的小專案 ● 時常和同事做 code review 避免寫出新 legacy

Slide 77

Slide 77 text

No content

Slide 78

Slide 78 text

tl;dr ● 冷靜評估重構和重寫的風險與效益 ● 重構之前先補測試和文件 ● 隨時使用各種工具分析現況，確認重構進度 ● 避免寫出新遺產

Slide 79

Slide 79 text

問答 ● legacy code 的常見特徵（共四點） ● 重構之前先補（共兩點） ● 避免寫出新遺產（共四點）

Slide 80

Slide 80 text

問答 ● legacy code 的常見特徵 ○ 年代久遠 ○ 結構龐大 ○ 經歷很多迭代 ○ 幾乎沒有文件

Slide 81

Slide 81 text

問答 ● 重構之前先補 ○ 文件 ○ 測試

Slide 82

Slide 82 text

問答 ● 避免寫出新遺產 ○ 花時間維護文件 ○ 時常和同事討論文件內容 ○ 建立方便修改的小專案 ○ 時常和同事做 code review