今天写了一个清洗数据的脚本，将感悟整理一下
清洗数据模块要与业务模块分开加载
清洗数据脚本需要在生产上跑，功能写完之后，想了一下应该为是否加载清洗数据模块加个配置参数，比如在生产上不应该加载（节省资源也更安全，如果做不到最好确保脚本是幂等的），而在和正式环境对等的影子库（使用使用相同的数据源）上加载，为了避免与生产数据操作冲突，可以在公共配置上加标记锁，这样在无法线性处理数据时会起到保护作用（但根据锁的实现，会对生产系统的体验造成一定影响），另外清洗系统需要在处理完成之后去除锁，不过让清洗系统做这件事有些风险（清洗系统挂掉了，就没有有机会去除锁了），为避免风险解决方式也很简单，设置手动命令去除锁，或者将清洗系统的状态汇报给监控系统，配置监控逻辑，达到条件（比如一定时间监控不到清洗进城）就解锁。
清洗数据逻辑需要自动测试来保障
另外就是测试，前几天看到有人说自动测试到底有没有用，我发表了自己的意见，在数据清洗任务中我觉得最好有（当然端自动测试好写些），因为人工测试 1 很难覆盖所有情况; 2 构建测试环境很麻烦，可能给执行人员留下短路机会。
由于需要在生产上直接运行，风险很高，加上后期可能调整业务逻辑（生产上运行前常有的事），有自动测试会更安全和轻松。当然没有完美的事情，写测试脚本和因需求变化调整很麻烦，不过至少可以将验证工作交给一般程序员或者测试人员来处理，这也算是个折中方案吧。
如何写出更易测试的程序
对于什么样的代码更方便测试，我的建议是，要对代码逻辑不断拆分到方便逐个测试为止，这与实现功能过程有些相反，实现功能一般都是自上而下的，而方便测试需要自下而上，所以先按一般思维实现，即自上而下，过程中或重构时不断的将功能细分，举个简单例子（非最恰当），处理数据需要循环，在循环里有各种加工逻辑，这是可以将每个加工逻辑拆分成子功能，子功能参数是父功能循环中的一个实体，以此类推，做出来的子功能就方便测试了。
最好将获取数据和处理数据过程分开
最后数据处理需要注意 就是尽量避免慢速操作，就是将数据先拿到（是否全部得看具体数据和机器情况），然后进行计算密集型操作，这个也与常识，我们习惯拿一条处理一条。当然集中处理也有弊端，比如需要自行处理主外键，要做数据缓存等等，这就又回到了前面关于测试的描述，有自动测试能好很多，可以说有了测试做保障我们就能玩更花的活儿。