说说软件工程 [复制链接]

xx：你是软件工程毕业的哦?

我：嗯

xx：说说HashMap与HashSet的区别？

我：忘了

xx：如何实现线程同步？

我：忘了

……

我：软件工程是一种思维方式，不是你眼中简单的coding，低级

这些都还给了大学课堂上吐沫横飞的老教授。软件工程毕业，敲代码的时间寥寥无几，在学校里与社会严重脱节，以为毕业了只能敲代码或者做测试，毕业后阴错阳差成了产品经理（不对，一定要说我是想改变世界才成为产品经理的）。

现在说起软件工程，只能是妄论了，本来也觉着自己不配聊，但是总有朋友对这个很好奇，我就斗胆胡诌两句，真想深入了解的，建议直接买一本大学软件工程的教材（虽然我们整个专业叫软件工程，但是软件工程也是单独一门课，也就上了半个学期），除了算法部分，其余都是汉字，不难理解。英文好的建议找英文文献，因为部分理论在转化为中文时，发生了词义的变化，英文原文更加准确。

行文结构如下：

什么是软件工程？

采用工程的概念、原理、技术和方法来开发和维护软件，把经过时间考验证明正确的管理技术和当前最好的技术方法结合起来，经济地开发出高质量的软件并维护它，这就是软件工程。

凡事都有第一性原理，对于软件工程来说，有7条基本原理：

用分阶段的生命周期计划严格管理——kickoff、里程碑、进度管理、上线计划、运维计划、迭代计划等；

坚持进行阶段评审——需求、UI、测试、技术方案等评审，初期评审的省略，会给后期上线带来不可预估的风险；

实行严格的产品控制——严格控制需求变更；

采用先进程序设计技术；

结果可验证——预期结果可被验证，例如xx指标提升；

开发小组人员应该少而精——以前一个同事的例子就是，一个女人十个月生下来一个孩子，但是十个女人不可能一个月生一个孩子，人员的简单堆砌，多数时候并不能提高效率，因为人员增加导致的沟通成本也是指数级增加，同时大大提高了项目管理难度；

承认不断改进的必要性——于单个项目，或者软件工程实践方法而言，都是要在不断实践中，不断迭代改变，才能找到因地制宜的最佳实践。

具体在实践过程中，软件工程范围包括：

软件需求——就是我们平常说的MRD（论证可行性：现在的经济、*策条件、用户群体等是否支持这个项目）、PRD（说明如何做：我们最终期望完成一个怎样的软件产品）

软件设计——技术概要设计，定义架构、组件、接口等

软件构建——软件实际的生产过程：编码、验证、单元测试、集成测试、上线调试等

软件测试——软件产品的质检，确保软件产品是按照PRD描述期望的样子被生产出来；

软件维护、配置管理——软件产品迭代优化、软件产品需求变更管理，类似于产品版本管理；

软件工程管理——现代软件项目进度控制管理；

软件工程工具和方法——通过通用的工具、符号、词汇表等，将重复且明确的动作自动化，减少重复操作。这个取决于技术工具的发展、团队内部的约定，所以一般没有通用规范；

软件质量——内在特征满足需求的程度。

软件生命周期

软件生命周期由软件定义、软件开发、运行维护三个时期组成。软件开发和运行维护主要涉及开发和运维，这里不再赘述。

软件定义包括：问题定义——》可行性研究——》需求分析。其中最重要是问题定义，如果不知道问题是什么就试图解决这个问题，显然是盲目的，只会白白浪费时间。这个过程对应产品日常工作中的MRD和PRD。

MRD市场需求文档只描述产品机会：一般由业务人员撰写，论证产品可行性。而评估产品机会是产品经理的重要职责，此阶段不应设计具体的解决方案，我们需要回答这些问题：

产品要解决什么问题？——产品价值

为谁解决这个问题？——目标市场

成功的机会有多大？——市场规模

怎样判断产品成功与否？——度量指标或收益指标

有哪些同类产品？——竞争格局

为什么我们最适合做这个产品？——竞争优势

时机合适吗？——市场时机

如何把产品推向市场？——营销组合策略

成功的必要条件是什么？——解决方案要满足的条件（产品的依赖因素和约束条件）

以上问题来自《启示录》，根据以上问题，给出评估结论。——继续或放弃

继续就进入需求分析阶段，PRD需求分析文档描述的是产品的理想情况和内在实现逻辑。关于一份理想的PRD是什么样的，各个公司各个产品都有自己的理解，也不存在一份统一的格式，虽然不是文档驱动开发，但是PRD无疑是软件开发过程中各个节点所参考依赖的最重要依据，交互UI需要根据prd出交互稿、UI稿，开发需要根据prd进行概要设计、详细设计，测试需要根据prd给出测试用例。目前为止，看到关于prd最好的描述，来自纯银：

