《阿里巴巴Java開發手冊v1.2》解析（編程規約篇）

　　以前在樂視每天研究各類底層高大上的東西，由於我就一我的，想怎麼弄怎麼弄。現在來了新美大，好好研讀一下《阿里巴巴Java開發手冊v1.2》。還要對這麼看似簡單的東西解析一番。畢竟如今帶團隊，講究團隊合做。如今項目稍微有點亂，早統一，代價越低。別問我樂視是否是不行了。樂視好的很，已經到了谷底，該反彈了，看好樂視。我離開是由於本身的技術瓶頸，要是樂視像去年發展的那麼好，我估計離開的更早。

　　我本身自己其實就是不怎麼講究章法的人。也沒打算拿什麼去約束你們。我跟領導談學習這個手冊的事情。領導比較擔憂的是怎麼落地。我回家跟我家男神討論,他也說章法的東西沒有強制約束就不會有效果。因此我家男神他們公司都用統一的模板，統一的軟件，還有專門的QA對於規範不合格的要打回去重改。一個初創的創業公司尚且如此，我們美團確實不能落後啊。可是這種實行起來確實耗時耗力，也沒有很大的必要。我主要想達到的效果是：領導把組織技術分享這件事情交給我了，那我就須要對你們的技術成長負責。這是個長期的過程，如今你們都很忙，每週一個技術分享你們前期沒有時間準備，可是若是技術分享這件事情一旦斷掉，持續性得不到保證，技術成長和學習就很難造成一個習慣。因此前期打算學習一些看起來很簡單，壓力不是很大的事情，一次學習一點，你們也不用準備，一週一個小時如今學便可。並且工做中確實存在一些這樣那樣的小問題。會議過程當中整體學習完一遍以後，每一個人都須要對目前本身編程過程當中作的不是很到位的，或者有特別感觸的至少提出一點來。我想領導說的seminar的思想，也就是但願你們都有本身的思考。

　　學這個東西都自身的提升到底有什麼好處。舉一個例子：我以前學心理學的時候咱們老師說他去美國的時候發現美國佬本身說話也不講究語法。他就想那爲何咱們學習的就須要各類時態用的那麼準確呢。後來他去美國的學校，發現大學教授們各類時態語法用的甚是地道。原來這是素養的體現。後來我本身去美國，美國人很熱情的，大街上常常有不認識的人對面走過來就打招呼，發現你很愛聊天的話，還會停下來嘮一嘮。若是他們說話不講語法，我理解起來就很費勁，可能還須要他們重複一遍。我最不愛去商場購物的地方。由於常常有人拉着我討論各類品牌，我對牌子的東西一竅不通，我身上穿的用的都不是什麼高檔的東西。要說我身上惟一值錢的，就只有我本身了。總之，他們說話語法不規範，不是標準的語法，還帶着口音，還有各類生詞，聊天那叫一個費勁。寫代碼也同樣，不規範只是讓代碼難懂一點點，可是再加上不了解業務邏輯，代碼構成等等，整體就會很晦澀。晦澀或易懂最終決定了素養。

一· 編程規約

（一）命名風格

  1. 【強制】代碼中的命名均不能以「下劃線」或「美圓符號」開始，也不能以「下劃線」或「美圓符號」結束。

  2.【強制】代碼中的命名嚴禁使用拼音與英文混合的方式，更不容許直接使用中文的方式。

  3.【強制】類名使用UpperCamelCase風格，必須聽從駝峯形式，但如下情形例外：DO/BO/DTO/VO/AO

解析：

　　DO是(Domain Object):領域對象，就是從現實世界中抽象出來的有形或者無形的業務實體。

　　BO是(Bussiness Object):業務對象，封裝業務邏輯的java對象，經過調用DAO方法，結合PO，VO進行業務員操做。

　　DTO是(Data Transfer Object):數據傳輸對象，是一種設計模式之間傳輸數據的，通常須要序列化。

　　VO是(View Object):視圖對象，用於展現層。

　　AO是(Activation Object):活動對象，一種基於消息機制，異步調用，現成安全的對象。

