回顾一下最近的工作

回顾一下这两个月的工作情况，我做了什么，遇到了什么问题，等等，大概做一个复盘吧。

第一个想法：两个月说长也不长，但是我根本想不起来五月初的我具体在做什么，只记得五月搬了个家。幸好有周报这个东西，他还是有意义的，之前一直是把他作为形式上的东西。

五月上旬到六月下旬我主要是在开发目前系统的通用功能，当前的系统是一个套壳的流程平台：流程引擎是已经现成的。但是目前来说这个项目还是很复杂，这是由于我们目前的情况是客户原来有一个流程平台，大概是2010年开始使用的，到目前超过十年了。用了这么多年的一个系统想要更新换代，这就挺麻烦的，主要麻烦有三个：

​ 第一，多年的旧系统的使用已经让用户形成了使用习惯，客户要求的新系统无时无刻体现着旧系统的影子，旧系统上不管是合理的还是不合理的东西可能就会一股脑的在提需求的时候往新系统上搬，当前我们可以挡掉一部分，但是还是有很多一部分的东西以习惯为由还是需要新系统继续实现，当然这个完全是正常的，客户能依照的参照物只有旧的系统，当前新的系统也需要完全包含旧系统的功能，并在此基础上扩展一些新的特性。

​ 第二，数据迁移的问题，这十年的旧系统运行下来流程业务方面的数据肯定是不能丢的。当前太久远的数据，比如说三年前的数据需要入到数据湖里去，但是三年内的数据还需要迁移到新系统，达到可查到环节的要求。先细说一下，数据迁移。旧系统使用的数据库是Oracle，而新系统使用的是Mysql，并且旧系统的表多且分散（大概四百张），且命名比较随意，很多表的表名基本上就是多前缀+数字，比如说AA_BB_CC024,面对这种数据库，我们首先需要他们问清楚旧系统数据库设计的文档，一边设计新的数据库表，一边还要考虑到设计的新表字段和原数据库表字段的对应关系，还要考虑设计新表时要给现在不用但原数据库有的字段留位置…这样一点一点的全部的弄清楚了，才用Kettle进行数据的迁移。在说一下数据入湖，入湖相对于迁移来说是简单的很多了，我是第一次接触入湖，但我觉得他们这种入湖的方式有些低级？（个人感觉）。他们的入湖的方式大致是这样的：我们首先要安装要求的格式输出由多个数据文件组合成的数据包，每个表的内容就是一个数据文件，在生成一些配置文件的东西，也放到包里，然后就要把数据包放到指定服务器的目录，最后，数据湖人员把包取走，做他们具体的操作。这一套下来有些像民国特务接头的感觉，一旦接受了这个设定….

​ 第三，文档缺失，旧的系统并不是独立的一个系统，它还要跟六个其他系统进行交互，由于各种原因，与旧系统对接的文档，有的内容缺失，有的文档没有更新，版本过老，在这十年中，跟旧系统的对接的接口很多都改过，旧系统中的流程也被各种扩展与修改，然而文档的更新却跟不上，我们浪费了很多时间去找文档，找人确认这些东西，对于我来说，这算是比较痛苦的一件事。

话说回来，我这两个月主要还是做一些通用的功能，由于当前的流程引擎不能完全满足客户的需求，尤其是部分从老系统传承过来的功能，我主要就是做这个事情，满足这些对不齐的部分。其次就是负责整个项目的运维，这段运维就是基础的运维，我自己为了方便也写了一些shell脚本，但是这只是杯水车薪的工作，没有体验过devops的我现在极度想要运维自动化…还有就是做数据迁移及入湖的工作，写新的文档，还有各种杂七杂八为了让流程满足要求运行下去的脚本…这些事繁复且杂乱，也比较烦这类事情。

说是复盘，其实算吐槽了，我不知道项目都是这样，还是我的经历比较奇特，我的项目经理不错，说实话大部分的沟通确认是他在承担，当然这是他的工作职责，也许我应该想想我怎么能让这个项目完成的更顺利一点。