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