计算器是我们熟知的一个工具，基本上它是以单机的形式存在的，但它的每一次更新都基本在重绘 UI 界面，把所有代码放在一起，处理维护很麻烦。有没有办法将界面代码和后台代码分开？本文就计算器的处理逻辑，探讨前后端分离，一起来看看吧。

作为一名刚入门的产品经理，在熟练掌握了画原型、写文档、绘制流程图等技能后，信心满满地踏入职场，结果在开始参与项目时就遇到了职场生涯的第一个槛，就是发现有一堆岗位的人需要跟自己协作，而自己却完全弄不清楚他们到底是干什么的，在项目中究竟扮演什么样的角色，其中最为头疼的，就是明明都是开发，怎么还分了前端和后端。

计算器，无论是手机上、电脑上还是日常生活中都能见到，所以相信以此来举例，应该能够让你更加容易理解，本文就从计算器说起，谈一谈产品经理应该搞清楚的前后端分离。

这是我们经常见到的计算器的样子，基本上它都是以单机的形式存在，也就是说，它在没有网络的情况下，也可以正常使用。

这种形式像极了开发模式最初的样子，所有代码都在一个项目里，开发既要写界面和交互，又要写处理逻辑，那时候还没有前端和后端的叫法。

后来做着做着，大家就发觉，计算器的处理逻辑就那样子，除非数学不存在了，否则几乎是永恒不变的，每一次更新，基本都是在重绘 UI 界面（软件升级，以换 UI 为本），但是所有代码放在一起，每次维护起来都很麻烦。

于是大家就想着，能不能把界面代码和后台代码分开，互不干扰，界面负责接收和显示数据，后台负责处理逻辑。

问题是，代码分开了，相互之间怎么通信？API 让这个逻辑成为可能，按照新的逻辑，产品的架构变成了这样：

从此，软件开发有了前后端的概念，前端只负责写界面和交互，后端只负责写处理逻辑，两者通过 API 接口进行通信。

比如在计算器这个项目中，前端只需要负责把计算器的界面画出来，并实现相应的交互，比如用户可以点击按键输入数字，符号，可以删除和清空输入，当用户输入完成按下“=”之后，前端就不管计算了，而是直接通过 API 接口将用户输入的内容传给后端，前端不用理会后端怎么计算，只知道过一会后端会把计算结果传回来，到时候前端只需要把结果显示给用户就可以了。

而后端，只管对前端传过来的内容进行计算，然后把计算结果通过 API 接口传回给前端就可以了，至于前端怎么显示给用户，后端也无需理会。

按照以上逻辑，当用户通过计算器计算“1+1”的整个处理过程是这样的：

前后端分离之后，会遇到一个新问题，就是谁来做验证。比如“0不能做除数”，当用户输入了以0作为除数的公式时，究竟是前端来做验证还是后端来做验证。其基本原则是：前端能做验证尽量做验证，后端一定要做验证。

之所以要求后端一定要做验证，是因为后端主要负责逻辑的处理，如果没有对数据进行验证，则处理过程可能出错，或者处理后输出的结果是不符合预期的。

而要求前端尽量做验证，是因为在前端能够发现数据有问题，验证不通过的情况下，可以不调用 API 接口，避免将错误的数据传输给后台，由于每次调用 API 都要消耗网络资源，前端校验可以有效减少错误的请求次数，避免资源的浪费。

前后端的分离，除了有更好维护的优势以外，还有另外一个好处，就是能够避免“重复造轮子”。

这是开发界广为流传的一句话，说的是在不同的产品中重复写一些相同的功能代码。比如现在有几个手机厂商，每个手机厂商都来找你开发一个计算器的 APP，每个厂商的计算器除了 UI 界面不一样，功能都是一样的。

刚刚说过，除非数学不存在了，否则计算器的计算逻辑是不会变的，无论你用哪个计算器，“1+1”的计算结果都是等于“2”。但在上面提到的这种情况下，你除了得为每一个厂商开发不同的前端界面，还要给每个应用写相同的计算代码，这就是所谓的“重复造轮子”，明明是相同的功能，为什么要一遍又一遍重复地写。

但如果我们用前后端分离的设计模式，我们可以先为每个厂商设计好计算器的前端界面，接着将计算逻辑的代码放到服务器上，然后让每个计算器将需要计算的内容发到这台服务器上，服务器再返回计算结果，整个架构就变成这样：

这样的好处是，相同的代码只需要写一套，同时，维护也更加方便，如果出现了 bug 需要修复，比如原本“0不能做除数”的错误提示文案写成了“0不能做被除数”，只需要更新服务端的代码，几个计算器收到的提示内容就会同步更新成正确的文案。

这个时候你肯定会想到另外一个问题，就是这种设计模式在现实中是行不通的，手机厂商不会同意与其他的厂商共用代码，而且将计算器的计算处理放在云端，一旦服务器出问题，计算器就“挂了”。

这个时候，又出现了另外一种解决方案，叫做 SDK。按以上的例子来理解，就是将服务器上用于处理计算器计算逻辑的代码打成一个包，这个包就叫 SDK 包，然后把这个包发给每个厂商，每个厂商再将 SDK 包集成到自己的计算器应用里，集成的逻辑是这样的：

而从每个计算器运作的角度来看，计算器应用和 SDK 包之间还是通过 API 来调用，但是无需经过网络，在本地就能完成计算的处理，其逻辑是这样的：

可以看到，虽然所有计算器用的是同一套计算逻辑，但是都在自己内部独立处理，互不干扰。你会发现，折腾了一番，这个计算器又回到我们最开始看到的那个样子，单机运行，无需联网。

这是 SDK 的优势，下一次更新，只需要将最新的功能代码重新打包，发给厂商更新即可。不过，这也暴露出 SDK 的缺点，就是如果厂商未能及时集成最新版的 SDK 包，则用户无法体验到最新的功能，比如基于安卓的不同国产手机操作系统，安卓底层不一样就是这个道理，因为如果 SDK 实现的功能比较多，那么集成 SDK 是一项非常大的工程，而且每次集成新的 SDK 都需要进行完整的测试，防止出现兼容性问题。

以上便是本文的全部内容，希望对你搞清楚前后端的具体工作有参考价值。

作者注：

软件开发模式中的前后端分离本身是一门比较复杂的学问，本文用了一种非技术出身的产品经理比较好理解的形式介绍了前后端分离的基本概念，如果各位有兴趣进一步探究，可以在网上搜索“MVC 软件开发模式”深入学习。

关于文中提到的 API 接口文档知识，有兴趣可参阅《新手产品经理必学技术接口文档知识》

专栏作家

产品锦李，公众号：产品锦李（ID：IMPM996），人人都是产品经理专栏作家。不务正业的产品经理和他的产品设计。

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。