《软件工程之美》—— 理解软件工程

文章目录

• • • 1、什么是软件工程
    • • 1.1、定义
      • 1.2、演化史
      • 1.3、软件工程的核心
    • 2、Everything is a project
    • • 2.1、什么是工程方法
      • 2.2、使用工程方法的好处
    • 3、软件工程中的过程模型
    • • 3.1 瀑布模型
      • • 3.1.1、定义
        • 3.1.2、优缺点
        • 3.1.3、 衍生模型
        • • 1、快速原型模型
          • 2、增量模型
          • 3、迭代模型
        • 3.1.4 如何选择过程模型
      • 3.2 敏捷开发
      • • 3.2.1、一切工作任务围绕Ticket开展
        • 3.2.2、基于Git和CI的开发流程
        • 3.2.3、部署上线流程
        • 3.2.4、每日站立会议
        • 3.2.5、实践示例
    • 4、软件项目管理金三角

1、什么是软件工程

1.1、定义

想起来在读李智慧老师的《从0开始学大数据》专栏的时候，有一段话印象深刻

不管是学习某门技术，还是讨论某个事情，最好的方式一定不是一头扎到具体的细节里，而是应该从时空的角度先了解它的来龙去脉，以及它为什么会演进成为现在的状态。当你深刻理解了这些前因后果之后，再去看现状，就会明朗很多，也能更直接地看到现状背后的本质。

我也超喜欢李智慧老师！！！

经典教材里给的图，回过头来看真的是很经典的啦~软件工程是应对软件危机诞生的学科，目标就是为了要聚焦于治疗，构建和维护高质量的软件。软件工程的核心就是，围绕软件开发过程，产生的方法学和工具。方法学包含两个部分：过程和方法。

• 过程：在软件项目的生命周期内，要遵循的步骤。
• 方法：过程中的每个步骤要如何进行。

2、Everything is a project

专栏刚出的时候给朋友、同事、领导安利过，也曾在闲暇的时候，在公司内 上搭建了禅道、confluence这些来“方便”大家高效协作。大部分都是不了了之的，更多的时候收获鄙疑（可能不是很合适的词，但是感受是这样的啦~）。回复都是感觉这是”假把式“：
…哇，很棒啊，但是这是领导该做的事情啦…
…项目紧急的时候为啥要花时间在这个上面…
…excel就很好丫…
…学习成本太高…
…领导能力不行…（话题马上就会偏，捂脸）

嗯，我从没质疑过，刚工作的时候被不知所云随便去 上抄一下的概要设计文档折磨的时候，领导就拍肩说：文档的目的是让你把重点说清楚。人生的一道闪光啊！所以工作中更多是感受到工程化方法带来的好处（感谢DZQ）。宝玉老师在这里说到的“掌握工程思维，把每一件事都当作一个工程项目来推进。”给了我更多的向别人安利好用的工具，好的工程方法的理由。

2.1、什么是工程方法

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

3.1 瀑布模型

边改边写（Code And Fix）模型无法满足复杂软件项目的原因：

• 整个开发过程不可控，基于这种开发模式做计划太难
• 项目人数上升后难以有效分工协作
• 缺少对需求的有效分析，容易导致后期返工
• 没有有效测试，难以保证程序质量

基于此，借鉴建筑工程提出了瀑布开发模型。

3.1.1、定义

瀑布模型将项目划分成六个主要阶段：

• 问题定义及规划：需求方和开发方共同制定开发目标，可行性研究。输出【需求文档】和【可行性研究 告】。
• 需求分析：对需求方提出的需求进行详细分析。输出【需求分析文档】。
• 软件设计：根据需求分析的结果，对整个软件系统进行抽象和设计，包含架构设计、数据库设计等等。输出【框架设计文档】。
• 程序编码：将架构设计和界面设计的结果转换成计算机能运行的程序代码。输出【可运行程序】
• 软件测试：对可运行的结果对照需求分析文档进行测试。输出【测试 告】
• 运行维护：正式投入使用后，需要继续维护，修复错误，增加功能。输出【使用说明文档】

3、迭代模型

场景：按照时间来拆分项目，看单位时间内完成的功能。
定义：每一个迭代结束时，要完成一个可以运行交付的版本。

