程序員，看他是如何高興的接手別人遺留下的代碼的？

對於別人遺留下來的代碼該如何接手呢？這應該是大多數剛入職的程序員面臨的問題！其實這狀況分爲兩種，第一種是前人還在職，這種狀況你能夠向他請教一下代碼的總體架構以及當時爲何這麼作。特別是一些業務代碼，裏面確定含了不少細節，必定要弄懂，不懂就問前輩，最後對整個業務瞭解後能夠考慮對代碼進行重構。第二種就是前人已經離職，這種狀況下也很差意思再讓他幫忙，只能靠本身一點一點捉摸，弄懂每一行代碼的邏輯，特別是業務邏輯，能夠找相應的產品瞭解一下相關業務，等弄懂後在對代碼進行重構，切記在沒有弄懂業務的前提下重構代碼，否則頗有可能形成線上重大問題！程序員

接手別人代碼是程序員最不喜歡作的事情之一，特別是沒有註釋的代碼，優秀的代碼自己自帶註釋，如今不少優秀開源的代碼註釋極少，但你們基本上都能服氣的確代碼質量高，但國內軟件開發環境絕大部分都是趕出來的代碼，主要考慮仍是短期內可以完成功能需求，能在規定時間內把需求搞完就算很不錯的了，更別說是文檔和註釋了，特別是文檔，不少人喊着前任程序員寫的程序代碼沒有留下文檔，但本身寫的代碼程序留下基本的文檔的也不多，在這種大環境下獨善其身也很難。
web

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

對於遺留代碼如何處理？
1.首先保證原有功能的穩定使用，畢竟剛接手代碼總體的設計思想以及理念都不清晰的狀態下，維穩是第一要素，先是嘗試看懂代碼瞭解代碼，作局部功能的修改，時間長了真正搞明白了再去作大規模的調整。架構

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

3.若是是很是優秀的代碼，就不要想太多了，直接開始慢慢消化學習，從基本的api接口學習，利用好測試模塊代碼，成熟的代碼維護起來也會比較方便，以學習態度對待。svg

C++視頻跟筆記都是全網最新最全的，看完工資翻翻，羣玖四捌，玖伍四，四捌四學習

總之來說接手前任代碼第一要素瞭解各個模塊的功能，若是有文檔就學習，沒有文檔就給補上，代碼質量不好就想辦法重構，接手別人代碼在編碼生涯中很是常見，要懂得西納百川，融合各類可能，這是做爲一個程序員的基本標準。測試

但願能幫到你。編碼