此博客用于记录2020年9月26日每日分享，
软件工程中的集中常见模式，瀑布模型，敏捷开发等

日期：2020年9月26日
主题：

1. 讨论讨论怎么使用软件工程的思想来解决问题
2. 软件工程中的集中常见模式，瀑布模型，敏捷开发等

软件工程

  软件工程是一门用工程化方法解决软件项目问题的学科，其本质也是一门工程学科，这门课的知识在学完后，不仅可以应用在软件项目中，还可以应用于日常生活中遇到的一些问题。

Everything is a project。

  有目的、有计划、有步骤地解决问题的方法就是工程方法。

• 想法：想法阶段通常是想要解决问题。最开始问题通常是模糊的，所以需要清晰地定义好问题，研究其可行性，检查是否有可行的解决方案。
• 概念：概念阶段就是用图纸、草图、模型等方式，提出一些概念性的解决方案。这些方案可能有多个，最终会确定一个解决方案。
  计划：计划阶段是关于如何实施的计划，通常会包含人员、任务、任务持续时间、任务的依赖关系，以及完成项目所需要的预算。
• 设计：设计阶段就是要针对产品需求，将解决方案进一步细化，设计整体架构和划分功能模块，作为分工合作和开发实施的一个依据和参考。
• 开发：开发阶段就是根据设计方案，将解决方案构建实施。开发阶段通常是一个迭代的过程，这个阶段通常会有构建、测试、调试和重新设计的迭代。
• 发布：将最终结果包括文档发布。

---

常见的开发模型

瀑布模型

  严格按照一定的流程开发，需求分析-设计-编码-测试，部署这样的流程开发，每个阶段都有相应的产出。但是当客户的需求变化了，就不得不重新来一次从头到尾的分析，灵活性较差。

瀑布模型的优缺点
  你会发现瀑布模型其实跟我们传统的建筑建造方式非常类似。我们拿盖房子的过程来看看瀑布模型。

客户想要盖一栋房子（初步的想法）。

• 客户一开始可能没想清楚想要什么样子的房子。（客户对需求还不清楚）
• 施工方开始找客户确认：用途是什么，要个几层的房子，什么建筑风格，希望什么时间完工，预算多少。（问题定义）
• 施工方根据客户提的需求，对比工期和预算，评估是不是值得做。（可行性研究）
• 施工方评估后觉得可行，于是和客户签订合同，约定价钱和工期。（立项，制定项目计划）
• 施工方开始跟客户沟通确认需求，例如每层户型如何，将来的装修风格等。（需求分析）
• 确认完需求后，施工方开始出建筑施工图，还画了漂亮的建筑效果图。（系统设计和 UI 设计）
• 施工方按照设计图开始施工。（程序编码）
• 这期间如果客户去参观施工情况，客户只能看到毛胚，只有最后施工完成才能看到最终样子。（在中间客户看不到结果，只有最后能看到结果）
• 原定二层是两个卧室，在房子施工过程中，突然客户说两个卧室不够，要改成三个卧室。这意味着施工方要对施工图重新设计，很多已经建好的房间要拆掉重建。（瀑布模型是很难响应需求变更的，而且越到后期代价越大）
• 工程质量检查人员对施工结果进行质量检测，如果不满足质量要求，需要修改。（测试）
• 最后验收通过后，客户入住。（上线）
  所以你看，用瀑布模型开发软件，就像建筑工程里，盖房子一样简单和自然。每个阶段都有侧重的事情，就像需求阶段专注于搞清楚需求，编码阶段专注于实现。

  最重要的是，这种编码前先设计、编码后测试、整个过程重视文档的方式，开发出来的产品，质量相对是有保障的。

  但用瀑布模式开发，也存在一些问题。

  最大的问题就是不能及时响应需求变更，越到后期变更代价越大。另外，通常要到最后阶段才能看到结果是什么样子。

---

敏捷开发

你如何理解敏捷开发？

  敏捷开发更多的是一种思想，开发当中注重“人”作用，更多的关心客户合作，团队之间的交流之类的

  各种敏捷框架、方法论和工具，就像是“术”，告诉你敏捷开发的方式，而敏捷则是“道”，是一套价值观和原则，指导你在软件项目开发中做决策。

