我在兰亭这三年之第一个项目

【前言】

在兰亭这段时间里，做了很多项目，前前后后加起来有10几个大版本和项目及很多的hotfix，当然每一个项目中都有收获，都让我得到一点点的积累和沉淀。但是让我记忆犹新的还是第一个项目。

【正文】

入职兰亭时职位是测试工程师，后来听我老大说一般这个岗位的人都需要在别的小公司有带过小团队的经验，或者是从跟兰亭一样或更大规模的公司平移过来的，我属于前者，在创业型公司摸爬滚打了2年。这么要求的原因是这个岗位是在测试团队真正干活的人，需要带人做项目，属于测试团队的中坚力量。

在兰亭做过很多的项目，最印象深刻的莫过于当时我以测试项目负责人名义全职做的两个项目--review改版和MINI首页改版。之后的很多项目我都算是作为前端测试团队的项目负责人来开展的，毕竟并行项目过多，而且都已经指派了项目负责人，我已经没有那么多精力E2E的这么跟过了。

第一次听说No-SQL

以前在创业型公司其实也用过No-SQL的数据库，像Tokyo tyrant，只不过不知道No-SQL这个词。事情的缘由是因为原来存储的网络上抓取的页面文件是放在磁盘上的，在读写时必然会导致磁盘I/O过高，所以后来迁移到TT server上来了。

在兰亭的review改版项目上，使用到了redis，把所有用户的评论及QA都存储到redis，毕竟这些数据不像抓取的网页那么占空间，总共加起来也不超过5G，而且更适合使用in-memory的场景，即加载到内存中可以高效的读取。兰亭其他项目也有使用MongoDB的，关于这三个常用No-SQL的差异大家感兴趣可以查查资料。

项目周期过长

回过头来总结当时的项目，的确有很多改进的地方，按理说这么简单的项目最多一个月搞完是没有问题的，但是前前后后做了2个多月。总结起来最重要的一个原因就是流程不够好，可以总结为以下重要的两点：

1）没有制定测试准入标准，没有督促开发人员进行自测，如果每一次测试前进行smoke，也就不会导致这么长的周期，毕竟同样一个bug经过两拨人来反复验证总会比开发人员自己check耗时的多;

2）测试过程中随意更新代码，这个项目有三个测试人员参与，各自负责不同的部分，经常会因为一个严重的bug fix后要更新代码，但是更新的内容不仅仅包括这部分，还有其他的bug fix，加之第一点的缘故会导致之前测试OK的部分又出现问题，这将引起很多工作的重复。

也许是之前公司很少有多人参与的项目，基本都是一个开发对一个测试，或者几个开发对二个测试，而且每次测试介入前开发都需要开发一个demo版本给老板演示，这必然需要他们最好自测然后才提交给我们测试。所以第一次做多人参与的项目，情况必然不同。后来其他的项目流程被新来的总监进行了优化，做起来就顺了很多。

我做的好的部分和坏的部分

对于我来说这也是第一次有这么多人参与的项目，但是还是被老大表扬了:

1）项目跟踪进行的较好，毕竟每天都有遇到各种问题，我能做的就是每天汇总重要的问题及时跟进让大家处理，包括与需求不符的部分，需求变更后模糊的内容及重要bug；

2）执行力较强，从不拖延。

当然也有做的不够好的地方：

1）既然我是项目负责人，我需要做的不只是我自己负责的部分能让老大觉得靠谱，而且还要让大家的工作都值得信任，也就是要做好每个人工作的指导和跟踪，适当的时候汇总大家的进度及遇到的问题，并发现潜在的风险，的确那个时候对风险的把控能力有待提高；

2）大局观不够，记得这个项目上线之后遗漏一个bug，原因是在业务上与另一个项目相交叉，但是我和另外一个项目负责人都没有意识到这一点。虽然我到目前为止都认为应该是负责整个前端业务的总负责人的失误，但是这次的教训让我更懂得要从一定的高度来看待目前所有的项目，在以后的工作中给了我很大的启发。