嗨，我是東哥。
今天剛好看到一個貼文，一位程式設計師對一位擁有8年資歷的程式設計師大佬進行程式碼review時表示被嚇到了
話不多說，先上程式碼截圖：
這段程式碼的需求是查詢本月的客戶返利資訊。
簡單來說，就是看看哪些客戶在本月得到了返利，並且將這些數據提取出來。大佬寫的這段程式碼實作了需求，但寫法真是別具一格，獨樹一幟。
# 程式碼解析
首先，這段程式碼使用了幾個動態SQL片段，主要包括：
判斷 partyName 是否為空，並根據條件進行相應查詢。
使用 YEAR(NOW()) 和 MONTH(NOW()) 函式來過濾返利確認日期。
使用了一些基本的條件判斷和連線操作。
加我領取Java架構師資料合集
# 深入分析
乍一看，這程式碼實作了需求，但問題卻藏在細節裏。
咱們程式設計師在編寫SQL查詢時，往往會考慮查詢效能，特別是如何利用索引來提高效率。然而，這位大佬在列上使用了函式（YEAR() 和 MONTH()），導致了無法利用索引的問題。
技術評論：在列上使用函式會阻止最佳化器利用索引，因為索引是基於列的原始值建立的，而函式改變了這些值的表示方式。這就導致無法直接匹配索引中的條目，需要執行全表掃描來尋找匹配的行，從而大大增加了查詢所需的時間和資源。
# 程式碼最佳化建議
為了解決這個問題，可以將日期過濾條件改為範圍查詢，這樣就能充分利用索引。例如：
AND crr.rebate_confirm_date >= DATE_FORMAT(NOW() ,'%Y-%m-01')AND crr.rebate_confirm_date < DATE_ADD(DATE_FORMAT(NOW() ,'%Y-%m-01'), INTERVAL 1 MONTH)
這種寫法可以確保查詢條件能用到索引，大大提高查詢效率。
這樣一來，既能滿足需求，又能保證程式碼的執行效能。
很多人看到這裏可能會說，這樣寫程式碼會阻止最佳化器利用索引，那是不是就不能這麽寫了？
其實不然。這位大佬的思路其實是很有意思的。
他采用這種寫法，可能是在權衡了實作難度和效能之後的選擇。簡單直接的寫法在開發初期可以快速實作需求，並且在數據量不大時，效能影響並不會很明顯。
但是，作為程式設計師，特別是有多年經驗的大佬，在實作功能的同時，也需要考慮到程式碼的可維護性和效能最佳化。
這段程式碼的寫法，雖然達到了需求，但在後期的效能最佳化上會帶來不小的挑戰。
# 養寇自重？
有人調侃說，這是在「養寇自重」，為後期最佳化做埋點。
其實，這是一種比較片面的看法。好的程式碼不僅要實作需求，還要考慮到未來的擴充套件和最佳化。
程式設計師不僅僅是「寫程式碼的人」，更是「設計系統的人」。在程式碼的每一行中，如何做到既滿足當前需求，又為未來的最佳化留出余地，是我們需要不斷思考的問題。
網友評論
在網上，關於這段程式碼的討論也是熱火朝天。
有網友說：「你剛畢業的吧？這麽較真，都遲早是要失業的人，別把自己太當回事。」
確實，作為新手，可能會對每一行程式碼都精雕細琢，追求極致的效能最佳化。但隨著經驗的積累，我們也需要學會在復雜度和效能之間找到平衡。
東哥覺得，這段程式碼的寫法雖然有些問題，但也反映了程式設計師在不同階段的思維差異。
我們需要尊重每一位程式設計師的選擇，同時也要不斷學習和改進，畢竟程式碼是一個不斷叠代最佳化的過程。
希望大家能在評論區分享你們的看法和經驗，讓我們共同進步。
發送關鍵字「 java 」，領取Java架構師資料合集
熱門推薦
