對於別人遺留下來的程式碼該如何接手呢？這應該是大多數剛入職的程式設計師面臨的問題！其實這情況分為兩種，第一種是前人還在職，這種情況你可以向他請教一下程式碼的整體架構以及當時為什麼這麼做。特別是一些業務程式碼，裡面肯定含了很多細節，一定要弄懂，不懂就問前輩，最後對整個業務瞭解後可以考慮對程式碼進行重構。第二種就是前人已經離職，這種情況下也不好意思再讓他幫忙，只能靠自己一點一點捉摸，弄懂每一行程式碼的邏輯，特別是業務邏輯，可以找相應的產品瞭解一下相關業務，等弄懂後在對程式碼進行重構，切記在沒有弄懂業務的前提下重構程式碼，不然很有可能造成線上重大問題！

接手別人程式碼是程式設計師最不喜歡做的事情之一，特別是沒有註釋的程式碼，優秀的程式碼本身自帶註釋，現在很多優秀開源的程式碼註釋極少，但大家基本上都能服氣的確程式碼質量高，但國內軟體開發環境絕大部分都是趕出來的程式碼，主要考慮還是短時間內能夠完成功能需求，能在規定時間內把需求搞完就算很不錯的了，更別說是文件和註釋了，特別是文件，很多人喊著前任程式設計師寫的程式程式碼沒有留下文件，但自己寫的程式碼程式留下基本的文件的也很少，在這種大環境下獨善其身也很難。

曾經在一家公司工作，有一部分的程式碼已經成為了死穴，外圍功能使用起來沒有多大問題，但裡面的程式碼結構比較混亂，基本上上沒人敢去觸碰，由於互相呼叫的次數太多，加上當初設計程式碼的人已經離職，後來的人由於板塊涉及太多也沒法動彈。

1.首先保證原有功能的穩定使用，畢竟剛接手程式碼整體的設計思想以及理念都不清晰的狀態下，維穩是第一要素，先是嘗試看懂程式碼瞭解程式碼，做區域性功能的修改，時間長了真正搞明白了再去做大規模的調整。

2.搞清楚接手的程式碼在整個公司中的地位以及前景，同時對程式碼的優劣程度做出一個評估，如果是寫的框架比較差，同時還是未來主打的一個方向，這個時候需要從長計議，考慮抽出一段時間對程式碼進行重構，使之真正成為有效的程式碼塊，在這塊就需要和上級主管做好密切的溝通，商議出重構的時間，並且做好程式碼重構的文件說明。

3.如果是非常優秀的程式碼，就不要想太多了，直接開始慢慢消化學習，從基本的api介面學習，利用好測試模組程式碼，成熟的程式碼維護起來也會比較方便，以學習態度對待。

總之來講接手前任程式碼第一要素瞭解各個模組的功能，如果有文件就學習，沒有文件就給補上，程式碼質量很差就想辦法重構，接手別人程式碼在編碼生涯中非常常見，要懂得西納百川，融合各種可能，這是作為一個程式設計師的基本標準。

首先要批判地接受。理論上只要好用沒bug程式碼就是好程式碼。畢竟程式寫出來是用來跑的。

但是為了工程化，各種程式碼規約，設計模式等出爐。

有很多程式設計師不遵守這些，咋說呢，這個事辯證地看。

一般剛畢業，進入一個大公司，不管做產品還是外包，會有一套成熟的培養體系，像小孩似的，類似程式設計師軍訓感覺，會把人教的很規範。90%程式設計師一般具備這種水準。

麻煩的是另外一部分，特別是讀研的，在學校所謂跟導師幹工程。高校的老師，計算機工程水平基本是不合格水平，帶出來學生也就帶著隨意邋遢的基因。這部分人進去職場，出色的技術能力，良好的技術基礎，而且年齡和三年經驗的人差不多，誰還不好意思像剛畢業那麼教和訓斥，特別還有求於這些技術人才做重點技術攻關。慢慢這些人還快速成長，寫一些關鍵程式碼，工程上0分的基因一直帶著。後人根本無法維護。所謂風格很差的程式碼，思維複雜的程式碼很多都是這些人寫出來的，更讓人稱奇的是他們還有自己的道理，效能，程式碼節省，等等，眼看就要發展出新設計模式了。

但是不規範就是不規範，狡辯終究是狡辯，可能確實他們的程式碼很優秀，很有創意。但是工程上程式碼為了可維護，所以不能隨意發揮。

先熟悉程式碼的整體框架及功能，多看看交接時所儲存的文件，最好和原來寫程式碼的人員有所交流。然後區域性修改並測試自己的理解是否正確，反覆這樣。對於好的模組程式碼可直接適用，對於效能不好的模組程式碼自己可以嘗試修改。曾就職一家公司產品需要升級，原來是51微控制器實現，後來改為ARM+Linux實現，我就對其中的程式碼“取其精華，去其糟粕”。

對於程式設計師來說，接手別人遺留下來的程式碼幾乎是一件不可避免的事情，原因是多方面的，常見的原因包括人員流動、專案調整等等，這些都會導致開發人員半路接手別人的程式碼。

對於開發人員來說，半路接手別人的遺留程式碼需要做好以下幾件事情：

第一：首先理清整體程式碼模組。隨著軟體開發過程的逐漸規範化，現在大部分專案的程式碼還是比較規範的，先從程式碼的整體結構入手，然後逐漸深入程式碼的各個組成部分，該添加註釋的地方自己新增一下注釋，並做出說明。

第二：先封裝後調整。對於半路接下來的程式碼，首先要把原有程式碼進行一定的“封裝”，因為功能還需要繼續開發，所以要保證新功能和原有功能不能出現大的衝突，對於已經上線運營的產品來說，更要保證已有功能的正常執行，所以要先封裝再調整。在趕上開發進度之後，再根據實際需要進行已有程式碼的整理，這是一個比較可行的辦法。

第三：重視交流。在接手已有程式碼的時候，最好跟團隊中的其他成員做好交流工作，因為大部分開發任務都是團隊協作的結構，大部分程式碼都存在邏輯上的關聯關係。如果是應用級開發，那麼程式碼裡就需要呼叫“容器”的功能，而此時跟開發容器的同事進行交流會節省大量的時間，畢竟不同公司開發的“容器”還是存在一定區別的。

不少程式設計師在接手別人程式碼的時候會隨著時間的推移，逐漸把程式碼調整成自己熟悉的風格，這也是一個比較常見的情況，但是一定要注意不能影響正常的開發進度，千萬不要在新功能沒有開發出來的情況下，就大面積修改遺留程式碼。

作者簡介：中國科學院大學計算機專業研究生導師，從事IT行業多年，研究方向包括動態軟體體系結構、大資料、人工智慧相關領域，有多年的一線研發經驗。

多看少動，能不改則不改，能補丁就補丁，有時間就慢慢釐清，滲透。這樣講，似乎是不求有功，但求無過。但如果你承接的數百萬行程式碼，而且這些程式碼已經上線執行，或經過量產的考驗，你就會理解我說的了。

文件，框架，用例，邏輯，模組，業務，等等，要想徹底吃透這些程式碼，除了以上輔助手段外，更需要你有深厚的程式碼基本功，過人的耐力與毅力。除非必要，否則真沒必要花那功夫，還想重構？推倒重來？有那功夫你還不如創造點新程式碼呢。老闆花錢請你，主要是想創造利潤。

問題來了，如果工作就是維護現有系統程式碼呀，怎麼辦？啃骨頭般的啃程式碼了，設計資料進行測試，觀察資料流，分析邏輯業務，慢慢吃透吧。