好的架构来自于演化，人亦之。
在公司做全栈工程师，一年的磨练，让我在开发道路上也有了长足的进步。现在，组里来了一些新员工，为了帮助他们更好的理解web开发，就写了这篇文章，也全当自己一年的“演进”吧。
目的
- web开发，是组内的工作之一，希望同事们对web开发有一些共同的认识，也欢迎读者拍砖（keypoint：前后端的分离）
web的演化之路
什么是web开发？
Web开发，一种基于B/S架构（BROWSER/SERVER）的应用软件开发技术，分为前端（用户接口）和后端（业务逻辑和数据）。
简单介绍一下技术：
- 前端：HTML（负责框架），CSS（负责样式），JavaScript（负责交互）【载体：浏览器。HTML、CSS渲染引擎，JS解释器，还有一些别的，比如客户端数据库】
- 后端：PHP，JAVA，PYTHON等等。【载体：python解释器，java编译器，Apache】
- OSI模型：物理层，数据链路层【SDLC】，网络层【IP】，传输层【TCP、UDP】，会话层，表示层，应用层【HTTP】（理论共七层）
在整个互联网的发展过程中，web的演化是非常漫长的，也伴随着技术的迭代。而在我们小组，这个过程是简单并且清晰的，我从一年众多的工作中找到这样一条web演化的路线，希望能够帮助同事们更加理解团队的技术架构。
v1.0
背景故事：
为了验证某项业务的有效性，我们启动了魔镜项目，第一个阶段是build一个能够让实习生标记tag的平台。这就是小组WEB开发的开端，我们选择python为基础的技术栈，试用Flask，然后就做出了第一个页面。
代码工具： mp
Jinja2。Flask自带的页面渲染模块，它被最常使用的就是变量传递和控制结构。
# hello.py
from flask import Flask, render_template
app = Flask(__name__)
@app.route('/')
def index():
user = {"Xing": "Ming", "Nian": "Ling"}
cool_here = "Thanks for reading!"
return render_template('index.html', user=user, cool_here=cool_here)
app.run()
# index.html
Hello World!
{% for key, value in user.items() %}
{{ key }}
{{ value }}
{% endfor %}
{{ cool_here }}
看代码，很容易就能发现Jinja2模版引擎的优势，它可以让你像写python一样写HTML页面，通过python解释器转化出整个HTML的DOM树，从而实现web开发。
在这个阶段，没有什么前后端的区分，大家都在写后端代码，所有的控制都在服务端完成，浏览器只用渲染后端提供的页面数据就可以了。
再补充一点关于数据传递（POST， GET）的代码。
{{ link_name }}
明显特点：
- 小巧的Flask以一己之力从后到前的实现了当时业务的需求，魔镜平台有条不紊的被搭建起来;
- 技术栈简单轻巧，团队能够在开发时有余力做模型建立和业务探索。
典型问题：
- 业务变得复杂。在一个页面内点击一个按钮，发出一个request但不reload页面，这套简单的开发模式根本无法实现类似的需求；
- 代码难维护。随着前端业务变得复杂，为了响应变动的前端业务，后端要付出的成本急剧增大，代码职责也变得不清晰起来；
- 交互体验。改善用户每次校验数据需要把数据传到服务器端的窘境。
v2.0
背景故事：
为了响应复杂的业务需求，我们必须在页面中使用ajax。JavaScript的加入，让前后端变得分明，也让代码职责重新变得清晰。页面的局部交互全部由ajax完成，部分数据校验也由ajax完成，这时候是前后端分庭抗礼的阶段。
代码工具：
Jquery，脱颖而出的JavaScript库，依赖简单的CDN就能完美使用，它被最常使用的是事件响应和ajax交互。
明显特点:
- 满足了需求，页面的功能逐渐饱满；
- 前后分明，在某种程度上简化了后端代码的复杂度，让代码维护变得轻松。
典型问题：
- 有Jinja2模版的支持，jquery操作DOM起来得心应手，但是jquery以功能交互为主，前端代码很快变得十分庞大，文件变得冗长，阅读困难倍增，维护亦然；
- 业务不断的迭代，对web页面的需求也不断拔高，jinja页面和ajax的配合逐渐不能满足日益增长的交互需求，新的技术扩展需求迫在眉睫；
- 后端业务的不断扩展，前端相同的交互功能代码，抽象和复用都很难进行，这几乎成为了制约前端进步的主要原因。
v3.0
背景故事：
为了响应复杂的业务需求，团队进一步践行SPA（single-page application），把大量的业务需求放在前端实现，进一步增加前端交互功能并且优化用户体验，推行了Vue框架。至此，组内的web开发已向前端倾斜。
代码工具：
Vue，构建用户界面的渐进式框架，它的核心库只关注页面本身，易于上手，方便集成。
请选择：你更喜欢哪一个还原过程呢？
var app = new Vue({
el: "#demoPage",
data: {
showOrHide: true,
comment: '',
warnMsg: '请输入理由！',
},
methods: {
makeDecision: function() {
let that = this;
if (that.chosenValue === null && that.comment === "") {
var msgArray = ["要输入理由哦~", "请务必告知原因~"];
that.warnMsg = msgArray[Math.floor(Math.random() * msgArray.length)];
return
};
$.ajax({
// do something
})
},
},
})
看代码，很容易知道Vue不仅在script层做交互，它绑定了DOM，实现了数据的双向绑定。各种语法和组件也易于使用，还有简单方便的打包工具，也给一段组件化的示例。
明显特点：
- 虚拟的DOM，双向绑定的数据，组件化的视图，简单的语法，Vue极大的满足了团队的前端需求，几乎对接了企业级的前端应用；
- 彻底分开的前后端架构，职责更清晰，开发更容易，维护更简单；
- 部署相对独立，产品体验可以快速改进。
典型问题：
- API不清楚。随着前后端的分离，所有链接变成API，那API的稳定和清晰就至关重要了。前端静态化、后端数据化、构架分离化，三大转变演进缓慢，导致团队配合失调。【前后端分离最困难、最关键的环节，API的制定和编写。】
- 设计阶段：架构负责人对项目整体进行分析，讨论并确定API风格，制定API接口；
- 开发阶段：前后端分离各自分工，后端提供数据API，并撰写文档，前端获取数据；
- 测试阶段：（mock测试）前后端拟定测试时间，迅速调整接口。
- SPA并不能满足所有需求，依旧存在大量多页面应用，某些design仍然需要后端配合。
Future
团队的web开发演化到了今天，几乎发生了沧海桑田的变化。但是，演化并没有走到尽头...
变美的关键-CSS
我们选用了bootstrap作为样式库。
结语
由于小组是以全栈为目的进行组建的，在前后端的处理上有很多麻烦，很多工作在前后端都能完成，所以职责不明晰、代码不简洁成为了web开发的主要问题。SPA让后端数据化确实给了我们很大的帮助。
最后，非常感谢花时间阅读文章的你们，非常欢迎大家指出我意识不到的BUG，如果有帮助到大家，也非常喜欢大家顺手点个赞！