软件工程基础知识总结
上一篇文章总结了关于软件工程的一些基本知识，包括如何理解软件工程、为什么要学习软件工程以及学习软件工程的一些思路和方法。
这篇文章，是对软件工程基础理论知识的部分总结和归纳，我会尝试用自己理解的语言来描述。
PS：这是一篇学习笔记式的文章，而非详细的落地实践。
培养工程思维
亢长枯燥的理论知识，对很多同学来说是一个巨大的挑战。那么如何简单的理解软件工程呢？
简单来说就是多人参与、有计划有步骤的构造一个符合质量标准的软件产品，这个过程称之为软件工程。
我们都知道，参与人越多、产品越复杂、流程越繁琐，最终构造的软件产品就越可能出现问题。
软件工程出现的初衷，就是为了摆脱软件质量危机，其核心内容是要用工程化的方法去规范软件开发，让软件开发项目可以按时保质完成的同时且成本可控。
对我们从事软件研发相关工作的同学来说，要做好本职工作，需要系统的学习软件工程相关的知识，培养软件工程思维。
抽象归纳可以称之为一个核心三个方法，即：以软件开发为核心，对开发过程组织+对方法的运用+对工具的使用。
软件工程方法一般分为六个阶段，即：想法、概念、计划、设计、开发、发布。如下图所示：
利用这六个或者其中几个阶段对照日常工作中遇到的问题，将这些问题都看作一个项目，并且逐步拆分去完成，你会发现这种有目的、有计划、有步骤的解决问题的方法就是工程方法（Everything is a project）。
实际上，无论是软件工程还是其他类似时间管理的方法论，其本质，都是结构化的一种思维方式。
结构化思维提倡的是从总体的角度去看待问题，然后不断拆解，在这个过程中关注项目的质量、进度、成本和用户体验。
尝试将这种解决问题的思路和方法应用到工作生活中，你也就拥有了工程思维。
研发过程如何管理
软件工程的核心是为了控制研发过程以保证最终的交付质量，但研发过程管理的方法并不是从一开始就完备的，它也经历了一系列不断的探索和迭代。
整个软件开发过程，一般分为：需求分析、架构设计、编码实现、测试验证、交付维护几个阶段。
每个阶段需要不同的人参与，因此就有我们所熟知的项目经理、产品经理、架构师、开发工程师、测试工程师、运维工程师等角色。对整个研发过程的管理，一般称之为“项目管理”。
瀑布模型
瀑布模型大家应该都很熟悉，最初软件工程中关于项目管理的方法就是瀑布模型。
瀑布模型是现代软件工程的起源，现在很多流行的项目管理方法大多都是构建于瀑布模型基础上。从瀑布模型诞生之后，才有了软件生命周期这个概念。
虽然现在很多互联网企业开始应用了其他更高效的项目管理方法，但软件研发的本质离不开瀑布模型的核心部分，即需求、设计、编码和测试。
瀑布模型的优点在于：
- 简单易懂，只需要遵循流程执行即可；
- 可以在不同阶段进行检查，及时发现问题；
- 前一个阶段完成后就可以将关注重心放在下一个阶段；
- 分工协作的优势明显，且不同岗位和环节之间边界划分明显；
虽然瀑布模型在软件研发的发展过程中起了至关重要的作用，但瀑布模型也有其不足之处，主要有：
- 工作量分布不均匀，无法提高团队整体的效率；
- 无法及时看到各个阶段的构建结果，到最后测试阶段才能发现问题；
- 难以及时的响应需求的变更，需求变更发生的越晚，修改的代价越大；
- 前期进度block很容易导致后期阶段的工作时间，造成延期或者影响交付质量；
瀑布模型的不足在于只能从上往下依次进行状态流转，生命周期太长。在此基础上，后来有衍生出V模型、W模型、双W模型、增量模型等来改善瀑布模型存在的不足。
到上世纪90年代，Scrum和极限编程等理念不断提出，缩短项目周期的同时也加快了软件的迭代速度。
瀑布模型的核心在于：将软件研发的过程进行分层，变成了工厂流水线作业。
其他衍生模型
增量模型
按模块分批次交付（前提是系统可以模块化），适用于需求清晰，能模块化的软件系统且可以分批次交付。有架构设计中分而治之的理念，本质是按照功能模块进行划分。
迭代模型
每次迭代都交付一个可用版本（规划每次迭代的内容和要达到的目标），从核心功能入手，不断深化细化满足用户需求。缺点是存在冗余，项目周期不可控，需要定时重构。
快速原型模型
解决客户需求不明确和需求多变的问题（软件质量往往容易成为牺牲的代价）；
敏捷开发模型
关于敏捷开发相关的知识和实践，业内已经有了很多案例，这里不做太多赘述，只列举一些较为基础的知识。
敏捷宣言：敏捷不是一种方法论，也不是一种软件开发的具体方法，更不是一个框架或过程，而是一套价值观和原则。
实际工作中遇到的各种敏捷框架和工具，就像是“术”，告诉我们敏捷开发的方式；而敏捷则是“道”，是一套做事的价值观和原则，更多的是在软件开发项目中指导我们做决策。
敏捷和瀑布的区别在于：
- 瀑布的典型特征是周期长/发布烦/变更难（瀑布面向的是软件开发过程）；
- 敏捷开发的特点是快速迭代、持续集成和拥抱变化（敏捷面向的软件开发的人）；
目前比较成熟的一套敏捷实践是：Scrum(管理项目过程)+极限编程(软件工程实践)+看板(工作流可视化)。
敏捷将每一个迭代称之为Sprint，是一种渐进式的架构设计，每个Sprint只做符合当前需求的架构设计。
每个Sprint没有专门的测试i阶段，而是在开发的同时，编写大量的单元测试和自动化测试辅助完成测试。
敏捷开发中每次提交代码都会触发构建部署，拉取最新代码构建并运行单元测试&自动化测试，通过后部署到测试环境。
敏捷开发通过通过“只做刚刚好的设计”来节约设计上的时间；通过“自动化测试”、“持续集成”来提升测试效率。
落地敏捷开发模型，需要满足如下几个条件：
- 团队规模不宜过大，超过一定人数规模就要分拆；
- 团队成员之间要紧密协作，客户也要自始至终深度配合；
- 敏捷需要扁平化的组织结构，更少的控制，更多的发挥项目组成员的主动性（自上而下的支持）；
- 写代码时要有一定比例的自动化测试代码，需要较好的代码管理和版本控制以及比较成熟的持续集成机制；
平衡质量三要素的关系
理想的软件产品研发过程，大家都希望做到“多快好省”，而实际中最多只能选其中两项。参考下面2张图：
软件工程的目标是构建和维护高质量的软件，质量是最核心的内容。
为了保障最终的软件产品质量，在实际的工作中就要学会利用好时间、范围、成本这三要素，以保障软件质量。
如何平衡这三要素的关系，比较好的实践经验是：从上述三要素中找到最核心的一点或亮点，再去调整其他要素。
近几年流行MVP版本(最小化的可行性产品)其实就是平衡三要素的一种实践。