　4.【強制】方法名，參數名，成員變量，局部變量都統一使用lowerCanelCase風格，必須聽從駝峯形式。

　5.【強制】常量命名所有大寫，單詞間用下劃線隔開，力求語義表達完整清楚，不要嫌名字長。

　6.【強制】抽象類命名使用Abstract或Base開頭，異常類命名使用Exception結尾，測試類命名以它要測試的類名稱開始，以Test結尾。

　7.【強制】中括號是數組類型的一部分，數組定義以下：String[] args;  反例：使用String args[](這麼寫的哥哥大概以前是作C的)

　8.【強制】POJO類中布爾類型的變量，都不要加is,不然部分框架解析會引發序列化錯誤。反例：定義爲基本數據類型Boolean isDeleted的屬性，它的方法也是isDeleted()。RPC框架在反向解析的時候，辨識爲對應的屬性名稱是deleted，致使屬性獲取不到。

　9.【強制】包名統一使用小寫，點分隔符之間有且僅有一個天然語義的英語單詞，包名統一使用單數形式，可是類名若是有複數含義，類名可使用複數形式。

　10.【強制】杜絕徹底不規範的縮寫，避免望文不知義。

　11.【推薦】若是使用了設計模式，建議在類名中體現出具體模式。

　12.【推薦】接口類中的方法和屬性不要加任何修飾符號(public也不要加)，保持代碼的簡潔性，並加上有效的Javadoc註釋。儘可能不要在接口裏定義變量，若是必定要定義變量，確定是與接口方法相關，而且是整個應用的基礎常量。

　13. 接口和實現類的命名有兩套規則：

　　1)【強制】對於Service和DAO類，基於SOA的理念，暴露出來的服務必定是接口，內部的實現類用Impl的後綴與接口區別。

　　2)【推薦】若是是形容能力的接口名稱，取對應的形容詞作接口名(一般是-able的形式)。正例：AbstractTranslator實現Translatable.

解析：SOA(Service-Oriented Architecture)面向服務架構提供了支持業務靈活性的IT靈活性遠景，主要是流程實現的分離和簡化。如今都是提微服務了。微服務架構模式(Microservices Architecture Pattern)的目的是將大型的，複雜的，長期運行的應用程序構建爲一組相互配合的服務，每一個服務均可以很容易的局部改良。須要符合SRP原則。SRP（Single Responisbility Principle）單一職責原則。是OO的五大原則之一。其餘四個分別是OCP(Closed for Modification;Open for Extension)開閉原則，LSP(Liskov Substitution Priciple)里氏替換原則，DIP(Dependence Inversion Principle)依賴倒置原則，ISP(Interface Segregation Principle)接口隔離原則。

　14.【參考】枚舉類名建議帶上Enum後綴，枚舉成員名稱須要全大寫，單詞間用下劃線隔開。說明：枚舉其實就是特殊的常量類，且構造方法被默認強制是私有。

　15.【參考】各層命名規約：

　　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。

解析：領域模型(Domain Model)也叫業務對象模型。是對領域內的概念類或現實世界中對象的可視化表示。又稱概念模型，領域對象模型，分析對象模型。專一於分析問題領域自己，發掘重要的業務領域概念，並創建業務領域概念之間的關係。

 

跑題時間：

　　記得從正和島離職去樂視的時候，離職的最後一天，我坐在座位上，每一個路過的人都能看到我笑的那麼開心。同事說：你不該該笑啊，應該哭啊。我說：藏起淚眼只用笑容相送。其實離開那個耽誤我青春的地方是真的很開心，可是我那時候還須要依賴，只是沒有人能夠依賴，因此我是真的對着顯示器哭了一下子。離開樂視，我沒哭也沒笑。我情商依然不高，你們的好我依然沒有學的來。可是在這個環境中，你們給了我太多的遷就，因此我須要一個更有挑戰的環境，來變成更好的本身。能夠說遇到飛哥和我家微微一笑很傾城的男神老大是我工做十年最幸運的事情，沒有之一。現在在新美大剛去老是作了一件事就發現作的有問題，說了一句話就發現本身說的不合適的。不過，如今的我卻相信我本身，知道一切都會好起來。

