你不知道的《阿里巴巴Java開發手冊》背後故事

weixin_34292287發表於2018-10-24

導讀:今天是2月9日,也是《阿里巴巴Java開發手冊》(下稱《手冊》)對外正式釋出一週年的日子。在過去的300多個日子裡,這本小小的手冊在業界產生了巨大的影響力。值此一週年之際,我們不妨一道圍爐煮酒,傾聽《手冊》的主要推動者——孤盡首次講述規約背後的故事。

2509688-22e998882e66d18f.png
孤盡

Q:為什麼當初會想去做這樣一本手冊,初心是什麼呢?

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

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

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

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

Q:手冊釋出後,受到許多工程師的認可與支援。可以分享一些資料嗎?

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

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

Q:對於一路陪伴它成長起來的你來說,你覺得最大的挑戰是什麼?

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

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

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

Q:今年手冊推出了實體書,怎麼會有這樣的想法呢?

2509688-075b77ecf47b9e30.png

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

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

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

Q:這本書推出後,你也承擔起了“佈道者”的角色,帶著它和業界童鞋積極交流。可以分享一下你遇到的人或故事嗎?

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

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

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

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

Q:未來,《手冊》還會給大家帶來哪些驚喜,可否提前透露一下?

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

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

2509688-42220ae09e9c42a0.png

Q:情懷,這似乎是一個非常虛的詞。但我卻聽到許多人,用“情懷”來評價這本書。在你眼裡,情懷是什麼呢?

經常有人問我,編寫和推廣《手冊》如此費心費力,是什麼樣的信念讓我如此執著?

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

2509688-3499c1e3e99a0443.png

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

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

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

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

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

Q:最後還有什麼話,想和大家分享?

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

最後提前祝大家新春快樂,也期待未來能與大家有更多交流學習的機會。


本文作者:雲效平臺

閱讀原文

本文為雲棲社群原創內容,未經允許不得轉載。

相關文章