扫码阅读
手机扫码阅读

软件工程基础知识总结

271 2023-08-25
上一篇文章总结了关于软件工程的一些基本知识,包括如何理解软件工程、为什么要学习软件工程以及学习软件工程的一些思路和方法。这篇文章,是对软件工程基础理论知识的部分总结和归纳,我会尝试用自己理解的语言来描述。
PS:这是一篇学习笔记式的文章,而非详细的落地实践。

培养工程思维

亢长枯燥的理论知识,对很多同学来说是一个巨大的挑战。那么如何简单的理解软件工程呢?
简单来说就是多人参与、有计划有步骤的构造一个符合质量标准的软件产品,这个过程称之为软件工程我们都知道,参与人越多、产品越复杂、流程越繁琐,最终构造的软件产品就越可能出现问题。
软件工程出现的初衷,就是为了摆脱软件质量危机,其核心内容是要用工程化的方法去规范软件开发,让软件开发项目可以按时保质完成的同时且成本可控
对我们从事软件研发相关工作的同学来说,要做好本职工作,需要系统的学习软件工程相关的知识,培养软件工程思维。抽象归纳可以称之为一个核心三个方法,即:以软件开发为核心,对开发过程组织+对方法的运用+对工具的使用
软件工程方法一般分为六个阶段,即:想法、概念、计划、设计、开发、发布。如下图所示:
利用这六个或者其中几个阶段对照日常工作中遇到的问题,将这些问题都看作一个项目,并且逐步拆分去完成,你会发现这种有目的、有计划、有步骤的解决问题的方法就是工程方法(Everything is a project)。
实际上,无论是软件工程还是其他类似时间管理的方法论,其本质,都是结构化的一种思维方式。结构化思维提倡的是从总体的角度去看待问题,然后不断拆解,在这个过程中关注项目的质量、进度、成本和用户体验。尝试将这种解决问题的思路和方法应用到工作生活中,你也就拥有了工程思维。

研发过程如何管理

软件工程的核心是为了控制研发过程以保证最终的交付质量,但研发过程管理的方法并不是从一开始就完备的,它也经历了一系列不断的探索和迭代。整个软件开发过程,一般分为:需求分析、架构设计、编码实现、测试验证、交付维护几个阶段。每个阶段需要不同的人参与,因此就有我们所熟知的项目经理、产品经理、架构师、开发工程师、测试工程师、运维工程师等角色。对整个研发过程的管理,一般称之为“项目管理”。

瀑布模型

瀑布模型大家应该都很熟悉,最初软件工程中关于项目管理的方法就是瀑布模型。
瀑布模型是现代软件工程的起源,现在很多流行的项目管理方法大多都是构建于瀑布模型基础上。从瀑布模型诞生之后,才有了软件生命周期这个概念。虽然现在很多互联网企业开始应用了其他更高效的项目管理方法,但软件研发的本质离不开瀑布模型的核心部分,即需求、设计、编码和测试。瀑布模型的优点在于:
  • 简单易懂,只需要遵循流程执行即可;
  • 可以在不同阶段进行检查,及时发现问题;
  • 前一个阶段完成后就可以将关注重心放在下一个阶段;
  • 分工协作的优势明显,且不同岗位和环节之间边界划分明显;
虽然瀑布模型在软件研发的发展过程中起了至关重要的作用,但瀑布模型也有其不足之处,主要有:
  • 工作量分布不均匀,无法提高团队整体的效率;
  • 无法及时看到各个阶段的构建结果,到最后测试阶段才能发现问题;
  • 难以及时的响应需求的变更,需求变更发生的越晚,修改的代价越大;
  • 前期进度block很容易导致后期阶段的工作时间,造成延期或者影响交付质量;
瀑布模型的不足在于只能从上往下依次进行状态流转,生命周期太长。在此基础上,后来又衍生出V模型、W模型、双W模型、增量模型等来改善瀑布模型存在的不足。到上世纪90年代,Scrum和极限编程等理念不断提出,缩短项目周期的同时也加快了软件的迭代速度。
瀑布模型的核心在于:将软件研发的过程进行分层,变成了工厂流水线作业

其他衍生模型

增量模型

按模块分批次交付(前提是系统可以模块化),适用于需求清晰,能模块化的软件系统且可以分批次交付。有架构设计中分而治之的理念,本质是按照功能模块进行划分。

迭代模型

每次迭代都交付一个可用版本(规划每次迭代的内容和要达到的目标),从核心功能入手,不断深化细化满足用户需求。缺点是存在冗余,项目周期不可控,需要定时重构。

快速原型模型

解决客户需求不明确和需求多变的问题(软件质量往往容易成为牺牲的代价);

敏捷开发模型

关于敏捷开发相关的知识和实践,业内已经有了很多案例,这里不做太多赘述,只列举一些较为基础的知识。
敏捷宣言:敏捷不是一种方法论,也不是一种软件开发的具体方法,更不是一个框架或过程,而是一套价值观和原则。
实际工作中遇到的各种敏捷框架和工具,就像是“术”,告诉我们敏捷开发的方式;而敏捷则是“道”,是一套做事的价值观和原则,更多的是在软件开发项目中指导我们做决策。
敏捷和瀑布的区别在于:
  • 瀑布的典型特征是周期长/发布烦/变更难(瀑布面向的是软件开发过程);
  • 敏捷开发的特点是快速迭代、持续集成和拥抱变化(敏捷面向的软件开发的人);
目前比较成熟的一套敏捷实践是:Scrum(管理项目过程)+极限编程(软件工程实践)+看板(工作流可视化)。敏捷将每一个迭代称之为Sprint,是一种渐进式的架构设计,每个Sprint只做符合当前需求的架构设计。每个Sprint没有专门的测试i阶段,而是在开发的同时,编写大量的单元测试和自动化测试辅助完成测试。
敏捷开发中每次提交代码都会触发构建部署,拉取最新代码构建并运行单元测试&自动化测试,通过后部署到测试环境。敏捷开发通过通过“只做刚刚好的设计”来节约设计上的时间;通过“自动化测试”、“持续集成”来提升测试效率。
落地敏捷开发模型,需要满足如下几个条件:
  • 团队规模不宜过大,超过一定人数规模就要分拆;
  • 团队成员之间要紧密协作,客户也要自始至终深度配合;
  • 敏捷需要扁平化的组织结构,更少的控制,更多的发挥项目组成员的主动性(自上而下的支持);
  • 写代码时要有一定比例的自动化测试代码,需要较好的代码管理和版本控制以及比较成熟的持续集成机制;

平衡质量三要素的关系

理想的软件产品研发过程,大家都希望做到“多快好省”,而实际中最多只能选其中两项。参考下面2张图:
软件工程的目标是构建和维护高质量的软件,质量是最核心的内容。
为了保障最终的软件产品质量,在实际的工作中就要学会利用好时间、范围、成本这三要素,以保障软件质量。
如何平衡这三要素的关系,比较好的实践经验是:从上述三要素中找到最核心的一点或亮点,再去调整其他要素。
近几年流行MVP版本(最小化的可行性产品)其实就是平衡三要素的一种实践。

想要了解更多,点击 查看原文