1、前言

最新動態：

阿里巴巴技術團隊于2020年04月22日發布v1.6.0（泰山版）！

阿里巴巴技術團隊于2020年8月5日發布《Java開發手冊》（嵩山版）！

距離《阿里巴巴Java開發手冊(規約)》（下稱《手冊》）對外正式發布幾年的時間已經過去了，在過去的日子里，這本小小的手冊在業界產生了巨大的影響力，值此金秋佳節之際，我們不妨一道圍爐煮酒，傾聽《手冊》的主要推動者——孤盡首次講述規約背后的故事，

2、作者其人

楊冠寶：

楊冠寶：花名孤盡，取自《笑傲江湖》中風清揚的“獨孤九劍，破盡天下武功”之意，是《阿里巴巴Java開發手冊》的主要作者，在阿里巴巴集團歷任研發、架構師、技術主管等不同的角色，承擔過雙11、國際化、代碼中心等大型專案，有著豐富的一線編程經驗，目前是研發協同平臺Aone代碼中心負責人，樂于分享與總結，在阿里巴巴集團內部大型分享多達30余次，不懈地追求技術創新，勇于挑戰技術難度，在大資料、高并發、研發效能領域均有較深的造詣，

2016年3月，孤盡帶領約碼專案組撰寫《阿里巴巴Java開發手冊(規約)》，碼出高效，碼出質量，推動阿里系與業界一起進步，讓代碼變得更舒服，更清澈，更好維護，

問：為什么當扯訓想去做這樣一本手冊，初心是什么呢？

大家好，很高興今天能與大家一起交流，要回答這個問題，我想用個例子來解釋，

原始社會的爭端，更多的是講究個人的蠻力；三國時代的群雄并起，開始講究士兵的團隊默契；到了現代戰爭，海陸空、資訊兵、工程兵，無不需要緊密配合，軟體發展至今，只是靠一句hello world走天下的時代，已經過去了，我們需要團隊緊密協作，

代碼規約是一種文化軟實力，關系著互聯網公司規模化生產效率，從這點上講就是要提升研發效率，提升代碼質量，在規約出現之前，一片混沌，如表達洗掉狀態的欄位名，非常多，像：delete, delete_flag, is_delete, is_deleted，在資料分析時，總要小心翼翼，像文字游戲，而0/1還是y/n來表示已洗掉和未洗掉，更是神坑，極易造成線上問題，再如，批量介面定義時，沒有介面保護很容易造成服務提供方記憶體耗盡，產生OOM等等，

所以，我們的初心是碼出高效，碼出質量，碼是名詞，也是動詞，希望規約能夠提升整個社會的研發協作效率，提升系統質量，提升我們廣大程式員編程的幸福感，

問：手冊發布后，受到許多工程師的認可與支持，可以分享一些資料嗎？

這本手冊的影響力，確實出乎我們所有人的意料之外，據不完全統計，手冊推出一周年，影響了全球范圍內逾160萬人，插件安裝數23萬+，《手冊》紙質版一個月連續增印兩次，一直處于熱銷狀態；插件開源不到4個月，已經超過7300star，曾達到周熱度排名世界第一；手冊插件正式在云效公有云上線；英文版也在海外發布，引起業界廣泛關注，

在此期間，業界同仁為我們提供了許多寶貴的建議，在此也非常感謝大家的支持與厚愛，

問：對于一路陪伴它成長起來的你來說，你覺得最大的挑戰是什么？

挑戰的主要來源是程式員內心的天馬行空和自身價值的不可替代性，

程式員都是天生幻想創造個性化作品的藝術家，變著法子想著要如何與眾不同，最好代碼只有自己能夠看懂，只有自己能夠維護，內心深處個人至上的不可替代性，是一個深層次的潛意識抵抗，是最大的阻力來源，沒有足夠的意識為了遵守團隊的代碼風格去委屈自己，

但是個性化應盡量表現在代碼質量和演算法效率的提升上，而不是對于合作規范上糾纏不休的爭論，再者，公司是請程式員來產出實際價值的，而不是經常消耗時間為TAB還是空格的事情爭得臉紅脖子粗的，有時候，就是一個規定，就像交規靠左行，還是右行一樣，大家這么做了，協作效率自然就提升了，正所謂無規矩不成方圓，無規范難以協作，

問：今年手冊推出了物體書，怎么會有這樣的想法呢？

其實，物體書的推出并非計劃之內，在2017年杭州云棲大會，為了方便現場做規約挑戰賽，我們精心準備了800本試讀本，把網路上公開發布的電子版制訂成薄薄的冊子，結果現場受到很多童鞋的喜歡，甚至有人愿意出錢收購，

后來我們意識到，盡管有電子版，同學們還是希望能夠有實物可以在紙上記錄自己的學習心得，在地鐵、公交、火車上的碎片化時間內也可以隨手翻翻，所以我們把尺寸極大縮小，制訂成冊，并且獨家發布了《設計規約》部分，

為了把物體手冊做好，我們做了反復校對，在標點符號、示例代碼、字體顏色等都做了認真的審核，到第三次印刷時，也進行了20處的精細修改，我們希望這是一本走向卓越的小冊子，是陪伴大家的床頭書、工具書，

問：這本書推出后，你也承擔起了“布道者”的角色，帶著它和業界童鞋積極交流，可以分享一下你遇到的人或故事嗎？

是的，我們非常欣喜地看到，手冊受到了廣泛的關注和支持，大家都希望它變得更好，蘇州微軟的一個同學提及錯誤的示例代碼，是關于延遲初始化的問題，我們反復論證，發現《手冊》的命名是存在問題，所以在第三次印刷中，我們進行了修改，

