先上乾貨，《阿里巴巴Java開發手冊》的下載地址
https://yq.aliyun.com/articles/69327
下面分幾個部分對這個手冊進行說明，都是個人的見解，本人技術一般，如果有錯誤或者不妥，請評論指出，虛心接受，提前感謝了。

建議邊看手冊，邊食用以下說明，效果比較好。

前言
首先當我第一次看見這個的手冊的時候或許和和你們是一樣激動的，因為在java行業內我還沒有看見有中文的規範，也可能是我讀書少。總之，這是我見到的第一個中文的java規範。

首先還是要感謝阿里能給出這樣一個規範，萬事還是要懷有感恩的嘛，畢竟也是別人努力的結果。

首先沒有規矩不成方圓，我覺得有了規矩，才能讓大家的程式碼可讀性和魯棒性上面有所提高。而且規矩這東西是慢慢形成的，如果之後行業內的規範越來越相同的話那麼互相交流也變的方便了不少。

然後要說明的是，規矩也是人定的，所以，不同的公司肯定有不同的程式碼規範，至少我所在的公司內部也漸漸的形成了自己的規範，我想說的是，並非我們一定要每一條都參考上面的手冊（也並非不可以），有些還是要看具體情況的，但是至少阿里的實力擺在那裡，所以有的規矩有它存在的道理。

其實我們要做的就是學習其中我們所不知道的，改掉我們那些壞習慣，保留我們的好習慣，那麼這個手冊的價值就大大的了，不是嗎？

廢話了這麼多，我知道肯定也沒有人會看的，下面趕緊上貨，我會分章節總結手冊中我認為重要和解釋有些不太明確的地方，沒有列舉的，並非不重要，而是覺得手冊已經寫的很棒，我沒啥好說的了。

程式設計規約
這次說的是第一章，因為我不想脫的太長，後面的我想慢慢整理，知識點還是很多的。所以這篇暫時只說明第一章的內容。

（一）命名規範
3、說明一下DO/BO/DTO/VO是什麼

看到這條的時候我對命名到是沒有疑問，但是很多人可能像我一樣看到這四個縮寫的時候有疑問。所以解釋一下。

首先要說的是他們都有一個統稱叫POJO。
DO Domain Object 領域物件：從現實世界抽象出來的業務實體。
BO Business Obejct 業務物件：面向業務建立的實體，包含多個PO或VO。
DTO Data Transfer Object 資料傳輸物件：展示層和服務層之間的資料傳輸建立的實體。
VO Value Object（還有叫View Object） 值物件：僅包含資料，不包含業務邏輯的物件，通常用於頁面顯示。
PO Persustan Object 持久物件：對應資料庫的物件，與資料庫欄位一一對應。
在簡單的專案中，或者當時在學習的時候，老師可能會不將實體分的很細，多數命名會直接採用末尾加POJO或者Entity或者Model等，一個類從資料庫一直用到頁面顯示，確實簡單，但是也危險。對於複雜的專案來說，對於實體來說其實分開很重要，舉個最簡單的例子，對於一個使用者實體來說，密碼不應該在查詢的時候返回給使用者，我們之前使用的可能是在資料庫中查詢的時候不查詢出來，但是實際中需要建立一個TO物件等，根本就不包含密碼這個欄位。再舉個例子，很多在資料庫中表的欄位有10多個，但是在頁面中需要顯示的只需要3個，多餘的資料會導致傳輸速度下降，所以需要新建VO物件去進行頁面顯示，只取用需要的資料。

對於各個物件的定義參考來自：http://www.open-open.com/lib/view/open1450427478266.html
8、POJO布林型別不要加is，這個是真的細節，本人遇到過boolean isSuccess的錯誤，千萬不要這樣命名，其實就是不要使用翻譯軟體直接去翻譯或者直接想著中式英語去翻譯你的變數就行了，規範一點就能避免很多錯誤。
15、DAO中，介面字尾Dao實現用Impl就不多說了，主要是這點對於方法的命名很重要。
A) Service/DAO 層方法命名規約
1） 獲取單個物件的方法用 get 做字首。
2） 獲取多個物件的方法用 list 做字首。
3） 獲取統計值的方法用 count 做字首。
4） 插入的方法用 save（推薦）或 insert 做字首。
5） 刪除的方法用 remove（推薦）或 delete 做字首。
6） 修改的方法用 update 做字首。