写好一份疑义性小，可读性强的prd不亚于写好一篇文章。

软件工程-方法

为了尽可能准确地了解用户当前的情况和需要解决的问题，以及保障最终设计出满足用户真实诉求的产品，我们采用抽象建模的方式完成软件产品的分析和设计。模型是对事物的一种无歧义的书面描述，结构化是通过树状结构总结要点（结构化梳理的好处是不重不漏，满足MECE原则）。

1、结构化分析

结构化分析就是按照既定模型结构分析实体，建立当前软件实体模型的过程。下图来自《软件工程》教材：

数据字典：软件使用/产生的数据对象，是分析的核心；

实体-关系图（E-R图）：描述数据对象之间的关系；

数据流图：数据在软件中的移动和变换过程；（源点、终点、处理、数据存储、数据流）

状态转换图：系统的各种状态和不同状态间的转换方式；

用例图：由参与者（Actor）、用例（UseCase），边界以及它们之间的关系构成的用于描述系统功能的视图。

某系统交易交收管理用例图

2、结构化设计（系统性设计）

系统性设计要求：要点无一遗漏、互相连接、跑通流程，原则是高内聚低耦合。

内聚标志着一个模块内各个元素彼此结合的紧密程度，理想内聚的模块只做一件事情。内聚程度如下由浅及深：

偶然内聚——一个模块完成一组任务，任务间有关系，但是关系松散；

逻辑内聚——一个模块完成的任务在逻辑上属于相同/相似一类；

时间内聚——一个模块完成的任务必须在同一段时间内执行；

过程内聚——一个模块完成的任务是相关的，且必须以特定次序执行；

通信内聚——一个模块所有的元素都使用同一个输入/产生同一个输出数据；

顺序内聚——一个模块内的处理元素和同一个功能密切相关，而且这些处理必须顺序执行；

功能内聚——一个模块内的处理元素属于一个整体，完成一个单一的功能；

耦合指一个软件结构内不同模块间的互连程度，如果耦合松散，那么一个模块的错误扩散到整个系统的可能性就很小，因此软件设计追求的是尽可能的松耦合。

两个模块通过参数交换数据为数据耦合，属于低耦合；

两个模块通过参数交换控制信息为控制耦合，属于中耦合，控制耦合往往是多余的；

如果把整个数据结构作为参数传递，但是被调用的模块只需要使用部分数据元素，就是特征耦合，会出现数据访问漏洞，有泄露风险；

当多个模块通过一个公共数据环境作用时，就出现了公共环境耦合；

一个模块访问另一个模块内部数据，一个模块通过非正常入口访问另一个模块，模块代码重叠，一个模块有多个入口，这就造成了内容耦合。

耦合程度由上往下逐渐加深，也会造成软件复杂度直线升高，数据耦合较为常见，内容耦合是不被允许的。

3、结构化实现

实现环节涉及编码和测试。

对于编码，一个产品不能班门弄斧，但是简单清晰、易读易懂绝对是好程序的重要标准，因为一个软件需要不断迭代，会经过若干个程序员接手，接手的程序员如果遇到一段易读的代码，简直要给前任烧香。

测试目的是要保障软件实现符合PRD设计，因此要做到逻辑覆盖，软件工程中对逻辑覆盖有明确的要求：

语句覆盖：为了暴露程序中的错误，每个语句至少要被执行一次；

判定覆盖：每个判定的每种可能结果至少应该执行一次（每个判定的每个分支）；

条件覆盖：判定表达式中的每个条件都取到各种可能的结果；

判定/条件覆盖：1、2、3均满足；

条件组合覆盖：使得每个判定表达式中条件的各种可能组合都至少出现一次。

4、统一建模语言

软件工程通过统一建模语言UML完成软件过程的工程化管理，UML三大模型为：对象、功能、动态，UML主要用图来表达模型内容，涉及5类图：

这些在现代的敏捷开发中部分被简化掉，大多由开发人员完成。

软件工程不是产品成功学，它不是产品市场成功的包票，也没有印着个人财富密码。于现代的小步快跑敏捷迭代而言，它甚至显得有些过时和形而上学，没学过这些也并不耽误谁设计开发一款产品。还是那句话：软件工程不仅仅是coding，它只是提供了另一个看待项目或者世界的角度——以工程学的角度管理软件过程。