什么是敏捷开发详解2

如果用敏捷的方式盖房子？
客户想要盖一栋房子（初步的想法）。

• 产品经理和客户进行了初步的沟通，把用户的需求写成了一个个用户故事（用简单的用户故事代替繁重的需求文档），例如：

作为一个上班族，我想要一个卧室，以便于休息；
作为一个家庭主妇，我想要一个厨房，以便于做饭。

• 施工人员根据用户故事和客户进一步沟通（客户合作高于合同谈判），然后对用户故事进行设计和实现；
• 每个用户故事开发时，还要给一个测试机器人编写测试脚本，让机器人可以自动测试（大量采用自动化测试），并且做好的用户故事可以随时被测试验收（随时发布，持续集成）；
• 每个 Sprint 四个星期时间（时间盒子，迭代时间固定）；
• 第一个 Sprint 搭了个草棚，一张床就是卧室，厕所就挖了一个坑，厨房还来不及搭建（每个 Sprint 会选择高优先级的用户故事），屋顶还在漏水（每个 Sprint 会定期发布，客户可以随时看到可用版本，即使还不完整）；
• 第二个 Sprint 有了简易厨房，同时修复了屋顶漏水的毛病（每个 Sprint 不仅完成用户故事，还会修复 Bug）；
• 第三个 Sprint 升级成了小木屋，但是忘记加上窗户（敏捷推崇自动化测试，但可能会测试不完备）；
• 第四个 Sprint 升级成了砖瓦房，窗户也开好了，客户可以入住。但是这时候客户发现一家三口的话，完全不够用，需要扩建到 3 个卧室。于是决定下个迭代改成 3 个卧室（响应变化高于遵循计划）；
• 第五个 Sprint，升级成了 3 个卧室，升级过程中把厨房下水道弄坏了（迭代过程中可能会导致质量不稳定）；
• 第六个 Sprint，修复了下水道的问题，房子也装修好了（迭代中不断完善）；
  客户验收使用（上线）。

  敏捷开发对团队成员的要求较高，可能某个小功能从需求分析，设计，编码，测试都需要你独立开发，如果客户不愿意配合你，那么敏捷开发也很难运行起来

  其他几个模型因为用的不是特别多，增量模型，螺旋模型，用的不是特别多，所以这里只简单地列出他们在哪些场景常见，其他的会把部分资料发到群里大家有空的时候一起学学吧。

小结

  根据项目特点，选择好合适的开发模型，可以让你事半功倍，降低项目风险，提高项目开发效率，控制项目成本。比如说：

• 一个以确认需求为主要目的的项目，就可以不用花太多时间在代码质量上面，低成本、高效做出来才是最重要的；
• 一个高风险的项目，则可以采用螺旋模型，出现问题及时止损；
• 一个很长时间加班加点，却一直没法上线，导致士气低落的项目，可以改成增量模型，先上线一个小模块，让大家看到成绩提升士气，然后再迭代，逐步上线其他模块。

---

• 快速原型模型：不见兔子不撒鹰。期初不考虑质量、架构，用最快的速度见效，并向用户确认需求。经过几轮直观、快速的反馈，把需求确定下来。接下来，既可以抛弃原型用瀑布精密重构，也可以在模型基础上完善。优点是快速有效的确认需求。不足难以有效应对后续的需求变更。

• 增量模型：分而治之。将大系统横向拆分成相对独立的若干小模块，每个模块采用瀑布模式分批次交付。优点是较快见到成果，且能够及时了解项目进展。不足是存在需求明确、系统可拆分、交付可分批等适用条件。

• 迭代模型：罗马不是一天建成。把软件项目纵向划分成若干阶段，从核心功能入手，逐渐深化、细化，直到满足用户的全部需求。每个阶段都是一个瀑布，都要在前一阶段成果基础上加工、打磨。优点是快速满足基本需要，并体会软件演进的快感。不足是需求演化具有不确定性，会导致代码冗余、系统重构风险、项目周期不可控。