前端开web开发培训发培训机构推荐(前端开发培训学校)

相关知识点：前言

前端分离已经成为业界常见的开发/部署模式。所谓前端分离，并不是传统行业的按部门划分。有的人是纯前端()，有的人是纯后端，因为这种方式不行：比如很多团队都采用了后端模板技术(JSP、ERB等)。)，而前端的开发和调试需要一个后端Web容器的支持，无法实现真正的分离(更不用说部署时动态内容和静态内容的混合，关于前端开发的另一个讨论可以在这里找到。

即使前端和后端开发流程通过API解耦，前端和后端通过接口通信，前端的静态内容和后端的动态计算分开开发部署，集成仍然是不可避免的问题。前端和后端应用程序可以独立运行，但集成不起作用。我们需要花费大量的精力去调试，在上线之前没有人有信心所有的接口都在工作。

一点背景

典型的网络应用程序的布局如下所示：

每个前端和后端都有自己的开发流程、构建工具、测试集等等。前端和后端只通过接口编程，接口可以是JSON格式接口，也可以是XML接口。关键是后台只负责提供和计算数据，根本不处理展现。前端负责获取数据，组织数据，呈现数据。这样结构清晰，关注点分离，前后端变得相对独立，松散耦合。

以上场景还是比较理想的。事实上，我们在实际环境中会有非常复杂的场景，比如异构网络、异构操作系统等。

在实际场景中，后端可能更复杂，比如用C语言采集数据，然后通过Java集成到一个数据仓库中，然后数据仓库又有了一层，最后这几层被一个Ruby聚合集成，返回到前端。在这样一个复杂的系统中，后台任何一个端点的故障都可能会阻塞前端开发流程，所以我们将使用mock来解决这个问题：

这个服务器可以启动一个简单的HTTP服务器，然后发出一些静态内容供前端代码使用。这样好处很多。

前端开发相对独立

后端的进度不会影响前端的开发

启动速度更快

你可以在前端和后端使用你熟悉的技术栈(前端学习和后端使用会非常不方便)

但是融合还是很头疼的。我们经常会发现集成时原来协商的数据结构发生了变化：字段原来是字符串，现在变成了数组(业务变了，系统现在可以支持多个快递地址)；字段变成字符串，协商时间为；用户的电子邮件地址又多了一层，以此类推。这些变化是不可避免的，并且时有发生，这将花费大量调试时间和整合时间，的时间，更不用说修改后的回归测试了。

所以仅仅使用一个静态服务器然后提供数据是不够的。我们需要的应该还是能够做到的：

前端依赖于用户界面开发中指定格式的模拟数据

前端的开发和测试基于这些模拟数据

后端生成指定格式的模拟数据

后端需要测试，以确保生成的模拟数据正是前端所需要的

简而言之，我们需要协商一些合同，并将其用作可以测试的中间格式。那么前端和后端都需要有测试来使用这些契约。一旦合同变更，对方的测试就会失败，带动双方协商，减少整合的浪费。

一个实际的场景是：前端发现一个现有的合同中有一个缺失的字段，所以它将这个字段添加到合同中。然后这个字段在UI上正确显示(当然还有字体、大小、颜色等。也被设置)。但是，在后台生成合同的服务并不知道这一变化。当运行生成合同部分(后台)的测试时，测试将失败，因为它没有生成此字段。所以后端工程师会和前端商量。理解了业务逻辑之后，他会修改代码，确保测试通过。这样在集成的时候，UI就不会出现字段缺失的情况，但是没有人知道是前端问题，后端问题，还是数据库问题。

而且在实际项目中，往往会有多个页面、多个API、多个版本、多个团队同时开发。这样的合同会减少很多调试时间的工作，使集成相对顺利。

实际上，合同可以定义为JSON文件或XML。只要保证前端和后端共享同一个契约集进行测试，集成工作就会受益。最简单的形式之一是提供一些静态文件，前端向后台发送的所有请求都被某种机制截获，并转换为对静态资源的请求。

Moco，基于Java

Wiremock，基于Java

西纳特拉，基于鲁比

看到这里列出来，熟悉的人可能会反对：这是一个功能齐全的程序库。之所以在这里列出来，是因为它提供了一种简洁优美的语言，非常契合。我找不到更漂亮的方式让它更易读，就采用了。

例子

我们以这个应用为例，说明如何在分离前端和后端后，保证代码质量，降低集成成本。这个应用场景很简单：每个人都可以看到一个物品列表，每个登录用户都可以选择自己喜欢的物品，并在上面添加星星。添加了星号的条目将保存在用户自己的。用户界面如下所示：

但是为了专注于我们的中心，我去掉了登录、个人中心等页面，假设你是登录用户，然后我们来看看怎么写测试。

前端开发

按照惯例，前端和后端分开后，我们很容易自己测试一些数据：

然后，一种可能的方法是请求

这样当然是可以工作的，但是这里发送请求的并不是最终的，当集成的时候我们又需要修改为真实的。一个简单的做法是使用来做一次url的转换：

这样，当我们和实际的服务进行集成时，只需要连接到那个服务器就可以了。

注意，我们现在的核心是这个文件。这个文件现在的角色就是一个契约，至少对于前端来说是这样的。紧接着，我们的应用需要渲染的功能，这就需要另外一个契约：找出当前用户加星过的所有条目，因此我们加入了一个新的契约：

然后在中加入一个新的映射：

通过这两个请求，我们会得到两个列表，然后根据这两个列表的交集来绘制出所有的星号的状态（有的是空心，有的是实心）：

剩下的一个问题是当点击红心时，我们需要发请求给后端，然后更新红心的状态：

这里又多出来一个请求，不过使用Sinatra我们还是可以很容易的支持它：

可以看到，在没有后端的情况下，我们一切都进展顺利后端甚至还没有开始做，或者正在由一个进度比我们慢的团队在开发，不过无所谓，他们不会影响我们的。

不仅如此，当我们写完前端的代码之后，可以做一个的测试。由于使用了mock数据，免去了数据库和网络的耗时，这个的测试会运行的非常快，并且它确实起到了端到端的作用。这些测试在最后的集成时，还可以用来当UI测试来运行。所谓一举多得。

关于如何编写这样的测试，可以参考之前写的这篇文章。

后端开发

我在这个示例中，后端采用了作为示例，你应该可以很容易将类似的思路应用到Ruby或者其他语言上。

首先是请求的入口，会负责解析请求路径，查数据库，最后返回JSON格式的数据。

具体查询的细节我们就不做讨论了，感兴趣的可以在文章结尾处找到代码库的链接。那么有了这个Controller之后，我们如何测试它呢？或者说，如何让契约变得实际可用呢？

提供了非常优美的DSL来编写测试，我们仅需要一点代码就可以将契约用起来，并实际的监督接口的修改：

建立了mockmvc之后，我们就可以编写Controller的单元测试了：

当发送请求到上之后，我们期望返回状态是200，然后内容是。然后我们预期返回的结果是一个长度为3的数组，然后数组中的第一个元素的字段不为空。

注意此处的方法，事实上它会去加载文件也就是前端用来测试的mock文件：

这样，当后端修改定义（添加/删除/修改字段），或者修改了mock数据等，都会导致测试失败；而前端修改mock之后，也会导致测试失败不要惧怕失败这样的失败会促进一次协商，并驱动出最终的service的契约。

对应的，测试的方式类似：

总结

前后端分离是一件容易的事情，而且团队可能在短期可以看到很多好处，但是如果不认真处理集成的问题，分离反而可能会带来更长的集成时间。通过面向契约的方式来组织各自的测试，可以带来很多的好处：更快速的测试，更平滑的集成，更安全的分离开发等等。

代码

前后端的代码我都放到了Gitbub上，感兴趣的可以clone下来自行研究：

bookmarks-frontend

bookmarks-server