華為 Java 編程軍規 ！

1、引言

這個標準是衡量代碼本身的缺陷，也是衡量一個研發人員本身的價值，華為作為一家全球化的 IT 公司，十幾萬員工，無論是人事管理，還是代碼管理，都是一件不容易的事情，沒有規范的約束，想想都是件可怕的事情，下面挑選了一些網上流傳的編程規范，一起來學習下，以下內容不涉及基礎的語法規范（請見 Refer），更側重于一些編程習慣，如何提高程式的健壯性、可維護性等，（PS：以下內容未經官方考證，如閱讀者出現不適，請選擇立即關閉本頁 -_-||| ）

2、軍規簡介

• 軍規一：【避免在程式中使用魔鬼數字，必須用有意義的常量來標識，】

• 軍規二：【明確方法的功能，一個方法僅完成一個功能，】

• 軍規三：【方法引數不能超過5個】

• 軍規四：【方法呼叫盡量不要回傳null，取而代之以拋出例外，或是回傳特例物件（SPECIAL CASE object，SPECIAL CASE PATTERN）；對于以集合或陣列型別作為回傳值的方法，取而代之以空集合或0長度陣列，】

• 軍規五：【在進行資料庫操作或IO操作時，必須確保資源在使用完畢后得到釋放，并且必須確保釋放操作在finally中進行，】

• 軍規六：【例外捕獲不要直接catch (Exception ex) ，應該把例外細分處理，】

• 軍規七：【對于if ? else if ?(后續可能有多個else if …)這種型別的條件判斷，最后必須包含一個else分支，避免出現分支遺漏造成錯誤；每個switch-case陳述句都必須保證有default，避免出現分支遺漏，造成錯誤，】

• 軍規八：【覆寫物件的equals()方法時必須同時覆寫hashCode()方法，】

• 軍規九：【禁止回圈中創建新執行緒，盡量使用執行緒池，】

• 軍規十：【在進行精確計算時(例如:貨幣計算)避免使用float和double，浮點數計算都是不精確的，必須使用BigDecimal或將浮點數運算轉換為整型運算，】

3、軍規說明

• 軍規一：【避免在程式中使用魔鬼數字，必須用有意義的常量來標識，】 說明：是否是魔鬼數字要基于容易閱讀和便于全域替換的原則，0、1作為某種專業領域物理量列舉數值時必須定義常量，嚴禁出現類似NUMBER_ZERO的“魔鬼常量”，

• 軍規二：【明確方法的功能，一個方法僅完成一個功能，】 說明：方法功能太多，會增加方法的復雜度和依賴關系，不利于程式閱讀和將來的持續維護，無論是方法還是類設計都應符合單一職責原則，

• 軍規三：【方法引數不能超過5個】 說明：引數太多影響代碼閱讀和使用，為減少引數，首先要考慮這些引數的合理性，保持方法功能單一、優化方法設計，如果引數確實無法減少，可以將多個引數封裝成一個類（物件），同時考慮在新的類（物件）中增加相應的行為，以期更符合OOP，

• 軍規四：【方法呼叫盡量不要回傳null，取而代之以拋出例外，或是回傳特例物件（SPECIAL CASE object，SPECIAL CASE PATTERN）；對于以集合或陣列型別作為回傳值的方法，取而代之以空集合或0長度陣列，】 說明：回傳null會增加不必要的空指標判斷，遺漏判斷也會導致嚴重的NullPointerException錯誤，

• 軍規五：【在進行資料庫操作或IO操作時，必須確保資源在使用完畢后得到釋放，并且必須確保釋放操作在finally中進行，】 說明：資料庫操作、IO操作等需要關閉物件必須在try -catch-finally 的finally中close()，如果有多個IO物件需要關閉，需要分別對每個物件的close()方法進行try-catch,防止一個IO物件關閉失敗其他IO物件都未關閉，

• 軍規六：【例外捕獲不要直接 catch(Exception ex) ，應該把例外細分處理，】 說明：catch (Exception ex)的結果會把RuntimeException例外捕獲，RuntimeException是運行期例外，是程式本身考慮不周而拋出的例外，是程式的BUG，如無效引數、陣列越界、被零除等，程式必須確保不能拋出RuntimeException例外，不允許顯示捕獲RuntimeException例外就是為了方便測驗中容易發現程式問題，

• 軍規七：【對于if ? else if ?(后續可能有多個elseif …)這種型別的條件判斷，最后必須包含一個else分支，避免出現分支遺漏造成錯誤；每個switch-case陳述句都必須保證有default，避免出現分支遺漏，造成錯誤，】

• 軍規八：【覆寫物件的equals()方法時必須同時覆寫hashCode()方法，】 說明：equals和hashCode方法是物件在hash容器內高效作業的基礎，正確的覆寫這兩個方法才能保證在hash容器內查找物件的正確性，同時一個好的hashCode方法能大幅提升hash容器效率，

• 軍規九：【禁止回圈中創建新執行緒，盡量使用執行緒池，】

• 軍規十：【在進行精確計算時(例如:貨幣計算)避免使用float和double，浮點數計算都是不精確的，必須使用BigDecimal或將浮點數運算轉換為整型運算，】 說明：浮點運算在一個范圍很廣的值域上提供了很好的近似，但是它不能產生精確的結果，二進制浮點對于精度計算是非常不適合的，因為它不可能將0.1——或者10的其它任何次負冪精確表示為一個長度有限的二進制小數，

4、有關開發效率和協作的幾點建議與心得體會

今天看到某同學寫給團隊成員的一封郵件，發現比較通用，分享出來吧:

1、小提交:

把大的任務拆分成多個獨立小任務，每完成小任務確保無 Bug 后就可以提交合并到主分支甚至發布；頻繁提交有利于自己把控專案進度、降低風險、同其他人協作和代碼 Review ; 每天可以提交合并多次，每個小任務是 1-2 個小時可以完成的粒度，最大的一天完成，并行做多個任務的時候，優先做最短時間能夠實作的任務，

2、命名規范:

盡量避免無意義的字符做變數 比如 a, b, t ，可以逐步改善，可以參考:http://google-styleguide.googlecode.com/svn/trunk/javaguide.html

3、避免過度設計: 能夠用簡單方式實作的功能，不引入復雜的類，物件，避免不必要的 new 物件，避免引入不必要的泛型、執行緒，開發初期冗余大于抽象和依賴，避免自己重新實作比較通用的組件和函式，調研多種實作方式的時候，選用做簡單的實作方式，盡量少寫代碼，

4、Web 工程盡量避免在應用內部保存“狀態”，這樣可以適應頻繁發布、重啟無影響，

5、善于用打日志的方式除錯，在程式關鍵點打日志，盡量少用斷點方式，日志方式可以批量除錯一批功能，效率相對高，

6、避免一屏顯示不下的超大函式，

7、添加必要、簡潔的注釋：

回圈中的 continue, break 盡量加上單行注釋；盡量避免非函式結尾的 return，必要的時候加注釋，類自動生成 toString() 方法，方便除錯和打日志，

8、不把自己局限到做某個功能，每個人都是整個專案的 Owner ，盡量交叉 Review ，交叉開發，

9、遇到問題及時和其他人溝通，避免浪費時間，

10、從最終產品的目標審視自己細小的設計，熟悉自己負責部分的上下游代碼，時刻關注最終產品(Web 界面和日志)，發現 Bug 和可以改善的地方，

標籤：Java

上一篇：Java 讀取Word文本框中的文本/圖片/表格

下一篇：docker apollo配置中心分布式部署