写给产品经理们的技术分享后端篇

在上一篇文章中，笔者分享了web前端的相关知识与应用（写给产品经理的技术分享–前端篇），这篇文章是对上一篇文章的补充，主要分享后端、以及前后端互动相关知识及其在产品工作中的应用。

一、简单谈一下API

上一篇分享中，我们提及了一种用于前后端通讯的API，其作用方式之一是：前端随请求将要传递的资料打包并发送到服务器，服务器执行相应处理程式，并将程式的输出发回前端。

前端通常使用这种方式从服务器请求最新资料，因为这些工作涉及到前后端配合，因而在实际工作中还需要产出相应的API文件（甚至于在一些公司是由产品经理去输出API文件），指明随请求传送的引数、请求方法，传回的引数等。

除了这种用于前后端通讯的API，还有很多其他型别的API，例如：我们呼叫支付宝、微信等第三方应用的API，从而为自己的应用增加支付、分享等功能。

在《headfirst python》这本书中，通过一个具体的例子，更加透彻的讲解了API的由来：

在程式设计中，通过定义函式，可以减少重复程式码；将函式储存在一个指令码档案中，使之转化为模组；将模组放入资料夹，同时增加元资料档案，就可以将模组打包准备释出；在web上释出你的档案（也就是API），以供他人下载、安装和使用，其他开发者可以使用API所提供的函式为产品增加功能。

为了让更多人以不同方式更加灵活的呼叫API，我们在定义函式时可以使用可选引数（也就是为引数提供预设值），通过使用引数控制函式的行为与表现。

2. 在产品工作中的应用即便不需要写API文件，产品经理对于API及其呼叫方式也需要有基本的认知，进行考虑并体现在产品设计方案或者PRD中。

以呼叫QQ分享界面为例进行说明：我们需要检视QQ开放平台API呼叫说明，明确各种API呼叫的效果以最终确定要选取的API，以及该API需要自定义哪些引数。

下图是我的PRD的截图，指明了呼叫的API、呼叫效果以及需要自定义的引数值。

二、web开发

这里再大概陈述一下：

使用者在浏览器执行操作，比如输入URL或者点选一个跳转连结。浏览器将使用者动作转换为一个web请求，通过互联网传送到服务器。服务器收到请求并进行处理。在这里，如果请求的是静态内容，服务器会找到相应资源并把它作为响应返回给浏览器；如果请求的是动态内容（也就是需要执行程式才能输出），那么服务器会找到并执行相应服务端程式，并将程式的输出作为响应发给浏览器。这个生成动态内容的过程称为通用闸道器界面（CGI），符合这个标准的服务端程式称之为CGI指令码。浏览器接收到web响应，通过改变DOM将之显示在使用者的屏幕上。

2. 采用MVC设计web应用MVC即模型-检视-（model-view-controller），这是一种常用的开发模式，有助于将程式码分解为易于管理、维护、扩充套件的功能模组。

其中：

模型（model）：用于封装与应用程序的业务逻辑相关的资料以及对资料的处理方法；检视（view）：程式码提供直接与使用者互动的界面；（controller）：程式码起到组织协调作用，将模型程式码和检视程式码粘合起来，用于处理响应，控制应用程序的流程。在互联网早期，后端做了绝大部分工作，也就是模型、检视、程式码都由后端完成。

后端会建立资料模型，通过检视程式码对HTML标记进行拼接，通过程式码将模型资料填充到页面检视中并打印出来，这些输出作为响应发回浏览器，浏览器再将页面显示出来。

这种模式的缺点在于：每次请求都要返回一个新页面，这会降低浏览器的响应性；另外，许多前端页面存在大量重复程式码，但是还要一遍一遍重复生成。

而现在，这一情况已经改变，检视程式码和部分程式码已经执行在前端，模型和部分程式码则执行在后端。

在这种模式下，后端不再需要每次都返回一个完整页面，只需传送资料（通常为JSON格式）；前端定义好页面样式，从服务端获取资料并根据业务逻辑填充到页面中。这可以提高页面的响应速度，并且高效利用了不同页面的重复程式码。

举个例子：比如我们的网站有一个这样的页面，使用者输入某一个歌手，我们的网站就为其展示该歌手的所有歌曲名。那么前后端分别需要编写哪些程式码模组呢？

前端需要编写检视（View）相关程式码，提供一个表单页面让使用者输入歌手名；前端还需要编写一部分（controller）程式码，用于建立请求，随请求将使用者的输入以键值对的形式（例如 singer：“周杰伦”）传送到服务端，另外还需要编写资料到达时的处理程式，在服务端资料到达时，对歌曲资料进行处理并以一定的结构增加到页面中。

