又到回望凝眸时

又快到农历的年根儿了，每到这个时候忙碌了一年的人们都会总结总结自己一年的经历，清点清点一年的所得，像是对自己的犒劳，也像是对自己的盘问。学习软件工程17周，课上课下也算是没少忙，确实也是时候总结一下自己的所得和所失了。

总的来说，这一学期的繁忙程度远远超越了前面几个学期，虽然前面几个学期的每一次回望我也都会有这学期比上学期还要艰难的感觉。但是这回的压力之大确实是客观摆在这里的，从开学伊始就投身战斗，一直到昨天刚提交了编译原理的大作业，再到接下来的几天里还要为期末考核各种忙碌。忙确实是忙过了，也算是没有虚度光阴，但是究竟得到了什么，只怕还是要静下心来细细点数一番了。之前的博客地址点击这里

part1：总结M1/M2：

软件工程的“做中学”的教学思路是非常正确的，我也能偶尔听得到接受传统软工教学模式熏陶的同学们在抱怨说什么也学不到，而且从我的亲身的实践中我也能感受得到有些概念就是针对实践中的情况提出来的，所以将经验化的东西概念化往往会在接受上具有一定的抽象性，而这种抽象性是要通过实践过程的重现才能理解概念自身的提出的原委和概念本身的适用性和局限性。我们团队中有两位实验班的学生他们的选课表中本来是没有这门课的，但是为了感受真正的软件工程的实践环节，他们几经“折腾”终于在自己课表上加上了这门课。于是我们的团队一开始就抱着非常强的实战的信念开始这个旅程。

在选题上我们选择了往届的题目，而且将往届的代码全部推倒重构了，于是在实践上就相当于是一个新的自选项目一样。在M1阶段我们面临的问题是团队与团队之间的衔接的问题，在M1过程中我们显然是过分陶醉于自己的开发之中没有顾及团队间的合作，导致最终衔接不到位，展示数据比较匮乏，效果不是非常好。而且在M1开发的阶段我们对于团队的整体的协调性不是很好，一些常见的甚至是低级的但是却致命的错误都在我们的团队上出现了，我们团队曾经因为scrum meeting 事件一度将面临崩溃，好在成员们临危不乱团结一致，才没有造成军心涣散。

到了M2阶段我们重视了团队间的合作，甚至为了团队间的更好的合作我们将前端的接口做了比较大的改动，但是无奈的是后期的各种大作业纷至沓来，时间成为了最致命的问题，原本设计好的计划没有很好被完成。也搞得自己很崩溃。但是在这个过程中我们非常重视组建的合作，原本的M1阶段搞不定的合作问题，都通过统一的接口使得整体上可以完成数据的正常流动了。

Part2

在前面的作业中我说对于测试部分不是非常的理解，其实一个重要的原因是自己以前所写的代码过于简短了，没有真正的可以达到工程的级别，这学期我们有数据库的大作业，编译的大作业，软件工程的大作业，这几个大作业每个都是数千行代码的级别，可以算得上是小小的工程了。在这个过程中我是真的充分感受到额（了）测试的重要性，我在写编译原理的大作业的时候往往会被某一个bug困扰一整天，到最后才发现居然不是算法的问题也不是逻辑的问题，而是非常边边角角的低级错误，这种错误只要稍作测试就会被发现，但是当它集成到数千行代码里面再做整体的测试时简直是要了命了，一天天被整得“呜呼哀哉”。真的就像哥伦比亚号飞船的发射失败起源于一个运算溢出那样的无奈和细微。可见测试不是浪费时间而是保证后向的无忧。

再者就是对于市场模式的理解我还是不太懂，但是我知道的是软件开发面向的是用户，这一点我在开发的过程中和在课堂上以及在和小伙伴们的讨论中有着非常深的感受，我们需要从需求到实现逐步求精迭代循环，以用户的反馈和需求作为调整的策略。这一点我想我是不会忘的，也算是和市场相关的理解吧。

对于开源的问题也有了深一步的理解，在软工实践的过程中我们使用github作为托管，在使用github之余，我也会看到有很多的项目在github上，我们可以将项目fork下来然后在其基础上进行自己的修改甚至成为项目的contributer的一员。这个也许就是开源最直接的表现了吧，代码透明，人人皆可参与。毫无疑问这种模式不仅可以加速软件周期还可以有效提高代码的健壮性。但是受到快播案的审判的提醒，纵然是分享精神不死，开源精神不灭，其他人的劳动成果的合法性是否可以获得保护、如何获得保护、凭什么获得保护，这些问题不得不提，不得不思考。所以其实现阶段对于开源的利弊的评估我是不太清楚的，角度太多，情况太复杂，这算是一个新的问题吧。

第一次读到大泥球的定义的时候倍感新奇，感觉形象而生动，好像又学到了一个有意思的称谓，但是到了后来alpha阶段的代码统计和总结的时候我们发现原来我们的代码好多的部分就是泥球啊，甚至直到M2的开发阶段还是不断在与泥球作斗争，所以泥球成为了通过阅读软件工程论文留下的印象最深的词了。

同时对于敏捷开发里面的两个特征也是印象深刻：适应性而非预测性、以人为本。这两个特征也在我们的团队上体现得非常好，也是对于敏捷开发过程贴切的概括。在这个过程中我对于教堂式开发和集市式开发有了新的理解。一开始我认为我们的项目是教堂式的，因为只有团队内部的人员在维护没有团队之外的人可以参与进来，整个的开发是相对封闭的，但是在团队的某位大神指教之后我发现我们的团队用集市式开发来定义也不算错，虽然我们对外是教堂式的，但是对内确实是集市式的，因为我们的每一个人都了解其他人在做什么，都能参与其他人的工作，可以协助完成开发，这样来看不就又是集市式的开发吗，人无固定的定位和一成不变的分工，凭靠兴趣和任务机动安排参与到或前端或后端的开发中，所以尽管在这个过程中学习成本高昂，但大家在这个过程中学到了很多。集市和教堂式的开发模式算是我新的理解和体会了。

需求分析阶段：我们使用问卷星进行了几乎是全球范围内的调查。所以得到了非常真实的数据结果，而且通过平台自带的统计功能使得数据可视而直观，所以问卷星这个工具算是在需求分析阶段掌握的“知识点”了。

设计阶段：在M1设计阶段我们通过组内一套基于Apache的框架搭建了完整的数据抓取利用的架构，在M2阶段我们利用solr工具以及json的数据传输组织形式开始了组间的合作开发。

实现阶段：我们采用“结对编程”的两两监督开发的模式提高了生产力。

测试阶段：作为开发人员一定要在开发的过程中将单元测试及时做好，并且同时留下测试的记录文档。最后才想起来做这个显然是费力不讨好的，而且是没有意义的。

发布阶段：在发布阶段要做好宣传工作，针对目标群体结合需求分析阶段定向宣传。

维护阶段：实时注重用户数目的变化以及用户反馈中可能出现的bug以及功能上的建议，这就要求在实现时注意融合入反馈机制，以及利用敏捷开发的手段进行逐步的迭代求精。

最后要说的是一个团队跌跌撞撞、一群少年哭哭笑笑，在软件工程的历程中渐渐成长。为老师为队友为助教为所有关注这门课的人们献上温情与敬意，谢谢。