我接手的第一樣東西就是React UI。我們有一個主要組件，它容納了其他所有組件。我喜歡在代碼中加入一點幽默感，我想把它命名為GodComponent。在code review的時候，我才明白為什么命名是一件很難的事情。

計算機科學有兩個難點：緩存失效，給變量命名，以及差一錯誤。

我經手的每一段代碼都帶有隱喻意。GodComponent?那時用來盛放所有那些我不知道該放到哪里的的爛代碼的。它包羅萬象。如果我將一個變量命名為LayoutComponent，未來我會知道，它所做的只是規劃布局，而不涉及任何狀態。

我發現的另一個好處是：如果它看起來太大了，就像包含大量業務邏輯的LayoutComponent一樣，我知道是時候重構了，因為業務邏輯不應當屬于那部分。而如果使用GodComponent這個名稱，那對里面的業務邏輯就不會產生任何影響。

命名你的集群?根據在它上面運行服務來命名是個好主意，可是你以后還可能會在上面運行其他東西。最終，我們是用團隊名稱來命名的。

對于函數來說也是一樣。doEverything()是一個可怕的名字，這會產生很多后果。如果這個函數可以完成所有操作，那么測試這個函數的特定部分就會變得特別難。無論這個函數有多大，你都不會覺得奇怪，因為畢竟這個函數就是要做所有事情的。所以需要換個函數名，重構。

有意義的命名也有不好的一面。如果名稱太有意義并隱藏一些歧義怎么辦?例如，在SQLAlchemy中調用session.close()時，closing sessions不會關閉基礎數據庫連接。

在這種情況下，將名稱視為x，y，z而不是count()，close()，insertIntoDB()可以防止賦予它們隱含意義——并迫使我仔細檢查它們正在做什么。

從來沒想到，關于命名我要說的東西居然不能用一句話就概括完。

舊代碼和下一個開發者

你有沒有看過一些代碼并覺得很奇怪?那些開發者為什么這樣做?這完全說不通啊。

我有幸曾經使用過遺留代碼庫。其中有類似這樣的注釋，“在與穆罕默德一起解決了這個問題以后，注釋就刪掉了。”你在做什么?誰是穆罕默德?

我可以在這里做一個角色轉換——想想以后來接手我代碼的人們——他們會不會發現它很奇怪。Peer review 部分解決了這個問題。這讓我意識到了環境的重要性：要時刻記得我的團隊正在工作的環境是什么樣的。

如果我忘記了代碼，稍后又看到它，而無法重新回想起當時的環境時，我會說：“到底為什么他們會這樣做?這講不通......哦等等，這是我自己寫的?！?/p>

這就是文檔和代碼注釋發揮作用的地方了。

文檔和代碼注釋

它們有助于保留環境(上下文，語境)，以及分享知識。

正如Li在“如何建立良好的軟件”中所說的那樣，“軟件的主要價值不在于生成的代碼，而在于產生它的人所積累的知識?！?/p>

“軟件的主要價值不在于產生的代碼，而在于產生它的人所積累的知識?！薄狶i

我們有一個面向客戶的API終端，似乎沒有人使用過。我們只是刪除它嗎?畢竟，這是技術負債。

如果我告訴你，每年在特定國家/地區，10名記者會將他們的報告發送到該終端，該怎么辦?你要如何測試?如果沒有文檔(現實中確實沒有)，我們就沒辦法。所以，我們沒有那么做。我們直接刪除了該端點。幾個月以后那個一年一度的時刻到了。十名記者無法發送10份重要報告，因為終端不再存在了。

擁有關于這個產品的知識的人離開了團隊。當然，現在代碼中有一些注釋解釋了端點的用途。

據我所知，文檔是一個每個團隊都在努力解決的問題。不僅僅是代碼文檔，還有代碼周圍的流程。

我們還沒有找到一個完美的解決方案。

我很喜歡Antirez對不同類型的有價值的代碼注釋的詳細分類。

原子提交

如果你必須回到之前的步驟(是的你會的。詳見測試部分)，這個提交作為一個單元是否合適?

在刪除爛代碼的時候有自信

刪除爛代碼或過時的代碼會使我感到非常不舒服。我認為多年之前被寫下的代碼是神圣的。我的想法是“當他們寫下這些東西時，他們肯定是考慮到一些事情的。”這是傳統和文化與第一原則思維方式之間的較量。刪除一年一次的終端也是如此。我在這方面得到了太多具體的教訓。

我會試著從周圍解決代碼，而高級工程師則會試著從中間解決。刪除所有內容。一個永遠不會運行的if語句?一個不應該調用的函數?是的，一切都沒了。我?我只會在最上面寫下我自己的函數而已。我沒有減少技術債務。如果我做了什么的話，我也只是增加了代碼復雜性和給他人的誤導而已。對下一個人來說把這些代碼功能拼湊到一起會更艱難。

我現在使用的啟發式是：現在有的代碼你無法理解，而且你知道有些代碼是你永遠也不會用到的。刪除那些你永遠不會用到的代碼，并對那些你不理解的代碼保持謹慎的態度。

Code Reviews

Code review是非常棒的學習途徑。這是一個外部反饋循環，反映了你現在和將來會怎么寫代碼。差別在哪里?有一種方式比另一種更好嗎?我在每次code review時都會問自己這個問題：“為什么他們那樣做?”。每當我找不到合適的答案時，我都會和他們談談。

在第一個月之后，我開始在我的隊友代碼中發現一些錯誤(就像他們曾經為我做的那樣)。這太瘋狂了。同行評論對我來說變得更加有趣了——變成了我期待的一場游戲——一場改善我的代碼感的游戲。

我的啟發是：在我了解代碼如何工作之前不要批準代碼。好啦！今天的分享到這里就結束了，希望大家持續關注馬哥教育官網，每天都會有大量優質內容與大家分享！

版權聲明：轉載文章來自公開網絡，版權歸作者本人所有，推送文章除非無法確認，我們都會注明作者和來源。如果出處有誤或侵犯到原作者權益，請與我們聯系刪除或授權事宜。