个人阅读作业

经历了一个学期的努力，我们的软件工程课终于走到了最后，在这么长的开发过程中我有很多收获。

首先我体会到了好的程序风格的重要性。大项目开发的艰辛，这远不是我们以前那种几百行的程序能比的，我们每个人都有大量的任务，而我们互相之间也有很多需要进行连接的部分，我作为开发人员，编写了大量的代码，为了保证测试人员认得出来以及方便其他人和自己调用我的方法，我只能强行改掉自己的坏习惯，保证代码的可读性和重用性。

其次我收获最多的就是深入体会了团队编程的氛围和流程，我第一次作为团队中的一员参与到团队编程中，这份经验是很宝贵的。

http://www.cnblogs.com/yanyuzheng/p/4834037.html

对于以前问题的回答：

1、如果没有时间测试他人的新功能，就不应该添加新功能，是否会使团队的信任度下降要看情况的，如果是测试人员的失职导致新功能得不到测试，无法添加，无疑会使开发人员的辛苦白费，从而降低对测试人员的信任度，而如果是开发人员工作完成太慢而导致来不及测试，这不会降低团队信任度。

2、在开发的前期要有明确的框架，对于接口等进行完善的定义，这样就可以保证开发后期不会因为太大的修改引起连锁反应，而我们爬虫几个组因为接口没有定义好，后期在对接过程中引起了相当大的连锁反应，因此可以看出接口是十分重要的。

3、pm要对工作有足够多的了解，然后对于队员的能力有足够的了解，这样在分配任务时可以较好地分配任务，但我认为最重要的是任务的安排要有弹性，这样可以灵活地安排任务。由于我在团队中不是pm，所以对这方面的理解不太深。

4、团队编程中我认为在大方向上一定要有一个统一的声音，我们爬虫几组就是因为大方向没有达成一致，结果迟迟不能开始任务，导致进度延后。而在细节方面，我认为意见上的些许分歧不会延误进度，反而同学们的讨论会完善设计

5、我一开始认为，开发某段代码的人对这段代码更加熟悉，调试起来更加容易，但在实践过程中，我发现有一名专门的测试人员是很方便的，因为像单元测试等详细的测试很繁琐也很复杂，集中起来交给一名测试人员来做可以使开发人员没有后顾之忧。

新的问题：

如果时间不太够，那么是快速完成工作避免拖后团队进度还是说保证质量更为重要？

新的体会：

我对于《大教堂和集市》的理论有了新的认识，Eric Raymond说的两个理论让我很受启发，一是强调架构的重要性，架构第一，功能第二，这点在我们的实践中是很重要的，因为功能是基于架构的，如果功能有问题只需要修改一个功能，而如果架构有问题，则需要修改大部分代码。

另一点则是强调项目的简单性，我们团队第二阶段的主要任务就是精简代码，删除冗余，因此对于这部分的重要性认识比较多。

学到的知识：

需求：学会了获取用户需求常用的方法和步骤

设计：学会了思维导图和实体关系图的使用方法

实现：认识到了每日构建和及时修复bug的重要性，

测试：学会了单元测试、验收测试等测试方法

发布：学会了DCR和ZBB等发布前稳定项目的方法。

维护