淘宝玉伯引发Web前后端研发模式讨论
openkk 12年前
<p> 淘宝<a href="/misc/goto?guid=4958343080387593493">玉伯</a>是是前端基础类库 <a href="/misc/goto?guid=4958343081190037917">Arale</a> 的创始人，Arale 基于 SeaJS 和 jQuery。不久前，淘宝玉伯在 Github 的 Arale 讨论页面上抛出了自己对于 <a href="/misc/goto?guid=4958343081984198892">Web 前后端研发模式的思考</a>。</p> <p> 他首先指出了前端的产品形态：</p> <blockquote> <p>前端涉及的产品形态在业界可分为两大类：Web Pages 和 Web Apps 。</p> <p>Web Pages 是浏览类的，用户主要是来看的：以内容展现为主，辅有少量交互。前端提供基础类库，开发工具化、外包化。典型：首页、营销活动、频道等等。</p> <p>Web Apps 则以交互为主，用户主要是来用的。可分为两种：</p> <ul> <li>体验类：包含大量交互，同时用户体验很重要。比如 GMail, 支付宝收银台、淘宝购物车等等。</li> <li>功能类：包含大量交互，以功能为主，体验不是第一位的。比如后台系统、认证流程等。</li> </ul> </blockquote> <p> 接下来又指出了目前遇到的问题：</p> <blockquote> <ol> <li>Web Apps 的开发，前端投入了大量人力，但前端资源依旧存在潜在的瓶颈（比如新增加一条业务线时，很可能无前端去支持）。现有前后端配合的开发模式，沟通协作成本偏 高，可维护性不够方便。在现有的研发模式下，前端自身的价值点也很难体现出来（花了大量时间在业务上，但得到的认可不多）。</li> <li>最核心的问题，依旧是前后端的解耦：如何让前后端的工作彼此更独立，如何让更合适的人做更合适的事，把事情做得更好。</li> <li>对于体验类，目前业界有很多新兴的解决方案：Backbone, Ember, Knockout 等等，包括 YUI 的 App framework 等。这些解决方案，都希望后端专注于提供 REST 接口，其他的都交给前端来搞定。</li> <li>对于功能类的，目前业界解决方案依旧是比较老的一套，比如 GWT 等，包括 ExtJS 也是希望能让后端搞定一切。</li> </ol> </blockquote> <p> 他还提到了一些现有的解决方式：</p> <blockquote> <p>要达成第 3 点，前端需要了解数据，以及深入把控住数据之外的业务逻辑，然后利用前端技术，完成开发。</p> <p>要达成第 4 点，后端依旧需要有一定的前端技能，否则容易出性能、可维护性等问题而玩不下去。</p> </blockquote> <p> 玉伯提到他期待的方式：</p> <blockquote> <ul> <li>让前端专注于 UI 层面、体验层面的开发。</li> <li>让后端专注于数据、业务逻辑的开发。</li> <li>第 1 点和第 2 点最好能并行。能有一种很便捷的方式，</li> <li>将第 1 点和第 2 点的工作无缝衔接起来。</li> </ul> <p><strong>核心是：解耦，让更合适的人做更合适的事。</strong></p> </blockquote> <p> <a href="/misc/goto?guid=4958343082781309134">pigcan</a> 在评论中指出：</p> <blockquote> <p>特别同意关于在 web app 方向做为前端对于数据需要有非常好的了解 ！正如“我们该怎么做”中提及的 backbone，其 model、以及依托 model 在对数据进行数据 change 监听的时候，都需要对数据本身需要有很好的了解。 而这就会是一个比较大的问题，当 model 数量足够多，且依赖关系足够深的时候，如何梳理数据关系以及多人协同开发就会是一个很大的问题 。有时候不得不涉及组件与组件的数据共享与通信，以及 view 层更多细节性的问题 。</p> </blockquote> <p> 玉伯接下来贴出了自己和小凡的讨论记录，结论是：</p> <blockquote> <p>组件和接口是个好的方向，对公司整体效率提升肯定有很大帮助。经历推广和培训之后，详细能大规模实施的，只是前期阻力可能比较大。</p> </blockquote> <p> <a href="/misc/goto?guid=4958343083576071930">itsoso</a> 根据自己的经验提出：</p> <blockquote> <p>后端按照 REST 方式的约定开发接口，前端开发足够多的组件给后端用，对公司研发效率的提升会有很大帮助；后端也愿意组装各个组件，跟自己的接口结合起来，完成功能的开 发。让这个流程走通，开始的阻力应该出在后端需要做一些前端积累上，在遇到脚本、样式错误的时候能够完成 debug 的工作，这个过程中仍然需要前端的帮助，需要前端投入，完成这个积累之后，前端就可以解放出来了。</p> </blockquote> <p> <a href="/misc/goto?guid=4958343084375468134">semious</a> 的经验是：</p> <blockquote> <p>体验类开发一般可以分为几个方面：</p> <ul> <li>UI 表现</li> <li>用户界面交互逻辑</li> <li>数据交互</li> <li>前端业务逻辑</li> </ul> <p>1、对于 UI 表现这个我觉得可以通过 html 模板框架将 UI 的表现方式交给 html、css 工程师负责</p> <p>2、对于用户交互逻辑可以通过组件的方式，大多数的用户界面交互逻辑都可以组件加上 data-*配置的方式来完成，对于绝大多数的用户交互都是类似的，并且可分装的，对于复杂的交互逻辑，组件可以开放足够的 api 结果，以供调用。这部分开发我觉得可以交给初级前端工程师就可以轻易实现。</p> <p>3、对于数据交互这块我建议使用数据和 html 结构解耦的方式，将数据结构定义和所绑定的 html 结构解耦，html、css 工程师负责指定调用模板的数据源，后端开发人员定义数据格式，两者通过数据解析框架实现，数据的调用源（本地或者远程）由数据解析框架实现</p> <p>4、对于前端业务逻辑的开发，我觉得可以让后端开发来参与，因为据我了解，对于绝大后端工程师最痛苦的不是 js 编程，而是页面组件的样式调整、定位之类。现有的模式，基本实现了表现和逻辑分离，后端开发人员在 js 编程中应该碰不到样式的调整。不过我们需要一套框架，已规范后端开发工程师对 js 的编码方式，以免造成 js 代码结构性混乱。</p> </blockquote> <p> 根据大家的讨论，玉伯总结出了解决问题的初步思路：</p> <blockquote> <ol> <li>前端组件化，包括两部分： <ul> <li>基础组件：通用的 Utilities + Widgets，比如 Cookie, Calendar, TabView 等等</li> <li>业务组件：针对具体的业务，由该业务线的前端，抽取出业务线的通用组件</li> </ul> </li> <li>后端接口化，将数据抽象化、模型化，可输出为 REST 接口</li> <li>耦合框架化： <ul> <li>将后端提供的 REST 接口封装成 Model 层（或者直接在模板层同步输出数据，将数据输出标准化）。</li> <li>将设计师提供的视觉产出转换成 Template 和 Style 。</li> <li>使用前端组件实现展现层的通用交互。可通过 data-attribute api 或 handlebars helper 在 template 配置完成。</li> <li>非标准化 View 层的开发，包括 Actions 等行为脚本的开发，含展现层的业务逻辑。</li> </ul> </li> </ol> </blockquote> <p> 他还点明了开发人员在其中的职责：</p> <blockquote> <ul> <li>前端组件化由前端开发工程师完成，输出为前端通用类库和业务线的组件库。</li> <li>后端接口化由后端开发工程师完成，输出为数据模型，可同步或 REST 调用。</li> <li>耦合框架化，早期由前端工程师负责，后端工程师参与 Model 和 Action 层的部分开发，等该模式成熟到一定阶段时，可交由后端工程师独立负责，同时前端工程师由具体项目的开发，退回到该业务线的前端技术支撑。</li> </ul> </blockquote> <p> 接下来，他还就如何实现“耦合框架化”提出两种思路：</p> <blockquote> <ol> <li>渐进增强派。保持现有的研发模式不变，只调整人员的职责。比如支付宝，现在前端负责模板层的开发，接下来会逐步把模板层交会给后端开发。前端将退回到 UI 组件和样式开发的工作，后端在这过程中，要逐步学会使用前端组件，独立完成开发。</li> <li>引入前端框架。将后端的 VC 层前置到浏览器端，引入前端的 MVX. 代码按照前端框架的方式重新规范和组织，后端需要学会这一套，特别是 M 层和 Biz 行为层。从协同前端开发，到逐步能完全胜任，独立开发。</li> </ol> </blockquote> <p> 玉伯所在的团队选择使用第一种方式，并指出了流程的变化：</p> <blockquote> <p>保持现有研发模式不变 --》但调整人员职责，将更多工作交给后端独立承担 --》 在这过程中，甄别出通用问题，沉淀到前端通用类库或工具规范里 --》 进一步推进前行直到达成理想情况</p> </blockquote> <p> 当然这对前端和后端的人员都提出了要求：</p> <blockquote> <p>这种方式下，前端需要做到：</p> <ul> <li>提供简单易用的前端组件库，包括特定业务的前端组件库。后端可以基于这些组件库，快速完成页面的搭建。</li> <li>前端组件库里，包括 Alice 等样式库，并以类似 Bootstrap 的方式产出，需要比 Bootstrap 更易用。</li> <li>一套前端编码规范，需要工具化为 IDE 的插件等，保障后端的基本编码质量。</li> <li>一套可衡量的有效的最佳实践，可让后端比较容易遵守。以保障后续前端的性能优化和可维护性。</li> </ul> <p>后端开发需要做到：</p> <ul> <li>熟悉 JavaScript 语言。</li> <li>了解基本的 DOM 和 CSS 知识。</li> <li>无需了解兼容性问题。</li> </ul> <p>通过上面的方式，达成后端开发往全能的 Web Developer 的转变。</p> </blockquote> <p> <a href="/misc/goto?guid=4958343085169931192">sundayu</a> 在评论中指出他们类似的工作以失败告终：</p> <blockquote> <p>前端的难点在于通用库庞大之后的维护和升级（各个业务线都会有自己的版本），主要看功力。</p> <p>最主要的是后端的问题：</p> <ul> <li>清晰的熟悉 js 的特性。</li> <li>让他们按你的逻辑干活。</li> <li>调试。</li> </ul> <p>一直祈求后端听话、爱学、人员稳定。足够长的时间和耐性来培训培训培训。。。</p> </blockquote> <p> <a href="/misc/goto?guid=4958343085976002622">jayli</a> 认为 sundayu 说的有道理：</p> <blockquote> <p>互联网开发的基本特点是“变化”，如果你的架构无足够强的“应变”能力，在 web 开发领域难于持久。所以，结构和解耦不是解决问题的关键，而是基础，关键是 JS 超强的灵活性能否在框架中有更极致更放松的表现。现在我们的思路过于纠结各种“约束”，这和快速变化的 web 开发有时是相背的，约束太多，反倒增加执行难度～</p> </blockquote> <p> <a href="/misc/goto?guid=4958343086774096625">iwege</a> 指出：</p> <blockquote> <p>其实研发模式本身应该是切合人员配置，你的新研发模式是因为前端是瓶颈，所以让后端的救火。倘若一个公司后端为瓶颈，那前端需要切合到后端去协助。 这种相辅相成才是真正的理想状态。除非你们觉得你们公司的后端都很悠閒无聊，想让他们提高下工作效率，否则我认为最好的方式还是招聘。</p> <p>对於转变方面，设置一个讨论前提，在无资源缺乏的情况下：</p> <p>对於后端来说，Java 也好，PHP 也好，至少都是同步的，但是你要求后端直接掌握 js 知识（虽然很好掌握）却实际上是两种思维方式的转变了，相反前端一直都在同步异步之间锻鍊，对内存方面也很计较，转后端是相对简单的。因此我个人的看法 是，让后端知道前端知识，不如让前端熟悉后端的基本数据调用。</p> <p>对於接口约定方面，当然是 REST 的最好了，最好的是前端约定好 json 格式，然后让后端尝试输出就好了。前端给测试用框架。无需后端熟悉 js。</p> </blockquote> <p> <a href="/misc/goto?guid=4958343084375468134">semious</a> 继续提到：</p> <blockquote> <p>个人认为，就程序的发展历程来看，前端是从后端分离出来的，因为前端变得越来越复杂，需要专门的人手去处理，本人就是一个例子。所以个人认为让后端 的开发人员写前端代码不会是一件很难的事情，现在 JavaScript 经过那么多年的发展，其编码规范、设计模式越来越有章可循，让后端开发人员学会 js 语言本身，个人认为难度不会很高，不过后端和前端有一些比较大的不同在于：</p> <ul> <li>代码结构的不同，从标准的 OO 变成 js 特有 OO 方式，面向对象式编程到面向混合式编程（有对象，有函数）</li> <li>面向请求式编程方式（主要指 web 后端开发人员，不包括纯后端业务级的开发人员）变化到面向事件和面向文档式的编程方式</li> <li>标记性语言方面的编程特性</li> <li>JavaScript 脚本语言的特性</li> <li>运行时环境不同，从服务器环境转向浏览器环境的变化等等</li> </ul> 如果能在培训中，重点说明这些不同的话，后端人员应该能很快上手。 </blockquote> <p> 随着 Web 前端开发重要性的不断增加，前后端开发人员之间如何协调成为了大家关注的焦点。我们的读者，不知道您所了解的前后端研发模式有哪些？欢迎分享！</p> <div id="come_from"> 来自: <a id="link_source2" href="/misc/goto?guid=4958343088310765109" target="_blank">InfoQ</a> </div>