都说互联网行业加班很是厉害，记得前不久网上还晒出了几个大城市互联网行业的加班排名调查，但是我们公司，或者说我们项目组倒是非常的例外，进公司也差不多半年了，才仅仅上个月有一个周六加过一天班而已。

不过好在，虽然不加班，但是事情还是有的，每个月基本上都有任务，一周需求，一周开发，一周联调，然后再一周测试，可能细节上不完全这样，但大体上也就这样吧。因而虽然不怎么加班，倒也不至于说是什么事都没有。

介于这样的安排，上上个月完成了我的第一次正式项目，也就是我们项目的迭代八，而上个月一个月的时间，又结束了我的第二次正式项目，也就是我们项目的迭代九。

相对于迭代八我只负责一个功能的实现来说，迭代九的工作就要多很多了。

因为之前两个来的久一点的同事被调到了其他项目组，所以我不仅要接手其中一个人的模块维护，还要负责新的迭代中两个统计模块，这样不仅从量上变多了，逻辑复杂度上也比迭代八要高。

这一轮的迭代，虽然说不是完全的新模块，只是在旧模块上修改，但是实际上在实现的时候，基本上跟新增没有多大的区别。

在我们的mongodb数据库中，统计需要用到的源数据表有四个，在统计的时候，之前的做法是把四张表的数据跑定时器统计出来，然后放到一个新的统计表中，再在项目页面统计的时候，直接拿出统计表中的数据就够了。

而新的需求中，要求把定时变成实时，如此一来，每一次的统计都需要根据不同的条件查询四张表，再把四张表的数据进行一定的处理：合并或者拆分。

同时查询四张表，如果是关系型数据库，可能会简单很多，但是mongodb是非关系型数据库，又因为自己对mongodb的使用并不是很熟，因此也是绕了相当多的弯子才勉强搞定。

应该是有了上一轮迭代的经验积累吧，这一次虽说工作比上次多了而且难了，但是我实际用的时间并不比上一次的多，甚至从某种程度上来说所花费的时间还要少一点。

这一轮的迭代，对mongodb的基本操作有了更进一步的掌握，上一轮中，学会了基本的增删改查语句，这一轮在此基础上新掌握了不同数据库间表的导入和导出，根据多条件查询以及排序和分组。

因为统计涉及到的数据很多，在测试调试的过程中，也要不断的把页面上的数据和数据库中的数据对比，因此也算是更熟练的掌握了调错、找错的技能，能更快的找到问题根源。

相对于上一次基本上弄清了springmvc的三层结构，这一次也算是进一步练习了三层结构的使用，除此之外，对于集合、数组等数据的封装和拆分也有了更进一步的理解和使用。

如果说收获的话，这一次最大的收获，大概就是关于代码优化和重构了。我所负责的两个模块，实现细节上有很多的不同，但是有一些环节却是大同小异的，可能是由于经验方面的不足，或者是知识方面的欠缺，所以在好几个地方都有看起来似乎一样的，但仔细看又不一样的代码。

当看到这些代码的时候，我想过要提炼出来，但是几经尝试后，没能提炼成功，我以为可能是真的不能提炼了。直到后来项目经理看到后，热情的帮我弄了一下，我才发现原来并不是不能提炼，而是自己经验不足，所以思维过于局限了。

值得一提的是，在项目经理指导我提炼上边代码的时候，顺便指出了我另外一个可以优化的地方。

在代码中，我有几个地方需要判断一个list中的元素是否存在于另一个list中，于是我用了for循环，结果项目经理只用了一个contains方法就搞定了我十几行。由此可见，有的时候多掌握一点知识，可能就能为我们省下很多的工夫了。

书山有路勤为径，学海无涯苦作舟，这句很早以前的名言早就烙印在我的心中，但是自从进入软件行业以来，我突然发现虽然要学的东西很多，但其实也是乐趣无穷！