在我們的職業生涯中，很少有機會可以從零開發一個項目，大部分都是接手别人的代碼繼續開發，或者做些維護性開發。而且，對于大部分業務系統來說，因為業務導向，需求倒逼，開發工期緊，團隊往往都不是很重視代碼品質，快速上線是第一要務。是以，很多團隊的代碼品質一般都不怎麼高。埋坑無數、沒有文檔、也沒有注釋，代碼讀不懂、也不敢改，這對于新人來說，會非常苦惱。今天，我們就聊一聊，如何接手一坨爛業務代碼，以及如在爛業務代碼中的成長？

話不多說，讓我們正式開始今天的内容吧！

如何接手一坨爛業務代碼？

在我過去10年的工作經曆中，我接手過很多個代碼品質比較爛的項目。這些項目都有很多共性的特點，大部分都已經維護了兩三年，甚至五六年之久，代碼量很大，有十幾萬行以上，并且大部分代碼都沒有任何注釋，業務功能非常龐雜，也沒有對應的業務文檔。

除此之外，代碼中還充斥着各種臨時解決方案（Workaround）、寫死（Hard Code）、遺留代碼（Legacy Code），還有很多匪夷所思的設計。對于有些設計來說，我們稱之為“反人類”設計或者“故意挖坑”，一點都不為過。如果沒有老員工給你解釋上下文，你萬萬都想不到它為什麼這麼設計和實作。

實際上，要想接手一個業務系統，前提是要讀懂代碼，而讀懂代碼的關鍵，是要熟悉業務。隻要業務搞清楚了，代碼隻不過是對業務的翻譯，對照着業務看代碼實作，看懂并不是件難事。不過，我所接手的這幾個項目，基本上都是零文檔，所有的業務知識都是靠口口相傳。是以，搞清楚業務，就成了接手項目最難的事情了。

面對如此龐大的項目代碼，沒有文檔，幾乎就是兩眼一抹黑。原來參與這個項目開發的老同僚，有的離職，有的去做其他新項目，一直問他們也不好意思，是以，大部分情況下，我都隻能硬着頭皮，通過閱讀代碼反推業務功能。

如果代碼品質比較高，子產品劃厘清晰，命名規範，那通過讀代碼反推業務，也并非不可能的事情。但真實的情況往往事與願違，就像我們前面提到的，代碼中充斥着臨時解決方案、寫死、遺留代碼等各種坑，這就使反推業務變得非常困難。對于代碼中的這些坑，盡管我不想一直麻煩同僚，但也隻有多問才能最快速地解決。

在讀代碼的過程中，我非常重視知識的文檔化，我會把讀懂的每個業務都寫到文檔中。當然，這其中也包括前面提到的各種坑。對于複雜的業務流程，我還會畫一些流程圖。讀代碼的過程非常痛苦，花了好幾個月，我才有信心說，自己幾乎把所有代碼都搞清楚了。同時，我也做了一件過去幾年都沒有人做的事情，那就是補充完整了技術文檔和業務文檔，之後再有新同僚加入，看了我的檔案，就可以很快了解代碼、了解業務，很快就能上手開發代碼。

總結一下，即便代碼再爛，隻要有完善的業務文檔，先了解業務，再去看代碼，幾乎就沒啥難度了。對于零文檔的項目，大部分情況下，我們隻能通過代碼來反推業務。當然，對于有些坑來說，必要的情況下，我們也要詢問前輩來搞定。在讀代碼的過程中，我們要将得到的知識文檔化，這也是對公司和團隊來說最有價值的部分。

如何在爛業務代碼中成長？

有人一遇到這種爛業務代碼，就覺得很心煩，我反倒不一樣。恰恰相反，相比接手好代碼，我覺得接手爛代碼，雖然過程更加痛苦，但同時也會給我更多施展才華的空間、鍛煉技術的機會，我的成長也會更多。

除此之外，很多人覺得做偏底層的開發（基礎架構、架構、中間件等開發）才鍛煉技術，做業務系統沒有挑戰，技術上沒有成長，對此非常苦惱。實際上，我覺得這種看法是比較片面的。做業務開發的難度不亞于底層開發，做好也不是件容易的事情，同樣可以積累技術、鍛煉能力。

偏底層的開發更加考驗程式員在某一細分領域的技術深度，偏業務的開發更加考驗程式員的能力，比如溝通能力、分析問題解決問題能力、權衡取舍能力、架構能力等，畢竟業務多種多樣，問題千奇百怪，單一細分領域的經驗很難應對所有問題。

實際上，業務系統的開發難度一般來自兩個方面：高性能要求和業務複雜。

解決性能問題，你需要具備一定的架構能力，有一定的技術廣度，需要對各種基礎架構、架構、中間件都有所了解。光了解還不夠，還要有一定的技術深度，最好能對原理甚至是源碼有所研究。除此之外，還要有一定的使用經驗。廣度、深度、經驗三者配合，這樣才能做到恰到好處組合這些技術搭建架構，解決性能問題，并且在出現問題之後才能快速地解決。

應對大型項目的業務複雜性，要想讓項目代碼一直在你的掌控範圍内，你需要有很強的業務模組化能力、複雜邏輯的抽象能力、代碼翻譯能力等。對于一個人的基本素質、基礎能力的要求要更高。實際上，對于複雜業務系統來說，對業務的熟悉也能成為你的競争壁壘，成為升職加薪的砝碼。我前面也講到，低級别的晉升靠技術，比如升阿裡的P7，進階别的晉升靠業務，比如升阿裡的P8、P9，或者換個說法，進階别的晉升，靠業務比單純靠技術，更容易一些。

如果你參與的項目，性能要求高、業務也複雜，那恭喜你，好好幹就成了。如果你參與的項目，在性能和複雜度上，隻兼具其中一點，那也不錯，值得一做。如果你參與的項目，既沒有性能壓力、業務也不複雜，那也别太着急，走着瞧，實在不行再跳槽。

課堂讨論

在過往的項目經曆中，你有沒有像我一樣，接手過代碼品質比較差的代碼？你又是如何順利接手的呢？

歡迎留言和我分享你的想法。如果有收獲，也歡迎你把這篇文章分享給你的朋友。

内容來源：《設計模式之美》https://time.geekbang.org/column/article/259489?utm_source=zmt&utm_medium=zmt&utm_term=zmt