阿里巴巴Java開發手冊 ( 簡體 字) |
| 作者：楊冠寶 | 類別：1. -> 程式設計 -> JAVA -> Java |
| 譯者： |
| 出版社：電子工業出版社 |  3dWoo書號： 48264
詢問書籍請說出此書號！【缺書】
NT售價： 175 元 |
| 出版日：1/1/2018 |
| 頁數：112 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787121332319 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：序
別人都說我們是搬磚的碼農，但我們知道自己是追求個性的藝術家。也許我們不會過多在意自己的外表和穿著，但在我們不羈的外表下，骨子里追求著代碼的美、系統的美，代碼規范其實就是一個對程序美的定義。但是這種美離程序員的生活有些遙遠，盡管編碼規范的價值在業內有著廣泛的共識，在現實中卻被否定得一塌糊涂。工程師曾經最引以為豪的代碼，因為編碼規范的缺失、命名的草率而全面地摧毀了彼此的信任，并嚴重地制約了相互的高效協同。工程師一邊吐槽別人的代碼，一邊寫著被吐槽的代碼，頻繁的系統重構和心驚膽戰的維護似乎成了工作的主旋律。
那么如何走出這種怪圈呢？眾所周知，互聯網公司的優勢在于效率，它是企業核心競爭力。體現在產品開發領域，就是溝通效率和研發效率。對于溝通效率的重要性，可以從程序員三大“編程理念之爭”說起：
? 縮進采用空格鍵，還是Tab鍵。
? if單行語句需要大括號，還是不需要大括號。
? 左大括號不換行，還是單獨另起一行。
在美劇《硅谷》中，你也許會記得這樣一個經典鏡頭：主人公Richard與同為程序員的女友分手，理由是兩人對縮進方式有著不同的習慣，互相擰巴地鄙視著對方的cody style。Tab鍵和空格鍵的爭議在現實編程工作中確實存在。《阿里巴巴Java開發手冊》（以下簡稱“《手冊》”）明確地支持了4個空格的做法，如果一定要問理由，沒有理由，因為能夠想出來的理由，就像最堅固的盾一樣，總有更加鋒利的矛會戳破它。只想說，一致性很重要，無邊無際爭論的時間成本與最后的收益是成反比的。
if單語句是否需要換行，也是爭論不休的話題。相對來說，寫過格式縮進類編程語言的開發者，更加習慣于不加大括號。《手冊》中明確if/for單行語句必須加大括號，因為單行語句的寫法，容易在添加邏輯時引起視覺上的錯誤判斷。此外，if不加大括號還會有局部變量作用域的問題。
左大括號是否單獨另起一行？因為Go語言的強制不換行，在這點上，“編程理念之爭”的銷煙味沒有那么濃。如果一定要給一個理由，那么換行的代碼可以增加一行，對于按代碼行數考核工作量的公司員工，肯定傾向于左大括號前換行。《手冊》明確左大括號不換行。
這些理念之爭的本質就是自己多年代碼習慣生的繭，不愿意對不一樣的風格妥協，不愿意為了團隊的整體效能提升而委屈自己。其實，很多編程方式客觀上沒有對錯之分，一致性很重要，可讀性很重要，團隊溝通效率很重要。有一個理論叫帕金森瑣碎定律：一個組織中的成員往往會把過多的精力花費在一些瑣碎的爭論上。程序員天生需要團隊協作，而協作的正能量要放在問題的有效溝通上。個性化應盡量表現在系統架構和算法效率的提升上，而不是在合作規范上進行糾纏不休的討論、爭論，最后沒有結論。規范不一，就像下圖中的小鴨子和小雞對話一樣，言語不通，一臉囧相。雞同鴨講也恰恰形容了人與人之間溝通的痛點，自說自話，無法達成一致意見。再舉個生活中的例子，交通規則靠左行還是靠右行，兩者孰好孰壞并不重要，重要的是必須要在統一的方向上通行，表面上限制了自由，但實際上是保障了公眾的人身安全。試想，如果沒有規定靠右行駛，那樣的路況肯定擁堵不堪，險象環生。同樣，過分自由隨意、天馬行空的代碼會嚴重地傷害系統的健康，影響到可擴展性及可維護性。
為了幫助開發人員更好地提高研發效率，阿里巴巴集團基于《手冊》內容，獨立研發了一套自動化IDE檢測插件。該插件在掃描代碼后，將不符合《手冊》的代碼按block/critical/major三個等級顯示在下方；編寫代碼時，還會給出智能實時提示，告訴你代碼如何編寫可以更優雅、更符合大家共同的編程風格；對于歷史代碼，部分規則實現了批量一鍵修復功能。此插件已經在2017年杭州云棲大會上正式對外開放并提供了源碼，下載地址：https://github.com/alibaba/p3c。
——孤盡
前言
《阿里巴巴Java開發手冊》（以下簡稱“《手冊》”）是阿里巴巴集團技術團隊的集體智慧結晶和經驗總結，經歷了多次大規模一線實戰的檢驗及不斷的完善，系統化地被整理成冊，回饋給廣大開發者。
現代軟件行業的高速發展對開發者的綜合素質要求越來越高，因為不僅是編程知識點，其他維度的知識點也會影響軟件的最終交付質量。比如，數據庫的表結構和索引設計缺陷可能帶來軟件的架構缺陷或性能風險；單元測試的失位導致集成測試困難；沒有鑒權的漏洞代碼易被黑客攻擊等。（與版權頁介紹一致）所以，《手冊》以Java開發者為中心視角，劃分為編程規約、異常日志、單元測試、安全規約、MySQL數據庫、工程結構、設計規約七個維度，再根據內容特征，細分成若干個二級子目錄。
根據約束力強弱及故障敏感性，規約依次分為【強制】、【推薦】、【參考】三大類。在規約條目的延伸信息中，“說明”對內容做了適當擴展和解釋，“正例”是提倡的編碼和實現方式，“反例”是需要提防的雷區及真實的錯誤案例。
既然《手冊》劃分為前文所說的七大維度知識點，那么延伸的問題就是“為什么我們會提到這些看似與編碼毫無關系的章節？”有人曾經質疑，擴展的知識體系本來就是十分龐大的規范文檔，比如安全規約擴展開來可以是上百頁的資料，與服務器維護相關的PE手冊厚厚一疊，不知道寫進《手冊》中的意義何在？其實，《手冊》主要關注的是與開發緊密相關的知識點，《手冊》不是提倡大家成為安全專家、運維專家，而是關注與編碼相關的生態知識，明確了作為一位合格的Java開發工程師應具備的基本技術素養。
設計規約部分是本手冊獨家首發，它根據阿里巴巴一線架構設計經驗沉淀而成，旨在幫助研發人員準確度量是否需要定向地設計文檔。近年來，敏捷開發的流行，在一定程度上弱化了設計的重要性，在《手冊》中明確了軟件設計底線，如果超過規定的閾值，則需要進行有針對性的軟件設計與文檔沉淀。
最后，《碼出高效——阿里巴巴Java開發手冊詳解》即將出版。此書將詳細說明規約的初衷和意義、編寫和推廣歷程，每個條目背后的思考與詳細的示例代碼，以及相應的故障案例分析。擬定的主要章節如下：
第1章 從程序員的“編程理念之爭”說起
第2章 編碼規范與團隊效能的辯證關系
第3章 Java編程規約剖析
第4章 異常日志與問題排查
第5章 兢兢業業的單元測試
第6章 安全無小事
第7章 MySQL數據庫
第8章 規范化的工程
第9章 設計中體現藝術家的氣質 |
內容簡介：《阿里巴巴Java開發手冊》的愿景是碼出高效，碼出質量。它結合作者的開發經驗和架構歷程，提煉阿里巴巴集團技術團隊的集體編程經驗和軟件設計智慧，濃縮成為立體的編程規范和最佳實踐。眾所周知，現代軟件行業的高速發展對開發者的綜合素質要求越來越高，因為不僅是編程相關的知識點，其他維度的知識點也會影響軟件的最終交付質量，比如，數據庫的表結構和索引設計缺陷可能帶來軟件的架構缺陷或性能風險；單元測試的失位導致集成測試困難；沒有鑒權的漏洞代碼易被黑客攻擊等。所以，本手冊以開發者為中心視角，劃分為編程規約、異常日志、單元測試、安全規約、MySQL數據庫、工程結構、設計規約七個維度，每個條目下有相應的擴展解釋和說明，正例和反例，全面、立體、形象地幫助到開發者的成長和團隊代碼規約文化的形成。從嚴格意義上講，本手冊跨越了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 |
| 序： |
