想必在很多程序員的職業(yè)生涯中，都有過一種難以避免的狀況，即接下別人的代碼。而這是種怎樣的體驗？有人說，接手別人的代碼之后我也想辭職；有人說，一個連注釋都沒有的代碼有何靈魂可言；更有網(wǎng)友說，如果你恨一個人，就讓他接手別人的代碼吧......
因此，在我們面對別人遺留下來的代碼時，究竟該如何處理？
作者 | Eric Stiens
譯者 | 彎月，責編 | 屠敏
出品 | CSDN（ID：CSDNnews）
以下為譯文：
最近，我找到了一份新工作，結(jié)果卻發(fā)現(xiàn)自己又一次身處相同的漩渦：接手一個陌生的大型代碼庫，我不知道這些代碼建立的初衷，也不明白編寫代碼的背景。
我不知道哪些代碼存在已知的問題，團隊中的其他開發(fā)掌管哪些代碼，哪些代碼需要重構(gòu)，而哪些代碼可能永遠也不會被觸碰。這完全是一個未知的領(lǐng)域，而且四周危機四伏。
在本文中，我將分享一些關(guān)于如何接手一個陌生代碼庫，并為團隊做出貢獻的經(jīng)驗。
搭建開發(fā)環(huán)境
首先搭建好應用程序的開發(fā)環(huán)境：安裝依賴項，初始化數(shù)據(jù)庫、配置網(wǎng)絡(luò)連接等。一般來說，這些工作都不會一帆風順。每個應用的背后都有一群開發(fā)人員，他們很難把每一個小竅門都爛熟于心。所以要注意做好筆記。你需要把一切不能按預期工作的問題都記錄下來。無法正確地安裝代碼庫的依賴項？記錄下來。無法初始化數(shù)據(jù)庫？記錄下來。初始化的用戶都密碼跟README中的密碼不一致？記錄下來。這是你發(fā)揮作用的第一步！缺乏知識就是你的優(yōu)勢，因為這些問題都凸顯了文檔和構(gòu)建腳本的缺陷。所以抓住這次機會。對于開發(fā)團隊來說，能夠通過可靠的手段搭建應用程序環(huán)境也是一項艱巨的任務，雖然這項任務經(jīng)常被人忽略。你可以讓團隊再次注意到這些問題。
保持謙虛
毫無疑問，你會覺得有些代碼寫得很糟糕。有些代碼太過于取巧或太簡單。有些代碼沒有經(jīng)過充分的測試。有些代碼過于冗長。有些代碼有嚴重的耦合。你可能想立即重構(gòu)。
幾個月后，你看自己的代碼時也會有同樣的感受。
人們在重重約束下，盡其所能編寫了這些代碼。想必這些代碼完成了一些功能，而且現(xiàn)在你接手了這些代碼。有一天，有人會在不了解上下文的情況下看到你寫的代碼，他們可能也會覺得你的代碼很糟。
所以，你不應該這樣想。你應該用初學者的心態(tài)，想法改進這些代碼，就像我們在第1條中提到的那樣，缺乏知識就是你的優(yōu)勢。你不像其他的團隊成員，他們在這個應用程序上工作了數(shù)月或數(shù)年，所以你沒有他們那樣的偏見，也沒有盲點。對你來說，一切都很新鮮。但是你也沒有足夠的背景知識下結(jié)論，所以不要總覺得自己能夠?qū)懗龈玫拇a！
黃金通道
找到應用程序中關(guān)鍵的一個功能。只需一個。這可以是關(guān)鍵的索引視圖或API端點。也可以是一個能完成很多功能的函數(shù)。然后，你需要找到一個測試，測試通往端點的黃金通道（在這個過程中，請暫時忽略其他干擾因素，比如輔助函數(shù)、錯誤處理、語法糖等）。如果沒有這樣的測試，你可以自己寫一個（請參照第4條）。
接下來，運行這個測試，并反向追蹤。找到輸出，通過閱讀代碼和調(diào)試技術(shù)找到輸入。然后將這些輸入作為輸出，再找下一個輸入，以此類推。提醒自己這只是一道非常復雜的邏輯難題。這中間沒有任何神秘的事情發(fā)生。一切都按部就班。任何輸出都不會憑空產(chǎn)生（請忽略庫、元編程、以及大量的依賴關(guān)系……這些只會讓手頭的代碼更為復雜，但它們也只是更多的代碼而已……）
寫測試
在了解現(xiàn)有代碼庫時，不引入任何錯誤，同時還能幫助你學習的一個好辦法就是測試文檔記載的現(xiàn)有功能。測試覆蓋范圍因具體情況而異。對于大多數(shù)開發(fā)團隊來說，單元測試是理想的選擇，但隨著你深入了解更高層的抽象，覆蓋范圍會變得更加模糊。你可以通過編寫良好的集成規(guī)范來簡單記錄已經(jīng)完成的工作。在搞清楚你測試的這些行為背后的驅(qū)動因素后，就可以了解到大量的代碼。你可以幫助自己和其他人今后更容易地重構(gòu)代碼，而且你不會破壞任何代碼，除了可能會改動部分測試代碼之外！
大量閱讀
大量閱讀。不僅僅是代碼——你遲早都要熟知代碼。閱讀Slack過往的聊天記錄。閱讀提交消息。閱讀PR中的注釋。閱讀數(shù)據(jù)庫結(jié)構(gòu)。閱讀事故報告。閱讀文檔以及文檔的修改記錄。不要認為這些工作沒有意義。你應該像一塊海綿，吸收所有的背景知識，即便目前你一頭霧水，也無需擔心。你還沒有正式開始工作，所以只需不斷收集零落在各個角落的故事，堅持一周或一個月你就會有所眉目。用直覺去感受大量的上下文，稍后就會有所幫助。
結(jié)對編程
請求別人和你結(jié)對編程。即便沒有人結(jié)對。即便你害怕結(jié)對。即便只有20分鐘。當別人在編寫代碼的時候，坐在一旁觀看，即便這些代碼目前你還用不到。要求與別人結(jié)對編程，即便他們不太了解你需要修改的那部分代碼。團隊中的每個人都積攢了大量的重要知識。這一個階段的工作是讓他們盡可能地將這知識傳輸給你。通常，你只需坐在一旁看他們寫代碼以及瀏覽代碼，就可以吸收大量信息，同時還可以幫助別人找出代碼中的拼寫錯誤，
提問
積極提問。不要在乎哪些問題太白癡。你的問題很重要，因為這些問題可能揭示了當前團隊沒有意識到的一些問題。你的問題很重要，因為你不必知道一切。既然你已經(jīng)被錄取了，面試已經(jīng)結(jié)束了，那么你就是團隊的一員，優(yōu)秀的開發(fā)團隊應該互相幫助，沒有人會有優(yōu)越感。
一位優(yōu)秀的經(jīng)理/項目經(jīng)理
這一點上你可能無能為力（除非你本人就是經(jīng)理），但如果你的確是團隊經(jīng)理的話，則需要分配給新來的開發(fā)人員一些簡單的任務。一般來說，這些都不是關(guān)鍵性的任務，而且也許新成員會犯錯。這些任務應該是簡單的功能或改bug，而且還應該讓新成員接觸到盡可能多的代碼。理想情況下，你應該確切地知道這些任務需要修改哪部分代碼，但你只能給出一些提示，比如：
“我感覺有一些奇怪的nil值以某種方式傳遞到了這個方法中，你可以看看X類和Y類，我感覺這兩個類可能漏掉了某處錯誤，然后不知怎地傳遞了錯誤的數(shù)據(jù)?！?/p>
澄清需求并尋求幫助
在第一次修改代碼的時候，你需要搞清楚具體的需求。首先應該確保大家的理解沒有偏差。如果你在某個任務上花費的時間超出了預想，則應該立即重新討論。尋求幫助，你沒有責任理解所有的代碼，每個人都有責任幫助你步入正常的工作。
“我認為我應該修改這個視圖，所以整個下午我都在看X和Y，但還是沒搞清楚這個值從哪兒來的，你可不可以花半個小時看看這段代碼，然后幫我搞清楚問題所在？”
你可以表現(xiàn)出自己的弱勢，在團隊成員的幫助下學習，這有助于提高團隊的指導水平，而且教學互長，在向你解釋代碼的過程，他們也可以加深對代碼的理解。
在向別人解釋代碼的時候，你完全可以說：“我……不太清楚這個方法，但我們應該修復這個問題?！?/p>
放松心情
有人雇傭你或讓你參與某個項目，是因為人們相信你，而不是為了考驗的你的編程技術(shù)有多爛。適應陌生的代碼庫需要一定的時間。有時候，還需要很多時間。但說到底也只是一些代碼，而作為開發(fā)你自然很懂代碼。雖然你可能還不熟悉眼前的代碼，但你也可以利用適應的過程為團隊創(chuàng)造價值。你要保持耐心、謙虛，同時還要密切關(guān)注大局，不要害怕花時間深入了解某個特定的功能。
原文：https://medium.com/@ericstiens/10-thoughts-on-orienting-yourself-in-a-new-codebase-2c2e9f443de2
【END】
