个人博客作业5 - 软工最后的总结

　　转眼到了期末，软工团队项目终于进入尾声，M1阶段的初识，M2阶段的深入，由浅入深，渐渐地遇到很多的坎坷，但也慢慢地收获到很多的知识。

　　一、M1阶段总结

　　M1阶段刚刚开始接触这种团队编程的模式，还不是很适应，而且不能够很好地发挥出团队的力量，有时候觉得还不如自己一个人做效率高，那种认识放到现在来看是错误的，一个项目之所以成为一个团队项目，皆因客观上它的工作量巨大，这样的工作量交付给一个人来完成，要么压力巨大，耗时变长，要么完成度不高，达不到预期目标，一个爬虫实现起来似乎就那点东西，然而链接的编码格式、过滤规则的自定义、文件的转存储、多线程调度互斥更新等等细节不多人协作真的难以完成。我们应该改变以前的理解，从一人完成一个程序改成一人完成一个模块，最后完美装配，实现1+1大于2，无论是时间还是效率。

　　二、M2阶段总结

　　M2阶段开始意识到团队的重要性，学会在开始着手项目前进行科学的任务分配，而且普遍参与度比M1阶段高，因为M1阶段大部分时间花在学习了解爬虫原理上了，学习成本比较高昂，不好下手。M2阶段有了M1的铺垫，上手快，切入点明确，知道了要做的东西，也倾尽全力去做了，虽然最后的结果离我们的预期还是很远，但是也没辜负我写那么久的代码，可以说满意。

　　三、软工问题解决情况

　　再回去看看学期初刚开始软工项目时候提的问题（http://www.cnblogs.com/plp1306/p/4830585.html），似乎已经得到了答案。

　　1) 软件工程的质量如何衡量 ----- 交付件完成度，代码覆盖率等

　　2）软件团队中测试的角色应该独立出来吗 ----- 应该和开发者结合起来，自己写的代码自己测试比较好

　　3）除了注释之外，怎样的代码风格比较约定俗成且通用，能让别人阅读代码更易 ----- 代码风格不应过分追求统一，因为太多的规范虽然让阅读代码更简单，但是却增加了写代码的难度，因为约束太多

　　4）如何通过测试样例来证明自己程序的正确性，穷举吗 ----- 可以穷举，但测试样例的选取最终还是应该覆盖尽量多的待测试点

　　5）如何均衡普通用户需求和相关技术人员需求 ----- 通过典型用户分析和典型场景分析来进行考量

　　四、团队项目中的收获

　　收获是阶段性的。

　　需求阶段：学会了如何分析典型用户和典型场景，提炼出最精简合适的需求

　　设计阶段：意识到大局观的重要性，设计阶段应该花费足够多的精力来奠定整个项目的基础，以免后续反复更改设计带来工作困难

　　实现阶段：代码能力和代码量正相关，这点我确认

　　测试阶段：灵活应用插件等辅助工具能减少很多工作量

　　发布阶段：详尽的设计文档和版本发布说明对于一个项目来说是必不可少的

　　维护阶段：所有关于项目代码与设计的明细都应当科学的记录在案，这对减少维护难度来说是相当理想的

　　五、完结

　　虽然很难，但是还是做到了，现在结课后全身轻松的感觉都是当初全力完成项目的反馈，庆幸有这样一门课，让我提前体会到团队编程的微妙，以及提升个人能力，获得妙不可言的充实感，算是完美谢幕了。