好的代碼往往也很好看!代碼是給機器運行的，但同樣也是給人看的，并且隨著上線還需要由人來運維。那么寫出可擴展、易維護、好讀懂的代碼就顯得非常重要。

[[343389]]
圖片來自 Pexels

 

對于新人來說，互聯網大廠項目開發(fā)與平常自己學習的代碼還是有很大的差別的。日常學習時候通常只要能運行出結果即可，并不會有其他的要求。

也不會說有;PRD 評審、研發(fā)設計評審、代碼開發(fā)、代碼評審以及中間一些列的提交物，直到測試完成，上線驗證，開量對外等等。

所以很多新人剛從學校畢業(yè)或者從小公司進入大廠，在規(guī)范制約下會有一些不習慣，甚至犯錯誤。

那么為了讓大家更好的知曉這些問題，我特意整理了一些例子，歡迎參考。

會議室

謝飛機，剛剛入職沒多久，興奮的寫著 Leader 給的需求，碼的飛快。恰巧組長走過來：“飛機，帶著你的電腦，跟我來會議室，做下代碼評審。”

Leader：飛機，你這代碼咋這么粗魯!

飛機：啊?😱

Leader：我要不攔著你，我感覺你這代碼都能飛。

Leader：你看哈，就說這行，這日志打的，上線后出了問題，你能查到原因嗎?

飛機：好像...

Leader：還有這，這 idea 都提示你了，都報黃色了，你怎么不看看。還有，這代碼也不格式化，一個月后它認識你，你還認識它嗎。

Leader：給你發(fā)的入職編碼規(guī)范看了?

飛機：哦，看一些，寫的時候忘了。

Leader：先別著急寫，看會了再寫代碼，這還有一個不錯的工程，可以參考。

寫代碼不是以完成功能就算完事，還需要寫的漂亮。評審后，飛機，坐回工位，收起了躁動的心，安心熟讀手冊并練習。

代碼評審

①日志規(guī)范

日志是整個代碼開發(fā)過程中非常重要的環(huán)節(jié)，如果日志打的不好，那么遇到的線上 Bug 就沒法快速定位，定位不了問題也就沒法快速解決問題。直接帶來的結果可能包括;客訴更多、資損更大、修復更慢。

public Result execRule(RuleReq req) { 
    try { 
        logger.info("執(zhí)行服務規(guī)則 req：{}", JSON.toJSONString(req)); 
        // 業(yè)務流程 
        return Result.buildSuccess(); 
    } catch (Exception e) { 
        logger.error("執(zhí)行服務規(guī)則失敗", e); 
        return Result.buildError(e); 
    } 
} 

就像上面這段代碼中的日志：

• 看似沒什么問題，但在這段異常代碼中，沒有打方法的入參信息。如果方法異常時只是拋出一些異常棧信息，那么是很難定位具體的由次調用觸發(fā)的。
• 另外如果你的系統(tǒng)監(jiān)控服務，沒有類似方法跟蹤 ID 的功能，最好還需要在日志中把本次調用具有標識性的 id，作為查詢條件打到日志中。

public Result execRule(RuleReq req) { 
    try { 
        logger.info("執(zhí)行服務規(guī)則{}開始 req：{}", req.getrId(), JSON.toJSONString(req)); 
        // 業(yè)務流程 
        logger.info("執(zhí)行服務規(guī)則{}完成 res：{}", req.getrId(), "業(yè)務流程，必要的結果信息"); 
        return Result.buildSuccess(); 
    } catch (Exception e) { 
        logger.error("執(zhí)行服務規(guī)則{}失敗 req：{}", req.getrId(), JSON.toJSONString(req), e); 
        return Result.buildError(e); 
    } 
} 

修改后的日志如上：

• 那么現在這樣改成這樣打日志，就可以非常方便的查詢問題，例如搜索;執(zhí)行服務規(guī)則 100098921，那么它的一整串關于這次調用的信息就可以都搜索出來了，方便排查問題。
• 在異常中打印入參是為了更加方便的定位問題，不需要比對上下文。
• 打日志還有很多技巧，但所有打的日志目的都為了在出問題時可以快速定位問題，但也注意不要打太多日志，精簡好用即可。

②IDEA 提示

很多時候因為你，走神、疏忽、手滑，寫出來的錯誤代碼，IntelliJ IDEA，都會給你警告⚠提示，只是你，沒有去看、沒有去看、沒有去看!

