前言：《阿里巴巴Java開發手冊》將阿里技術團隊的經驗總結，系統化整理成冊，獻給廣大開發者。如今，該手冊的實體書已正式開啟預售（此處應有掌聲），並在書中獨家披露設計規約，它根據阿里巴巴一線架構設計經驗沉澱而成，旨在幫助研發人員準確地度量是否需要定向的設計方案。
近年來，敏捷開發的流行，在一定程度上削弱了設計的重要性，但在某些方面，需要明確地進行詳細地方案設計與評審，比如：存儲方案和底層數據結構的設計。有缺陷的底層數據結構容易導致系統風險高，可擴展性差，重構成本因歷史數據遷移、系統平滑過渡也會陡然增加。所以，存儲方案和數據結構需要認真地進行設計和評審，生產環境提交執行後，需要進行double check；明確存儲介質選型、表結構設計能否滿足技術方案、存取性能和存儲空間能否滿足業務發展、表或字段之間的辯證關係、字段名稱、字段類型等。
在其它設計領域，《手冊》也明確了軟件設計底線，如果超過規定的閾值，則需要進行有針對性的軟件設計與文檔沉澱。
如果有興趣瞭解更多，可參考文末說明，第一時間購得此書，甚至有機會免費獲得作者簽名版。
今天我們也有幸邀請了作者孤盡，請他來聊聊規約背後的故事與初心。
孤盡：別人都說我們是搬磚的碼農，但我們知道自己是追求個性的藝術家。也許我們不會過多在意自己的外表和穿著，但在我們不羈的外表下，骨子裡追求著代碼的美、系統的美，代碼規範其實就是一個對程序美的定義。
這篇文章分享之前我還是要推薦下我自己的JAVA群：472052538，不管你是小白還是大牛，小編我都挺歡迎，不定期分享乾貨，包括我自己整理的一份2017最新JAVA資料和零基礎入門教程！，歡迎初學和進階中的小夥伴
但是這種美離程序員的生活有些遙遠，儘管編碼規範的價值在業內有著廣泛的共識，在現實中卻被否定得一塌糊塗。工程師曾經最引以為豪的代碼，因為編碼規範的缺失、命名的草率而全面地摧毀了彼此的信任，並嚴重地制約了相互的高效協同。工程師一邊吐槽別人的代碼，一邊寫著被吐槽的代碼，頻繁的系統重構和心驚膽戰的維護似乎成了工作的主旋律。
那麼如何走出這種怪圈呢？眾所周知，互聯網公司的優勢在於效率，它是企業核心競爭力。體現在產品開發領域，就是溝通效率和研發效率。對於溝通效率的重要性，可以從程序員三大“編程理念之爭”說起：
縮進採用空格鍵，還是Tab鍵。
if單行語句需要大括號，還是不需要大括號。
左大括號不換行，還是單獨另起一行。
在美劇《硅谷》中，你也許會記得這樣一個經典鏡頭：主人公Richard與同為程序員的女友分手，理由是兩人對縮進方式有著不同的習慣，互相擰巴地鄙視著對方的cody style。Tab鍵和空格鍵的爭議在現實編程工作中確實存在。《阿里巴巴Java開發手冊》（以下簡稱“《手冊》”）明確地支持了4個空格的做法，如果一定要問理由，沒有理由，因為能夠想出來的理由，就像最堅固的盾一樣，總有更加鋒利的矛會戳破它。只想說，一致性很重要，無邊無際爭論的時間成本與最後的收益是成反比的。
if單語句是否需要換行，也是爭論不休的話題。相對來說，寫過格式縮進類編程語言的開發者，更加習慣於不加大括號。《手冊》中明確if/for單行語句必須加大括號，因為單行語句的寫法，容易在添加邏輯時引起視覺上的錯誤判斷。此外，if不加大括號還會有局部變量作用域的問題。
左大括號是否單獨另起一行？因為Go語言的強制不換行，在這點上，“編程理念之爭”的銷煙味沒有那麼濃。如果一定要給一個理由，那麼換行的代碼可以增加一行，對於按代碼行數考核工作量的公司員工，肯定傾向於左大括號前換行。《手冊》明確左大括號不換行。
這些理念之爭的本質就是自己多年代碼習慣生的繭，不願意對不一樣的風格妥協，不願意為了團隊的整體效能提升而委屈自己。其實，很多編程方式客觀上沒有對錯之分，一致性很重要，可讀性很重要，團隊溝通效率很重要。
有一個理論叫帕金森瑣碎定律：一個組織中的成員往往會把過多的精力花費在一些瑣碎的爭論上。程序員天生需要團隊協作，而協作的正能量要放在問題的有效溝通上。個性化應儘量表現在系統架構和算法效率的提升上，而不是在合作規範上進行糾纏不休的討論、爭論，最後沒有結論。規範不一，就像下圖中的小鴨子和小雞對話一樣，言語不通，一臉囧相。
雞同鴨講也恰恰形容了人與人之間溝通的痛點，自說自話，無法達成一致意見。再舉個生活中的例子，交通規則靠左行還是靠右行，兩者孰好孰壞並不重要，重要的是必須要在統一的方向上通行，表面上限制了自由，但實際上是保障了公眾的人身安全。試想，如果沒有規定靠右行駛，那樣的路況肯定擁堵不堪，險象環生。同樣，過分自由隨意、天馬行空的代碼會嚴重地傷害系統的健康，影響到可擴展性及可維護性。
閱讀更多 猿說教育 的文章
