Rec是一个用来验证和转换数据文件的Java应用。从第一行代码到v1版本成形，仅仅经历了一个半月的时间，作为一个开源项目，在很多方面都有着各种各样的纠结。
需求
Rec的需求源自于我们团队所做项目的特殊性：遗留系统迁移。在工作中，我们需要跟各种团队打交道，每天处理各种来自ETL(Extract、Transform、Load)过程中的数据和程序问题，而整个ETL程序运行起来过于笨重，并且还要考虑准备后端数据和各种验证问题，非常不方便。
其实在此之前，只要有一些简单的程序跑起来、能够进行一些简单的检查，比如唯一性(uniqueness)、关联关系等等，就可以在很大程度上减少我们在ETL过程中花费的时间。并且，这半年多来的实践也证实了这一点。
最初，同事的建议是写一个脚本文件来解决这个问题，这对于程序员来说当然不是什么大问题。但随着使用次数的增加，我渐渐发现一套Python脚本并不能胜任：一方面，面对复杂的业务场景，很难有一套灵活的模式去匹配所有的数据格式;另一方面，随着数据量的增长，性能也成了一个大问题。
于是我开始着手设计和实现Rec。
设计
Rec第一个可用版本的设计共花了七天的时间，基本上具备了我期望的各种能力：
- 可以自定义数据格式
- 能够进行简单的唯一性和关联关系验证
- 支持一些扩展的查询语法：比如，可以验证多字段组合的唯一性
- 性能上基本能够胜任
Rec面向的数据文件格式是类CSV的文件，包括其他的一些使用分号(;)或者竖线(|)来做分隔符的文件。出于习惯，文件的Parser并没有选取现成的库，而是我自己按照Wikipedia和RFC4180的规范写出来的，基本上能够解析所有类似的文件。而且还有一个意外的发现：用空格做分隔符的文件(比如，某些日志)也是可以支持的。
对于每一条数据，Rec提供了两部分组件，一部分是数据本身，另一部分是该数据的访问器(accessor)。访问器提供把字段名转换成对应数据项下标的功能：跟Spring Batch中的FieldSetMapper很像，当然在其之上还多了一层语法糖。
一个典型的accessor format如下：
- first name, last name, {5}, phone, …, job title,{3}
其中，“…”表示中间的字段全部可以忽略，{3}和{5}是占位符，表示在这些字段之间有如此多个字段也是可以忽略的。而由“…”分割成的两部分也是有差异的：在其后的字段使用的是类似Python的负数下标;换句话说，我并不需要知道本来的数据有多少个字段，只需要知道我要获取的倒数第几个是什么就可以了。
Rec的验证规则也是从简设计。由于最初的需求只有唯一性检查和关联关系检查，所以第一个版本里面就只加入了这两个功能，语法如下：
- unique: Customer[id]
- unique: Order[cust_id, prod_id]
- exist: Order.prod_id, Product.id
每一行表示一个规则，冒号前面是规则的名字，后面是规则所需要验证的数据查询表达式。对于查询表达式，这里需要提一点，本来是设计了更多的功能，比如过滤和组合等等，在后面扩展的时候发现在语法上很难实现得更直观而且方便使用，于是就决定改用嵌入脚本引擎的方式来解决。
另外Rec第一个版本发布只有Kotlin运行时的依赖，所以完整的Jar文件只有2MB。同时，只要给对应的数据文件提供.rec格式的描述文件，再在同一目录创建一个default.rule来加入各种检验规则，就可以运行、然后得到你想要的结果了。
扩展
Rec的第一个版本在某些方面是达到预期结果了的。但在那之后就发现了一些很重要的问题：首先，我们另一层的需求并没有得到满足：Rec能够帮我们验证并且找到有问题的数据，但是不能够按需来选择我们想要的内容;其次，在检查数据的同时，我们也隐含地有集成和转换数据的需求，Rec也不能够满足。
于是第一个星期以后我开始考虑对Rec进行扩展。首先是在同事的建议下把乱成一坨的代码分成多个module;其次考虑加入前面提到的过滤和格式转换的功能。
第一个步骤勉强算是完成了，但是卡在了第二步上：对于转换的规则，要不要和验证的规则放在一起?如何对这两种规则做区分?如何在过滤器中设计变量引用等细节?每一个问题都让我纠结了很多，直到最后决定放弃这一步，直接通过引入脚本引擎来实现：从最初hack Kotlin编译器的嵌入版，到决定用JavaScript，到放弃Nashorn转而用Rhino，中间虽然辗转几次又遭遇了不少坑，但毕竟有成熟的社区经验辅以指导，还是顺利地走了下来。
Test Driven Development vs Test Driven Design
其实直到现在Rec的测试也只有少量的一些。而且在拆分模块的时候，因为测试代码之间的依赖比较多，并没有做拆分，所以基本上还是集中在一个模块中。当然这也是很多时候我自己做项目时的一个习惯：并不会完全以TDD的方式来开发，而是把单元测试作为一个验证设计思路的手段。因为很多时候思路转变的太突然，不实现的话估计下一秒钟就完全变了。而且，作为一个简单的工具类程序，并不需要重度面向对象的设计，如何规划和设计流畅易用的接口就成了必须考虑的一个问题。这个时候测试的设计性变得更明显。
另外，对于Parser这种东西，测试是必不可少的，但是要TDD一个Parser出来，基本上就是在给自己找活干了。所以这种时候，我会先加一些基本的case，来确保能够正常的实现功能，然后再引入一些比较corner的case来确保实际的可用性。对我来说，这是完全没有问题的：当然后面的实践验证了这一点，Rec没在解析文件方面出现过任何问题。
Kotlin vs Java(Script)
最初采用Kotlin就是因为它有很多优点，而且这些优点也确实影响了Rec的设计，但是因为各种原因，还是被替换了两次。首先迟迟不发布的1.1版本和编码兼容性的诸多问题，导致我决定用原生Java换掉Kotlin。当然，这也导致了不得不强行舍弃很多好用的编译期检查和语法糖，以及一个用来做bean mapping的组件。
至于采用JavaScript，则是另外一个问题。
众所周知，JSR223定义了一套JVM平台的脚本引擎规范，但是作为一个强静态类型的编译型语言，Kotlin想要契合这套规范还是很困难的，于是无论是官方的实现还是Rec的解决方法，都不是很好：
首先你要启动一个JVM来执行这个脚本的动作;在这个动作里面，启动第二个JVM要调用Kotlin的编译器来将该脚本编译成class;然后这个编译器会再去利用自定义的classloader来加载和执行这个class文件。当所有的功能都集中在一个Jar文件里面的时候，每次都要选择指定classpath等选项，实现非常复杂。而且，由于第二次执行的Kotlin编译器是识别不到你已引入的kotlin-reflect类库的(因为已经统一包装到rec的jar包里面去了)，就会导致脚本中bean mapper的一些功能根本不能使用。万般无奈，选择采用更成熟的JS引擎。
当然选择JS带来的一个好处就是，有更多人可以拿来就用了，而且，最新的Rhino提供了CommonJS扩展，能够顺手require所需的JS文件，在复用和模块化方面也能够有不少提升。
技术抉择
除了部分Parser相关的代码外，Rec采用的基本都是不可变的数据结构：一方面是因为使用Kotlin;另一方面，在整个模型里面并没有特别的需求会涉及更改数据。
唯一的担心是内存占用，但是后来发现这部分担心也是不必要的，因为所有内存的瓶颈只在数据文件的Parser上，项目中的数据条目动辄数十个数据项，几十万条数据，再加上每次parse都会把一个字符串分割成多个，最后再合并到一个大的集合里面，在最开始设计的时候没有考虑这一点，轻轻松松就爆了JVM堆。这也是后期需要着重优化的一个方面。
另外一个点是关于异常处理。对于Java应用来说这是个巨坑：异常本身并没有问题，但是由于checked和unchecked的区分以及众多设计哲学的不同，所以就成了争议点所在。在这里我参考了Joe Duffy的做法。对于严重的不可重试的错误，比如文件找不到，空指针异常，下标错误等，直接让程序die(没错，就是PHP中的那个die)，至于数据格式错误等问题，更多的做法是做一条记录然后选择继续。当然这一套东西并不依赖Java的异常系统，只是作为一个设计原则来应用，毕竟这不是一个App server，并不需要高可用的保障，相反这种fail fast的直接反馈更有助于发现和解决问题。
在类型系统上，最初实现Rec的语言是Kotlin，它提供了一套比Java略微高级一些的类型系统。当然主要的点还是在于nullable：在功能上，nullable与Java 8的Optional类似，用来容纳可以为空的值，同时能够有效避免空指针异常;在实现上，比Java略微高出了一点的是，非nullable的对象必须被初始化并且不容许为null。这直接解决了Optional对象为空的尴尬问题。
当然，由于运行时的依赖还是无法避免地使用JVM，而且没有自定义值类型的支持，在使用Kotlin，特别是跟Java标准库和其他框架结合使用的时候，还是会遇到空指针的坑。但是在这一点上，Kotlin给我们开了个好头，比如在后面convert到Java的过程中，我也尽量保证各种对象都是final并且被非空初始化了的。
结语
当然也许很多人会说，Unix那套工具用的很顺手的话，上面说的这些都不是问题，其实Rec本来的思路也是来自于它们：accessor来自于awk的列操作模式，scripting中的过滤器来自于sed和grep，链式调用源于管道。Rec也只是在这些思路之上加了一些方便的操作而已。但是对于我个人来说，这种折腾其实是在检验我自己的理论和思考，更别说还提升了项目的生产力。也许哪一天实在受不了了，还可以拿C++和Lua重写了呢。毕竟，生命不息，折腾不止。
【本文是51CTO专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】