另外，也有人覺得設計規約過分量化了，事實上，如果描述為“原則上”，或者說寫一個非常寬泛的區間，指導意義也很弱，干脆就寫成具體的數字，當然具體的數字，也是從無數的設計案例中抽象出來的，

前段時間有讀者問我如何理解<? extends T>和<? super T>的區別，我是這么舉例的，好多人看過優酷劇場的《白夜追兇》吧，關宏峰追查他弟弟的懸案時，去查看被封存的證物箱，被明確告知，你只能看，不能動，當然更不可以增加一件新的證物進去，那是在偽造證據，這就是前者，只能讀取，不能增加，

那<? super T>在什么樣的情況下只能增加，不能讀取呢？這個場景似乎更難立體地被想象出來，比如，投票選舉代表時，你只能往里投選票，如果自己選錯了代表，想從票箱里撈出來，重新投票，這可能嗎？更加不可能給你讀取票箱元素的機會，有人說，這只是一種生活場景，在系統設計中，很難有這樣的情形，那么，我再舉例說明一下，我們在填寫對于主管的年度評價時，填寫完畢提交后，即使填寫錯誤，當你再次訪問之前的鏈接時，也會告訴你：“您已經完成對主管的年度反饋，謝謝參與”，當然更加不可能讓你讀取到其它成員對于主管的反饋內容，

問：未來，《手冊》還會給大家帶來哪些驚喜，可否提前透露一下？

《碼出高效——阿里巴巴開發手冊詳解》即將出版，此書將詳細說明規約的初衷和意義、撰寫和推廣歷程，每個條目背后的思考與詳細的示例代碼，以及相應的故障案例分析，當前基本完成了三章的撰寫，我們希望這本書是深入淺出、言之有物，從實踐中來，走向理論，再走向指導實踐，

言之有物，物指的是有定義、推導、案例、總結，而深入淺出的深指的是能夠在業界領先的深度上，把內容講深講透，淺指的是讓一個Java初學者都能夠看得懂，

問：情懷，這似乎是一個非常虛的詞，但我卻聽到許多人，用“情懷”來評價這本書，在你眼里，情懷是什么呢？

經常有人問我，撰寫和推廣《手冊》如此費心費力，是什么樣的信念讓我如此執著？

我想說一個自己經歷的事：我很喜歡電影《岡仁波齊》，也去過岡仁波齊，轉山的那段路，汽車呼嘯而過，塵土飛揚，可是轉山的藏民，還是那樣的虔誠，叩拜之后，即使滿臉灰塵，他們的信念依然樸實而篤信，陸川的電影《可可西里》也是，很多事情是因為信念而堅守，現實中為可可西里申遺做過巨大貢獻的王欣，畢生都獻給了藏羚羊的保護，長年駐守在高原雪域，他無私地付出了很多，也放棄了很多，因為信念而堅持體現出人類的偉大，信念就是一種情懷，

情懷，如果用武俠文化來說，是行俠仗義于江湖，快意瀟灑于恩仇，大江南北，俠之大者，為國為民；俠之小者，為紅顏，為知己，而技術情懷是什么？它是一種匠心；是追求一年又一年雙11業務背后的技術突破，拓展商業邊界；是解決問題后客戶的認可，

說到底，技術情懷是一個比較虛的詞，工程師是偏向于資料驅動的群體，希望能夠用資料來量化定義，能夠明確符合什么特質，達到什么程度的人，才是具有技術情懷的，我拋一下個人愚見，嘗試從三個維度來解讀一下技術情懷：熱愛、思考、卓越，熱愛是一種源動力，而思考是一個程序，而卓越是一個結果，如果給這三個詞加一個定語，使技術情懷更加立體、清晰地被解讀，那就是奉獻式的熱愛，主動式的思考，極致式的卓越，

問：冰凍三尺，絕非一日之寒，這本手冊雖小，卻是眾多工程師平日一點一滴的積累而成，在你平常的作業里，有哪些一直保持的良好編碼習慣，可以分享給大家嗎？

我很習慣去做摘記，從進入阿里第一天開始，沉淀了近2000頁的筆記，分為兩個檔案，搜集和整理，我會讓知識快速進入搜集區，包括聽到的、看到的、疑惑的，不斷地去思考，不斷地去總結之后，將它們沉淀進入整理區，有一些至今沒有搞清楚的知識點，在搜集區已經沉淀了多年，依然會不斷地去review一下，所以，我對于知識的記憶非常清晰，因為那是不斷進行總結、思考、沉淀的結果，

編碼的程序也是一種藝術的演繹，對于設計七大原則和架構設計理念的理解，需要充分融入到代碼體系中，使代碼有靈感，有活力，有創造力，軟體設計是一個不斷學習，不斷實踐，不斷參悟的反復程序，這個程序可能比較辛苦，也容易缺氧，這個時候，多和身邊的良師益友溝通，或許會有“聽君一席話，勝讀十年書”的感受，

問：最后還有什么話，想和大家分享？

忽悠是把我不相信的東西說給大家聽，而信念是把我相信的用行動傳遞給大家，我相信手冊的愿景是碼出高效，碼出質量，碼出未來，幫助到更多的人，希望我們開發同學，能夠覺得開發是一件幸福的事情，開發是一件有創造力的事情，開發是一件能夠改變世界的事情，而不是為了爭論不休的規范，影響了演算法效率和架構設計的優雅性，