经历了跨时一个月的两次迭代，我们的大学生竞赛(报名)平台的框架已经搭起来，并实现了基本的创建比赛、组队参赛，载入成绩等基本功能，基本达到了中期展示的要求。而同向对比，与之最接近的就是大二小学期里的django作业了。因此本文主要以对比这两次开发为脉络，主要谈谈自己的一些感受，而非一篇介绍相关技术的博客。这可能会在期末结束后做一次相关的总结。

压力

我个人两周一迭代的开发压力其实还是蛮大的。而在开发软工大作业的过程中时不时穿插着其他课程的小作业大作业。再加上中间两周的期中考备考压力，确实有一段时间确实是疲于奔命，基本没有喘息的余地。相对来说小学期的作业相对轻松不少，虽然时间不长但没有其他的压力。不过再熬过这一段小高潮后也相对也轻松一些，但很快又要进入下一次迭代的开发了(中期展示完的周末就是第三次迭代会议的召开之时)，整体的安排还是特别紧凑的。

开发跨度

可以看到这次的软工大作业其实是跨时八到十周的，因此才会采取迭代式开发。那么在这样一个长的周期里面，如何合理安排进度也是对我们的一个考验。安排得不合理，将有可能导致期末开发压力极大，甚至无法上线稳定的经过测试的版本就要草草提交。如此的话这个项目就是彻底失败的。

团队开发

小学期的项目虽然也是组队开发，但三个人的小组和现在五个人的小组还是有些许不同的。小学期项目中我们三个人我负责前端的页面渲染，另外两人负责后端的两个大模块。其项目本身就易于解耦，前后端的数据接口也没有这次的复杂，因此开发起来相对轻松很多。而这次的开发中两前端两后端加一个配置集成开发环境，因此。尽管做了解耦，但仍会遇到这样或那样的bug需要沟通联调。而沟通难度和成本其实随着组的增加也是在上升的。因此这一次的五人组开发其实也是一个挑战。
不过好在我在一个特别nice的组。每当召开迭代会议和集体开发大家都能到齐而不用催，出现bug的时候大家的心态也都比较平和，相互review代码。
当然，刚开始的时候仍然对于使用gitlab做团队管理等不太熟悉，包括issue的划分，时间的估计等等。而我们组也在不断尝试适合我们组的开发方式。因此开发的过程虽然磕磕绊绊，但也逐步形成了我们组内的一套开发流程(比如共同维护一份接口文档等)。
还有一点需要提的，就是我们这次的开发自然也是需要做单元测试、功能测试乃至性能测试的。同时开发的时候也需要部署相关的集成开发模块，这都和以往开发的小项目有着很大的不同。

开发困难

最开始的时候我们前后端是口头约定了几个模型的字段。但后来觉得不够，就由后端写出一个极其简陋的示意网页告知前端。最后我们决定由前后端共同在hackmd上维护一个接口文档，有任何需求都在文档里体现出来并交由对方实现。
另一个困难就是项目刚开始的时候完全没有成型，许多前后端的typo和bugs，以及接口的细微差别都难以直接检出。因此我们决定在集体开发的环节就留出一定的时间进行前后端的联调和简单的debug，而在私下的时间则是开发具体的功能。尽管前两次在联调时花费的时间比较久，但如今项目已经基本成型，以后在这方面消耗的时间将会大幅度减少。

甲方沟通

小学期的项目基本是交由我们决定上线的网站支持哪些功能，并根据具体的情况进行增删。而这次我们则是真正面对着甲方。因此在每两周的定期迭代检查中，我们也与甲方进行深入的交流，了解甲方的需求，及时修正我们的设计。比如在第一次迭代会议后，我们发现甲方对于比赛多阶段的需求是非常强烈的，为此我们也放弃了之前对于比赛的一些设想，重新规划部署了相关模型。而在这样一次次的交流中，我们对于产品的需求和定位也就越来越清晰，这有助于我们今后的开发工作。当然我们也不是一味的听从甲方的安排，对于一些实现起来确实有困难，以及有更好的设计方案时，我们也和甲方积极沟通，争取达成共识。

总结

其实这次的团队开发确实是一次很珍贵的开发经验，至少比起之前的项目都更加地与现实接轨。