B) 領域模型命名規約
1） 資料物件：xxxDO，xxx 即為資料表名。
2） 資料傳輸物件：xxxDTO，xxx 為業務領域相關的名稱。
3） 展示物件：xxxVO，xxx 一般為網頁名稱。
4） POJO 是 DO/DTO/BO/VO 的統稱，禁止命名成 xxxPOJO。
首先為什麼要使用字首，因為我們的IDE都有自動識別你要的方法，當我們使用的時候很方便，方法字首的統一，可以讓多人開發的時候想要找別人寫好的介面方法很容易。sava和remove我之前在github上面看見過，不知道是不是國外這麼寫的，insert和delete太資料庫化了感覺。

這裡還要補充一點的是，每個公司最好定義一下分頁方法的規則，對於分頁來說用到的很多，而且特別的命名讓別人知道這個是分頁的方法。有時還有特別的用處。
補充第二點，如果是系統的專案，後臺管理系統和前臺的系統方法最好分開命名，比如在方法中加入back，雖然程式碼量上去了，但是為了保證以後進行修改的時候，一旦修改後臺要動到前臺這種麻煩，還有就是，前臺和後臺查詢的資料肯定是不同的，有些資料不應該顯示的就不要查詢出來。

（二）常量定義
這裡主要總結一點，把常量進行區域範圍管理，不要總是不動腦子的全部全域性變數。

（三）格式規範
5、這裡我使用的tab不喜歡空格，空格容易敲錯。其他均同意。
10、關於空行，空行的使用是這樣的，首先我們在寫程式碼的時候，我習慣先寫註釋，然後用很多的空行把業務邏輯分塊，這樣出現的程式碼會是一塊塊的，這樣容易識別，但是要注意的是，最後需要刪除多餘的空行，保留最需要的，利用註釋去分塊業務。

（四）OOP規約
6、不要使用Object的equals，使用常量呼叫equals
7、注意包裝類的數值比較用equals（是不是很疑惑為什麼要列這一條，而且這條你還從來不注意。看下一條！）
8、（這裡的RPC可以理解為通訊獲取資料）
1） 所有的 POJO 類屬性必須使用包裝資料型別。
2） RPC 方法的返回值和引數必須使用包裝資料型別。
3） 所有的區域性變數【推薦】使用基本資料型別。
說實話，我看見這條的時候嚇死了，因為我之前在實體類中使用的一直是int double，幾乎沒用過包裝類。 但是更嚇人的是阿里的反例說明正是我之前遇到的情況，而且我正是在這種情況下才使用的包裝類，其他都沒用過。真的是被嚇死了。
這裡給出我的意見，包裝類的好處是可以有null，基本型別是必須有值的。
在頁面顯示的時候，有的資料其實查詢的是null應該顯示的是空白，而不是0，那麼必須使用包裝類，其他我真的找不到的其他的必要。所以要不要尊重這一條就看你們自己了。
9、之前已經我們公司已經有人試過了，設定實體類預設值會導致一系列問題，最後崩盤，所以千萬不要中招。
12、POJO必須寫toString，我這個人比較懶，所以沒寫過。（應該不止我一個人吧~害怕）因為大多數時間我都使用斷點除錯，並不需要輸出資料進行除錯，但是當一些日誌除錯的時候還真的需要使用，所以我之後會考慮加上的。同時如果你覺得沒有必要，我也不反對。
16、不要在get和set方法中加入業務邏輯，注意這裡指的是業務邏輯，如果是對資料的處理是沒關係的，比如對於一些資料欄位的拼接。
17、一句話，儘量使用StringBuilder，不要怕麻煩，記憶體不是用來給你浪費的。
18和20一起說，時時刻刻都要注意final關鍵字的使用，這個關鍵字其實我們很多時候都會忘記掉，我就是，除了全域性變數，我還真的很少用，其實這裡列舉的很好，不需要重新賦值，不允許修改引用的指向，不允許被重寫，都要使用final，會避免很多問題，真的。變數的控制永遠從嚴，我覺得舉的例子特別形象，就在下面列一下。

1. 【推薦】類成員與方法訪問控制從嚴：

