先講結論：
- 老系統是否可以精簡？
- 如何重構才可以一步一步上線？
公司之前的專案是一個大雜燴，多個業務放在一個專案中，多個網站也是放在一起，因為總是有一些共用的資料，結果導致很多工程師同事在一個專案上開發，之前大家開開心心和和睦睦，平安無事，但是隨著業務越來越複雜，問題出現了：
- 共用的東西很多，牽一髮動全身，經常出現修改一些東西需要在多個業務裡面測試，因為沒有寫單元測試，就只能手動測試。
- 每個人寫的程式碼參差不齊，某天你想重構一些程式碼，但你看看要改那麼多地方，你就只能苦笑，結果就是破罐子破摔，就像有潔癖的人，只能捏子鼻子閉著眼睛生活。
所以今年7月份，我們啟動了核心專案的重構，整體來說就是拆服務，寫 API，用 API。 今天我不講整個過程是這麼做的，我只分享重構前做的一些考慮，如果你也在做一些大的重構，希望這些考慮可以給你幫助。
一，老系統的業務是否可以精簡或者刪除？
專案重構可不單單隻重構程式碼，這正是一個非常好的機會來重新梳理業務，可能你感覺業務跑的很順，但是：
- 會不會有哪些業務已經是可有可無的狀態？
- 會不會有哪個流程本來可以更簡單？
- 會不會有一些遺留問題早就應該解決了，但是一直因為忙忙忙的緣故被拖後？
在重構的之前，技術人要完整的理解現有系統的結構，更重要的是要理解業務，尤其是要和第一線的業務人員進行溝通，瞭解他們的工作模式，瞭解他們的現有流程的一些困惑或難點。
瞭解清楚後，開始做減法，已經不需要的功能或流程要在老系統上進行精簡或刪除，可能你會問“我已經要重構了，為什麼還需要在老系統上精簡？“，因為你重構的系統還不知道什麼時候上線呢，而且重構的系統再開發的時候需要參考老系統。
二，如何重構才能一步一步上線？
這一點是我考慮不足的地方，因為專案拉的比較長，時間預估方面也考慮不周，導致專案延期比較久。其中很重要的一個問題是：如何才能一步一步上線？
- 重構後的系統哪些部分可以先做完上線？讓老系統與新系統的相容工作分步做，而不是想著一步就全部替換掉，這不現實。
- 資料儲存結構是否需要修改？如果修改，是否可以先洗一部分資料？
分步上線是把風險也分步，把風險分散開對一個成熟的業務非常關鍵。而且每一步都會給大家很多的信心，很清楚看到我們在前進，否則戰線拉太長，大家都會覺得比較疲勞。
總體來說，這兩點是在重構專案的時候大家都可以嘗試考慮的問題，希望對你有幫助。
原文連結：https://www.lijinma.com/blog/2017/01/18/tw...
本作品採用《CC 協議》，轉載必須註明作者和本文連結