后端需要有一个数据模型（model），该模型以一定的结构储存了许多歌手及其歌曲资料，还定义了获取业务所需资料的方法或者说函式（在这个例子中就是通过歌手的名字，获取该歌手的所有歌曲）；后端还需要有一个控制层（controller），用于处理前端发来的请求并进行响应，在这里就需要获取使用者输入的歌手名（同样是使用键获取对应的值），呼叫资料模型及相应函式，并将歌手名传入函式。该函式会获取模型资料并进行处理，最终输出该歌手对应的歌曲列表，作为响应发回前端。

3. 在产品工作中的应用通过以上的例子，我们就可以看出：前后端在软件开发中角色的分工与配合方式，知道了目前前后端的分工原则后，我们在和前后端的沟通中就应该相应有所侧重。

着重像前端展示页面的结构、样式、互动，指明页面资料来源；着重向后端展示，哪些资料来源于后端，这些资料的计算规则（如上文所言，复杂的资料逻辑运算一般发生在服务端），和现有资料的关联等。

了解前后端的分工不仅可以帮助我们更好的推动产品方案落地，还有助于在出现bug时，更加快速定位到问题来源与对应开发人员。

在这里还要强调一下：无论是“模型-检视-”这一开发模式，还是上述的前后端的分工方式，都不是唯一正确答案，这种划分也不是非黑即白的。我们要明确其间的区别，但更要知道其中的联络。

三、关于数据库

数据库的型别主要有关系型数据库和非关系型数据库。

关系型数据库是一种基于关系模型的数据库，这种关系模型是对现实中实体关系的抽象表达。非关系型数据库，在储存的资料结构上没有那么严格的约束和规范，以更加灵活的方式定义资料储存。

常用的数据库管理系统（软件）包括：Oracle、MySQL、MongoDB等。

可以这样理解数据库和数据库管理软件的关系，数据库就是一个类似Excel档案的资料档案，里面包含很多的资料表，这些档案会放在web应用的根资料夹下，以便在执行程式时进行访问；数据库管理系统类似于Excel软件，可以视觉化的检视并管理数据库档案。

在这里我们仅对关系型数据库进行讲解。

2. 如何与数据库互动这里以python程式设计为例，讲解服务端程式与数据库如何进行互动。python的数据库API提供了一种操作数据库的标准机制，如下图（注意这并不是与数据库进行互动的唯一方式）

以上流程翻译成python程式码是这样的：

3. 设计并建立数据库关系型数据库是由一张张相互关联的资料表构成的，对数据库的设计也就是设计资料表的结构和关联。我们现在来设计一个数据库，并使用python真正建立这个数据库。

现在我们设计了一个名为runningdata的数据库，里面包含两张资料表，一张表记录每个使用者的基本资讯（姓名和出生日期），另一张表记录每个使用者的跑步时间资料。

两张资料表分别如下：

可以看到，这两张表通过使用者ID进行关联，这种表的结构和关联应该是具有逻辑意义、现实意义、业务导向、支援扩充套件的。

上面是对资料表的设计，那么如何通过python建立上面的资料表，并进行资料插入和查询等操作呢？

首先套用3.2中的流程，建立与数据库的连线、建立资料游标，然后使用create语句建立两个资料表。使用SELECT语句对资料表进行查询并获取结果，使用INSERT语句分别向表增加资料（其中使用者ID可以自动生成，我们使用第一个表生成的使用者ID填充第二个表，使之关联起来），然后提交修改并关闭连线。

建立后的数据库一般长这个样子：

4. 将数据库整合到web应用上面讲MVC（模型-检视-）时我们提到，模型程式码用来储存并提供资料。所以，我们只需在模型（model）中编写上述程式码，让其帮助我们建立数据库，并定义相关的资料处理方法。这样在程式码进行响应时就可以呼叫该方法，使之返回我们需要的资料。

5. 在产品工作中的应用产品经理对于数据库的设计方式、作用方式有一定的了解，有助于评估产品功能的实现对现有数据库的影响，以及新的设计对原有资料的相容性问题。

另一方面，现在的产品设计往往需要参考大量的使用者行为资料，进行下一步优化。这些使用者资料往往储存在数据库中，产品经理有时需要使用SQL语句对数据库进行查询，因而对于数据库的了解也是大有帮助的。

写在后面

关于API的基本知识web应用的工作方式、开发模式数据库的简介、操作方法、应用方式通过这些内容简单介绍了服务端的基本知识，以及与产品工作的联络。

我个人对于服务端技术的学习是通过《Head First Python》这本书，因此写这篇文章，也算是抛砖引玉。后端的内容非常之庞大，我虽诚惶诚恐，还是大胆把自己有所感悟的写了下来，欢迎大家与我探讨或者批评指正。

这两篇文章讲解了web应用开发所涉及的基本知识，希望大家看完之后有所收获，也建议产品经理们去看一下技术相关的书籍，甚至于写一个自己的应用，体会一下开发的过程，思考产品设计与技术实现的关系，思考产品经理与开发人员的协作方式。

本文由 @lemon 原创释出于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议