團隊裡的程序員張三丰要離職，領導讓你接手他的工作，叮囑你一定要儘快掌握張三丰的代碼。你的心兒撲通撲通地跳動，你的腦海裡縈繞著三個選擇：是拒絕呢，還是拒絕呢，還是拒絕呢？你強顏歡笑但實際上心煩意亂怨氣縱橫——接手別人的代碼，那可是程序員要面對的最痛苦最可怕的事啊。
你記起江湖前輩黃藥師說過的一句話：如果你恨他，就讓他去接手別人的代碼。
你的內心是拒絕的，可是你卻不由自主地說出了“可以啊”三個字，於是你悲催的旅程拉開了序幕。
這，就是程序員的工作啊~~~~你有什麼辦法……你特別擔心自己會被別人的代碼玩兒死，你憂心忡忡卻無計可施……真真是此情無計可消除，才下眉頭卻上心頭……
我能理解你的感受，因為這樣的事情，我經歷了沒十回也有八回。你不是一個人在戰鬥，想想這個你也許能得到些安慰，再不行，就看看下面的故事吧。
鐵中棠不堪老代碼的摧殘而離職
下面的故事發生在我做流媒體產品的時候。
那一年我招募了一個有三年工作經驗的程序員，叫鐵中棠（借用一下古龍《大旗英雄傳》中的主人公的名字）。我讓鐵中棠接管產品代碼裡的網絡傳輸模塊（P2P協議實現），我告訴他這個模塊很重要，公司的視頻點播產品最關鍵的就是這塊代碼，掌握了這塊代碼，就掌握了軟件的關鍵。
然後我又告訴鐵中棠，現在的代碼前後有四個人維護過，可能有些凌亂，讀起來有一定難度，如果遇到問題，隨時可以來問我。我還告訴他可以用SourceInsight來讀代碼，效率比較高。
鐵中棠面色凝重，沒有說什麼，只是點了點頭，回到自己的工位，打開了Qt Creator，開始看代碼了。
一個星期後，我問鐵中棠代碼看得怎麼樣，他面露難色，但卻什麼困難也沒說，只說正在看，正在瞭解。我再次叮囑他，有問題隨時問我，因為我也維護過那塊代碼，對代碼的邏輯有所瞭解。
又過了一個星期，鐵中棠找到我，猶猶豫豫地說覺得自己不太適合做軟件開發，準備離職。我大驚，難道別人的代碼真的像江湖傳言那樣能夠殺人於無形嗎？像鐵中棠這樣堅毅果決、鐵血無雙的大英雄、大豪傑居然也會被代碼殺死？
我問鐵中棠是不是覺得代碼太難懂了，他說確實有點兒難，但也不是因為代碼難懂就要離職，而是通過接手別人的代碼讓他意識到自己其實不太適合做開發，所以決定轉行，離開軟件開發了。
我心如刀割卻無話可說。
鐵中棠離職後，我又招了一個剛畢業的大學生陽頂天，聰明絕頂，意氣風發，我打算把P2P協議這模塊交給他。陽頂天看了幾天代碼，說現在的代碼雖然有點凌亂有點兒難懂，但自己有把握重構好它。我和他討論了重構計劃，他就開始重構了。
過了半年，陽頂天還在重構，重構的代碼還不能正常和服務器通信，而且他不看老代碼而是通過抓取並分析老程序的網絡報文來琢磨怎麼寫新代碼！於是我和他進行了一次艱難的談話，結果差點兒吵起來。再後來，陽頂天離開了公司，出國了……
怎樣才能不被玩兒死
卡夫卡說：一切障礙都可以粉碎我。這話如果從鐵中棠口中說出來，就是：任何代碼都可以玩兒死我。
你估計不願意像鐵中棠那樣被別人的代碼玩兒死。So，假如你真的要接手別人的代碼，怎樣才能不被玩兒死呢？
雖然你可能會說，聽了很多道理，依然交接不好代碼，可作為經常被別人的代碼玩兒的欲仙欲死的老司機，我有些話如鯁在喉，不吐不快。
當你被要求接管要離職的程序員的代碼時，如果能注意以下幾點，就有可能活著從他的代碼裡爬出來，而那些不能將你擊潰的代碼，都將成為你成長的墊腳石。
- 1. 產品需求與業務流程文檔
產品需求與業務流程文檔，這些是你先要找到的，你接手的代碼，必然和某個產品需求相對應，必然實現了某個業務流程，先了解產品需求和業務流程，才能更好的讀代碼。
假如你的團隊就是沒文檔，Ok，也可以要求離職或轉移戰線的這位程序員把需求描述出來，把業務流程畫出來。
- 2. 測試環境
瞭解了產品需求和業務流程，最好能體驗一下軟件，從用戶的角度來理解軟件的使用。這個時候你要麼需要生產環境，要麼需要測試環境。哪個環境不重要，重要的是，你需要一個能Run，能體驗的軟件。
- 3. 業務流程在代碼層面的體現
負責交接代碼給你的那位同事，要麼在辦離職，要麼已經介入了其他產品，眼下很可能已無心戀戰，但你心裡要清楚，只有他才能提供代碼層面的東西，比如
- 類圖模塊劃分說明數據流圖時序圖狀態圖
所以，你需要他整理一些文檔和圖表出來。你可以告訴領導你需要上面的東西，讓領導和他溝通，讓他在離開之前準備好這些文檔給你，並留一些時間以便你熟悉。
- 4. 讀代碼，不死不休
有了產品需求，有了業務流程，有了代碼設計相關的文檔和圖表，接下來你就該死磕代碼了：
while（不懂）
{
讀
}
- 5. 開發環境與調試
有的產品需要比較複雜的開發環境配置，一定要提前做好，讓即將離開的同事輔導你搭建好開發環境，這樣你就可以利用“調試”這個強大的武器來快速理解代碼了。
- 6. 調試
調試是接手別人代碼時的利器，如果你看不明白一個業務在代碼層面是怎麼體現的，也看不懂代碼之間的調用關係，那最好的辦法就是調試。從一個業務的起點所對應的代碼開始調試，一步一步跟進去，就能快速理清函數調用鏈。
- 7. 樹立可實現可衡量的目標
程序員的工作交接，尤其是代碼交接，怎樣才算順利完成呢？
這簡直就是一個謎！
沒人說得清楚。
所以，你最好給自己梳理一些可衡量的、可實現的目標。比如讀懂A、B、C三個業務流程……
最好，找一個Bug或者一個新增的功能，帶著目的去讀代碼、修改代碼，有目的，有目標，有時間盒，就容易投入，容易讀進去，容易掌握與Bug或新增功能相關的代碼的邏輯與流程。
- 8. 輸出、分享與重構
你在讀代碼時，如果能撇開給你交接工作的程序員提供的文檔，按自己的理解，自己繪製類圖、數據流圖、時序圖、關鍵業務流程對應的函數調用關係鏈等，就能更快的掌握別人的代碼。
如果你還能將你理解到的東西，講給其他人聽，並且講明白，那Ok，你真的理解了別人交接給你的代碼。
再進一步，如果你在理解現有代碼的基礎上，可以識別出哪些部分實現得邏輯不清晰或有待改善，然後可以結合業務與自己的理解將其重構，那就真的是完全接手了別人的代碼，別人的代碼與你的代碼就沒有差別了，它們終將成為你的代碼。
最重要的事兒
如果你總是看見代碼多就發愁，看見代碼髒亂差就詛咒埋怨，看見代碼邏輯複雜就頭疼，搞不清調用關係就放棄，那你可能永遠也變不成代碼的主人，只能一次又一次被代碼蹂躪。
所以，其實交接代碼最重要的事兒，就是：
不要被浩渺如煙並且陌生怪誕的代碼嚇得不敢動彈，現在就開始讀，立刻，馬上，堅持十分鐘，再堅持十分鐘，你就能妙悟真諦。
作者：安曉輝
鏈接：http://www.imooc.com/article/258125
來源：慕課網
本文原創發佈於慕課網 ，轉載請註明出處，謝謝合作
