導讀：2月9日，也是《阿裡巴巴Java開發手冊》（下稱《手冊》）對外正式釋出一周年的日子。在過去的300多個日子裡，這本小小的手冊在業界産生了巨大的影響力。值此一周年之際，我們不妨一道圍爐煮酒，傾聽《手冊》的主要推動者——孤盡首次講述規約背後的故事。
Q：為什麼當初會想去做這樣一本手冊，初心是什麼呢？
大家好，很高興今天能與大家一起交流。要回答這個問題，我想用個例子來解釋。
原始社會的争端，更多的是講究個人的蠻力；三國時代的群雄并起，開始講究士兵的團隊默契；到了現代戰争，海陸空、資訊兵、工程兵，無不需要緊密配合。軟體發展至今，隻是靠一句hello world走天下的時代，已經過去了，我們需要團隊緊密協作。
代碼規約是一種文化軟實力，關系着網際網路公司規模化生産效率，從這點上講就是要提升研發效率，提升代碼品質。在規約出現之前，一片混沌，如表達删除狀态的字段名，非常多，像：delete, delete_flag, is_delete, is_deleted，在資料分析時，總要小心翼翼，像文字遊戲。而0/1還是y/n來表示已删除和未删除，更是神坑，極易造成線上問題。再如，批量接口定義時，沒有接口保護很容易造成服務提供方記憶體耗盡，産生OOM等等。
是以，我們的初心是碼出高效，碼出品質。碼是名詞，也是動詞，希望規約能夠提升整個社會的研發協作效率，提升系統品質，提升我們廣大程式員程式設計的幸福感。
Q：手冊釋出後，受到許多工程師的認可與支援。可以分享一些資料嗎？
這本手冊的影響力，确實出乎我們所有人的意料之外。據不完全統計，手冊推出一周年，影響了全球範圍内逾160萬人，插件安裝數23萬+，《手冊》紙質版一個月連續增印兩次，一直處于熱銷狀态；插件開源不到4個月，已經超過7300star，曾達到周熱度排名世界第一；手冊插件正式在雲效公有雲上線；英文版也在海外釋出，引起業界廣泛關注。
在此期間，業界同仁為我們提供了許多寶貴的建議，在此也非常感謝大家的支援與厚愛。
Q：對于一路陪伴它成長起來的你來說，你覺得最大的挑戰是什麼？
挑戰的主要來源是程式員内心的天馬行空和自身價值的不可替代性。
程式員都是天生幻想創造個性化作品的藝術家，變着法子想着要如何與衆不同，最好代碼隻有自己能夠看懂，隻有自己能夠維護。内心深處個人至上的不可替代性，是一個深層次的潛意識抵抗，是最大的阻力來源，沒有足夠的意識為了遵守團隊的代碼風格去委屈自己。
但是個性化應盡量表現在代碼品質和算法效率的提升上，而不是對于合作規範上糾纏不休的争論。再者，公司是請程式員來産出實際價值的，而不是經常消耗時間為TAB還是空格的事情争得臉紅脖子粗的。有時候，就是一個規定，就像交規靠左行，還是右行一樣，大家這麼做了，協作效率自然就提升了，正所謂無規矩不成方圓，無規範難以協作。
Q：今年手冊推出了實體書，怎麼會有這樣的想法呢？
其實，實體書的推出并非計劃之内。在2017年杭州雲栖大會，為了友善現場做規約挑戰賽，我們精心準備了800本試讀本，把網絡上公開釋出的電子版制訂成薄薄的冊子，結果現場受到很多童鞋的喜歡，甚至有人願意出錢收購。
後來我們意識到，盡管有電子版，同學們還是希望能夠有實物可以在紙上記錄自己的學習心得，在地鐵、公交、火車上的碎片化時間内也可以随手翻翻，是以我們把尺寸極大縮小，制訂成冊，并且獨家釋出了《設計規約》部分。
為了把實體手冊做好，我們做了反複校對，在标點符号、示例代碼、字型顔色等都做了認真的稽核。到第三次印刷時，也進行了20處的精細修改，我們希望這是一本走向卓越的小冊子，是陪伴大家的床頭書、工具書。
Q：這本書推出後，你也承擔起了“布道者”的角色，帶着它和業界童鞋積極交流。可以分享一下你遇到的人或故事嗎？
是的，我們非常欣喜地看到，手冊受到了廣泛的關注和支援，大家都希望它變得更好。蘇州微軟的一個同學提及錯誤的示例代碼，是關于延遲初始化的問題，我們反複論證，發現《手冊》的命名是存在問題，是以在第三次印刷中，我們進行了修改。
另外，也有人覺得設計規約過分量化了。事實上，如果描述為“原則上”，或者說寫一個非常寬泛的區間，指導意義也很弱，幹脆就寫成具體的數字，當然具體的數字，也是從無數的設計案例中抽象出來的。
前段時間有讀者問我如何了解<? extends T>和<? super T>的差別，我是這麼舉例的。好多人看過優酷劇場的《白夜追兇》吧，關宏峰追查他弟弟的懸案時，去檢視被封存的證物箱，被明确告知，你隻能看，不能動，當然更不可以增加一件新的證物進去，那是在僞造證據，這就是前者，隻能讀取，不能增加。
那<? super T>在什麼樣的情況下隻能增加，不能讀取呢？這個場景似乎更難立體地被想象出來。比如，投票選舉代表時，你隻能往裡投選票。如果自己選錯了代表，想從票箱裡撈出來，重新投票，這可能嗎？更加不可能給你讀取票箱元素的機會。有人說，這隻是一種生活場景，在系統設計中，很難有這樣的情形。那麼，我再舉例說明一下，我們在填寫對于主管的年度評價時，填寫完畢送出後，即使填寫錯誤，當你再次通路之前的連結時，也會告訴你：“您已經完成對主管的年度回報，謝謝參與”，當然更加不可能讓你讀取到其它成員對于主管的回報内容。
Q：未來，《手冊》還會給大家帶來哪些驚喜，可否提前透露一下？
《碼出高效——阿裡巴巴開發手冊詳解》即将出版，此書将詳細說明規約的初衷和意義、編寫和推廣曆程，每個條目背後的思考與詳細的示例代碼，以及相應的故障案例分析。目前基本完成了三章的編寫，我們希望這本書是深入淺出、言之有物，從實踐中來，走向理論，再走向指導實踐。
言之有物，物指的是有定義、推導、案例、總結。而深入淺出的深指的是能夠在業界領先的深度上，把内容講深講透，淺指的是讓一個Java初學者都能夠看得懂。
Q：情懷，這似乎是一個非常虛的詞。但我卻聽到許多人，用“情懷”來評價這本書。在你眼裡，情懷是什麼呢？
經常有人問我，編寫和推廣《手冊》如此費心費力，是什麼樣的信念讓我如此執着？
我想說一個自己經曆的事：我很喜歡電影《岡仁波齊》，也去過岡仁波齊。轉山的那段路，汽車呼嘯而過，塵土飛揚，可是轉山的藏民，還是那樣的虔誠，叩拜之後，即使滿臉灰塵，他們的信念依然樸實而笃信。陸川的電影《可可西裡》也是，很多事情是因為信念而堅守，現實中為可可西裡申遺做過巨大貢獻的王欣，畢生都獻給了藏羚羊的保護，長年駐守在高原雪域，他無私地付出了很多，也放棄了很多，因為信念而堅持展現出人類的偉大，信念就是一種情懷。
情懷，如果用武俠文化來說，是行俠仗義于江湖，快意潇灑于恩仇，大江南北，俠之大者，為國為民；俠之小者，為紅顔，為知己。而技術情懷是什麼？它是一種匠心；是追求一年又一年雙11業務背後的技術突破，拓展商業邊界；是解決問題後客戶的認可。
說到底，技術情懷是一個比較虛的詞，工程師是偏向于資料驅動的群體，希望能夠用資料來量化定義，能夠明确符合什麼特質，達到什麼程度的人，才是具有技術情懷的。我抛一下個人愚見，嘗試從三個次元來解讀一下技術情懷：熱愛、思考、卓越。熱愛是一種源動力，而思考是一個過程，而卓越是一個結果。如果給這三個詞加一個定語，使技術情懷更加立體、清晰地被解讀，那就是奉獻式的熱愛，主動式的思考，極緻式的卓越。
Q：冰凍三尺，絕非一日之寒。這本手冊雖小，卻是衆多工程師平日一點一滴的積累而成。在你平常的工作裡，有哪些一直保持的良好編碼習慣，可以分享給大家嗎？
我很習慣去做摘記，從進入阿裡第一天開始，沉澱了近2000頁的筆記，分為兩個文檔，搜集和整理。我會讓知識快速進入搜集區，包括聽到的、看到的、疑惑的，不斷地去思考，不斷地去總結之後，将它們沉澱進入整理區。有一些至今沒有搞清楚的知識點，在搜集區已經沉澱了多年，依然會不斷地去review一下。是以，我對于知識的記憶非常清晰，因為那是不斷進行總結、思考、沉澱的結果。
編碼的過程也是一種藝術的演繹，對于設計七大原則和架構設計理念的了解，需要充分融入到代碼體系中，使代碼有靈感，有活力，有創造力。軟體設計是一個不斷學習，不斷實踐，不斷參悟的反複過程，這個過程可能比較辛苦，也容易缺氧，這個時候，多和身邊的良師益友溝通，或許會有“聽君一席話，勝讀十年書”的感受。
Q：最後還有什麼話，想和大家分享？
忽悠是把我不相信的東西說給大家聽，而信念是把我相信的用行動傳遞給大家。我相信手冊的願景是碼出高效，碼出品質，碼出未來，幫助到更多的人。希望我們開發同學，能夠覺得開發是一件幸福的事情，開發是一件有創造力的事情，開發是一件能夠改變世界的事情，而不是為了争論不休的規範，影響了算法效率和架構設計的優雅性。