我认为的服务端软件开发

干了几年开发，搜了几年资料，写了几年代码，感觉服务端的开发也是有规律可寻的。无论什么体量的项目，都应该遵守软件工程的开发流程和规范。这几年我发现，教科书上写的都是对的，经典是永不过时的。那些抨击、挑战这些软件工程基石的人还真是不靠谱。

功能实现是根本，工程化是可持续发展。开发不能只顾着实现功能，把其他方面抛于脑后。

通常

我开发的时候总是有个习惯，想知道专业的从业人员到底是怎么设计、怎么实现这一功能，大到整体业务流程、小到源文件结构。其实这些东西对于计算机而言，无关紧要。设计再糟，计算机也只是按部就班地执行，只要结果对了，那就是对了。源文件的样式风格、项目结构再精美，计算机也不会去欣赏。但是开发者不一样，开发者是人，是有独特的审美和品味。每个人的开发习惯和编码风格各有特点，但总是能找到一些共性。开发习惯和编码风格在很多情况下，也有优劣之分。取之精华，弃其糟粕，提炼出来便是规范。若是规范能应对所有场景，那遵守规范便是行业底线。但事与愿违，现实并不是能抽象为精炼的规则。所以严格的规范有的时候便成了枷锁。在互联网上你很难得到通用的解决方案，所以这些年，我经常在开发新的功能前，即使已经有明确的思路了，也会想着去搜索下，看看前人是如何走过这条路的。甚至开发到之前开发过的功能时，也会搜索下，最近有什么更好的解决方案。这不是抄作业，也不是放弃独立思考，而是为了少走弯路。

测试

软件测试可以说比开发更为重要。你可以认为，一个软件程序是比钻石还永恒的。它很可靠，只要它依赖的运行时没有缺陷，那么这个程序基本上就是按着你的源代码跑的。但是你和源代码之间存在的巨大的鸿沟，一不留神可能就是留下了令他讨厌的 BUG。软件测试能帮你更早地发现这个 BUG。

测试可分单元测试、集成测试、回归测试等等等等，教科书上写得清清楚楚，但是不知道诸位是否对一个软件走完了这么些个的测试？我也不曾走完这么多测试，毕竟测试成本挺高的，没那么多的资源能分配到所有流程。所以，我觉得单元测试和 E2E 测试能共同覆盖大部分场景，能发现大部分的问题。而且这两个测试对后端服务来说应该是不可或缺的，你想想，手动调用接口挨个参数测试是不是还不如写个 E2E 测试来得划算？

单元测试比较简单，目标外部的逻辑全部 mock，只测目标内部的逻辑。测一般情况、边缘情况、异常情况，每个分支都测到，这就差不多了。单元测试只测很小的一块代码，一般是按一个函数一个函数来测，如果要测一个外部请求进来后走的整个链路，那就应该使用集成测试。

E2E 测试作为集成测试的一种，它主要是通过模仿真实的动作，从系统外部对系统进行操作，并验证操作结果是否符合预期，在服务端，这意味着是通过模拟调用 API 后，验证返回值、数据库等数据是否符合预期。

E2E 测试因为走的链路比较完整，所以一般会并行测试。但是测试用例与测试用例之间互相干扰的可能性较大，所以，隔离测试用例的测试数据与测试用例的抗干扰能力就比较重要。以常用的 PostgreSQL 数据库举例，假设我们的数据存放在数据库中，那么我们有下面几种方案：

1. 重建测试环境
   1. 在执行每个测试用例启动前，使用 PostgreSQL 的 Docker 镜像创建新的数据库，并填充测试数据，测试结束后销毁这个数据库；
   2. 所有测试用例使用同一份测试数据，在开始所有测试前清空测试数据库并重新构建测试。
2. Mock
   1. 使用 Mock 的 PostgreSQL 来替代正常环境使用的数据库（一般 Mock 用的数据库是支持大部分功能的内存数据库）；
   2. 使用 Mock 的方式，劫持传入数据库的 SQL 语句来判断是否正确来确认前面链路的正确性，并返回假数据用于后面链路的测试。
3. 使用串行的方式，有序执行测试用例，每个测试用例可以将前一个测试用例产生的副作用作为自己测试数据的一部分。

我目前使用方案 1.2 来进行 E2E 测试。