| 作业要求见链接： | 讨论软件开发方法的思潮 |
|---|---|
| 参考的文章: | Big Ball of Mud、瀑布模型、银弹、敏捷方法 |
| 作业正文: | 作业五 |
本文主要是针对讲义上介绍的项目中大泥球的含义及其解决办法，瀑布模型、敏捷开发和银弹的相关概念进行总结和整理。
大泥球
Big Ball of Mud这篇文章介绍了程序中大泥球的产生和发展以及解决办法。大泥球又称棚户区或意大利面条式代码，它是一个随便，甚至是随意的结构化系统。大泥球的组织，更多的是权宜之计而非设计。它的持久流行不能仅仅表示对建筑的普遍无视。
大泥球产生的原因是多方面的，包括时间，成本，经验，技能，可见性，复杂性，变化和规模。比如，你要在短时间交付一项高质量多功能的软件，那么你一定会先关注功能，而将架构和性能这些较为耗时的列为次要的考虑因素（即功利主义思想的驱使）。大泥球的出现通常代表着实用主义对美学的胜利，即为了功能性而牺牲了工艺甚至结构和耐久性，因为一个难以理解的程序无法进行维护。有三种方法来处理大泥球：
- 保持系统的健康。认真地将扩展阶段与合并阶段交替进行，重构和修复可以在系统发展的过程中维护甚至增强系统的结构。
- 种是抛弃这个系统，重新开始。重构模式探索了这种激烈但经常必要的替代方法。
- 向熵投降，在泥沼中打滚。
瀑布模型
网页瀑布模型中指出，瀑布模型是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。它的核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为六个基本活动：
- 制定计划->需求分析->软件设计->程序编写->软件测试->运行维护
并且规定了这六个环节自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
瀑布模型的优点：
- 为项目提供了按阶段划分的检查点。
- 当前一阶段完成后，您只需要去关注后续阶段。
- 可在迭代模型中应用瀑布模型。
- 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
瀑布模型的缺点
- 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
- 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
- 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
- 瀑布模型的突出缺点是不适应用户需求的变化。
银弹
文章There Is a Silver Bullet中指出银弹一种能让软件成本与计算机硬件成本一样迅速下降的东西（-布鲁克斯）。银弹是文化上的改变，而不是技术上的改变，这是一个范式转变——一场基于可重用和可互换部件的软件工业革命，它将改变软件世界，就像工业革命改变制造业一样。软件世界的工业革命莫过于面向对象技术的产生到广泛为人们熟知和应用。
敏捷方法
敏捷方法是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。百度和文章敏捷方法中都提到，敏捷开发（agile development）是一种以人为核心、迭代、循序渐进的开发方法。软件的开发是from Nothing, to Monumental, to Agile(即从一无所有，到繁重，再到敏捷)。敏捷方法与普通的工程方法之间的差别是：
- 敏捷方法是适应性的，而不是预测性的。工程方法倾向于在很长一段时间内对软件过程的大部分进行详细的规划，这在事情发生变化之前都是有效的。所以他们的本性是抵制改变。然而，敏捷方法欢迎变化。
- 敏捷方法是面向人的，而不是面向过程的。工程方法的目标是定义一个无论谁使用都能很好工作的过程。敏捷方法断言，任何流程都不会构成开发团队的技能，因此流程的角色是支持开发团队的工作。
敏捷开发方法要避免的过程设计的几个常见错误
1. 对所有的项目使用同一种过程
2. 没有弹性
3. 过于沉重
4. 增加不必要的“必须完成”
5. 没有经过实践检验
由于敏捷方法本质上是以人为本的，所以再找到合适的项目来进行敏捷流程的软件开发时，必须从一个希望尝试以敏捷方式工作的团队开始。不仅仅是不情愿的团队更难合作，将敏捷方法强加给不情愿的人，从根本上来说与敏捷开发的整个概念是不一致的。