1） 如果不允許外部直接通過 new 來建立物件，那麼構造方法必須是 private。
2） 工具類不允許有 public 或 default 構造方法。
3） 類非 static 成員變數並且與子類共享，必須是 protected。
4） 類非 static 成員變數並且僅在本類使用，必須是 private。
5） 類 static 成員變數如果僅在本類使用，必須是 private。
6） 若是 static 成員變數，必須考慮是否為 final。
7） 類成員方法只供類內部呼叫，必須是 private。
8） 類成員方法只對繼承類公開，那麼限制為 protected。

說明：任何類、方法、引數、變數，嚴控訪問範圍。過寬泛的訪問範圍，不利於模組解耦。思 考：如果是一個 private 的方法，想刪除就刪除，可是一個 public 的 Service 方法，或者一 個 public 的成員變數，刪除一下，不得手心冒點汗嗎？變數像自己的小孩，儘量在自己的視 線內，變數作用域太大，如果無限制的到處跑，那麼你會擔心的。

（五）集合處理
2、這個點我遇到過，參考我之前寫的部落格，比較好理解的。
http://www.cnblogs.com/linkstar/p/5710116.html
7、foreach中不要進行remove和add
11、這張表格是重點（考試是重點，記一下咯）

（六）併發處理
對於併發，本人經驗不足，而且在下載地址的最底下的評論，你們可以看見，有人對其中一些產生了質疑，我暫時真的在實際中運用過，所以等有經驗我在告訴你們，雖然我知道很重要，但我也很無奈啊（滑稽臉）

（七）控制語句
3、多使用if+return，你們懂的。我們老師有一句經典的話，儘早退出能更好選擇對的人。
7和8一起說：很多人都在程式設計中糾結這個問題，我到底判不判斷這個引數對不對空不空啊，判的太多，效能就下去了，判的太少，那麼容易出問題。

這裡我給出我的建議，首先你大可不比去記手冊上面說的，情況，我覺得有點多，我給出我自己的方法，你們看著接住。
1、迴圈呼叫，儘可能不判，效能太低，或者判斷之前就應該解決掉。
2、dao不判，接觸資料庫，這種底層是不會出錯的，否則就是你程式碼有問題，上層再去判斷。
3、私有不判，這個引數上面剛用過，不可能是空的，要錯上面早就之前這個引數早就錯了，所以不判。
4、如果不確定，先判再刪，不判不知道會不會出錯，那麼就判，判最多就是效率低，但是不會出錯，優化效能的時候在考慮要不要把判斷的語句刪除即可。
5、我們只記住不需要判斷的情況剩下的都是要判的。

（八）註釋規範
對於註釋就總結一下：
對於註釋的要求：第一、能夠準確反應設計思想和程式碼邏輯；第二、能夠描述業務含 義，使別的程式設計師能夠迅速瞭解到程式碼背後的資訊。完全沒有註釋的大段程式碼對於閱讀者形同
天書，註釋是給自己看的，即使隔很長時間，也能清晰理解當時的思路；註釋也是給繼任者看 的，使其能夠快速接替自己的工作。 好的命名、程式碼結構是自解釋的，註釋力求精簡準確、表達到位。避免出現註釋的 一個極端：過多過濫的註釋，程式碼的邏輯一旦修改，修改註釋是相當大的負擔。

特殊標記：TODO我們經常用，FIXME還沒開發或者有錯誤，///////吃飯之前我剛寫到這（別小看這個註釋，救了很多人的），//-----業務邏輯….（利用這個分離還沒寫的業務邏輯），OTHER需要呼叫別人的介面（開發的時候並介面都是你自己寫的，有可能別人還沒寫好，註釋一下自己就不會忘記，或者自己寫多了。），當然你們可以規定你們自己的。這些是我常用的。

（九）其他
3、這個點我保留懷疑態度，我覺的有的業務下面是允許空的，所以不應該為強制。
4、使用 Random 物件的 nextInt 或者 nextLong 方法獲取整數隨機數。
以上就是我需要整理出來的點，如果有什麼地方說的不對的，謙虛求評論，我馬上改正。
你們需要的就拿走不要的就留下就行咯。

---

本文作者：LinkinStar
本文轉自：https://www.cnblogs.com/linkstar/p/6413402.html

社群技術交流：歡迎關注【阿里Java技術進階】每週在群內進行【免費技術直播】和【線上回答技術問題】歡迎點選link入群： http://tb.cn/gXRstIw
或者 釘釘掃碼入群：