0.3 Serverless正在颠覆研发模式

下面谈一下对研发岗位的一些看法。我比较反对用不同岗位（如前端研发工程师、后端研发工程师、测试工程师、运维工程师等）来区分研发人员。

之所以需要分工，实际上是因为软件研发的复杂度上升，并且研发团队希望保持一个较高的研发效率造成的。也就是说，如果软件研发的所有工作都通过同一个团队完成，那么他们需要掌握的知识就会十分庞杂。这涉及软件研发的方方面面，需要一个漫长的学习过程，并必将导致研发效率的降低。因此，我们通过分工协作，降低了这种学习成本，提高了软件研发人员的效率。

我们不妨思考一下，前端研发工程师岗位是怎么出现的。

前端研发工程师这个岗位大概出现于 10 多年前，因为业务上的需要（给用户提供更好的终端体验），导致前端工作的复杂度快速上升，以致一个人无法同时负担前端和后端的研发工作，所以细分出来一个独立的岗位。

那么，是否能通过工具或基础设施的升级，降低研发的复杂度，从而不再需要这个独立的岗位呢？实际上，在软件研发领域，最早提出类似想法并且实施的，恐怕是专职的测试工程师。通过研发各种自动化测试工具来保障项目的质量，降低测试成本，从而可以不再需要单独的 QA团队。同样，通过研发自动化运维的产品，让研发人员具备运维能力（即现在的 DevOps），简化运维的复杂度，从而可以不再需要专职的运维人员。

而现在，前端通过搭建平台的建设，简化了页面开发，又通过 AI 能力的运用，实现了从设计稿到页面代码的自动化生产，因此我们还需要专职的前端研发人员吗？而我们基于Serverless 极大地降低了运维门槛，这使得我们从 DevOps 演进到了 NoOps，当所有前端研发人员都掌握了这一能力后，我们真的还需要专职的后端研发工程师吗？

因此，我认为随着技术和配套工具的迭代，我们无须再因为技术栈不同而去区分不同的岗位，不会再有前端研发工程师、后端研发工程师、测试工程师、运维工程师之分，今后软件研发领域将只会有两种岗位：基础设施研发工程师（Infrastructure Engineer）和应用研发工程师（Application Engineer）。基础设施研发工程师将致力于提供更易于使用的计算资源，并使得计算资源的利用就像水电煤的使用那样便利；而应用研发工程师则将专注于业务研发，以便更快、更好、更容易地开发出让用户满意的产品。

可见，技术的不断演进迭代，让我们不再需要按技术栈来区分研发的岗位。

虽然 Serverless 帮助我们隐藏了运维背后的工作，但是否就代表我们无须了解其背后的原理，只需要学会使用就可以了呢？

从全球各行各业的工作来看，软件研发是一个颇奇怪的岗位。其他行业随着科技的不断发展，生产工具也在不停地演进和进化，最终工具会变得越来越便利、越来越易于使用。从业人员直接使用这些工具，无须理解其内部原理，就能比以前更好、更快地完成工作。

比如，对负责将乘客从出发地送往目的地的司机来说，他无须了解内燃机原理，也能很好地驾驶车辆，到达目的地；同时，摄影师也无须了解光学原理，在完成构图后，只需要简单地按下快门，就能拍出优美的照片。然而在软件研发领域，无论目前使用的语言有多么先进，研发人员却仍然需要理解计算机硬件的工作原理、操作系统的运行原理、互联网是如何链接的、程序是如何编译的。

是什么原因导致了这一现象？我想大概是因为对于司机来说，如果车辆发生了故障，可以送到 4S 店来维修；对于摄影师，如果相机发生了故障，可以送至相机生产厂商去更换。然而对于软件研发人员来说，若程序发生了故障，由于时间上的紧迫性，并没有谁能够立即提供帮助，只能研发人员自己解决。因此，如何能快速地定位和解决问题，这就依赖研发人员的相关经验和对底层原理的理解程度了。

平台做的事情越多，屏蔽的内部细节越多，研发人员使用起来就越方便。只有理解和掌握了底层原理，并通过更加深刻的思考和分析，才能设计出合理的架构。如果研发人员只是简单地使用云计算供应商提供的各种服务，那么当这些服务出现异常时，将无从下手来解决具体问题。所以，对于 Serverless 来说，其内部的原理研发人员仍然有必要了解。

因此，希望本书的读者通过对 Serverless 技术原理的学习，从而不再将自己局限于前端或特定领域，而是站在更高的角度看待软件研发。正如本章开头高更的名画——《我们从何处来？我们是谁？我们向何处去？》暗喻的那样，本书将从原理到实践、架构起源，再到发展方向，对 Serverless 进行全方位的解读，从而让读者把握软件研发的发展方向。

让我们进入云计算背景下的下一代软件架构——Serverless 的世界，一起感受它的魅力吧。