程式設計師：當你面對一坨程式碼時，你應該怎麼做？

摘要： 我經常要遇到很多我寫的 shit 一樣的程式碼，你經常要遇到很多你寫的 shit 一樣的程式碼。不對，別人要經常遇到別人寫的 shit 一樣的程式碼。總之，你寫的程式碼可能不是 shit，但是你看別人的可能就是.. 適合閱讀人群： 有一定工作經驗（2~3 年），並...

我經常要遇到很多我寫的 shit 一樣的程式碼，你經常要遇到很多你寫的 shit 一樣的程式碼。不對，別人要經常遇到別人寫的 shit 一樣的程式碼。總之，你寫的程式碼可能不是 shit，但是你看別人的可能就是..

適合閱讀人群：

有一定工作經驗（2~3 年），並且對程式碼有追求的程式員 。

面向複雜的遺留/舊系統，無法下手的專案 。

熟悉面向物件的程式設計師

如果你工作 2~3 年，並且遇到瓶頸，也不妨來看看。

你遇到一坨程式碼時，你要怎麼做？

正確做法

我們在之前寫了那麼多的程式碼，有一天成為了遺留程式碼，這些程式碼可能會到別人的手裡，也可能回到我們自己的手裡。這時，我們應該怎麼做了。

有了上面的那張圖，我這裡就只列出一些比較重要的知識：

進行重構計劃之前

先進行探索性重構——使用 IDE、編譯器輔助、版本管理

收集資料來對專案進行評估——效能、錯誤日誌、異常監測

對常見任何進行計時——環境搭建時間、開發部署、修復bug

使用程式碼審查工具，如 PMD、Findbugs、CheckStyles

使用 Jenkins 和 SonarQube 進行持續檢查

重構決策會議

會議應該決定重構、重寫或者重搭

重構

重構相關的內容，可以參見《重構》一書。

重搭

方法：

識別業務和重搭範圍

定義模組和介面

構建指令碼和依賴管理

分拆模組

更新技術棧

重寫

確認重寫範圍：黑盒式、溫習式、補償式

從過去學習

資料庫遷移：共享或遷移

結論

從重構專案中學習，更容易學到新的東西。

感謝閱讀