普通的项目开发日记（一）：新需求与代码开发

2020.8.24

总结一下最近几天的工作内容：

8.18，需求会议，一堆新需求下来了，每人挑一个需求进行开发；本人挑的需求预计26号提测。

8.19，分析需求与熟悉相关代码，需求中提到要在原有的代码上新增加功能，对提交的表单增加一个限制；涉及到2个项目，一个是管理系统，一个是移动端。（这两个项目倒是共用一个数据库，有相似的地方，有不同的地方）

8.20，开始开发代码，首先对管理系统的前端jsp部分增加了限制；

8.21，继续开发，对管理系统的后台java部分增加了限制；

8.22，开始开发移动端，与移动端的前端沟通后，发现这次前端不用限制，只要在后台加限制并返回信息即可；在下班之前基本开发完毕并提交了svn，之后准备下周自测。

 

总结：

1.这应该是最普通的项目开发了，属于新增功能，流程大概就是【分析需求-熟悉之前的代码-开发-自测-联调-提交正式测试】，后续的发版部分暂时还没接触到，也许有专人发版。

2.公司的一个项目代码svn分三类，一个开发，一个测试，一个生产；先在开发路径进行开发，然后将代码合并(merge)到测试路径就是'提测'；最后将测试路径下的代码合并到生产就是'上生产'了。（当然，这说的是代码，实际还需要打jar/war包放到服务器上，服务器2个，一个测试服务器，一个生产服务器）

3.【分析需求】与【熟悉之前的代码】这两步感觉是真的花时间，自己看一遍文档后会发现文档中有很多细节没有提到，需要与需求人员去沟通，大概确定怎么做，然而有些问题需求人员也确定不了，这就只能自由发挥了（等测出bug来再说呗）；

至于熟悉之前的代码，花的时间就更多了，因为注释没有你想象中那么详细，只能连蒙带猜、打断点看；

终于好不容易看懂了代码，又发现不太好开发，因为之前的逻辑与你准备写的代码可能会有冲突；为了效率、为了新功能，不得不改老代码，然而老代码的逻辑又很复杂，‘牵一发而动全身’，工作量巨大，如果硬改，不但需要大量时间，而且有可能改出bug来，得不偿失……

4.由于26号就要正式提测，开发时间不充裕，因此本人选择了【先加功能、牺牲效率】的方法，优先实现需求，至于代码优化，就等后续有时间再说吧。