个人博客作业——结课总结
阶段再感触
在本学期接触软工之前，对软件工程的认知就只有一个：写代码。通过这一学期两个团队开发阶段后，渐渐对软件工程有了更深入的了解，自以为已经具备了最基本的团队开发素养和能力了。我是爱码室团队的成员，在M1阶段我们由于经验的缺乏，只能紧紧跟着老师所提示的开发模式走，不一小心时间规划有误还有可能导致阶段性目标的完成不理想。而在M2阶段我认为我们的开发虽然收尾不是特别完美，但这一阶段肯定是成功的。我们总结了M1阶段的种种问题，以及老师和助教老师给予我们的建议，重视单元测试、代码复审和TFS源代码的管理等等，整个M2阶段相比于M1更规范、更系统。
在M1中我担任的是DEV，在这期间给我的一个很深刻的感觉就是：编码成员就像是一辆车，即便我充满了汽油，即便我的马力十分惊人，但是缺少道路和路标，仍旧无用，更何况我这辆马力不是那么足的车，再遇上坎坎坷坷的山路，令人费解的路标时该怎么办呢？在M1阶段中我们所有小组成员都是从零开始：从零开始接触UI控件、从零开始接触数据库、从零开始接触网页文件分析、更是从零开始接触软工。我们行进的速度很慢，因为我们必须再三思量我们所走的方向是对的而非南辕北辙。在M1阶段结束之后我们回顾阶段成果，发现虽然紧张得缓慢，最后的功能实现得略微粗糙，但是我们爬虫性能得增强，所爬取下来的文件是实打实的，这为我们M2阶段奠定了基础，同时M1阶段出现的各类问题也成为我们M2阶段的方向标。
在M2中我自告奋勇请求担任PM，这是因为在M1阶段的编码工作中，我自以为对我们团队的理解程度和开发经验足以让我在这一阶段为我们的开发成员树立好方向标，让开发成员们无所顾忌地行进。在这一个月的PM担任中，我的感觉就是PM就是我们所需要的主导这个团队运作的导向标。我需要和开发人员进行会议商讨，制定开发设计，测试计划。需要每一个开发小阶段衡量DEV的工作进展并更新项目进展情况。而这一导向标并非只有一个，它需要布满我们整个开发道路，鼓励正确道路上的DEV继续进行开发，同时也能让走向错误道路的DEV引导回来。最终由于我们团队成员的共同努力，完成了一个全新的爬虫：线程池让它拒绝崩溃、动态爬取让它日夜兼程、异常清理器让它保持健康、视频爬取让它营养均衡不挑食，既吃html、pdf也吃mp4。
问题再回顾
课程开始时所提问题的博客：http://www.cnblogs.com/FUduomi/p/4830411.html
1.通常，我们阅读软件比编写软件花费的时间更多。正因为编写软件比阅读软件要容易，因此代码的可读性显得尤为重要。那么我们在写程序时应该如何避免多余的，带有误导性的注释，写出一个利于帮助别人读懂程序的注释？
答：两个开发阶段下来对于代码的编写和注释的认识更深了一些。首先：不管是Java、C都是一种语言，如果你的语言让通晓这门语言的人们看不懂，只能说明一个问题：你的语言组织能力太差。例如：怎么为一个扫描pdf的方法起名，有的人这样起：PdfScan()，而有的人这样起：Haha233()。这就好比在我们现实生活中，有的餐馆起名盖饭王、有的餐馆起名大拇指，对于前者，人们不需要再具体看介绍就能猜到它的性质。在编码就是这样一个道理，我们的命名要的是“顾名思义”而非故弄玄虚，我们的代码组织要的是言简意赅而非各类“修辞”。在复杂的算法块中，我们可以加上必要的注释进行功能介绍以及大致的算法实现。正如助教老师提醒我的，没有注释就是最好的注释，倘若我写出的程序能让人一眼看懂，又何必再花时间去考虑注释的问题呢。
2.当今时代人们的需求各式各样，一个有着敏锐嗅觉的软件团队能够准确而全面地捕捉人们的需求，从而能设计出满足人们需求的软件。像我们这样刚刚诞生的缺乏经验的软件团队应该如何获知市场客户的需求？
答：这两个阶段下来，对于这个问题还是不了解。因为我们做的爬虫的目前的需求就来自于后面的几个小组，但我认为这两个阶段的需求分析有些简单：就是快爬、多爬、久爬等等，更重要的还是实现，所以目前对需求分析还没有更好的一个了解。
3.一个软件团队里的成员之间相互分工协作，在书上有特别介绍了项目经理——PM这一团队角色，并提出了PM的工作是除了开发和测试之外的所有事情。然而这一角色的定位对于我还是太模糊，有没有那些经典的PM的工作实例？
答：心想事成，我成功担任了M2阶段的PM。和开始想的不太一样，在想象中，PM至少是个经理，应该能在团队中呼风唤雨，成员们应该莫敢不从。实际上开发成员经常会提出自己不同的看法，PM需要和开发成员分析不同实现可能造成的结果，有时在开发成员强大的论证观点下，PM还可能需要调整实现方案。而经历过M2之后我认为就是这样才是团队开发的正轨，PM是对整个团队进度最了解的人，需要实时进行进展更新和剩余任务的评估，同时还发挥润滑油的效果使得我们的团队大机器能够在分歧中磨合地进行下去。
4.一个软件设计编写完成后，避免不了在产品使用过程中根据客户需求对软件进行更新和维护。我们在软件设计及代码的编写时，如何避免在产品开发后期重大修改而导致其他模块的连锁反应，提高代码的可维护性？
答：在M1阶段就有这样的惨剧发生。通过老师和助教老师的建议，我们在M2阶段对单元测试和代码复审尤其重视。所以在单元测试和代码复审伴随着开发阶段进行，能有力从底层排除BUG而避免后期因BUG而产生重大修改。同时程序各模块应该设计好代码规范（我们M2没有做到），各模块各司其职，尽量减少那种贯穿程序各处的代码块。
5.我们都知道一个网络游戏都会先内侧再公测，同时也不断鼓励玩家发现并提出BUG。在一个软件开发完成后进行测试，进行Debug是必不可少的。那我们应该如何进行高效的测试，而不是穷举，地毯式地进行测试。
答：这个问题和上一个问题类似，测试的作用是不可估量的，在项目展示中我们就提及地毯式Debug的效率低下。所以我们让单元测试伴随开发工作进行，能够有效地预防BUG。
6.一个软件团队成员之间分工协作。但在软件开发过程中各项工作往往不是同时进行的。我们应该如何充分协调成员之间的工作关系，尽量使各成员都能够尽可能多地了解软件开发过程，而不是仅仅只学到了自己所负责得那部分工作的知识和经验。
答：我们Scum Meeting中各开发人员都会进行每日的工作汇报和进展状况，这样一定程度应该能增加其他成员对这一模块的认识。（好吧通过了解其他成员我承认他们对其他部分的了解还是不高！！）
新问题提出
1.其实在两周的开发阶段之后的那一周的稳定阶段中我们小组是挺迷茫的。要做稳定，要做系统测试，该怎么做？系统测试不同于单元测试能有Junit这样的控件帮助，所以在这一周我们确实工作进度缓慢。
2.大多还是开发阶段之外的问题，例如M2阶段我们多组之间形成了一个开发框架，大多小组的有向老师反映组内和组间的对接问题，我们怎样做能更好地实现对接？
相关论文回顾
Alpha阶段，在大教堂和市集的两次软件工程开发模式中，我们属于大教堂模式。当时我们选择的原因如下：
1.所有用户的需求不可能是一致的，而用户的需求在短期内往往是不会轻易改变的。团队只要在需求分析中抓住大部分人的需求，用户在软件实现之后就会买账。
2.代码的修改往往会牵一发而动全身。如果我们要对其中一个算法，或一个功能实现修改，那么与它联系的其他部分难免需要变动。我认为代码的改动应该需要在实现之后，充分分析代码改动的得失而做出判断。
3.大多数人更喜欢选择，而不是设计。网络中有这么一句话：一个游戏的衰败是因为有更好玩的游戏出现了。游戏就是软件，用户的需求有时是难以表达的或从未需求过的，他们需要将两款软件进行对比而选择更好的一方。也就是说有的用户更喜欢去体验实体，而不是去感受概念。
而在Alpha阶段结束后我们发现一个问题：因为各方面的原因（主要就是对接问题），后面几个小组几乎没有用到我们的数据。虽然这主要是因为对接问题，但也引发了我们的思考，如果我们爬取的内容没有人用，那我们爬取的意义何在？所以在M2阶段我们推翻了大教堂模式，肯定了需求对我们小组的影响，进行“集市”模式的开发，并由此成功开发出了视频链接爬取和基于基地址的规范爬取。市集模式”众人拾柴火焰高“，能够充分的了解到用户们的需求，及时地进行修改，更符合我们这一阶段与其他小组协作开发的特点。
做中学
1.需求：获取用户需求——用户调查之深入面谈。
我们小组与数据处理小组通过详细的面谈，广泛和深入地了解数据处理小组的背景和需求。这种方法虽然费时费力，但是能够直接获取到需求信息。
2.设计：设计方法——UML。
把设计设计画成图，更易理解。
3.实现：开发阶段——每日构建。
Daily Scrum和TFS源代码管理。
4.测试：单元测试——通过Junit工具。
5.发布：发布声明和事后诸葛亮会议。
6.维护：设计变更。
在因时间关系开始的动态爬取没能实现之后通过降低复杂度变更为新的设计。
