# 程式碼品質

我覺得短解，這件事需要被重視，我這幾天在看bug 很多都是短解，甚至短解疊加短解，我覺得短解，要搭配配套，甚至紀錄下來，中長期要怎麼做，安排時間怎麼做。

我們既有的程式，不管前端或後端，都不是模組化的程式，要移做他用，是很困難的，很多是都是短解堆疊而成的。

短解，可以短期解決暫時，但因為長期就累積很多複雜問題，短解上堆疊短解，簡單問題就變複雜了，既有程式已在線上，要在花力氣改回來，讀懂，不改爆他，得付出更多的成本。

我們這次規劃 cart 改版，資源有限，將前端稍微模組化，但我們很多還是綁在後端，後端沒沒模組化，有些還是被後端綁死。

原本的負責的程式的人離職，後面的人接不上，
過去的人，

1.只有作者看得懂，怎麼改，其他人改會花比較多時間，沒有規範。 => 制度化

2.耦合度太高，要大調整，改a 壞b機會很高，幾乎重新測試 => app monitor

3.元件肥大到不好維護 一個元件4000多行，光是讀懂再改對很花時間 =>

4.既有問題沒辦法解決。 ( reload )

5.無法輕易的移作他用。 => 模組化

但中長期發展，越改越慢，量大，資料多，或是要快速迭代，就會開始出現問題。（我們現在就遇到）

舉例來說像前幾天Jimmy 遇到一個live 問題，我和 Andy 在幫忙看，都覺得寫的怪怪的，Andy 也指出問題，我也驗證問題也讓Jimmy知道這樣寫怪怪的，且React 這框架隨便寫都會動，太自由。（自由不是問題，沒有規範，才是問題）


開始要思考建立制度規範，改善程式碼品質，讓其他成員可以互相cover，讓我有時間做其他事，不然成員人越多，會一直都在救火。

我的建議是
1.Coding standard  =》 我先，起頭團隊一起維護
2.Code review (抽檢、cowork ）=》我先，大家有共識，其他人起來幫忙看

（我發現先私下找那個人談，
能理性溝通的，
很快改好，就立刻排著改
很花時間功能又很急上線的，
另外開單改，

不配合貼在群裡討論，
或是列成工作讓 pm 分派給他，
過去經驗，跑個一次兩次就會配合）

Issue tracking system （ who ? manager ）
3.Bug 追蹤機制  (過去寫新需求發現一堆，沒辦法立即改，就應該被記錄）
4.短解配套追蹤
5.Enhance機制 ( engineer self, another people )
PM 在專案縫隙，要安排在專案間去解決上面的問題