最近利用闲暇时间从图书馆借了两三本书来“充电”，因为如果不及时摄取新的营养，感觉会越来越难有新的想法输出出来，尤其是像 ServerLess、组件化、分布式等等这样的场景慢慢开始接触，就势必无法再用从前的眼光去看待。大概去年的时候，阿里巴巴发布了「阿里巴巴开发手册」这本小册子，大概不到 100 页的样子，这次我就挑选了我觉得还不错的关键点，和大家简单分享一下，所以，这是一篇“典型”的读书笔记，下面的编号代表的是指定章节下的第几条规范，例如，1.1.2 表示的是第一章第一节中的第二条规范，欢迎大家一起讨论。

编程规范

1.1.2 代码中的命名严禁使用拼音与英文混合的方式，不允许直接使用中文的方式，纯拼音命名方式更要避免采用。

说明：英文不好可以去查，禁止使用纯拼音或者拼音缩写的命名方式，除了不能“望文生义”以外，对导致别人在调用接口的时候，向这种“丧心病狂”的编码风格妥协，这里不点名批评某 SAP 提供的 OA 接口，除了超级难用以外，每次都要花大量时间去对字段。

1.4.3 相同参数类型，相同业务含义，才可以使用 Java 的可变参数，避免使用 Object，可变参数必须放置在参数列表最后。

说明：例如一个接口同时支持单条更新或者批量更新，此时，完全就可以使用 param 关键字来声明相同的参数类型，而无须定义 InsertOne 和 InsertMany 两个方法。

1.4.4 对外部正在使用或者二方库依赖的接口，不允许修改方法签名，以避免对接口调用方产生影响。若接口过时，必须加@Deprecated 注解，并清晰地说明采用的新接口或者新服务是什么。

说明：对于过期的接口可以通过 Obsolete 特性来声明过期，这样在编译时期间可以告知使用者该接口已过期。对于 WebAPI 接口，除非有版本控制机制，否则一律不允许修改已上线的接口签名、参数和返回值。

1.4.17 在循环体内，字符串的连接方式使用 StringBuilder 的 append 方法进行扩展。

说明：这一点，在 C#中同样适用，因为字符串类型是 Immutable 的，对字符串进行拼接会产生大量的临时对象。

1.5.7 不要在 foreach 循环内进行元素的 remove/add 操作。remove 元素请使用 Iterator 方式，如果并发操作，需要对 Iterator 对象加锁。

说明：因为 foreach 是基于迭代器(IEnumerator)的，在 foreach 循环内部修改集合，会导致 Current 和 MoveNext()发生混乱，早期的集合使用 SynRoot 来解决线程安全(内部原理是使用了 Interlocked 锁)，现在我们使用 CurrentBag 等线程安全的集合。

1.6.1 获取单例对象需要保证线程安全，其中的方法同样要保证线程安全。

说明：只要类型中有静态成员存在，就要考虑线程安全，因为静态成员隶属于类型而非类型的实例。

1.6.5 SimpleDataFormat 是线程不安全的类，一般不要定义为 static 变量，如果定义为 static，必须加锁，或者使用 DateUntils 工具类。

说明：无论所声明的静态成员是否线程安全，都应该考虑到在竞态条件下，可能会出现多个线程同时修改静态成员的风险，此时最好对其进行加锁。

1.6.8 在并发修改同一条记录时，为避免更新丢失，需要加锁。要么在应用层加锁，要么在缓存层加锁，要么在数据库层使用乐观锁，使用 version 作为更新依据。

说明：所谓“悲观锁”，是指认为数据一定会被篡改，此时，在一个作用域结束前对其进行加锁，典型的如 lock 关键字。而所谓“乐观锁”，是认为数据不一定会被篡改，此时，通过一个 version 来作为更新的依据。

1.6.12 在并发场景下，通过双重检查锁(double-checkedlocking)实现延迟初始化的优化问题隐患，推荐解决方案中较为简单的一种(JDK5 及以上版本)，即目标属性声明为 volatile 型。

1.7.4 在表达异常的分支时，尽量少用 if-else 方式。如果不得不使用 if……elseif…else 方式，请勿超过 3 层。

说明：当条件不满足时可以直接 return，或者先判断不满足的条件，则剩余逻辑默认就是满足条件的分支，尽量避免使用 if……elseif……else 方式，同时保证分支里的代码足够简单，复杂的逻辑应考虑封装或者用 switch……case 甚至多态来重构。

1.7.8 循环体的语句要考量性能，以下操作请尽量移至循环体外处理，如定义对象或变量、获取数据库连接，避免进行不必要的 try……catch 操作。

说明：抛出一个异常是非常简单的，然而捕获一个异常需要付出一定的性能代价，因为它需要捕捉程序异常时的上下文信息，建议在进入循环内部合理检验，覆盖到每一种考虑到的情况，考虑不到的请让它向上抛出。

