阿裡巴巴開源Java編碼規範背後的故事

（作者：無獨 | 校對：孤盡）

《阿裡巴巴java開發手冊》（下稱《手冊》）凝聚了阿裡集團很多同學的知識智慧和經驗，這些經驗甚至是用血淋淋的故障換來的，希望前車之鑒，後車之師，能夠幫助更多的開發者少踩坑，杜絕踩重複的坑。 

此手冊從構思到現在的最新版本，曆時一年半，曆經無數次内部針鋒相對的讨論，疊代105次。可以說手冊中每一個條目的背後，都有一個很長、很精彩的故事。為了讓廣大開發者更加深入地了解到項目組的初衷，項目組第一次公開談一些手冊背後的故事。

第一、本手冊主要是面向java開發群體，java做為面向對象語言，在業界的生命力還是非常強大的，技術生态豐富，架構結構成熟，經曆了超高并發的“雙十一”實戰考驗，阿裡真誠地想把多年的java技術積累回饋給java開發者 社群。

第二、它是一個廣義的編碼規範， 一個随時可以查閱的技術參考，在手冊中可以找到很多的技術規範、最佳實踐，避坑指南等。

現代軟體行業的高速發展對于開發者的綜合素質要求越來越高，因為不僅是程式設計知識，其它次元的知識結構也會影響到軟體的最終傳遞品質。比如：資料庫的表結構和索引設計缺陷可能帶來軟體上的架構缺陷或性能風險；工程結構混亂導緻維護困難；沒有鑒權的漏洞代碼被黑客攻擊等等。

是以手冊以java開發者為中心視角，劃分為程式設計規約、異常日志規約、mysql規約、工程規約、安全規約五大塊。那麼衍生的問題是為什麼我們提到的這些看似與編碼毫無關系的内容，有人說，僅安全規約如果擴充開來可以是上百頁的資料，不知道寫在《手冊》裡的意義何在，我們的答案是，手冊關注的是與開發緊密相關的知識點，試問一個不知道水準權限校驗的java開發者，會是一個合格的程式員嗎？《手冊》不是提倡大家深究所有的知識點而成為安全專家、運維專家，而是關注在編碼相關的生态知識上。

《手冊》根據限制力強弱及故障敏感性，規約依次分為強制、推薦、參考三大類。強制是一種指令型的，是協作的gap，或是故障的痛點；而推薦，希望這樣做是一件好事，大家都這樣做，結構更清晰，協作更高效，但是不這樣做也不會死。而參考分成兩種情況：第一種是無法用代碼量化的描述，提倡什麼什麼樣的做法，如索引的建立索引時，甯濫勿缺的錯誤做法；第二種是真心覺得或左或右都可以，隻是有傾向于一種，這個自由度由開發者自己把握。

擴充的說明、正例、反例用來表達什麼。如果隻是冷冰冰的條目，對于閱讀者了解成本和記憶成本都是很大的挑戰，《手冊》希望閱讀者能夠非常舒心地看完整個文檔，掩卷遐思，亦有所得。具體來說， “說明”是對内容做了引申和解釋，為求知其然；“正例”提倡什麼樣的編碼和實作方式，推薦做法的其中之一；“反例”說明需要提防的雷區，以及真實的錯誤案例，讓人知其不然。

最後，《手冊》的願景是碼出品質、碼出高效，即代碼的字裡行間如何提升系統的品質，如何提升協作的高效性。 我們提倡算法效率和架構擴充的個性化，而不是代碼風格随意化，盡量減少沒有營養的“聖戰”，如：4個空格、單行語句換行等。程式員是天生幻想創造個性化作品的藝術家，變着法子想着要如何與衆不同，最好代碼隻有自己能夠看懂，隻有自己能夠維護。

真正的藝術家是個性獨立、張揚文化的群體，他們之間不需要協同工作，大家很少見過書法，畫畫、雕塑是一個團隊協作來創作完成的，但是程式員這個工種，天生需要團隊協作，而協作的正能量要放在問題的有效讨論和快速解決上， 個性化應盡量表現在代碼品質和算法效率的提升上，而不是對于合作規範上糾纏不休的争論。再者，公司是請程式員來産出實際價值的，而不是經常消耗時間為幾個空格的事情争得臉紅脖子粗的。有時候，就是一個規定，大家這麼做了，協作效率自然就提升了，正所謂無規矩不成方圓，無規範難以協作。