來自 idea 的警告：

 

idea 警告

idea 在警告提示這方面非常優(yōu)秀，只要你能看得見，按照它的提示修改，就可以減少很多的錯誤。如果你還希望有更強的提示，那么你可以按照 p3c 插件，幫你檢查代碼錯誤。

③代碼格式

可能這并不是一個致命的問題，但代碼格式化最大的好處是，提升可讀性、規(guī)整性、以及可以讓整組人都在一個標準下執(zhí)行。

因為很多時候一個組的程序員，會在一個類下開發(fā)，有人格式化、有人不格式化除了不好看以外，合并代碼有時候也會遇到麻煩。

不格式化的代碼缺少靈魂：

 

代碼格式化

對于嚴格要自己的程序員來說，代碼沒有格式化還是很難受的。看一段代碼，只要發(fā)現差一個空格位置，都知道這是格式化還是沒格式化。

④單元測試

單測?覆蓋率?寫代碼不是寫完就可以了嗎?

當然不是，你寫的代碼你需要保證它能你跑通你所有的流程節(jié)點，確保這份功能是沒有問題的，才能提交給測試，否則來回反復，耗時耗力。

這也就是寫單測的目的!甚至好一點的研發(fā)可以通過單測驅動開發(fā)，在這個階段能把一些共用的方法合并、抽離，避免過多的冗余方法。

 

單測長什么樣，如上圖：

• 單測完整基本也就是代碼的健壯性更好，能把單測寫好，基本提交的代碼就不會有那么多測試妹子找你聊天。
• 在很多公司中一般都會要求單測覆蓋率超過多少，否則是不允許編譯提交的，這有插件可以和 Jenkins 配合使用。

⑤分支規(guī)范

可能有些人看到分支規(guī)范根本沒有感覺，因為他們開發(fā)的項目較小，沒有多人開發(fā)，上線周期也短，也不會開發(fā)中添加需求。

但在互聯網中并不是這樣，往往一個系統(tǒng)需要幾個人維護，并同時進行開發(fā)。一般這里會包括 master 分支、test 分支、本次需求的分支。

有這么多分支怎么用呢，如下：

• master 分支，是主分支，也是上線分支，不允許在上面直接修改代碼。
• test 分支，是測試環(huán)境分支，每個人都需要把自己開發(fā)完的分支，提測后合并到 test 分支，交由測試驗證。
• 需求分支，也是個人開發(fā)的分支，同一個需求下，大家在這個分支寫代碼，當然也可能這個系統(tǒng)模塊的分支就一個人在開發(fā)。

重點，如果有人不遵守分支規(guī)范或者壓根沒概念，把自己的需求代碼寫在 test 分支上，并且是多次修改提交都在 test 分支寫。那么就危險了，嚴重會耽誤上線。

為什么?

• test 分支，是由大家把自己的代碼合并過來共用的，那么這個分支就會包含 2 個或者更多的并行需求，當你需要上線的時候，需要把自己的代碼合并到 master，但 test 分支代碼是不能合并到 master 的，那么多未知的內容，根本沒有在上線范圍。
• 那么你又想上線，又不能避開 test 分支，就需要把你寫的代碼，重新粘貼過去，這個時間成本非常大。
• test 分支，還隨時有刪除重新拉的可能，如果有人通知大家刪除重新拉，那你的代碼就會丟失。

⑥夾帶需求

提交測試，但還藏一個需求。

研發(fā)開發(fā)需求代碼時候，有時候會額外加一些其他代碼，而且這些代碼可能跟本次需求并沒有關系。

那為什么會這樣呢?

• 以前留下來的 Bug，想修復下，但忘記告知測試。
• 在開發(fā)這個需求時，其他產品又找過來讓加功能，并說功能很小，沒有發(fā)郵件通知相關測試人員。
• 看到某塊以前寫的代碼太亂了，就想著優(yōu)化下，自信心很高，不必告訴測試。

那這時候你提交的代碼，如果不在測試范圍又出了問題，只能研發(fā)自己抗。并且在所有的研發(fā)團隊，幾乎是不會讓夾帶需求上線的，這樣的做完了不算功勞，做出了問題還會被罵。

所以，千萬不要私自夾帶!哪怕你是好心!

