Web研发模式演变（转自玉伯）.pdfVIP

Web研发模式演变（转⾃⽟伯） 前不久徐飞写了⼀篇很好的⽂章：。本⽂尝试从历史发展⾓度，说说各种研发模式的优劣。 ⼀、简单明快的早期时代 可称之为 Web 1.0 时代，⾮常适合创业型⼩项⽬，不分前后端，经常 3-5 ⼈搞定所有开发。页⾯由 JSP、PHP 等⼯程师在服务端⽣成，浏 览器负责展现。基本上是服务端给什么浏览器就展现什么，展现的控制在 Web Server 层。 这种模式的好处是：简单明快，本地起⼀个 Tomcat 或 Apache 就能开发，调试什么的都还好，只要业务不太复杂。 然⽽业务总会变复杂，这是好事情，否则很可能就意味着创业失败了。业务的复杂会让 Service 越来越多，参与开发的⼈员也很可能从⼏个 ⼈快速扩招到⼏⼗⼈。在这种情况下，会遇到⼀些典型问题： 1、Service 越来越多，调⽤关系变复杂，前端搭建本地环境不再是⼀件简单的事。考虑团队协作，往往会考虑搭建集中式的开发服务器来解 决。这种解决⽅案对编译型的后端开发来说也许还好，但对前端开发来说并不友好。天哪，我只是想调整下按钮样式，却要本地开发、代码 上传、验证⽣效等好⼏个步骤。也许习惯了也还好，但开发服务器总是不那么稳定，出问题时往往需要依赖后端开发搞定。看似仅仅是前端 开发难以本地化，但这对研发效率的影响其实蛮⼤。 2、JSP 等代码的可维护性越来越差。JSP ⾮常强⼤，可以内嵌 Java 代码。这种强⼤使得前后端的职责不清晰，JSP 变成了⼀个灰⾊地 带。经常为了赶项⽬，为了各种紧急需求，会在 JSP ⾥揉杂⼤量业务代码。积攒到⼀定阶段时，往往会带来⼤量维护成本。 这个时期，为了提⾼可维护性，可以通过下⾯的⽅式实现前端的组件化： 理论上，如果⼤家都能按照最佳实践去书写代码，那么⽆论是 JSP 还是 PHP ，可维护性都不会差。但可维护性更多是⼯程含义，有时候需 要通过限制带来⾃由，需要某种约定，使得即便是新⼿也不会写出太糟糕的代码。 如何让前后端分⼯更合理⾼效，如何提⾼代码的可维护性，在 Web 开发中很重要。下⾯我们继续来看，技术架构的演变如何解决这两个问 题。 ⼆、后端为主的 MVC 时代 为了降低复杂度，以后端为出发点，有了 Web Server 层的架构升级，⽐如 Structs、Spring MVC 等，这是后端的 MVC 时代。 代码可维护性得到明显好转，MVC 是个⾮常好的协作模式，从架构层⾯让开发者懂得什么代码应该写在什么地⽅。为了让 View 层更简单⼲ 脆，还可以选择 Velocity、Freemaker 等模板，使得模板⾥写不了 Java 代码。看起来是功能变弱了，但正是这种限制使得前后端分⼯更清 晰。然⽽依旧并不是那么清晰，这个阶段的典型问题是： 1、前端开发重度依赖开发环境。这种架构下，前后端协作有两种模式：⼀种是前端写 demo ，写好后，让后端去套模板。淘宝早期包括现 在依旧有⼤量业务线是这种模式。好处很明显，demo 可以本地开发，很⾼效。不⾜是还需要后端套模板，有可能套错，套完后还需要前端 确定，来回沟通调整的成本⽐较⼤。另⼀种协作模式是前端负责浏览器端的所有开发和服务器端的 View 层模板开发，⽀付宝是这种模式。 好处是 UI 相关的代码都是前端去写就好，后端不⽤太关注，不⾜就是前端开发重度绑定后端环境，环境成为影响前端开发效率的重要因 素。 2、前后端职责依旧纠缠不清。Velocity 模板还是蛮强⼤的，变量、逻辑、宏等特性，依旧可以通过拿到的上下⽂变量来实现各种业务逻 辑。这样，只要前端弱势⼀点，往往就会被后端要求在模板层写出不少业务代码。还有⼀个很⼤的灰⾊地带是 Controller，页⾯路由等功能 本应该是前端最关注的，但却是由后端来实现。Controller 本⾝与 Model 往往也会纠缠不清，看了让⼈咬⽛的代码经常会出现在 Controller 层。这些问题不能全归结于程序员的素养，否则 JSP 就够了。 经常会有⼈吐槽 Java ，但 Java 在⼯程化开发⽅⾯真的做了⼤量思考和架构尝试。Java 蛮符合马云的⼀句话：让平凡⼈做⾮凡事。 三、Ajax 带来的 SPA 时代 历史滚滚往前，2004 年 Gmail 像风⼀样的⼥⼦来到⼈间，很快 2005 年 Ajax 正式提出，加上 CDN 开始⼤量⽤于静态资源存储，于是出现 了 JavaScript 王者归来的 SPA （Single Page Application 单页⾯应⽤）时代。 这种模式下，前后端的分⼯⾮常清晰，前后端的关键协作点是 Ajax 接⼝。看起来是如此美妙，但回过头来看看的话，这与 JSP 时代区别不