个人博客作业WEEK7

团队项目到现在已经进行到一定阶段了，我们小组的爬虫项目进行的很不错。在这个过程中我们遇到了很多挫折与困难，但最终都被我们解决了，小组每个人的能力都得到了不同程度的锻炼。

大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来，为了对付这个泥球，我们看到了多种指导方法，比如SOLID、GRASP和KISS，与其他诸多年代久远的、提倡高内聚、低耦合的方法一起出现。然而，实际情形没多大变化，“大泥球”看起来仍然是设计软件架构的最常见方法。在阅读并且理解完上一届学生留下来的代码以后，我感受到了深深的恶意。比如其中有一个CraUi类一共有一千多行，其中有2个方法长度高达3,400行，读起来让我感觉逻辑并不清晰。同时在eclipse里面我还发现了许多黄线，把鼠标放在黄线上你会发现xxxxx is never used、xxxxx is not used或者the static method xxx from xxx should be accessed in a static way。这说明里面充斥着不少的无用代码，而这仅仅只是无用的代码，还不包括细读代码以后发现的杂乱无章的代码。所以首先我们要移除无用代码，然后细分各代码段的功能并且将其分类放入一个个方法中，每个方法行数不要太长，这样读起来就好多了，以后改写代码也更容易。

我们的项目采用的是大教堂模式进行设计。我们的组长符美潇和PM潘礼鹏同志不但要写博客、写代码，还要为我们分配任务、督促我们按时完成任务，在这里我要感谢他们，我们小组按时完成任务与他们两个人的付出是分不开的。我认为大教堂模式确实更加适合我们这个项目，组长和PM给我们分配的任务十分明确，我们可以很清楚地知道我们负责哪一部分代码，我们需要在什么时候提交，这种责任制使得我们的项目得以顺利进行下去。

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。