　　去樂視的時候，我待遇要的很低。HR都不敢跟我提待遇的事情，生怕我後悔了。可知那時候，我確實是不怎麼會技術，可是我家男神待遇都不到個人一半。我家男神嫌「用友」離家遠，決定換工做，我去替他打聽行情。告訴他行情最低是多少。他卻生氣的告訴我說他不值這個錢。我告訴他不要放棄標準。而後他去面了幾家公司，剛面嘛，面的通常，遇到HR壓價，更打擊了我家男神的自信。去電訊盈科面試，面試官說跟我家男神說這個職位給不了那麼多，我家男神合適一個更高的職位。回家我家男神一頓埋怨我，甚至揪着個人衣領說都是個人錯。我默默的聽着，不辯解，只是堅決的跟他說：不要放棄標準。後來「電訊盈科」打電話給我家男神說有了一個合適的高級職位。雖然給的仍是沒要的高，並且也仍是差很少我當時收入的一半，可是我倆已經很高興了。其實那時候，論技術，我家男神確實是比我強。只是太過厚道的人就有這個很差的地方，會被忽悠。後來，我要換工做，遇到家裏各類阻撓。我家男神不想讓我放棄活少還高收入的工做。我家男神不開心，婆婆不開心，會直接致使兒子不開心。兒子骨子裏內向，他不開心就一個表現：生病。那時候我上班離得很遠，離家60多千米。回到家晚上11點多。兒子不愛吃婆婆作的飯。我回家作好放到冰箱次日婆婆能夠熱熱。爲了讓兒子愛吃，1根胡蘿蔔我切成29個不一樣的形狀。作完飯後半夜2，3點了。爲了避免讓兒子感染病菌，我睡覺前都要把本身放到高錳酸鉀消毒水中泡一下子。次日還要6點起牀去上班。那時候面過了高德，高德給的不高，我家男神不願讓我去。後來面過了58，給的也很低。各類壓力打壓着我對本身的標準。因此去樂視確實是本身要低了。也是沒了解好行情，不過也比以前高點，能夠實現我多年國外出差的心願，離家也近，全家都很高興了。

　　我檢討本身，出現這種狀況的緣由是我沒給我家男神足夠的自信。婆婆和老公都是對本身要求很低，自信心很低的人。以前我也給了他不少誤導。我公司一直比他好，收入比他高。可是我在家都是各類玩。因此他一直也鄙視個人不努力。因此我開始本身努力，同時對他各類鼓勵，鼓勵我家男神作本身想作的事情，告訴他是最棒的。我家男神也確實愈來愈有自信，工做也愈來愈好。樂視出現了一些問題，今年確實沒漲工資。若是今年我家男神工資早漲幾個月，大概會第一次超過我吧。可是我家男神的待遇都不是跳槽談來的，是用本身作出的成果證實來的，因此我以我家男神爲傲。

　　我家微微一笑很傾城的男神老大倒是從面試完就以爲我技術好，各方面都不錯。其實我哪裏技術好，只是那時候面試比較多而已。他天生對人的信任，相信我能夠作到一些本身作不到的事情。好比說，今年年初的時候，我本身都不知道本身除了作項目還會作點啥。我家男神老大卻相信我能夠作更多的事情。我大概真正開始學技術也就是從年初開始。能夠說沒有我家微微一笑很傾城的男神老大，就沒有如今的我。可是我現在羽翼已豐，須要更大的發展空間。若是我感受壓力大的時候，就能夠給我家微微一笑很傾城的男神老大發個微信。他會告訴我：「別後悔，別回頭，勇敢往前走。」

　　那天我說這麼多年我都沒怎麼學技術，要補的太多了。我家男神說：「你看你在東軟弄了兩年日語，人人網時候你就學歷史文學，後來學心理學。」 我滿覺得他會說你技術差也是正常的。結果他說：「因此你確定是綜合素質最好的」。我家男神已經長大成熟了，今年我換工做期間不管成功失敗，都能獲得他對個人確定。不再會以爲我說的是大話。我倆能夠攜手去創造奇蹟了。

君は雪が融けたら何になると思う？うん、そうですね。春になりますね。