前文：
最近，我找到了一份新工作，結果卻發現自己又一次身處相同的漩渦：接手一個陌生的大型代碼庫，我不知道這些代碼建立的初衷，也不明白編寫代碼的背景。
我不知道哪些代碼存在已知的問題，團隊中的其他開發掌管哪些代碼，哪些代碼需要重構，而哪些代碼可能永遠也不會被觸碰。這完全是一個未知的領域，而且四周危機四伏。
在本文中，我將分享一些關於如何接手一個陌生代碼庫，併爲團隊做出貢獻的經驗。
一、搭建開發環境
首先搭建好應用程序的開發環境：安裝依賴項，初始化數據庫、配置網絡連接等。一般來說，這些工作都不會一帆風順。每個應用的背後都有一羣開發人員，他們很難把每一個小竅門都爛熟於心。所以要注意做好筆記。你需要把一切不能按預期工作的問題都記錄下來。無法正確地安裝代碼庫的依賴項？記錄下來。無法初始化數據庫？記錄下來。初始化的用戶都密碼跟README中的密碼不一致？記錄下來。這是你發揮作用的第一步！缺乏知識就是你的優勢，因爲這些問題都凸顯了文檔和構建腳本的缺陷。所以抓住這次機會。對於開發團隊來說，能夠通過可靠的手段搭建應用程序環境也是一項艱鉅的任務，雖然這項任務經常被人忽略。你可以讓團隊再次注意到這些問題。
二、保持謙虛
毫無疑問，你會覺得有些代碼寫得很糟糕。有些代碼太過於取巧或太簡單。有些代碼沒有經過充分的測試。有些代碼過於冗長。有些代碼有嚴重的耦合。你可能想立即重構。
幾個月後，你看自己的代碼時也會有同樣的感受。
人們在重重約束下，盡其所能編寫了這些代碼。想必這些代碼完成了一些功能，而且現在你接手了這些代碼。有一天，有人會在不瞭解上下文的情況下看到你寫的代碼，他們可能也會覺得你的代碼很糟。
所以，你不應該這樣想。你應該用初學者的心態，想法改進這些代碼，就像我們在第1條中提到的那樣，缺乏知識就是你的優勢。你不像其他的團隊成員，他們在這個應用程序上工作了數月或數年，所以你沒有他們那樣的偏見，也沒有盲點。對你來說，一切都很新鮮。但是你也沒有足夠的背景知識下結論，所以不要總覺得自己能夠寫出更好的代碼！
三、黃金通道
找到應用程序中關鍵的一個功能。只需一個。這可以是關鍵的索引視圖或API端點。也可以是一個能完成很多功能的函數。然後，你需要找到一個測試，測試通往端點的黃金通道（在這個過程中，請暫時忽略其他干擾因素，比如輔助函數、錯誤處理、語法糖等）。如果沒有這樣的測試，你可以自己寫一個（請參照第4條）。
接下來，運行這個測試，並反向追蹤。找到輸出，通過閱讀代碼和調試技術找到輸入。然後將這些輸入作爲輸出，再找下一個輸入，以此類推。提醒自己這只是一道非常複雜的邏輯難題。這中間沒有任何神祕的事情發生。一切都按部就班。任何輸出都不會憑空產生（請忽略庫、元編程、以及大量的依賴關係……這些只會讓手頭的代碼更爲複雜，但它們也只是更多的代碼而已……）
四、寫測試
在瞭解現有代碼庫時，不引入任何錯誤，同時還能幫助你學習的一個好辦法就是測試文檔記載的現有功能。測試覆蓋範圍因具體情況而異。對於大多數開發團隊來說，單元測試是理想的選擇，但隨着你深入瞭解更高層的抽象，覆蓋範圍會變得更加模糊。你可以通過編寫良好的集成規範來簡單記錄已經完成的工作。在搞清楚你測試的這些行爲背後的驅動因素後，就可以瞭解到大量的代碼。你可以幫助自己和其他人今後更容易地重構代碼，而且你不會破壞任何代碼，除了可能會改動部分測試代碼之外！
五、大量閱讀
大量閱讀。不僅僅是代碼——你遲早都要熟知代碼。閱讀Slack過往的聊天記錄。閱讀提交消息。閱讀PR中的註釋。閱讀數據庫結構。閱讀事故報告。閱讀文檔以及文檔的修改記錄。不要認爲這些工作沒有意義。你應該像一塊海綿，吸收所有的背景知識，即便目前你一頭霧水，也無需擔心。你還沒有正式開始工作，所以只需不斷收集零落在各個角落的故事，堅持一週或一個月你就會有所眉目。用直覺去感受大量的上下文，稍後就會有所幫助。
六、結對編程
請求別人和你結對編程。即便沒有人結對。即便你害怕結對。即便只有20分鐘。當別人在編寫代碼的時候，坐在一旁觀看，即便這些代碼目前你還用不到。要求與別人結對編程，即便他們不太瞭解你需要修改的那部分代碼。團隊中的每個人都積攢了大量的重要知識。這一個階段的工作是讓他們儘可能地將這知識傳輸給你。通常，你只需坐在一旁看他們寫代碼以及瀏覽代碼，就可以吸收大量信息，同時還可以幫助別人找出代碼中的拼寫錯誤。
七、提問
積極提問。不要在乎哪些問題太白癡。你的問題很重要，因爲這些問題可能揭示了當前團隊沒有意識到的一些問題。你的問題很重要，因爲你不必知道一切。既然你已經被錄取了，面試已經結束了，那麼你就是團隊的一員，優秀的開發團隊應該互相幫助，沒有人會有優越感。
八、一位優秀的經理/項目經理
這一點上你可能無能爲力（除非你本人就是經理），但如果你的確是團隊經理的話，則需要分配給新來的開發人員一些簡單的任務。一般來說，這些都不是關鍵性的任務，而且也許新成員會犯錯。這些任務應該是簡單的功能或改bug，而且還應該讓新成員接觸到儘可能多的代碼。理想情況下，你應該確切地知道這些任務需要修改哪部分代碼，但你只能給出一些提示，比如：
“我感覺有一些奇怪的nil值以某種方式傳遞到了這個方法中，你可以看看X類和Y類，我感覺這兩個類可能漏掉了某處錯誤，然後不知怎地傳遞了錯誤的數據。”
九、澄清需求並尋求幫助
在第一次修改代碼的時候，你需要搞清楚具體的需求。首先應該確保大家的理解沒有偏差。如果你在某個任務上花費的時間超出了預想，則應該立即重新討論。尋求幫助，你沒有責任理解所有的代碼，每個人都有責任幫助你步入正常的工作。
“我認爲我應該修改這個視圖，所以整個下午我都在看X和Y，但還是沒搞清楚這個值從哪兒來的，你可不可以花半個小時看看這段代碼，然後幫我搞清楚問題所在？”
你可以表現出自己的弱勢，在團隊成員的幫助下學習，這有助於提高團隊的指導水平，而且教學互長，在向你解釋代碼的過程，他們也可以加深對代碼的理解。
在向別人解釋代碼的時候，你完全可以說：“我……不太清楚這個方法，但我們應該修復這個問題。”
十、放鬆心情
有人僱傭你或讓你參與某個項目，是因爲人們相信你，而不是爲了考驗的你的編程技術有多爛。適應陌生的代碼庫需要一定的時間。有時候，還需要很多時間。但說到底也只是一些代碼，而作爲開發你自然很懂代碼。雖然你可能還不熟悉眼前的代碼，但你也可以利用適應的過程爲團隊創造價值。你要保持耐心、謙虛，同時還要密切關注大局，不要害怕花時間深入瞭解某個特定的功能。