作者｜無獨
校對｜孤盡
《阿里巴巴Java開發手冊》（下稱《手冊》）凝聚了阿里集團很多同學的知識智慧和經驗，這些經驗甚至是用血淋淋的故障換來的，希望前車之鑒，后車之師，能夠幫助更多的開發者少踩坑，杜絕踩重復的坑。 此手冊從構思到現在的最新版本，歷時一年半，歷經無數次內部針鋒相對的討論，迭代105次?？梢哉f手冊中每一個條目的背后，都有一個很長、很精彩的故事。為了讓廣大開發者更加深入地了解到項目組的初衷，項目組第一次公開談一些手冊背后的故事。
為何叫《Java開發手冊》。第一、本手冊主要是面向Java開發群體，Java做為面向對象語言，在業界的生命力還是非常強大的，技術生態豐富，框架結構成熟，經歷了超高并發的“雙十一”實戰考驗，阿里真誠地想把多年的Java技術積累回饋給Java開發者 社區。第二、它是一個廣義的編碼規范， 一個隨時可以查閱的技術參考，在手冊中可以找到很多的技術規范、最佳實踐，避坑指南等。
手冊內容為何引入數據庫、安全、服務器等知識?，F代軟件行業的高速發展對于開發者的綜合素質要求越來越高，因為不僅是編程知識，其它維度的知識結構也會影響到軟件的最終交付質量。比如：數據庫的表結構和索引設計缺陷可能帶來軟件上的架構缺陷或性能風險；工程結構混亂導致維護困難；沒有鑒權的漏洞代碼被黑客攻擊等等。
所以手冊以Java開發者為中心視角，劃分為編程規約、異常日志規約、MySQL規約、工程規約、安全規約五大塊。那么衍生的問題是為什么我們提到的這些看似與編碼毫無關系的內容，有人說，僅安全規約如果擴展開來可以是上百頁的資料，不知道寫在《手冊》里的意義何在，我們的答案是，手冊關注的是與開發緊密相關的知識點，試問一個不知道水平權限校驗的Java開發者，會是一個合格的程序員嗎？《手冊》不是提倡大家深究所有的知識點而成為安全專家、運維專家，而是關注在編碼相關的生態知識上。
約束力等級為何是三級。《手冊》根據約束力強弱及故障敏感性，規約依次分為強制、推薦、參考三大類。強制是一種指令型的，是協作的Gap，或是故障的痛點；而推薦，希望這樣做是一件好事，大家都這樣做，結構更清晰，協作更高效，但是不這樣做也不會死。而參考分成兩種情況：第一種是無法用代碼量化的描述，提倡什么什么樣的做法，如索引的創建索引時，寧濫勿缺的錯誤做法；第二種是真心覺得或左或右都可以，只是有傾向于一種，這個自由度由開發者自己把握。
擴展的說明、正例、反例用來表達什么。如果只是冷冰冰的條目，對于閱讀者理解成本和記憶成本都是很大的挑戰，《手冊》希望閱讀者能夠非常舒心地看完整個文檔，掩卷遐思，亦有所得。具體來說， “說明”是對內容做了引申和解釋，為求知其然；“正例”提倡什么樣的編碼和實現方式，推薦做法的其中之一；“反例”說明需要提防的雷區，以及真實的錯誤案例，讓人知其不然。
最后，《手冊》的愿景是碼出質量、碼出高效，即代碼的字里行間如何提升系統的質量，如何提升協作的高效性。 我們提倡算法效率和架構擴展的個性化，而不是代碼風格隨意化，盡量減少沒有營養的“圣戰”，如：4個空格、單行語句換行等。程序員是天生幻想創造個性化作品的藝術家，變著法子想著要如何與眾不同，最好代碼只有自己能夠看懂，只有自己能夠維護。
真正的藝術家是個性獨立、張揚文化的群體，他們之間不需要協同工作，大家很少見過書法，畫畫、雕塑是一個團隊協作來創作完成的，但是程序員這個工種，天生需要團隊協作，而協作的正能量要放在問題的有效討論和快速解決上， 個性化應盡量表現在代碼質量和算法效率的提升上，而不是對于合作規范上糾纏不休的爭論。再者，公司是請程序員來產出實際價值的，而不是經常消耗時間為幾個空格的事情爭得臉紅脖子粗的。有時候，就是一個規定，大家這么做了，協作效率自然就提升了，正所謂無規矩不成方圓，無規范難以協作。
InfoQ觀察：Java EE的未來
推薦一個對技術人員的成長很有幫助的線下會議，將于4月16～18日舉行的QCon全球軟件開發大會（北京站），目前已經邀請來自Google、Facebook、LinkedIn、Airbnb、百度、阿里巴巴、騰訊等公司的100多位一線技術專家，是難得的線下交流學習的機會。具體詳戳「 閱讀原文 」驚喜不停！