敏捷开打不是具体方法、框架或过程，是一套价值观和原则。

想解决的问题：用一种轻量的、敏捷的方法来改善瀑布模型中的问题。
软件工程中必不可少的四个阶段，敏捷开发的做法：

• 需求分析：建立一个个用户故事
• 架构设计：每个迭代中只做一部分需求，渐进式架构设计。
• 质量保证：自动化测试，开发的同时编写单元测试和集成测试代码。
• 发布部署：持续集成。

敏捷开发和迭代模型的区别：

• 没有严格的阶段划分
• 节奏恒定，产品相对稳定，需求未完成不影响发布

敏捷开发适用条件：

• 团队要小，超过规模要进行分拆
• 团队成员之间要紧密协作，客户也要自始至终深度配合
• 扁平化的组织结构，更少的控制。
• 有一定比例的自动化测试代码，有好的源码管理和持续集成环境。

介绍一些大厂在用的敏捷方法。

3.2.1、一切工作任务围绕Ticket开展

适用看板来跟踪任务状态。

阮一峰老师的两篇文章写的超级好：
Git工作流程
持续集成是什么

3.2.3、部署上线流程

在流程上对上线部署进行控制：

• 不再部署程序代码，而是Dockers的Image，每次代码合并后CI自动生成新的Image，测试也是基于Image测试
• 部署生产环境前，现在内部的测试环境充分测试
• 部署生产环境前，需要审批确认，有Ticket跟踪。
• 部署时，先部署一部分，监测正常后再全量部署。
• 整个过程都有监控 警，出现问题及时回滚。

3.2.4、每日站立会议

站立会议主要是为了高效沟通反馈，一般控制在半小时内。站立会议的一般流程：

• 成员轮流发言：介绍昨天任务内容，今天计划内容，工作障碍。会议主持者要及时打断偏离主题的问题，建立问题停车场。
• 检查最新的Ticket：检查新增的Ticket，甄别优先级。
• 停车场问题：针对之前来不及讨论的问题进行讨论，能在会议时间解决的立马解决，不能解决的另外组织会议或私下讨论。

3.2.5、实践示例

人员：4个程序员（至少一个资深，有架构能力），1个产品经理，1个测试，1个项目经理。
分工：

• 产品经理：写需求设计文档，将需求整理成Ticket，随时和成员沟通确认需求。
• 开发人员：每天从看板上按优先级从高到低领取Ticket，完成日常开发任务。
• 测试人员：测试已经部署到测试环境的程序，发现bug，提交Ticket。
• 项目经理：保障日常工作流程正常执行，让团队成员可以专注工作，提供必要帮助，解决问题。

每周一个sprint：

• 周一：部署生产环境
• 周二：迭代回顾会议，总结上个sprint
• 周四：迭代规划会议，计划下个sprint工作
• 周五：分支切割
• 每周轮值：鼓励发挥每个成员的主动性

其中迭代规划会议中，需要对大家一起评估Ticket，可参考的流程如下：

• 会议组织者阅读Tikcet，同时询问大家对内容是否存在疑问。
• 大家一起讨论Ticket，确保充分理解Ticket
• 每个成员在心中对Ticket进行工作量估算，评分。
• 会议组织者确保同时确认估算结果。
• 如果估算存在分析，最高分和最低分各自说明理由，讨论达成一致。

4、软件项目管理金三角

了解了软件工程的核心，掌握了工程思维，实践中对软件项目的管理需要建立理性的认知，必要时进行合理取舍。
软件项目中有一个平衡关系：

• 软件质量：产品的质量，客户满意度
• 范围：需要实现多少功能
• 实践：多久可以完成
• 成本：花多少钱

瀑布模型的范围是固定的，时间和成本是变量。出现不能如期完成进度时，通常选择加人或加班。
敏捷开发中，时间和成本两条边时固定的，范围是变量。所以在每个sprint开始之前的迭代规划会议十分重要。

但看理论的部分其实感觉会很枯燥，但是通过实例的分析，发现掌握了矛盾的本质，就理解了现象的因。
男票说看完时间、成本和范围的这部分后，直到怎么扯皮哈哈哈，超可爱~