當你換槽填坑時，面對一個新的環境。能夠快速熟練，上手實現業務需求是關鍵。
但是，哪些因素會影響你快速上手呢？是原有代碼寫的不夠好？還是註釋寫的不夠好？
昨夜，閒情雅緻，瞅了瞅隔壁小王的代碼，看完之後真是太上火，氣不打一處來。
於是，把小王犯的錯誤拉了個清單，一起幫他改進一下，順便看看這些壞習慣，你是否也有呢？
1.
過度相信別人，會給自己挖坑。
針對接口輸入參數，沒有進行嚴格校驗，尤其是要插入數據庫庫的參數，一路透傳到底（數據庫層面），數據庫就報數據插入異常。
對於調用者而言，會一直等待接口響應，而最後拿到數據庫錯誤，會一臉懵 B；對於接口本身而言，會佔用數據庫連接，損耗資源，如果併發量大的情況，影響可想而知。
建議：業務代碼研發過程中，不要相信調用者會按照要求傳參數，要做到防禦性編程。
2.
異常捉都捉啦，就差一哆嗦。
2.1. 抓住了異常，卻什麼都沒做！
2.2. 打印異常棧的方式，卻顯得毫無意義。
估計很多人，都會這麼寫，但是在生產上，卻顯得意義不大，所以最好用記錄日誌的形式輸出異常信息。
建議：業務代碼研發過程中，針對接口中發生的異常，既然進行了 catch，那就一定要好好封裝處理，若不做任何處理，私自把異常給吞沒了，一旦線上出了問題，卻不知道問題出在了哪裡。
3.
小兒科的問題，會大意失荊州。
3.1. 代碼這麼寫，還談什麼用戶體驗？
例如，用戶綁定銀行卡場景，判斷銀行卡是否已經綁定，未綁定則進行綁定。
循環遍歷用戶綁定的銀行卡列表，然後比較傳入的卡號（cardNo）是否已經綁定過，當傳入的卡號與綁定的卡號一致時，修改 hasCard 為 true，並沒有跳出循環，繼續下一次比較判斷。
那麼，如果類似這種代碼，發生在數據量比較大的場景下，勢必會降低性能，過度浪費資源，用戶肯定會罵街。
建議修改方式（仁者見仁智者見智）：
3.2. 數據挨個去處理，怎麼還出現了漏網之魚？
例如，三方數據對賬時，判斷三方傳過來的數據在本地狀態是否正常匹配，把沒匹配的數據進行註銷處理。
代碼這麼寫，一旦條件匹配，進行刪除某條記錄後，list 的大小發生了變化，而 i 的值也在變化，就會導致在遍歷的時候，漏掉某些記錄。
比如，當刪除第 1 個元素後，繼續根據索引訪問第 2 個元素時，因為刪除的關係，後面的元素都往前移動了一位，所以實際訪問的是第 3 個元素。
建議採用 Iterator 刪除，或者集合倒序遍歷刪除。
3.3. & 與 && 的使用不當，終釀錯。
例如，在 Web 項目中，判斷輸入的郵箱是否為空。
當 email 輸入為 null 時，& 使用時，後面的條件會發生空指針異常。
建議修改為:
同樣，| 與 || 也有類似的情況，所以在使用時，也要注意此類場景的問題。
3.4. equals 比較，搞不好會出么蛾子。
當 resMap.get(Global.RETCODE) 為 null 時，會發生空指針異常。
鑑於 Object 的 equals 方法容易拋空指針異常，所以業務研發中，應使用常量或確定有值的對象來調用 equals。
建議修改為：
3.5. 數學運算，搞不好會傾家蕩產。
輸出結果：0.010000000000005116，一般遇到需要用到浮點數運算的地方，都可以使用 java.math.BigDecimal。
建議修改為：
注意構造 BigDecimal 的參數為 String，千萬別搞錯了，這也是新手易犯的問題。
3.6. 奇葩的註釋，看到就想罵街。
3.6.1. 項目中的某類的註釋。
代碼的作者是管理員，敢問，管理員 TM 又是誰？而且源文件有過修改，但是修改描述的是啥？著實讓人費解！
3.6.2. 項目中的某方法的註釋。
方法參數沒有解釋；方法返回值沒有解釋；作者又是屬於管理員；修改描述描述的是個啥？
4.
讓代碼會說話。
4.1. 避免江邊賣水。
4.1.1. 業務接口驗籤代碼片段。
紅色圈住部分，感覺有點江邊賣水，多此一舉。那麼，可以去掉 false 判斷，建議修改如下：
同樣的，代碼研發中，true 的判斷也一樣可以去掉。
4.1.2. 用戶登錄代碼片段。
最後的 else 有點多此一舉，可以省略，可以修改為：
4.1.3. 用戶是否綁定銀行卡片段。
在 return 前的判斷，貌似略顯多餘，可以修改為：
4.2. 減少 Bug，減少圈的複雜度。
會發現嵌套層數越多，代碼越複雜，其圈複雜度也就可能越高。不過，控制嵌套層數，便是降低 Bug 發生概率的一個有效手段。
例如，下面的代碼片段，項目中可謂是一抓一大把。
根據場景，可以適當調整如下：
4.3. 統一作戰，代碼未動，規範先行。
為了讓寫出的代碼能夠清晰閱讀，前提是團隊要進行統一，不能為了個人嗜好，而獨創研發秘笈。
敢問，有哪些需要進行統一呢？
統一的開發環境（JDK版本、集成開發工具 IDE、存放目錄...）；
統一的開發框架，更多精力集中到業務開發上；
統一的開發模板，開發工具要進行統一 Scheme；
統一的開發規約，命名、註釋、代碼結構等約束；
統一的 DB 規約，具備一個良好的標準。
統一的 ... ...
5.
代碼評審的過程，會讓人哭笑不得！
鐵打的營盤流水的碼農，你的代碼遲早會被其他同事接手，為了讓接手你代碼的同事，心裡不默默罵你，建議還是好好對待編碼這件事，認真寫好每行代碼。
寫代碼是一件快樂的事情，評審代碼更是一件有趣的事情，通過評審代碼，能夠相互學習，並使代碼更加健壯，提早發現 Bug，所以每一次都不要錯過。
最後，本次分享就到這裡，希望你們能夠喜歡，歡迎多關注「一猿小講」。
閱讀更多 一猿小講 的文章
