描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787121332319丛书名: 阿里巴巴集团技术丛书
1.从编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约七大维度，诠释编程规范和*实践！
2.受到毕玄、多隆大神高度认可！并获得社区及Java爱好者支持！
3.*集体技术团队的集体编程经验和软件设计智慧的结晶！
《*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
序
别人都说我们是搬砖的码农，可我们知道自己是追求个性的艺术家。也许我们不会过多在意自己的外表和穿着，但在我们不羁的外表下，骨子里追求着代码的美、系统的美，代码规范其实就是一个对程序美的定义。但是这种美离程序员的生活有些遥远，尽管编码规范的价值在业内有着广泛的共识，在现实中却被否定得一塌糊涂。工程师曾经引以为豪的代码，因为编码规范的缺失、命名的草率而全面地摧毁了彼此的信任，并严重地制约了相互的高效协同。工程师一边吐槽别人的代码，一边写着被吐槽的代码，频繁的系统重构和心惊胆战的维护似乎成了工作的主旋律。
那么如何走出这种怪圈呢？众所周知，互联网公司的优势在在于效率，是企业核心竞争力，体现在产品开发领域，就是沟通效率和研发效率。对于沟通效率的重要性，可以从程序员三大“编程理念之争”说起：
? 缩进采用空格键，还是Tab键。
? if单行语句需要大括号，还是不需要大括号。
? 左大括号不换行，还是单独另起一行。
在美剧《硅谷》中，你也许会记得这样一个经典镜头：主人公Richard与同为程序员的女友分手，理由是两人对缩进方式有着不同的习惯，互相拧巴地鄙视着对方的cody style。Tab键和空格键的争议在现实编程工作中确实存在。《阿里巴巴Java开发手册》（以下简称“《手册》”）明确地支持了4个空格的做法，如果一定要问理由，没有理由，因为能够想出来的理由，就像坚固的盾一样，总有更加锋利的矛会戳破它。只想说，一致性很重要，无边无际争论的时间成本与后的收益是成反比的。
? 缩进采用空格键，还是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章 设计中体现艺术家的气质
“一个优秀的工程师和一个普通工程师的区别，不是满天飞的架构图，他的功底体现在所写的每一行代码上。”——毕玄
评论
还没有评论。