十步教你如何接手別人的代碼！

想必在很多程序員的職業生涯中，都有過一種難以避免的狀況，即接下別人的代碼。而這是種怎樣的體驗？有人說，接手別人的代碼之後我也想辭職；有人說，一個連注釋都沒有的代碼有何靈魂可言；更有網友說，如果你恨一個人，就讓他接手別人的代碼吧......

因此，在我們面對別人遺留下來的代碼時，究竟該如何處理？

作者 |Eric Stiens

譯者 | 彎月，責編 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下為譯文：

最近，我找到了一份新工作，結果卻發現自己又一次身處相同的漩渦：接手一個陌生的大型代碼庫，我不知道這些代碼建立的初衷，也不明白編寫代碼的背景。

我不知道哪些代碼存在已知的問題，團隊中的其他開發掌管哪些代碼，哪些代碼需要重構，而哪些代碼可能永遠也不會被觸碰。這完全是一個未知的領域，而且四周危機四伏。

在本文中，我將分享一些關於如何接手一個陌生代碼庫，並為團隊做出貢獻的經驗。

搭建開發環境

首先搭建好應用程序的開發環境：安裝依賴項，初始化資料庫、配置網路連接等。一般來說，這些工作都不會一帆風順。每個應用的背後都有一群開發人員，他們很難把每一個小竅門都爛熟於心。所以要注意做好筆記。你需要把一切不能按預期工作的問題都記錄下來。無法正確地安裝代碼庫的依賴項？記錄下來。無法初始化資料庫？記錄下來。初始化的用戶都密碼跟README中的密碼不一致？記錄下來。這是你發揮作用的第一步！缺乏知識就是你的優勢，因為這些問題都凸顯了文檔和構建腳本的缺陷。所以抓住這次機會。對於開發團隊來說，能夠通過可靠的手段搭建應用程序環境也是一項艱巨的任務，雖然這項任務經常被人忽略。你可以讓團隊再次注意到這些問題。

保持謙虛

毫無疑問，你會覺得有些代碼寫得很糟糕。有些代碼太過於取巧或太簡單。有些代碼沒有經過充分的測試。有些代碼過於冗長。有些代碼有嚴重的耦合。你可能想立即重構。

幾個月後，你看自己的代碼時也會有同樣的感受。

人們在重重約束下，盡其所能編寫了這些代碼。想必這些代碼完成了一些功能，而且現在你接手了這些代碼。有一天，有人會在不了解上下文的情況下看到你寫的代碼，他們可能也會覺得你的代碼很糟。

所以，你不應該這樣想。你應該用初學者的心態，想法改進這些代碼，就像我們在第1條中提到的那樣，缺乏知識就是你的優勢。你不像其他的團隊成員，他們在這個應用程序上工作了數月或數年，所以你沒有他們那樣的偏見，也沒有盲點。對你來說，一切都很新鮮。但是你也沒有足夠的背景知識下結論，所以不要總覺得自己能夠寫出更好的代碼！

黃金通道

找到應用程序中關鍵的一個功能。只需一個。這可以是關鍵的索引視圖或API端點。也可以是一個能完成很多功能的函數。然後，你需要找到一個測試，測試通往端點的黃金通道（在這個過程中，請暫時忽略其他干擾因素，比如輔助函數、錯誤處理、語法糖等）。如果沒有這樣的測試，你可以自己寫一個（請參照第4條）。

接下來，運行這個測試，並反向追蹤。找到輸出，通過閱讀代碼和調試技術找到輸入。然後將這些輸入作為輸出，再找下一個輸入，以此類推。提醒自己這只是一道非常複雜的邏輯難題。這中間沒有任何神秘的事情發生。一切都按部就班。任何輸出都不會憑空產生（請忽略庫、元編程、以及大量的依賴關係……這些只會讓手頭的代碼更為複雜，但它們也只是更多的代碼而已……）

寫測試

