《软件工程之美》总结四：系统设计、开发编码、软件测试、运行维护

架构设计

复杂的软件项目通常有两个特点：需求不确定和技术复杂

技术复杂主要体现在：需求复杂导致、人员过多导致、技术本身导致、软件稳定运行导致

架构设计可以降低满足需求和需求变化的开发成本、可以帮助组织人员一起高效协作、可以帮助组织好各种技术、可以保障服务稳定运行

什么是架构设计

用最小的人力成本来满足需求的开发和响应需求的变化，用最小的运行成本来保障软件的运行

架构设计的本质要求就是组织人员和技术把系统和团队拆分，并安排好切分后的排列关系，让拆分后的部分能通过约定好的协议相互通信，共同实现最终的结果

步骤

1 分析需求

2 选择相似的成熟的架构设计方案

3 自顶向下层层细化

部署架构、开发架构（如分层）、API/数据库表/模块设计

4 验证、优化架构设计方案

可参考《从零开始学架构》，也可以看本人关于此课程的总结

技术选型

受制于时间、范围和成本的约束，要分析可行性和风险，要考虑利益相关人

步骤：问题定义、调研、验证、决策，也是根据工程思维得出来的

1 问题定义

为什么需要技术选型？技术选型的目标是什么？

只有明确了技术选型的目标，才能有一个标准可以来评判该选择哪一个方案

2 调研

满足技术选型目标吗？ 满足范围、时间和成本的约束吗？ 是不是可行？ 有什么样的风险？风险是不是可控？ 优缺点是什么？

3 验证

可以通过一 个小型的快速原型项目，用候选的技术方案快速做一个原型出来，做的过程中才能知道选择的技术选型是不是真的能满足技术选型的目标

4 决策

架构师思维

抽象思维、分治思维、复用思维、迭代思维

技术债务

有一些技术债务是开发人员在时间、成本减少的情况下造成的，大家心里有数，不一定是坏的，因此要清楚地知道项目有哪些技术债务，以及它给项目带来的收益和产生利息，这样才能管理好这些债务

《重构》把技术债务产生的原因分成了两个维度：
1 轻率（reckless）还是谨慎（prudent）；
2 有意（deliberate）还是无意（inadvertent）

全部分为四个：轻率/有意、谨慎/有意、轻率/无意、谨慎/无意

如何管理

目标：保证软件项目中的收益大于支付的利息

可以通过很多指标来发现软件项目存在的技术债务：开发速度降低、单元测试代码覆盖率低、代码规范检查的错误率高、Bug数量越来越多

处理方式：重写、维持、重构

根据系统特点、人员量等得出的性价比来决定

对于重写的策略，要当作一个正式的项目来立项，按照项目流程推进；
对于重构的策略，要把整个重构任务拆分成一个个小任务，放到项目计划中，创建成Ticket，放到任务跟踪系统中跟踪起来；
对于维持的策略，也要把需要做的修补工作作为任务，放到计划中，放到任务跟踪系统中

如何预防

预先投资、不走捷径、不得不走捷径时记得及时还债

开发效率

以终为始，想清楚要的结果再开工

持续交付

持续集成：持续频繁地将代码从分支集成到主干，并且要保证在合并到主干之前，必须要通过所有的自动化测试。

持续交付：基于持续集成，在自动化测试完成后，同时构建生成各个环境的发布包，部署到测试环境，生产环境的部署则需要手动确认。

持续部署：在持续交付的基础上，对生产环境的部署也采用自动化

解决问题

1 明确问题

2 拆分和定位问题

3 提出解决方案并总结，提出预防方案

自动化测试

是敏捷开发能快速迭代很重要的质量保障，是持续交付的基础前提，可以最大可能地保障服务是稳定的

分为小型、中型、大型

小型测试是为了验证一个代码单元的功能，例如针对一个函数或者一个类的测试，单元测试就 是一个典型的小型测试

中型测试是验证两个或多个模块应用之间的交互，通常也叫集成测试

大型测试则是从较高的层次运行，把系统作为一个整体验证。会验证系统的一个或者所有子系统，从前端一 直到后端数据存储。大型测试也叫系统测试或者端对端测试

小型测试，没有外部服务的依赖，都是要模拟的；
中型测试，所有的测试几乎都不需要依赖其他服务器的资源，如果有涉及其他机器的服务，则本地模拟， 这样本机就可以完成测试；
大型测试，几乎不模拟，直接访问相关的外部服务。