2.1.2 对大段代码进行 try-catch，使得程序无法根据不同的异常做出正确的应激反应，不利于定位问题，这是一种不负责任的表现。

说明：对大段代码进行 try-catch，或许可以保证应用程序不崩溃，但在程序异常的一瞬间，可能业务数据已经出错，此时再让程序继续运行下去，不仅无法快速定位出错原因，而且会对下一流程的业务产生“污染”。

异常日志

2.1.2 捕捉异常是为了处理它，不要捕捉了却什么都不处理而抛弃之，如果不想处理它，请将该异常抛给它的调用者，然后由调用者在最外层业务中处理异常，并将其转化为用户可以理解的内容。

说明：捕捉了异常一定要去处理它，如果单单是为了记录个错误日志，完全可以通过 AOP 来记录，底层抛出的异常不允许被“吞掉”，必须将其抛给它的调用者，异常最终需要转化为友好的界面提示。

2.2.5 finally 块必须对资源对象、流对象进行关闭操作，如果有异常同样要做 try-catch 操作(JDK7 及以上版本可以使用 try-with-resource 方式)

说明：因为 finally 块一定会在 return 前执行，所以，无论程序是否发生了异常，我们都可以在 finally 块中对资源对象、流对象、数据库连接等进行关闭或者释放，using 其实是 try……finally 的语法糖，它会自动地在 finally 块里调用 Dispose 方法(因为它要实现 IDispose 接口)。

2.2.7 不能在 finally 块中使用 return。

说明：这里涉及到一个 return 和 finally，尽管 return 可以提前“跳出”，但对 finally 来说，不管是否发生异常，它都会执行，在此之前 return 会把返回值写入内存，等 finally 块执行结束后，return 再“跳出”。C#中 finally 块中不允许写 return，否则会导致编译错误。通常，finally 块用来做清理相关的工作。

数据库

5.1.1 表达是否的概念时，必须使用 is_xxx 的命名方式，数据类型是 unsigned tinyint。其中，1 表示是，0 表示否。

说明：表达是否最好用 0 和 1 来表示，我们用 Y 和 N 时经常会出现，开发人员忘记给模型赋值，导致进入到数据库里的数据出现错误数据，而领域模型里又不建议给字段默认值，可如果使用 unsigned tinyint 类型，它本身就自带默认值 0，这样就可以避免这种问题的出现。

5.1.2 表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下画线中间只出现数字。

说明：建议全部使用小写，因为主流 SQL 教程的里关键字都采用大写，但在 PLSQL/SQLyog 里编写 SQL 语句时，字段会自动地变成小写，而且不区分大小写，为了避免人格分裂，建议所有字段都用小写。我们表名用小写，表字段用大写，输出的 SQL 语句看起来特别奇怪。

5.1.13 字段允许适当冗余，以提高查询性能，但必须考虑数据一致。冗余字段应遵循：

• 不是频繁修改的字段
• 不是 varchar 超长字段，更不能是 text 字段。

说明：冗余字段是个好东西，但主表和扩展表间的一致性保证需要经过良好的设计，那种把相关表都放在一个事务里处理的做法，都声称是为了保证数据的一致性，可实际过程中依然会存在数据不一致的情况。

5.1.15 当单表行数超过 500 万行活着单表容量超过 2G 时，才推荐进行分库分表。

说明：多租户架构下，不同租户采用不同的库，是最简单的数据隔离方案，但缺点是增加了维护多个库的成本。如果要分库分表，最好从框架层面来“切库”，而不要让开发人员自行维护数据库的连接字符串。

5.2.1 业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。根据墨菲定律，只要没有唯一索引，必然会有脏数据产生，即使在应用层做了非常完善的检验控制。

5.2.2 超过三个表禁止 join，需要 join 的字段，类型必须绝对一致；当多表关联查询时，保证被关联的字段需要有索引。

说明：关系型数据库最值得炫耀的地方就是表多，超过三张表禁止 join，实际中根本不现实，所以，建议以业务场景为准，我就曾经 join 了 5 张表，大概客户就喜欢看这些东西吧！

5.3.7 禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。

说明：存储过程和触发器是万恶之源，不同数据库下的 SQL 语句千姿百态，同样的业务逻辑，Oracle、MySQL 和 SQLServer 基本上是三种语法，更不用说$$、/和@这种奇葩的东西了，查询语言就老老实实写查询，写业务了逻辑，SQL 真的不行，太垃圾，虽然做权限划分非常容易……

5.3.9 in 操作能避免则避免，如实在避免不了，需要仔细评估 in 后面的集合元素数量，最好控制在 1000 之内。

说明：这一点表示认同，我们经常遇到这样的情况，先筛选出 A 表符合条件的所有记录，然后根据 A 表中某一列(通常是外键)，通过 IN 操作来筛选出 B 表中符合条件的所有记录，这个时候，应该注意控制 IN 后面集合内元素的数目，总之不要太大……