在了解現有代碼庫時，不引入任何錯誤，同時還能幫助你學習的一個好辦法就是測試文檔記載的現有功能。測試覆蓋範圍因具體情況而異。對於大多數開發團隊來說，單元測試是理想的選擇，但隨著你深入了解更高層的抽象，覆蓋範圍會變得更加模糊。你可以通過編寫良好的集成規範來簡單記錄已經完成的工作。在搞清楚你測試的這些行為背後的驅動因素後，就可以了解到大量的代碼。你可以幫助自己和其他人今後更容易地重構代碼，而且你不會破壞任何代碼，除了可能會改動部分測試代碼之外！

大量閱讀

大量閱讀。不僅僅是代碼——你遲早都要熟知代碼。閱讀Slack過往的聊天記錄。閱讀提交消息。閱讀PR中的注釋。閱讀資料庫結構。閱讀事故報告。閱讀文檔以及文檔的修改記錄。不要認為這些工作沒有意義。你應該像一塊海綿，吸收所有的背景知識，即便目前你一頭霧水，也無需擔心。你還沒有正式開始工作，所以只需不斷收集零落在各個角落的故事，堅持一周或一個月你就會有所眉目。用直覺去感受大量的上下文，稍後就會有所幫助。

結對編程

請求別人和你結對編程。即便沒有人結對。即便你害怕結對。即便只有20分鐘。當別人在編寫代碼的時候，坐在一旁觀看，即便這些代碼目前你還用不到。要求與別人結對編程，即便他們不太了解你需要修改的那部分代碼。團隊中的每個人都積攢了大量的重要知識。這一個階段的工作是讓他們儘可能地將這知識傳輸給你。通常，你只需坐在一旁看他們寫代碼以及瀏覽代碼，就可以吸收大量信息，同時還可以幫助別人找出代碼中的拼寫錯誤，

提問

積極提問。不要在乎哪些問題太白痴。你的問題很重要，因為這些問題可能揭示了當前團隊沒有意識到的一些問題。你的問題很重要，因為你不必知道一切。既然你已經被錄取了，面試已經結束了，那麼你就是團隊的一員，優秀的開發團隊應該互相幫助，沒有人會有優越感。

一位優秀的經理/項目經理

這一點上你可能無能為力（除非你本人就是經理），但如果你的確是團隊經理的話，則需要分配給新來的開發人員一些簡單的任務。一般來說，這些都不是關鍵性的任務，而且也許新成員會犯錯。這些任務應該是簡單的功能或改bug，而且還應該讓新成員接觸到儘可能多的代碼。理想情況下，你應該確切地知道這些任務需要修改哪部分代碼，但你只能給出一些提示，比如：

「我感覺有一些奇怪的nil值以某種方式傳遞到了這個方法中，你可以看看X類和Y類，我感覺這兩個類可能漏掉了某處錯誤，然後不知怎地傳遞了錯誤的數據。」

澄清需求並尋求幫助

在第一次修改代碼的時候，你需要搞清楚具體的需求。首先應該確保大家的理解沒有偏差。如果你在某個任務上花費的時間超出了預想，則應該立即重新討論。尋求幫助，你沒有責任理解所有的代碼，每個人都有責任幫助你步入正常的工作。

「我認為我應該修改這個視圖，所以整個下午我都在看X和Y，但還是沒搞清楚這個值從哪兒來的，你可不可以花半個小時看看這段代碼，然後幫我搞清楚問題所在？」

你可以表現出自己的弱勢，在團隊成員的幫助下學習，這有助於提高團隊的指導水平，而且教學互長，在向你解釋代碼的過程，他們也可以加深對代碼的理解。

在向別人解釋代碼的時候，你完全可以說：「我……不太清楚這個方法，但我們應該修復這個問題。」

放鬆心情

有人僱傭你或讓你參與某個項目，是因為人們相信你，而不是為了考驗的你的編程技術有多爛。適應陌生的代碼庫需要一定的時間。有時候，還需要很多時間。但說到底也只是一些代碼，而作為開發你自然很懂代碼。雖然你可能還不熟悉眼前的代碼，但你也可以利用適應的過程為團隊創造價值。你要保持耐心、謙虛，同時還要密切關注大局，不要害怕花時間深入了解某個特定的功能。

原文：https://medium.com/@ericstiens/10-thoughts-on-orienting-yourself-in-a-new-codebase-2c2e9f443de2

本文為CSDN翻譯，轉載請註明來源出處。

【END】

熱 文推 薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！