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如下：

其中，“…”表示中间的字段全部可以忽略，{3}和{5}是占位符，表示在这些字段之间有如此多个字段也是可以忽略的。而由“…”分割成的两部分也是有差异的：在其后的字段使用的是类似Python的负数下标；换句话说，我并不需要知道本来的数据有多少个字段，只需要知道我要获取的倒数第几个是什么就可以了。

Rec的验证规则也是从简设计。由于最初的需求只有唯一性检查和关联关系检查，所以第一个版本里面就只加入了这两个功能，语法如下：

每一行表示一个规则，冒号前面是规则的名字，后面是规则所需要验证的数据查询表达式。对于查询表达式，这里需要提一点，本来是设计了更多的功能，比如过滤和组合等等，在后面扩展的时候发现在语法上很难实现得更直观而且方便使用，于是就决定改用嵌入脚本引擎的方式来解决。 另外Rec第一个版本发布只有Kotlin运行时的依赖，所以完整的Jar文件只有2MB。同时，只要给对应的数据文件提供.rec格式的描述文件，再在同一目录创建一个default.rule来加入各种检验规则，就可以运行、然后得到你想要的结果了。

Rec的第一个版本在某些方面是达到预期结果了的。但在那之后就发现了一些很重要的问题：首先，我们另一层的需求并没有得到满足：Rec能够帮我们验证并且找到有问题的数据，但是不能够按需来选择我们想要的内容；其次，在检查数据的同时，我们也隐含地有集成和转换数据的需求，Rec也不能够满足。 于是第一个星期以后我开始考虑对Rec进行扩展。首先是在同事的建议下把乱成一坨的代码分成多个module；其次考虑加入前面提到的过滤和格式转换的功能。

第一个步骤勉强算是完成了，但是卡在了第二步上：对于转换的规则，要不要和验证的规则放在一起？如何对这两种规则做区分？如何在过滤器中设计变量引用等细节？每一个问题都让我纠结了很多，直到最后决定放弃这一步，直接通过引入脚本引擎来实现：从最初hack Kotlin编译器的嵌入版，到决定用Java，到放弃Nashorn转而用Rhino，中间虽然辗转几次又遭遇了不少坑，但毕竟有成熟的社区经验辅以指导，还是顺利地走了下来。