编程规约
本段讲的是传统意义上的代码规范,包括变量命名、代码风格.控制语句、代码注释等基本的编程习惯,以及从高并发场景中提炼出来的集合处理技巧与并发多线程的注意事项。
1.1 命名风格
➊[ 强制]代码中的命名均不能以下画线或美元符号开始，也不能以下画线或美元符号结束。
反例:_ name /__name /$name / name_ / nameS / name .
❷[ 强制]代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。
说明:正确的英文拼写和语法可以让阅读者易于理解，避免歧义。注意，即使是纯拼音命名方式也要避免采用。
正例: alibaba / taobao / youku / hangzhou 等国际通用的名称，可视同英文。
反例: DaZhePromotion [打折] / getPingFenByName ()[评分] / int某变量= 3
❸[ 强制]类名使用UpperCamelCase风格，但DO/BO/ DTO/VO/AO/PO等情形例外。
正例: MarcoPolo / UserDO / XmlService / TcpUdpDeal/ TaPromotion / QrCode
反例: macroPolo / UserDo / XMLService / TCPUDPDeal/ TAPromotion / QRCode
❹[强制] 方法名、参数名、成员变量、局部变量都统- - 使用lowerCamelCase风格，必须遵从驼峰形式。
正例: 1ocalValue / getHttpMessage() / inputUserId
❺[强制] 常量命名全部大写，单词间用下画线隔开，力求语义表达完整清楚，不要嫌名字长。
正例: MAX_ STOCK_ COUNT/PRIZE_ NUMBER_ EVERYDAY
反例: MAX_ COUNT/ PRIZE_ NUMBER
❻) [强制]抽象类命名使用Abstract或Base开头;异常类命名使用Exception结尾;测试类命名以它要测试的类名开始，以Test结尾。
❼[强制]类型与中括号之间无空格相连定义数组。
正例:定义整形数组int[] arrayDemo;
反例:在main参数中，使用String args[]来定义。
❽[强制] POJO类中布尔类型的变量都不要加is前缀，否则部分框架解析会引起序列化错误。
反例:定义为基本数据类型Boolean isDeleted; 的属性，它的方法名称也是isDeleted(), RPC 框架在反向解析的时候，“误以为" 对应的属性名称是deleted,导致属性获取不到抛出异常。
后续的书里为大家讲。。。。。
1.2 常量定义
➊[ 强制]不允许任何魔法值(即未经预先定义的常量)直接出现在代码中。
反例: String key = "Id#taobao_ ”+ tradeId;cache.put (key, value) ;
❷[ 强制] long或者Long初始赋值时，使用大写的L，不能是小写的1。小写1容易跟数字1混淆，造成误解。
说明: Long a = 21;写的是数字的21，还是Long型的2?
❸[推荐] 不要使用一个常量类维护所有常量，要按常量功能进行归类，分开维护。
说明:大而全的常量类，非得使用查找功能才能定位到修改的常量，不利于理解和维护。
正例:缓存相关常量放在类CacheConsts下;系统配置相关常量放在类ConfigConsts下。
❹[推荐] 常量的复用层次有5层:跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常量、类内共享常量。
1)跨应用共享常量:放置在二方库中，通常是在client.jar中的constant目录下。
2)应用内共享常量:放置在一方库中，通常是在子模块中
异常日志
异常处理是大部分程序员积攒多年的痛点，本章主要涉及如何定义、捕获、处理异常事件，如何以合理的8志结构保存出错现场信息，以便快速定位问题。
2.1异常处理，
➊[强制]Java类库中定义的可以通过预检查方式规避的Runt imeException不应该通过catch的方式来处理,如:IndexOutOfBoundsException, NullPointerException等。
说明:无法通过预检查的异常不在此列，比如，在解析字符串形式的数字时，可能存在数字格式错误，不得不通过catch NumberFormatException 来实现。
正例: if (obj != null) {...}
反例: try { obj .method() } catch (NullPointerExceptione) {...}
❷[强制] 异常不要用来做流程控制、条件控制。
说明:异常设计的初衷是解决程序运行中的各种意外情况，况且异常的处理效率比条件判断方式要低很多。
❸[强制] catch时请分清稳定代码和非稳定代码。稳定代码指的是无论如何都不会出错的代码。对于非稳定代码的catch,尽可能在进行异常类型的区分后，再做对应的异常处理。
说明:对大段代码进行try-catch,将使程序无法根据不同的异常做出正确的应激反应，也不利于定位问题。这是一种不负责任的表现。
正例:在用户注册的场景中，如果用户输入非法字符，或用户名称已存在，或用户输入的密码过于简单，在程序上会作出分门别类的判断，并提示用户。
❹[强制]捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之，如果不想处理它，请将该异常抛给它的调用者。
最外层的业务使用者必须处理异常，将其转化为用户可以理解的内容。.
❺[强制]有try块放到了事务代码中，catch异常后，如果需要回滚事务，一定要注意rollback事务。
❻[强制] finally块必须对资源对象、流对象进行关闭操作，如果有异常也要做try-catch操作。
说明:对于JDK7及以上版本，可以使用try-with-resources方式。
❼[ 强制]不能在finally块中使用return。
说明:当finally块中的return返回后方法结束执行，不会再执行try块中的return语句。
单元测试
什么是好的单元测试标准?如何写好单元测试?本章首次提出AIR原则和BCDE原则来进行相应的衡量。
➊[强制] 好的单元测试必须遵守AIR原则。
说明:单元测试在线上运行时，感觉像空气(AIR)一样并不存在，但在测试质量的保障方面，它却是非常关键的。
从宏观上来说，好的单元测试具有自动化、独立性、可重复执行的特点。
1) A: Automatic (自动化)。
2) I: Independent (独立性)。
3) R: Repeatable (可重复)。
6 ? [ 强制]单元测试应该是全自动执行的，并且是非交互式的。
测试用例通常是被定期执行的，执行过程必须完全自动化才有意义。需要人工检查输出结果的测试不是一个好的单元测试。单元测试中不准使用System. out进行人肉验证,必须使用assert验证。
❸[强制] 保持单元测试的独立性。为了保证单元测试稳定可靠且便于维护，单元测试用例之间绝不能互相调用，也不能依赖执行的先后次序。
反例: method2需要依赖method1的执行，将执行结果作为method2的输入。
安全规约
“安全生产，责任重于泰山。"这句话同样适用于软件生产，本章主要说明编程中需要注意的比较基础的安全准则。
➊[强制] 隶属于用户个人的页面或者功能必须进行权限控制校验。
说明:防止没有做水平权限校验就可随意访问、修改、删除别人的数据,比如查看他人的私信内容、修改他人的订单。
❷[强制]用户敏感数据禁止直接展示，必须对展示数据进行脱敏。
说明:个人手机号码会显示为158****9119,隐藏中间4位，防止个人隐私泄露。
❸[强制]用户输入的SQL参数严格使用参数绑定或者METADATA字段值限定，防止SQL注入，禁止字符串拼接SQL访问数据库。
❹[强制]用户请求传入的任何参数必须做有效性验证。
说明:忽略参数校验可能导致如下情况。
1) page size 过大导致内存溢出。
2)恶意order by导致数据库慢查询。
3)任意重定向。
4) SQL注入。
5)反序列化注入。
6 )正则输入源串拒绝服务ReDoS。
Java代码用正则来验证客户端的输入，有些正则写法验证普通用户输入没有问题，但是如果攻击人员使用的是特殊构造的字符串来验证，则有可能导致死循环。
MySQL数据库
底层数据库的规范有助于减少软件实现的复杂度，降低沟通成本，本章主要说明建表规范、索引优化准则以及ORM层的处理约定。
5.1建表规约
➊[强制] 表达是与否概念的字段，必须使用is_ xx的方式命名，数据类型是unsigned tinyint (1表示是，0表示否)。
说明:任何字段如果为非负数，则必须是unsigned。
正例:表达逻辑删除的字段名is_ _deleted, 1表示删除，0表示未删除。
❷[强制] 表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下画线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。
说明: MySQL在Windows下不区分大小写，但在Linux下默认区分大小写。因此，数据库名、表名、字段名都不允许出现任何大写字母，避免节外生枝。
正例: aliyun_ admin, rdc_ config, 1evel3_ name 。
反例: AliyunAdmin, rdcConfig, level_ 3_ name。
工程结构
应用分层的百花齐放，导致对于分层与领域模型的理解多样化,非常不利于团队合作。本章主要说明应用工程分层思想、二方库约定及基本的服务器知识。
设计规约
诚如序言所讲，程序员是天生的艺术家，软件设计能力就是考验“艺术家"成色的试金石。本章主要说明软件设计过程中UML设计准则以及基本的架构理念。
专有名词
1. POJO (Plain Ordinary Java object) :在本手册中，POJO专指只有setter / getter / toString 的简单
类，包括DO/DTO/BO/VO等。
2. GAV (GroupId、 ArtifactctId. Version) : Maven坐标，用来唯一标识jar 包。
3.0OP (Object oriented Programming) :本手册泛指类、对象的基本编程处理方式。
4. ORM (object Relation Mapping) :对象关系映射，对象领域模型与底层数据之间的转换，本文泛指iBATIS、mybatis等框架。
5，NPE (java. lang . Nul1PointerException) :即空指针异常。
6. SOA (Service-Oriented Architecture) :面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用，有利于提升组件可重用性和可维护性。
7. -方库:本工程内部子项目模块依赖的库(jar包)。
8.二方库:公司内部发布到中央仓库，可供公司内部其他应用依赖的库(jar 包)。
9.三方库:公司之外的开源库(jar包)。
10. IDE ( Integrated Development Envi ronment) :用于提供程序开发环境的应用程序，一般包括代码编辑器、编译器、调试器和图形用户界面等工具,本手册泛指IntelliJIDEA和Eclipse。:
今天就把这本阿里巴巴Java开发手册p df送到大家手上，希望大家能够喜欢！
小编没有太多的华丽辞藻来修饰，只有拿出最真诚的东西奉献给大家！
大家只需要转发关注小编，请加扣扣裙：943064644 获取