1. 這世界上全是祖傳代碼
有的代碼傳了四五年，有的傳了十幾年，還有的傳了二十多年！
做Java的同學，你能想象得到隻用JSP做的系統嗎？ 我遇到過， 6000多行的JSP充當Controller， 有個程式員某一次在JSP中加代碼太多了，直接導緻無法編譯了。
大名鼎鼎的Oracle很強吧？
2018年有個Oracle程式員吐槽說每次處理一個Bug ，都需要花費兩周時間搞清楚20個不同的flag以及它們之間的神秘作用，然後自己才能添加若幹新flag和邏輯來fix bug。
然後需要将代碼送出到200台伺服器組成的測試叢集，等待20到30小時運作數百萬個測試。 可能有100~1000個測試失敗，你需要分析它們和更多的flag。
如此循環兩周，直到確定神秘的flag組合通過所有測試。
然後為你的更改再添加上百個測試，保證别人不會破壞。
是不是很瘋狂？
你也可以看看你手頭的代碼，看看最早的作者是誰，經曆了多少個版本。
我看到的最早的版本是1998年，那個作者現在是個進階的架構師了。
如果你很幸運， 一開始就啟動了一個全新的項目，沒有祖傳代碼的問題。
但是，請放心，根據“代碼腐化定律”和“破窗效應”， 你的項目很快就會變成“祖傳代碼”， 毫不例外！
2. 遏制你重寫代碼的沖動
我不止一次一邊砸鍵盤一邊罵： 這麼爛的代碼，維護成本這麼高，重寫得了！
但是理智告訴我： 重寫的成本更高，祖傳代碼雖然很爛，但是經曆過無數測試和真實使用者的考驗， 那些看起來無法理喻的分支、條件恰恰是在彌補那些程式員沒有考慮到的邏輯。
如果真的重寫，你能保證這些邊邊角角的邏輯都實作正确嗎？ 能保證不出重大的纰漏嗎？能保證不給公司帶來重大的财務損失嗎？
軟體品質包括兩個方面： 内在的和外在的。
内在的是代碼品質， 外在的是對外表現的行為是否符合預期，不符合就是Bug了。
祖傳代碼的外在品質是不錯的，畢竟是經過血與火的考驗的。
如果重寫，你能保證内在的代碼品質和外在的行為都超越祖傳代碼嗎？
重寫不能保證業務中斷，這是基本條件， 2010年在華為做靈活咨詢，華為有個口号我記得非常清楚： 要在高速公路上給汽車換輪子，這可能嗎？ 據說華為有團隊真的做成了，如果是真的，确實讓人佩服。
3. 尋找優秀架構的影子
祖傳代碼雖然亂，但是初始的架構一般還是優秀的。
我在華為就看到有個産品是這樣的，應用層堆積起來的代碼看起來很差勁，但是仔細瞧瞧，依稀可見優秀架構的影子，這肯定沒有守住， 後來慢慢腐化了。
是以面對祖傳屎山代碼，要捏着鼻子，抛棄細節，在裡邊努力搜尋優秀架構的影子。
從功能上看，系統分為哪些元件，元件之間是如何互動的？
從技術上看，這些元件部署到了什麼樣的軟體上？ 元件之間互動用了哪些協定，同步還是異步？資料再元件之間如何流動？
一些核心元件的内部是如果進行再次劃分的，如何分層的？
總之，要回答這麼一個問題： 如果是我，我能獨自把這個系統給搭建起來嗎？
總有一天，你會成為這樣的人， 要做好儲備。
4. 在自己的範圍内盡量重構
面對祖傳代碼，初心不改。
努力把自己的代碼寫好，能重構的地方盡量重構，哪怕是一個函數，一個變量名。
這些都是自己賴以生存的技能，不能因為祖傳代碼爛，自己寫的代碼更爛！
重構和測試不分家， 把自己的單元測試寫好，把功能測試做好，必要的話請測試人員幫個忙。
一定要有勇氣去做，尤其是面對屎山代碼的時候。
要對得起自己，不能坑了自己。
5. 看優秀源碼
祖傳代碼雖然有優秀架構的影子， 但是看多了也會吐的。
在這個世界上還是有優秀源代碼的， 尤其是開源的代碼， 它們沒有進度的巨大壓力，維護者有足夠的時間打磨自己的代碼， 像一個工匠一樣。
我知道的一些優秀源碼有這些： JUnit，Redis，SQLite, Spring等。
這寫代碼現在都很龐雜了，看起來很累，最好去找他早期的源碼，要簡單得多，并且基本架構還在。
比如JUnit早期代碼，幾百行的代碼就把很多設計模式都給組合了起來，非常巧妙，設計模式看多少都不如看一個活生生的例子。
看完以後，自己嘗試着造一個輪子，把主要思想都給展現出來，你的功力至少上一個層次。
