《软件工程之美》笔记
《软件工程之美》笔记
到底应该怎样理解软件工程？
软件产品危机：软件产品质量低劣、软件维护工作量大、成本不断上升、进度不可控、程序人员无限度地增加。
软件工程，它是为研究和克服软件危机而生。
软件工程的本质：用工程化方法去规范软件开发，让项目可以按时完成、成本可控、质量有保证。
软件工程的核心：是围绕软件项目开发，对开发过程的组织，对方法的运用，对工具的使用。
软件工程 = 过程 + 方法 + 工具。
工程思维：把每件事都当作一个项目来推进
有目的、有计划、有步骤地解决问题的方法就是工程方法。
工程方法通常会分成六个阶段：想法、概念、计划、设计、开发和发布。
- **想法：**想法阶段通常是想要解决问题。最开始问题通常是模糊的，所以需要清晰地定义好问题，研究其可行性，检查是否有可行的解决方案。
- **概念：**概念阶段就是用图纸、草图、模型等方式，提出一些概念性的解决方案。这些方案可能有多个，最终会确定一个解决方案。
- **计划：**计划阶段是关于如何实施的计划，通常会包含人员、任务、任务持续时间、任务的依赖关系，以及完成项目所需要的预算。
- **设计：**设计阶段就是要针对产品需求，将解决方案进一步细化，设计整体架构和划分功能模块，作为分工合作和开发实施的一个依据和参考。
- **开发：**开发阶段就是根据设计方案，将解决方案构建实施。开发阶段通常是一个迭代的过程，这个阶段通常会有构建、测试、调试和重新设计的迭代。
- **发布：**将最终结果包括文档发布。
瀑布模型：像工厂流水线一样把软件开发分层化
瀑布模型把整个项目过程分成了六个主要阶段：
- 问题的定义及规划：这个阶段是需求方和开发方共同确定软件开发目标，同时还要做可行性研究，以确定项目可行。这个阶段会产生需求文档和可行性研究报告。
- 需求分析：对需求方提出的所有需求，进行详细的分析。这个阶段一般需要和客户反复确认，以保证能充分理解客户需求。最终会形成需求分析文档。
- 软件设计：根据需求分析的结果，对整个软件系统进行抽象和设计，如系统框架设计，数据库设计等等。最后会形成架构设计文档。
- 程序编码：将架构设计和界面设计的结果转换成计算机能运行的程序代码。
- 软件测试：在编码完成后，对可运行的结果对照需求分析文档进行严密的测试。如果测试发现问题，需要修复。最终测试完成后，形成测试报告。
- 运行维护：在软件开发完成，正式运行投入使用。后续需要继续维护，修复错误和增加功能。交付时需要提供使用说明文档。
瀑布模型之外，还有哪些开发模型？
快速原型模型
快速原型模型，就是为了要解决客户的需求不明确和需求多变的问题。
先迅速建造一个可以运行的软件原型，然后收集用户反馈，再反复修改确认，使开发出的软件能真正反映用户需求，这种开发模型就叫快速原型模型，也叫原型模型。
原型模型因为能快速修改，所以能快速对用户的反馈和变更作出响应，同时原型模型注重和客户的沟通，所以最终开发出来的软件能够真正反映用户的需求。
但这种快速原型开发往往是以牺牲质量为代价的。
增量模型
增量模型是把待开发的软件系统模块化，然后在每个小模块的开发过程中，应用一个小瀑布模型，对这个模块进行需求分析、设计、编码和测试。相对瀑布模型而言，增量模型周期更短，不需要一次性把整个软件产品交付给客户，而是分批次交付。
因为增量模型的根基是模块化，所以，**如果系统不能模块化，那么将很难采用增量模型的模式来开发。**另外，对模块的划分很抽象，这本身对于系统架构的水平是要求很高的。
基于这样的特点，增量模型主要适用于：需求比较清楚，能模块化的软件系统，并且可以按模块分批次交付。
迭代模型
迭代模型每次只设计和实现产品的一部分，然后逐步完成更多功能。每次设计和实现一个阶段叫做一个迭代。
在迭代模型中，整个项目被拆分成一系列小的迭代。通常一个迭代的时间都是固定的，不会太长，例如 2-4 周。每次迭代只实现一部分功能，做能在这个周期内完成的功能。
在一个迭代中都会包括需求分析、设计、实现和测试，类似于一个小瀑布模型。迭代结束时要完成一个可以运行的交付版本。
增量模型是按照功能模块来拆分；而迭代模型则是按照时间来拆分，看单位时间内能完成多少功能。
V 模型
V 模型适合外包项目。V 模型本质上还是瀑布模型，只不过它是更重视对每个阶段验收测试的过程模型。
针对从需求定义一直到编码阶段，每个阶段都有对应的测试验收。
螺旋模型
如果你现在要做一个风险很高的项目，客户可能随时不给你钱了。这种情况下，如果采用传统瀑布模型，无疑风险很高，可能做完的时候才发现客户给不了钱，损失就很大了！
这种情况，基于增量模型或者迭代模型进行开发，就可以有效降低风险。你需要注意的是，在每次交付的时候，要同时做一个风险评估，如果风险过大就不继续后续开发了，及时止损。
这种强调风险，以风险驱动的方式完善项目的开发模型就是螺旋模型。
敏捷开发到底是想解决什么问题？
敏捷开发是一套价值观和原则。
瀑布模型面向的是过程，而敏捷开发面向的是人。
大厂都在用哪些敏捷方法？（上）
一切工作任务围绕 Ticket 开展
- 每一个任务的状态都可以被跟踪起来：什么时候开始做的，谁在做，做完没有。
- 整个团队在做什么一目了然。
- Ticket 和敏捷开发中的 Backlog（任务清单）正好结合起来，通过 Ticket 可以收集管理整个项目的 Backlog 和当前 Sprint（迭代）的 Backlog。
基于 Git 和 CI 的开发流程
Git 本来只是源代码管理工具，但是其强大的分支管理和灵活的权限控制，结合一定的开发流程，却可以帮助你很好的控制代码质量。
站立会议
- 每个人轮流介绍一下，昨天干了什么事情，今天计划做什么事情，工作上有没有障碍无法推进。有问题，记录到“问题停车场”。
- 检查最近的 Ticket，甄别一下优先级。有需要讨论的先收集到问题停车场。
- 针对未讨论的问题展开讨论，能在会议时间内解决的问题，就马上解决，不能解决的会后再私下讨论或者再组织会议。
大厂都在用哪些敏捷方法？（下）
在分工上：
- 产品经理：写需求设计文档，将需求整理成 Ticket，随时和项目成员沟通确认需求；
- 开发人员：每天从看板上按照优先级从高到低领取 Ticket，完成日常开发任务；
- 测试人员：测试已经部署到测试环境的程序，如果发现 Bug，提交 Ticket；
- 项目经理：保障日常工作流程正常执行，让团队成员可以专注工作，提供必要的帮助，解决问题。
如何完成需求和修复 Bug？
日常工作，是围绕 Ticket 来开展的。所有的需求、Bug、任务都作为 Ticket 提交到项目的 Backlog，每个 Sprint 的任务都以看板的形式展现出来。
每个人手头事情忙完后，就可以去看板上的“To Do”栏，按照优先级从高到低选取新的 Ticket。选取后移动到“In Progress”栏。
每周一部署生产环境