最近利用闲暇时间从图书馆借了两三本书来“充电”,因为如果不及时摄取新的营养,感觉会越来越难有新的想法输出出来,尤其是像 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 后面集合内元素的数目,总之不要太大……