當你換槽填坑時，面對一個新的環境。能夠快速熟練，上手實現業務需求是關鍵。
但是，哪些因素會影響你快速上手呢？是原有程式碼寫的不夠好？還是註釋寫的不夠好？
昨夜，閒情雅緻，瞅了瞅隔壁小王的程式碼，看完之後真是太上火，氣不打一處來。
於是，把小王犯的錯誤拉了個清單，一起幫他改進一下，順便看看這些壞習慣，你是否也有呢？
過度相信別人，會給自己挖坑。
針對介面輸入參數，沒有進行嚴格校驗，尤其是要插入數據庫庫的參數，一路透傳到底（數據庫層面），數據庫就報數據插入異常。
對於呼叫者而言，會一直等待介面響應，而最後拿到數據庫錯誤，會一臉懵 B；對於介面本身而言，會佔用數據庫連線，損耗資源，如果併發量大的情況，影響可想而知。
建議：業務程式碼研發過程中，不要相信呼叫者會按照要求傳參數，要做到防禦性程式設計。
異常捉都捉啦，就差一哆嗦。
2.1. 抓住了異常，卻什麼都沒做！
2.2. 列印異常棧的方式，卻顯得毫無意義。
估計很多人，都會這麼寫，但是在生產上，卻顯得意義不大，所以最好用記錄日誌的形式輸出異常資訊。
建議：業務程式碼研發過程中，針對介面中發生的異常，既然進行了 catch，那就一定要好好封裝處理，若不做任何處理，私自把異常給吞沒了，一旦線上出了問題，卻不知道問題出在了哪裏。
小兒科的問題，會大意失荊州。
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.1. 避免江邊賣水。
4.1.1. 業務介面驗签程式碼片段。
紅色圈住部分，感覺有點江邊賣水，多此一舉。那麼，可以去掉 false 判斷，建議修改如下：
同樣的，程式碼研發中，true 的判斷也一樣可以去掉。
4.1.2. 使用者登錄程式碼片段。
最後的 else 有點多此一舉，可以省略，可以修改爲：
4.1.3. 使用者是否系結銀行卡片段。
在 return 前的判斷，貌似略顯多餘，可以修改爲：
4.2. 減少 Bug，減少圈的複雜度。
(圖片來源於網路)
會發現巢狀層數越多，程式碼越複雜，其圈複雜度也就可能越高。不過，控制巢狀層數，便是降低 Bug 發生概率的一個有效手段。
例如，下面 下麪的程式碼片段，專案中可謂是一抓一大把。
根據場景，可以適當調整如下：
4.3. 統一作戰，程式碼未動，規範先行。
爲了讓寫出的程式碼能夠清晰閱讀，前提是團隊要進行統一，不能爲了個人嗜好，而獨創研發祕笈。
敢問，有哪些需要進行統一呢？
統一的開發環境（JDK版本、整合開發工具 IDE、存放目錄…）；
統一的開發框架，更多精力集中到業務開發上；
統一的開發模板，開發工具要進行統一 Scheme；
統一的開發規約，命名、註釋、程式碼結構等約束；
統一的 DB 規約，具備一個良好的標準。
統一的 … …
程式碼評審的過程，會讓人哭笑不得！
鐵打的營盤流水的碼農，你的程式碼遲早會被其他同事接手，爲了讓接手你程式碼的同事，心裏不默默罵你，建議還是好好對待編碼這件事，認真寫好每行程式碼。
寫程式碼是一件快樂的事情，評審程式碼更是一件有趣的事情，通過評審程式碼，能夠相互學習，並使程式碼更加健壯，提早發現 Bug，所以每一次都不要錯過。
最後，本次分享就到這裏，希望你們能夠喜歡。