还有一个契约测试，是针对微服务的：微服务在测试时，不需要依赖于引用的外部的微服务，在本地就可 以模拟运行，同时又可以保证外部微服务的接口更新时，本地模拟的接口（契约）也能同步更新，属于中型测试的一种

测试步骤：准备、执行、断言、清理

一般需要三个部分的测试：验证功能是否正确、覆盖边界条件、异常和错误处理

自动测试配合持续集成的一个标准流程：

1 在提交代码前，先本地跑一遍单元测试，这个过程很快，失败了需要继续修改

2 单元测试成功后就可以提交到源代码管理中心，提交后持续集成服务会自动运行完整的自动化测试，不仅包括小型测试，还有中型测试

3 通过所有的测试后，就可以合并到主分支，如果失败，需要本地修改后再次提交，直到通过所有的测试为 止

源代码管理工具

Github flow：

1 创建分支

2 开发

3 提交更新

4 PR

5 code review

6 部署测试

7 合并

bug修复：

如果线上发布的版本（例如v1.0）发现Bug，需要修复，那么基于之前的Tag创建一个分支（例如hotfixv1.0-xxx）出去，在分支上修复，然后提交PR，代码审查和自动化测试通过后，从分支上创建一个新的Tag （例如v1.0.1），将新的Tag发布部署到生产环境，最后再把修改合并回master

如果bug修复频繁，可以在每次发布后，创建一个发布版本的分支，例如release-v1.0，每次打补丁，都直接从发布分支releasev1.0而不是master创建新的分支（例如hotfix-release-v1.0-xxx），修复后提交PR，代码审查和自动化测试通过后，合并回分支release-v1.0，然后基于release-v1.0分支发布补丁，最后将合并的PR，借助git的cherry-pick命令再同步合并回master

软件质量

三个考量方面：功能质量、代码质量、流程质量

功能质量：最终用户得到是软件，体验的是软件的功能，功能的质量直接决定了产品的质量

代码质量：可维护性、可读性、执行效率、安全性、可测试性

过程质量：是否有自动化测试？持续交付？

测试人员可以对功能质量负责，开发人员可以对代码质量负责，项目经理可以对过程质量负责，当然前提是权责对等

软件测试

主要工作：从需求开始，在需求确定后要去对需求进行分析，然后做测试设计，把业务需求分解成一个个具体的用户操作步骤，也就是测试用例，然后在开发完成后，按照设计好的测试用例进行逐一的测试验证，将发现的Bug报告给开发人员，并跟踪Bug的修复

如何发现bug：考虑所有可能的用户使用场景，方法有等价类划分、边界值分析、探索性测试、场景设计、因果图、错误推测法等等

如何报告bug：基于Ticket系统等

如何跟踪bug：开发人员修复完一个Bug后，测试人员首先会验证这个Bug是不是真的被修复了，然后还要对整体功能做一 个回归测试，确保不会因为修复Bug而引起其他功能出现问题；回归测试是指修改了旧代码后重新进行测试，以确认修改没有引入新的错误或导致其他代码产生错误

版本发布

1 在发布之前要做代码冻结

代码冻结：在发布之前，对于要发布的版本，在源代码管理工具中，专门创建一个release分 支，然后对于这个分支的代码，冻结功能的修改，不接受新功能的增加，甚至重要性不高的Bug都不修改， 只修复重要的Bug

2 对代码冻结后发现的Bug要分级

在代码冻结后，可能还存在一些Bug，测试的过程中也会新增一些Bug

代码冻结的原则就是尽可能减少代码的修改，避免引起不稳定。所以对于这些Bug，要有一个简单的分级：是否在发布前修改，还是留在发布后再修改

3 每次修复Bug后，发布新的候选版本

4 每次部署新的候选发布版本后，要做回归测试

5 申请上线发布

6 部署发布

7 上线后的测试

DevOps

一种开发（Development）和运维（Operations）一起紧密协作的工作方式，从而可以更快更可靠的构建、测试和发布软件

DevOps贡献：

建立基于持续集成和持续交付工作流程；

建立基于日志的监控报警的系统，以及故障响应的流程；

构建基于云计算和虚拟化技术的基础设施；

形成DevOps的文化

线上故障

恢复生产、降低损失是第一要务，修复Bug是其次的

1 评估影响范围，马上恢复生产，避免进一步损失

2 尝试重现问题

可以基于ELK技术来搭建日志管理系统，通过日志快速定位问题

3 临时方案和最终方案

4 风险评估及持续优化、总结

项目复盘

1 回顾项目目标

2 评估项目结果

3 分析原因

4 总结规律，落实行动

本文地址：https://blog.csdn.net/qq_41594698/article/details/107578543