⑦異常流程

擦屁屁的紙，80% 的面積都是保護手的!

這句話是我經常用的，因為我們編程很多時候都是在處理異常流程，正常流程往往并不難，難的是分析出這段開發(fā)的代碼有多少異常流程有沒有處理。

那么，會有哪些異常呢?

• 支付成功 MQ 消息發(fā)送失敗，需要 worker 補償。
• PRC 接口調用失敗，網絡超時，實際成功。
• 接口冪等性，多次調用結果一致性。

等等，這些都是異常流程，尤其在一些交易提現環(huán)節(jié)，會出現各種異常，那么不可能把這些異常都反饋用戶展示到界面。

而是要有一些非常友好的提示，并且在服務端的流程里，有一定的補償機制，來保證最終的調用成功，或者逆反。

⑧代碼成坨

代碼成坨

 

CRUD 往往可能是因為你的設計，換個人寫也許不同。

很多時候研發(fā)寫代碼，根本不考慮是否要擴展，總之一個類+幾十行 if else，能搞定所有需求。等下次在開發(fā)類似的，就粘貼過去再修修補補，能用就行。

缺少寫出良好代碼的研發(fā)，一方面是經歷有限，另外一方面是學了很多理論但是不好落地。比如設計模式，但自己實際寫代碼的時候還是很暈。

⑨SQL 性能

select * from table where status = 1 limit 200; 

這是一段定時任務掃描庫表的 SQL，這段 SQL 會定時掃庫，將庫表中狀態(tài)是 1 的掃描出來進行處理，每次掃描 200 行。

你發(fā)現有什么問題了嗎?

• 掃描必要字段即可，不需要全部字段。
• 這段 SQL 會越來越慢，即使狀態(tài)字段加了索引。因為 status 并不能大量排掉其他狀態(tài)字段，隨著數據越來越多依然是全表掃描。

那么怎么優(yōu)化呢，其實優(yōu)化也比較簡單，需要先根據狀態(tài)查詢到符合條件的最小的 id，之后再 SQL 的查詢條件中添加 id>xx，即可。

另外如果你的任務需要多個 worker 掃描，增加效率，可以增加門牌號設計，提升掃描效率，如下：

 

門牌號掃描

⑩結伴編程

評審代碼最后這點想說說，陪伴式開發(fā)，可能這不是結伴編程，不是共同合作，而是一個研發(fā)需要另外一個研發(fā)不斷的提供幫助。有時候可能就是很簡單的問題，也不想查，或者說沒有意識去查，只是問。

業(yè)務開發(fā)的過程，只要把流程定下來，研發(fā)設計評審完，其他的開發(fā)過程中遇到的小點并不難，只要查一查就可以搞定。

當日也不是說完全不能問，只不過特別普遍，簡單的代碼問題，自己搞定就可以了，但這個時候還像保姆似的陪伴，就會拖累整個團隊的進展，最終大家都需要扛起那個慢的。

所以，如果你是那個需要陪伴的，要及早斷奶，學會自己攻克，快速成長。而如果你是那個卷紙，可哪擦屁股的，要把卷紙傳遞給他。一個人擦一次是能力體現，反反復復擦一個人，就惹屎上身了。

總結

總結如下：

• 以上介紹了代碼評審中涉及到的比較常見的點，基本也是很多研發(fā)容易忽略和犯錯誤的地方。這些問題點拿出哪一個看，都不大，但運行在代碼中，確都有可能發(fā)生致命或者麻煩的事情。
• 想讓自己能把代碼寫好，就不只面試時候造飛機的回答，什么時間復雜度、什么可重入鎖、什么紅黑樹，什么 DDD，只要你不能正確的落地和運用這些技術，說的再多都是空談。
• 多學一些、多看一些、多問一些，沒有壞處，但要自己能成長，把吸取到的經驗心得，運用到業(yè)務開發(fā)中，寫出可擴展、可維護的代碼，才能讓自己真的升職加薪。也能讓既有留下的本事，也有出去的能力。

作者：小傅哥

簡介：多年從事一線互聯網 Java 開發(fā)，從 19 年開始編寫工作和學習歷程的技術匯總，旨在為大家提供一個較清晰詳細的核心技能學習文檔。

編輯：陶家龍

出處：轉載自公眾號 bugstack 蟲洞棧(ID：bugstack)