《极客时间教程 - 软件工程之美》笔记

到底应该怎样理解软件工程？

软件产品危机：质量低劣、维护量大、成本上升、进度不可控、人员无限度增加。

软件工程：为研究和克服软件危机而生。

• 本质：用工程化方法规范软件开发，让项目按时完成、成本可控、质量有保证
• 核心：围绕项目开发，对过程的组织、方法的运用、工具的使用
• 公式：软件工程 = 过程 + 方法 + 工具

工程思维：把每件事都当作一个项目来推进

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

工程方法六个阶段：

• 想法：定义问题，研究可行性
• 概念：提出概念性解决方案（图纸/模型），确定最终方案
• 计划：人员、任务、时长、依赖关系、预算
• 设计：细化解决方案，设计架构和划分功能模块
• 开发：根据设计方案构建实施（包含构建、测试、调试的迭代）
• 发布：发布最终结果和文档

瀑布模型：像工厂流水线一样把软件开发分层化

瀑布模型六个阶段：

• 问题定义及规划：确定开发目标，可行性研究 → 需求文档 + 可行性报告
• 需求分析：详细分析需求，与客户反复确认 → 需求分析文档
• 软件设计：系统抽象设计（框架、数据库等）→ 架构设计文档
• 程序编码：将设计转换为计算机可运行的代码
• 软件测试：对照需求文档严密测试，修复问题 → 测试报告
• 运行维护：正式运行后持续维护、修复错误、增加功能 → 使用说明文档

瀑布模型之外，还有哪些开发模型？

快速原型模型

快速原型模型：解决客户需求不明确和需求多变的问题。

先迅速建造可运行原型 → 收集用户反馈 → 反复修改确认 → 使软件真正反映用户需求。

• 优势：快速响应用户反馈和变更，注重客户沟通
• 劣势：往往以牺牲质量为代价

增量模型

将软件系统模块化，每个模块应用小瀑布模型（需求分析→设计→编码→测试），分批次交付。

• 前提：系统必须能模块化。不能模块化的系统无法采用增量模型
• 适用场景：需求清晰、能模块化、可按模块分批次交付

迭代模型

每次只设计和实现产品的一部分，逐步完成更多功能。每次设计和实现一个阶段叫做一个迭代。

• 迭代时间固定且较短（通常 2-4 周）
• 每次迭代包含需求分析、设计、实现和测试
• 迭代结束时要完成一个可运行的交付版本

增量模型 vs 迭代模型：增量按功能模块拆分；迭代按时间拆分。

V 模型

本质还是瀑布模型，但更重视每个阶段的验收测试。从需求定义到编码，每个阶段都有对应的测试验收。适合外包项目。

螺旋模型

适用于风险较高的项目。基于增量/迭代模型开发，每次交付时进行风险评估，风险过大则及时止损。

以风险驱动的方式完善项目的开发模型。

敏捷开发到底是想解决什么问题？

敏捷开发是一套价值观和原则。

瀑布模型面向过程，敏捷开发面向人。

大厂都在用哪些敏捷方法？（上）

一切工作任务围绕 Ticket 开展

• 任务状态可追踪：开始时间、负责人、完成情况
• 团队工作内容一目了然
• Ticket 与敏捷开发的 Backlog 结合，管理项目和当前 Sprint 的任务

基于 Git 和 CI 的开发流程

Git 的强分支管理和灵活权限控制，结合开发流程，可有效控制代码质量。

站立会议

1. 每人轮流介绍：昨天做了什么、今天计划做什么、有无障碍
2. 检查最近 Ticket，甄别优先级，有问题记录到“问题停车场”
3. 未讨论的问题展开讨论，能当场解决就解决，不能则会后处理

大厂都在用哪些敏捷方法？（下）

角色分工：

• 产品经理：写需求文档，整理 Ticket，沟通确认需求
• 开发人员：从看板按优先级领取 Ticket，完成开发
• 测试人员：测试已部署的程序，发现 Bug 提交 Ticket
• 项目经理：保障流程正常执行，提供必要帮助

日常流程：围绕 Ticket 开展。所有需求/Bug/任务作为 Ticket 进入 Backlog，每个 Sprint 以看板展示。完成后从“To Do”栏按优先级选取新 Ticket，移至“In Progress”栏。每周一部署生产环境。

参考资料

• 极客时间教程 - 软件工程之美