我对软件工程的理解

最近在重学软件工程相关的知识，一方面是对自己过往工作经历的一个梳理总结；另一方面，是在和同行交流过程中，发现自己对于一些知识的理解还存在不足。后续一段时间的文章内容，会以软件工程方面为主，当然也会穿插一些工具使用和技术落地的实践。

如何理解软件工程？

我最初入行做软件测试，是培训机构学习了 3 个月后就一脸懵的出来找工作的。

虽然在培训机构学了一些用例设计、测试方案编写和基础 SQL/Linux 命令，但缺乏实战经验。磕磕绊绊找了一个软件测试的工作后，迷茫的工作了两年。工作中犯过不少现在看来很基础的错误，也找不到方向学习提升自己，总有一种疲于奔命的感觉。我曾经遇到过很多问题，比如：

• 用例是写好了，但上线后总有遗漏的点；

• 缺乏理论指导，遇到新的业务很难快速上手；

• 工作没有计划性，想到哪儿坐到哪儿，效率和质量比起其他同事都差；

• 不知道如何与研发团队其他同事协作，职业发展遇到瓶颈，无法得到晋升；

后来在一个很好的 leader 提醒下，系统的学习了很多基础的软件工程相关知识，才开始明白软件研发交付更本质的东西。系统的学习之后我才知道，无论是日常的版本迭代还是一些独立的技术项目，其实背后都有软件工程的方法论在指导着项目有条不紊的迭代交付。现在和一些同学交流技术落地的问题，我也更喜欢用软件工程实践来这样提出自己的建议。

学习让我明白，从项目立项评审到编码测试上线，都需要通过合理的流程规范和有效的组织协调来保驾护航。在整个项目的生命周期各环节，业内都有许多解决问题的最佳实践，在不同的领域也有不同的工具来辅助提高过程效率。比如：

• 提到架构设计，大家会想到抽象思维、分而治之、复用和迭代；

• 提到复杂场景高并发下的性能测试，大家会想到生产全链路压测；

• 提到服务治理，大家会想到配置中心/注册中心如 Apollo/nacos/sentinel；

• 提到应用管理和流水线交付，大家会想到 Jenkins/docker/k8s 或 CICD 相关的知识；

从技术的角度来看，上面罗列的几点都是道法术器中的法术器，而软件工程则是培养这一切诞生并茁壮成长的道。

为什么要学习软件工程？

亚马逊的创始人杰夫·贝索斯（Jeff Bezos）曾经在一次演讲中说：“人们经常问我，未来 10 年什么会被改变？我觉得这个问题很有意思，但也很普通。从来没有人问我，未来 10 年，什么不会变？”这个回答同样适用于软件研发交付领域。

经常有同学问我该如何学习提升自己，我一般会给出下面 2 条建议：

• 短期，学习可以快速变现的技术，比如自动化测试的市场需求很大，就去学习框架/代码/工具相关的技术；

• 长期，学习那些底层不变的技术，如操作系统、通信协议、数据结构、软件工程、网络、数据库相关知识；

因为技术是为了解决问题而不断迭代变化的，但从最早的开发语言诞生直到现在，底层的如操作系统、通信协议和网络几乎没什么变化，这些知识可以受用十年以上甚至更久。

做测试的同学应该都知道，影响质量的三要素是时间、范围和成本。

PS：图来自极客时间，侵删。

实际的软件研发项目中，除了上述三点之外，还需要考量技术落地难易程度、团队成员的适应能力以及成员利益之间做平衡（trade-off）。

而软件工程的诞生，则是为了解决软件研发过程的质量不可控，其目标就是为了要聚焦于质量，构建和维护高质量软件。

软件工程是软件行业知识体系的内核，无论你想走技术路线，还是转向做管理，想要走的更快更稳，都绕不开软件工程。

如何系统的学习软件工程？

PS：图来自极客时间，侵删。

如上图所示，要构建和持续维护高质量的软件系统，需要从工具、方法、过程来入手。

“过程”指的是将软件研发过程中包含立项、计划、沟通、编码、测试和部署等工作通过有效的流程规范组织起来。无论是早起的瀑布模型、双 W 模型，还是近几年流行的敏捷开发、流水线交付，都可以看作是对过程的控制和管理。

“方法”指的是在软件项目整个过程中，如何构建并交付高质量系统的一整套理论。比如：

• 用户需求分析；

• 系统架构设计；

• 软件测试验收；

• 软件构建部署；

“工具”自不用多言，所有能辅助我们提高解决问题效率的都可算作工具。比如：

• 要验证代码覆盖率，我们常用的工具有 jacoco、coverage.py；

• 提高用例执行和回归效率，我们用到的自动化测试工具如 selenium；

• 需求/用例/缺陷管理工具如禅道、jira、TAPD 等；

总结一下，软件工程 = 工具 + 方法 + 过程。要系统的学习软件工程相关的知识，可以参考如下的思维导图：

PS：图来自极客时间，侵删。