项目开发心得（201201-201204）

项目心得

 

功能开发接近结束，剩下的是项目推广了，经过近4个月的开发（含春节）身心俱疲。总结下项目经验，为我的下一次成长做准备。

1. 项目计划：

在接到开发任务的时间是1月15号，计划结束时间2月15号，包含春节10天假（公司春节假期长一些）。从工作量上看这个开发需要从零开始，20天的开发时间即使天天加班都很困难，但是公司是乙方，没有选择权。

这么段的开发周期面临的最大问题是设计与开发时间的权衡，从这次开发的结果看来，我们没有平衡好这个时间，这个稍后再提。

在开发接近尾声的时候（二月十几号，具体忘了），接到项目组的通知：他们可以顶一个月，开发时间延长。

面对基本成型的产品模块，剩下的时间应该是测试及优化工作。由于新功能是在原有系统上的新增模块，避免对原有业务的影响显的尤为重要。

 

2. 用好兵

这次作为小组的负责人，待着几名外包和其他几名公司人员进行开发。由于业务模块相对集中，我计划让每一个人负责一个业务模块，这样便于功能的维护。

在开发阶段这个方式效果还行，出问题的模块可以很快定位问题。随着项目进入测试阶段，这个划分带来了一定的弊端（测试部能提供的帮助太少了），交叉测试需要其他人了解对方的开发思路，所以进度较慢。

这次开发中，个别人的力能比较差（并非贬低，闻道有先后，术业有专攻），他们的编码需要及时跟踪，保证后期的维护工作。

指导的同时注意解释，教会他人解决一个问题要比快速解决一个问题更重要。

 

3. 重构

项目在3月15号上线了，之后可以存在一段时间的项目调整优化时间。此时项目上的一些问题也暴漏了出现，面对大数量对接口造成的压力，代码需要调整。在梳理过现有代码之后，得到一个结论：重构。

设计之初的目标是快速、低耦合的完成业务模块，没有过多的考虑到接口的压力，原有的业务逻辑进行修改与重构的工作量基本相当，所以选择重构。

重构的结果个人不满意，2000+的类完全可以优化，但是项目已经上线，进行大的改造若造成系统异常，公司的代价非常大，需要避免风险。

 

结束语：想与做还是有差距，设计对于产品开发非常重要。