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