編輯推薦
規範了Java開發準則與代碼編寫習慣
將直接影響Java從業者、求職者和在校相關專業大學生等逾百萬的計算機相關人群
以阿里的技術底蘊，以一個獨特的視角地成為影響到世界的經典計算機圖書
對Java教育教學產生深遠影響
對社會貢獻及深遠影響不可估量
內容提要
《阿里巴巴Java開發手冊》的願景是碼出高效，碼出質量。它結合作者的開發經驗和架構歷程，提煉阿里巴巴集團技術團隊的集體編程經驗和軟體設計智慧，濃縮成為立體的編程規範和最佳實踐。眾所周知，現代軟體行業的高速發展對開發者的綜合素質要求越來越高，因為不僅是編程相關的知識點，其他維度的知識點也會影響軟體的最終交付質量，比如，資料庫的表結構和索引設計缺陷可能帶來軟體的架構缺陷或性能風險；單元測試的失位導致集成測試困難；沒有鑒權的漏洞代碼易被黑客攻擊等。所以，本手冊以開發者為中心視角，劃分為編程規約、異常日誌、單元測試、安全規約、MySQL資料庫、工程結構、設計規約七個維度，每個條目下有相應的擴展解釋和說明，正例和反例，全面、立體、形象地幫助到開發者的成長和團隊代碼規約文化的形成。
從嚴格意義上講，《阿里巴巴Java開發手冊》超越了Java語言本身，明確作為一名合格開發者應該具備的基本素質，因此本手冊適合計算機相關行業的管理者和研發人員、高等院校的計算機專業師生、求職者等閱讀，希望成為大家如良師益友般的工作手冊、工具字典和床頭書。
目錄
序 V
前言 XI
第1章 編程規約 1
1.1 命名風格 2
1.2 常量定義 7
1.3 代碼格式 9
1.4 OOP規約 14
1.5 集合處理 21
1.6 並發處理 28
1.7 控制語句 33
1.8 注釋規約 38
1.9 其他 41
第2章 異常日誌 43
2.1 異常處理 44
2.2 日誌規約 49
第3章 單元測試 53
第4章 安全規約 59
第5章 MySQL資料庫 63
5.1 建表規約 64
5.2 索引規約 68
5.3 SQL語句 72
5.4 ORM映射 75
第6章 工程結構 79
6.1 套用分層 80
6.2 二方庫依賴 83
6.3 伺服器 87
第7章 設計規約 89
附 錄 專有名詞 94
作者簡介
楊冠寶
花名孤盡，取自《笑傲江湖》中風清揚的“獨孤九劍，破盡天下武功”之意，是《阿里巴巴Java開發手冊》的主要作者。在阿里巴巴集團歷任研發、架構師、技術主管等不同的角色，承擔過雙11、國際化、代碼中心等大型項目，有著豐富的一線編程經驗，目前是研發協同平台Aone代碼中心負責人。樂於分享與總結，在阿里巴巴集團內部大型分享多達30餘次，不懈地追求技術創新，勇於挑戰技術難度，在大數據、高並發、研發效能領域均有較深的造詣。
媒體評論
“一個優秀的工程師和一個普通工程師的區別，不是滿天飛的架構圖，他的功底體現在所寫的每一行代碼上。”——畢玄
前言
序
別人都說我們是搬磚的碼農，可我們知道自己是追求個性的藝術家。也許我們不會過多在意自己的外表和穿著，但在我們不羈的外表下，骨子裡追求著代碼的美、系統的美，代碼規範其實就是一個對程式美的定義。但是這種美離程式設計師的生活有些遙遠，儘管編碼規範的價值在業內有著廣泛的共識，在現實中卻被否定得一塌糊塗。工程師曾經最引以為豪的代碼，因為編碼規範的缺失、命名的草率而全面地摧毀了彼此的信任，並嚴重地制約了相互的高效協同。工程師一邊吐槽別人的代碼，一邊寫著被吐槽的代碼，頻繁的系統重構和心驚膽戰的維護似乎成了工作的主旋律。
那么如何走出這種怪圈呢？眾所周知，網際網路公司的優勢在在於效率，是企業核心競爭力，體現在產品開發領域，就是溝通效率和研發效率。對於溝通效率的重要性，可以從程式設計師三大“編程理念之爭”說起：
縮進採用空格鍵，還是Tab鍵。
if單行語句需要大括弧，還是不需要大括弧。
左大括弧不換行，還是單獨另起一行。
在美劇《矽谷》中，你也許會記得這樣一個經典鏡頭：主人公Richard與同為程式設計師的女友分手，理由是兩人對縮進方式有著不同的習慣，互相擰巴地鄙視著對方的cody style。Tab鍵和空格鍵的爭議在現實編程工作中確實存在。《阿里巴巴Java開發手冊》（以下簡稱“《手冊》”）明確地支持了4個空格的做法，如果一定要問理由，沒有理由，因為能夠想出來的理由，就像最堅固的盾一樣，總有更加鋒利的矛會戳破它。只想說，一致性很重要，無邊無際爭論的時間成本與最後的收益是成反比的。
左大括弧是否單獨另起一行？因為Go語言的強制不換行，在這點上，“編程理念之爭”的銷煙味沒有那么濃，如果一定要給一個理由，那么換行的代碼可以增加一行，對於按代碼行數考核工作量的公司員工，肯定傾向於左大括弧前換行。《手冊》明確左大括弧不換行。
這些理念之爭的本質就是自己多年代碼習慣生的繭，不願意對不一樣的風格妥協，不願意為了團隊的整體效能提升而委屈自己。只想說，很多編程方式客觀上沒有對錯之分，一致性很重要，可讀性很重要，團隊溝通效率很重要。有一個理論叫帕金森瑣碎定律：一個組織中的成員往往會把過多的精力花費在一些瑣碎的爭論上。程式設計師天生需要團隊協作，而協作的正能量要放在問題的有效溝通上。個性化應儘量表現在系統架構和算法效率的提升上，而不是在合作規範上進行糾纏不休的討論、爭論，最後沒有結論。規範不一，就像下圖中的小鴨子和小雞對話一樣，言語不通，一臉囧相。雞同鴨講也恰恰形容了人與人之間溝通的痛點，自說自話，達不成一致意見。再舉個生活中的例子，交通規則靠左行還是靠右行，兩者孰好孰壞並不重要，重要的是必須要在統一的方向上通行，表面上限制了自由，但實際上是保障了公眾的人身安全。試想，如果沒有規定靠右行駛，那樣的路況肯定擁堵不堪，險象環生。同樣，過分自由隨意、天馬行空的代碼會嚴重地傷害系統的健康，影響到可擴展性及可維護性。
——孤盡
前言
《阿里巴巴Java開發手冊》（以下簡稱“《手冊》”）是阿里巴巴集團技術團隊的集體智慧結晶和經驗總結，經歷了多次大規模一線實戰的檢驗及不斷的完善，系統化地被整理成冊，回饋給廣大開發者。
現代軟體行業的高速發展對開發者的綜合素質要求越來越高，因為不僅是編程知識點，其他維度的知識點也會影響軟體的最終交付質量。比如，資料庫的表結構和索引設計缺陷可能帶來軟體的架構缺陷或性能風險；單元測試的失位導致集成測試困難；沒有鑒權的漏洞代碼易被黑客攻擊等。（與著作權頁介紹一致）所以，《手冊》以Java開發者為中心視角，劃分為編程規約、異常日誌、單元測試、安全規約、MySQL資料庫、工程結構、設計規約七個維度，再根據內容特徵，細分成若干個二級子目錄。
根據約束力強弱及故障敏感性，規約依次分為【強制】、【推薦】、【參考】三大類。在規約條目的延伸信息中，“說明”對內容做了適當擴展和解釋，“正例”是提倡的編碼和實現方式，“反例”是需要提防的雷區及真實的錯誤案例。
既然《手冊》劃分為前文所說的七大維度知識點，那么延伸的問題就是“為什麼我們會提到這些看似與編碼毫無關係的章節？”有人曾經質疑，擴展的知識體系本來就是十分龐大的規範文檔，比如安全規約擴展開來可以是上百頁的資料，與伺服器維護相關的PE手冊厚厚一疊，不知道寫進《手冊》中的意義何在？其實，《手冊》主要關注的是與開發緊密相關的知識點，《手冊》不是提倡大家成為安全專家、運維專家，而是關注與編碼相關的生態知識，明確了作為一位合格的Java開發工程師應具備的基本技術素養。
設計規約部分是本手冊獨家首發，它根據阿里巴巴一線架構設計經驗沉澱而成，旨在幫助研發人員準確度量是否需要定向地設計文檔。近年來，敏捷開發的流行，在一定程度上弱化了設計的重要性，在《手冊》中明確了軟體設計底線，如果超過規定的閾值，則需要進行有針對性的軟體設計與文檔沉澱。
最後，《碼出高效——阿里巴巴Java開發手冊詳解》即將出版。此書將詳細說明規約的初衷和意義、編寫和推廣歷程，每個條目背後的思考與詳細的示例代碼，以及相應的故障案例分析。擬定的主要章節如下：
第1章 從程式設計師的“編程理念之爭”說起
第2章 編碼規範與團隊效能的辯證關係
第3章 Java編程規約剖析
第4章 異常日誌與問題排查
第5章 兢兢業業的單元測試
第6章 安全無小事
第7章 MySQL資料庫
第8章 規範化的工程
第9章 設計中體現藝術家的氣質
