项目踩坑及成长

4月1号那天，我领导给我安排了一个任务，让我负责一个小系统，带北京的两个同事，还有上海这边的一个前端。讲实话，我又兴奋又觉得有压力。在这三个星期当中，我觉得我从这个项目里成长的不仅仅是技术、还有对整个项目的把控、项目的进度计划、部署都得到完整的体验性成长，当然有成长，就会有很多麻烦的事情，不过我觉得作为一个技术人员来说，解决问题的办法总是会比遇到的问题多！

4月1号开始，领导只是给我说，就按照（第三方系统）写一个中间系统，给公司的一个平台使用，为什么要这么做，是因为第三方系统不提供页面，只提供接口。于是，我参照第三方系统给出的接口文档，开始思考，我能做些什么。由于这个系统没有产品，于是我就成了这个系统最上级的人，这个系统怎么做，页面怎么画都是我说了算。我花了1天的时间去查看第三方系统的接口文档和我们公司平台的文档，确定了我这个系统将要完成的事情。我排了一个项目进度表，包括分配给个人的工时。（插一句：我真的是年轻，没有考虑到很多的细节，还有人员技术水平的把控，导致最终完成时间推迟了一个星期。）

当我的计划表出来后，所有的表设计都是我来做的，大概花了1天的时间。于是我给北京的同事分配了每天应该做的事情。（这里有个坑：由于我从来没有真正担任过一个项目的负责人，导致我没有提前去了解北京同事的技术水平，于是后来就有了坑。）

坑1：

由于第三方系统给的接口有一部分是静态数据，所以我们会写成定时任务定期更新数据库的静态数据。这里遇到了一个问题，有一个静态数据文件非常大，700m。如果只是单纯的读取文件，导入数据库，得花个把小时，于是我用mysql的load file语句将这个文件以字段格式区分导入数据库。这里解决的是第一个难点（大文件如何读取到数据库），第二个难点是，这个静态数据，第三方系统建议是一个星期更新一次，那么我怎么更新呢？如果我只是往同一张表更新数据，可是没有主键，数据无法识别是哪一条数据是更新，哪一条数据是插入，更别说这种方式，会导致请求挤压，最后系统崩溃（因为700m的文件增量更新或者全量更新，会让jvm内存溢出的。于是这种方式就pass了），我又想了一个办法，我新建了一个复制表，load file到复制表中，但因为没有主键，也无法更新。后来跟我领导讨论了一下，采用方案如下：每周一的凌晨1点跑一个定时任务，这个任务先会新建一张表，表名是静态数据表+日期，然后将数据load file进新建表，数据导入完成后，去config表里插一条数据，表明现在可用的表是新建的这张表，然后往redis缓存中存一下新建表的表名，整个系统中所有用到静态数据表的sql获取表名都从redis缓存中取最新的。

坑2：

由于我没有提前对北京的同事申明该系统采用什么风格、以及使用什么代码规范约束、没有给他们写例子代码、也没有提前向领导询问技术水平，后来跟前端联调的时候，接口老是报错，我就去看了一下他们写的接口，后来一边看一边改，确实很痛苦，让我有一种，还不如我一个人做的感觉。当时就已经预感这个系统可能要延期了。后来有一天晚上我实在是心态爆炸，跟我领导提了一下这个事情，我领导说：这个系统我交给你了，不管你下面的人做的多么不好，这些问题都是你的问题，你为什么不提前说明、为什么不提前做codeview。嗯，那天聊完之后，感觉自己心态好了很多，的确有些事情是我做的还不够好，所以才导致这些问题的存在。

坑3：

公司运维不给北京同事开设外网映射ip和端口，导致很多事情只能我来做，于是我经常加班，北京同事到点就走。

成长：

这一次做系统的时候，我经常想的问题是：这个系统还有什么问题，反复的去串联流程。而以前我考虑的问题是：这个功能是不是做完了，是不是没有bug了。你可以看到我现在想事情就升高了一个级别。在这个过程中，我每天花了70%的时间开发、指导北京同事开发、测试、联调，剩下30%的时间我一直都在想，这个系统上线有什么问题，目前存在什么问题，到当前时间截至，系统的完成度是一个怎样的情况。我从一个只站在思考功能如何完成的层面上提升到思考整个系统如何正常运转的层面，我觉得这是我这一次最大的成长。还有就是，对带人带项目这个方面来说，如果下一次还有这样的机会，我觉得我会表现得比现在更好。

总结：

多经历才会成长的更快！