研发模式的思考 about aralejs.github.io HOT 38 CLOSED

特别同意关于在web app 方向做为前端对于数据需要有非常好的了解 ！正如“我们该怎么做”中提及的backbone，其model、以及依托model在对数据进行数据change监听的时候，都需要对数据本身需要有很好的了解。 而这就会是一个比较大的问题，当model 数量足够多，且依赖关系足够深的时候如何梳理数据关系 以及多人协同开发就会是一个很大的问题 。 有时候不得不涉及组件与组件的数据共享与通信，以及view层更多细节性的问题 。

from aralejs.github.io.

做了一个后端，说下浅见：后端按照REST方式的约定开发接口，前端开发足够多的组件给后端用，对公司研发效率的提升会有很大帮助；后端也愿意组装各个组件，跟自己的接口结合起来，完成功能的开发。
让这个流程走通，开始的阻力应该出在后端需要做一些前端积累上，在遇到脚本、样式错误的时候能够完成debug的工作，这个过程中仍然需要前端的帮助，需要前端投入，完成这个积累之后，前端就可以解放出来了。

from aralejs.github.io.

本人抛下砖~~
个人看法，体验类开发一般可以分为几的方面：1、UI表现 2、用户界面交互逻辑 3、数据交互 4、前端业务逻辑
1、对于UI表现 这个我觉得可以通过 html模板框架 将UI的表现方式交给 html、css工程师负责
2、对于用户交互逻辑 可以通过组件的方式，大多数的用户界面交互逻辑都可以组件加上data-*配置的方式来完成，对于绝大多数的用户交互都是类似的，并且可分装的，对于复杂的交互逻辑，组件可以开放足够的api结果，以供调用。这部分开发 我觉得可以交给 初级前端工程师就可以轻易实现。
3、对于数据交互这块 我建议使用数据和html结构解耦的方式，将数据结构定义和所绑定的html结构解耦，html、css工程师负责指定调用模板的数据源，后端开发人员定义数据格式，两者通过数据解析框架实现，数据的调用源（本地或者远程）由数据解析框架实现
4、对于前端业务逻辑的开发，我觉得可以让后端开发来参与，因为据我了解，对于绝大后端工程师最痛苦的不是js编程，而是页面组件的样式调整、定位之类。现有的模式，基本实现了表现和逻辑分离，后端开发人员在js编程中应该碰不到样式的调整。不过我们需要一套框架，已规范后端开发工程师对js的编码方式，以免造成js代码结构性混乱。

from aralejs.github.io.

感谢以上各位的建议。

初步思路

1. 前端组件化，包括两部分：
   1. 基础组件：通用的 Utilities + Widgets，比如 Cookie, Calendar, TabView 等等
   2. 业务组件：针对具体的业务，由该业务线的前端，抽取出业务线的通用组件
2. 后端接口化，将数据抽象化、模型化，可输出为 REST 接口
3. 耦合框架化：
   1. 将后端提供的 REST 接口封装成 Model 层（或者直接在模板层同步输出数据，将数据输出标准化）。
   2. 将设计师提供的视觉产出转换成 Template 和 Style 。
   3. 使用前端组件实现展现层的通用交互。可通过 data-attribute api 或 handlebars helper 在 template 配置完成。
   4. 非标准化 View 层的开发，包括 Actions 等行为脚本的开发，含展现层的业务逻辑。

开发人员的职责

• 前端组件化由前端开发工程师完成，输出为前端通用类库和业务线的组件库。
• 后端接口化由后端开发工程师完成，输出为数据模型，可同步或 REST 调用。
• 耦合框架化，早期由前端工程师负责，后端工程师参与 Model 和 Action 层的部分开发，等该模式成熟到一定阶段时，可交由后端工程师独立负责，同时前端工程师由具体项目的开发，退回到该业务线的前端技术支撑。

理想情况

假设：业务线 A 有 项目1，项目2，项目3

早期：每个项目依旧要配备 1-2 名前端，负责耦合框架化的开发工作，这期间后端工程师需学习前端知识，逐步学习更多知识，直到可独立承担。

理想情况：项目 1 - 3 不再配备前端开发，直接由后端开发独立负责。针对整条业务线 A，配备 1-2 名前端，对整条业务线做前端支撑（不参与具体项目开发，主要工作是该业务线的前端通用组件的梳理，以及样式的开发和维护。）

需要的支持

1. 要让后端学习前端知识，包括：JavaScript 语言，基础的 DOM 知识，以及前端的展现架构（比如前端的 MVC 模式）。不需要掌握 CSS。
2. 时间，试错时间，和试点项目。

from aralejs.github.io.

关于 耦合框架化 的部分，有两种思路：

1. 渐进增强派。保持现有的研发模式不变，只调整人员的职责。比如支付宝，现在前端负责模板层的开发，接下来会逐步把模板层交会给后端开发。前端将退回到 UI 组件和样式开发的工作，后端在这过程中，要逐步学会使用前端组件，独立完成开发。
2. 引入前端框架。将后端的 VC 层前置到浏览器端，引入前端的 MVX. 代码按照前端框架的方式重新规范和组织，后端需要学会这一套，特别是 M 层和 Biz 行为层。从协同前端开发，到逐步能完全胜任，独立开发。

今天和团队成员一起讨论了下，觉得第一种方式更妥当，流程为：

保持现有研发模式不变 ---》但调整人员职责，将更多工作交给后端独立承担 --》 在这过程中，甄别出通用问题，沉淀到前端通用类库或工具规范里 --》 进一步推进前行直到达成理想情况

这种方式下，前端需要做到：

1. 提供简单易用的前端组件库，包括特定业务的前端组件库。后端可以基于这些组件库，快速完成页面的搭建。
2. 前端组件库里，包括 Alice 等样式库，并以类似 Bootstrap 的方式产出，需要比 Bootstrap 更易用。
3. 一套前端编码规范，需要工具化为 IDE 的插件等，保障后端的基本编码质量。
4. 一套可衡量的有效的最佳实践，可让后端比较容易遵守。以保障后续前端的性能优化和可维护性。

后端开发需要做到：

1. 熟悉 JavaScript 语言。
2. 了解基本的 DOM 和 CSS 知识。
3. 无需了解兼容性问题。

通过上面的方式，达成后端开发往全能的 Web Developer 的转变。

from aralejs.github.io.

总觉得后端开发往全能的Web Developer发展的曲折程度要大于前端开发呢，最终两种角色还是会分久必合。

from aralejs.github.io.

让后端成为前端的mysql吧.

from aralejs.github.io.

这个工作我们失败过，前端的难点在于通用库庞大之后的维护和升级（各个业务线都会有自己的版本），主要看功力。
最主要的是后端的问题：1、清晰的熟悉js的特性。2、让他们按你的逻辑干活。3、调试。
一直祈求后端听话、爱学、人员稳定。足够长的时间和耐性来培训培训培训。。。

from aralejs.github.io.

我还是觉得直接培养前后端都有兴趣的开发人员来的比较靠谱。。。

from aralejs.github.io.

@sundayu 说的有道理，互联网开发的基本特点是“变化”，如果你的架构无足够强的“应变”能力，在web开发领域难于持久。所以，结构和解偶不是解决问题的关键，而是基础，关键是JS超强的灵活性能否在框架中有更极致更放松的表现。现在我们的思路过于纠结各种“约束”，这和快速变化的web开发有时是相背的，约束太多，反到增加执行难度～

培训倒是个好方法，只是成本有点高，还是花点事件培养人才吧，呵呵

from aralejs.github.io.

其實研發模式本身應該是切合人員配置，你的新研發模式是因爲前端是瓶頸，所以讓後端的救火。倘若一個公司後端爲瓶頸，那前端需要切合到後端去協助。這種相輔相成才是真正的理想狀態。除非你們覺得你們公司的後端都很悠閒無聊，想讓他們提高下工作效率，否則我認爲最好的方式還是招聘。

對於轉變方面，設置一個討論前提，在無資源缺乏的情況下：

對於後端來說，Java也好，PHP也好，至少都是同步的，但是你要求後端直接掌握js知識（雖然很好掌握）卻實際上是兩種思維方式的轉變了，相反前端一直都在同步異步之間鍛鍊，對內存方面也很計較，轉後端是相對簡單的。因此我個人的看法是，讓後端知道前端知識，不如讓前端熟悉後端的基本數據調用。

對於接口約定方面，當然是REST的最好了，最好的是前端約定好json格式，然後讓後端嘗試輸出就好了。前端給測試用框架。無需後端熟悉js。

from aralejs.github.io.

针对阿里现有的业务，总结出几套符合情况的前后端开发连调规范，对前后端人员进行培训。或者分发手册。

from aralejs.github.io.

感谢大家的参与讨论。

一期 Arale 将专注于前端通用组件的打造，让 utilities 和 widgets 更简洁易用，让后端开发都能快速学会使用。

一期 Arale 不考虑前端应用框架，不试图通过 widget/view 的构建方式来改变研发模式。研发模式的改变，更多的会去从人的角度去考虑，着力点在：

1. 前端组件的文档是否丰富，接口是否易用，要让开发也能快速学会。
2. 多一些培训，让后端也懂前端。

感谢。

from aralejs.github.io.

个人认为，就程序的发展历程来看，前端是从后端分离出来的，因为前端变得越来越复杂，需要专门的人手去处理，本人就是一个例子。所以个人认为让后端的开发人员写前端代码不会是一件很难的事情，现在javascript经过那么多年的发展，其编码规范，设计模式越来越有章可循，让后端开发人员学会js语言本身，个人认为难度不会很高，不过后端和前端有一些比较大的不同在于：
1、代码结构的不同，从标准的OO变成js特有OO方式，面向对象式编程到面向混合式编程（有对象，有函数）
2、面向请求式编程方式（主要指web后端开发人员，不包括纯后端业务级的开发人员）变化到面向事件和面向文档式的编程方式
3、标记性语言方面的编程特性
4、javascript脚本语言的特性
5、运行时环境不同,从服务器环境转向游览器环境的变化
等等
如果能在培训中，重点说明这些不同的话，后端人员应该能很快上手，加上我们现有强大的arale框架的支撑

from aralejs.github.io.

@rekey 的思路与我的想法一致，要找一个人来做相关思路的鼓吹！

from aralejs.github.io.

继续细分开发者角色分工吧！
开发分为 web developer、data developer，前端的JS工作移交到 web developer身上，CSS/Html 交给专门的页面构建师

from aralejs.github.io.

这个问题，深感受，而且兄弟们，正大部分被拆到业务线去了。前端人的痛啊。

from aralejs.github.io.

我觉得前端就应该是前端后端就应该是后端，必须要区分开！
为什么非呆要后端去写前端啊？非呆要前端去写后端呢？如果他们有兴趣的话，他们自己去学习、研究！
后端同学遇见样式出问题、数据渲染有问题，就应该立刻有前端同学去支持，为什么非要让他们自己去搞呢，为了让他们能够自己搞得来，前端付出了很多的精力考虑如何让后端做些前端的事情，真的有介个必要嘛！
我觉得当前需要做的是在前端这块把写 js 的和写 html & css 的做下清晰的区分，这样让 js 的同学畅快的写 js，并且去研究、学习后端；让写 html & css 的同学畅快的写华丽的页面吧！

我咋感觉大家讨论的有些偏题了呢，有兴趣的朋友可以阅读Google小组研发模式分析 软件开发模式概述

from aralejs.github.io.

我赞同 @xhowhy ，搞一份前后端开发连调规范还是需要的

from aralejs.github.io.

@mui-lychi 前端跟后端分离我赞同.毕竟搞惯了数据库东倒西倒的人,让他来做UI的东西,不习惯,甚至是没概念.前端一定程度上对于后端的各种中间件之类的其实也是不太能有概念的.

from aralejs.github.io.

@mui-lychi 唯一不敢苟同的就是把js和html,css分开操作.难道搞javascript大多数时候不是在处理dom之类的东西么?难道javascript可以好好的变成一个纯数据操作么?

P.s : 前后端其实真的只需要一份api.据说数字公司的同行要写smarty.我在我公司也写jsp.我们都没有所谓的文档这一说.自己查阅api就可以了.无非就是数据是啥.

from aralejs.github.io.

@rekey 这一点，你多从事复杂性的前端工作应该有所感悟：展现与互动分离 ； html负责任何js执行前应该展现的代码；而js负责与用户交互

不知道是不是这个意思

from aralejs.github.io.

页面是前后端共同操作的主体，但页面的职责又不是单一的（展示+互动+数据），就要有一个共同的交流平台（通常为前端调用模板或者后端调用模块化的组件），所以最后划为谁来管理制作这个页面的问题。
假设一，前端人员负责管理这个平台（页面）
优势：可以快速调整debug页面的展现（样式及行为）
劣势：需要处理好页面的业务逻辑及数据的交流，那么前端人员就被迫了解整个系统才能处理好

假设二，后端人员负责管理这个平台（页面）
优势：整个业务逻辑、数据都在掌握之中
劣势：需要弄清楚每个前端给的组件的调用，在debug及fix bug阶段，会比较痛苦

好吧，我也赞成zjb82930的建议，就让开发变成
”页面重构人员（提供组件化的ui）←→页面装配人员（负责前端业务逻辑+组装页面）←→（提供交互的数据）后台程序人员“
（实在是奢侈的开发方式。。。）

from aralejs.github.io.

过程艰辛，路途遥远，能否得到支持是个问题。不过可以慢慢的朝这个方向努力。和我期待的模式差不多，其实每个有过3年以上经验，并且经历过项目，并且有思考意识的开发者，都会思索研发如何才能更快，更少重复，过程更愉悦，人员成长更快。结论大多相同，只是有细节不同，方向还是一致的。
主要问题是如何去实施自己的想法，从哪里下手，如何得到上面的支持，如何在当今这个快速响应的时代抽出时间做这些基础支撑工作。
肯定不能全面铺开，只能从一个角度改进，这个角度在哪里，铺开的度如何把握，需要为将来预留吗，预留到什么程度，等等这类的问题，才是关键所在。

from aralejs.github.io.

希望Arale能包含Css开发与部署，利用好Less或Sass的模块化编程能力。

from aralejs.github.io.

@zicjin css 部分，会在 Alice 里系统考虑

from aralejs.github.io.

Web Pages 和 Web Apps很大的一个变化就是职责重心的偏移，以前的话，前者前端开发人员也许只要切割下页面，实现些效果，做些简单的页面逻辑就好了，而现在服务端的一部分任务转移到了前端，他们不得不深深的涉及到到业务逻辑内部，如果没有一定的思维能力，即使有完善的接口文档、丰富的组件库，依然难以保证开发质量和进度，这也是前端资源很容易紧张的根本原因。

我们尝试过将后端开发人员培训前端知识，不得不说这个难度超出想象。从心理上讲，后端开发属于正统开发，前端开发属于花拳绣腿，会有抵触。从技术上讲后端开发平台确定，不用过多考虑兼容性，可以专注于业务本身，而前端涉及技术芜杂又过于灵活，动不动还要为一两个浏览器兼容性的小bug折腾几个小时，这些不确定性考验着人的耐力。作为前端工程师，没有个一、两年的积累，入门可能都算不上，这个确实还要要看人的潜质如何。

总的来说，人决定开发模式，没有统一模式。后端资源多就把更多的处理放在后端，前端多就放在前端，初级前端工程师多就多利用模板特性，放在页面模板上。

from aralejs.github.io.

很认同 @bigtreexu：人决定开发模式

目前阿里的困惑是，人短时间内无法发生很大的改变，在这种现状下（后端开发很多但了解前端的不多，前端开发一直很紧张），如何去做到项目开发不受前端制肘。

根据和后端开发交流的经验，我觉得后端并不排斥学习前端，特别是学习 JavaScript，后端排斥和难以精通的是前端的兼容性问题，这不是后端开发的强项所在。如果能通过框架、工具等方式，做到让前端兼容性的绝大部分隔离，让后端可以基于前端组件、工具写出页面，这对后端开发来说会是很不错的开发体验，我接触过的后端开发是愿意去尝试的。如果能做到这一步，也能让前端开发更专注于展现层、体验层的开发和创新，于己于公司，都是更好的。

Arale 项目的核心，是尝试去构建一套前端组件库，基于这套组件库，不光前端可以极大提高工作效率，后端开发也可以直接使用起来。尝试中前行，行进中开火ing

from aralejs.github.io.

@lifesinger 恩，这两年我们已经做了这样的尝试，有不少经验和教训，可以做借鉴。

1. 性能：后端开发人员的一知半解可能会造成前端代码有破碎感，容易造成严重的性能问题和很多莫名奇妙的小bug，需要有核心人员参与控制，不过成本偏高。这个可以参考微软WinForm到WebForm转变出现的问题，以及ExtJS众多的使用反馈。
2. 约束：如果说javascript这种弱类型语言比较灵活，而YUI封装的更面向对象些友好些，那么jQuery更是有些天马行空了，可能需要更多的约束。
3. 开发模式：前端资源不足是普遍现象，但如果有几个核心的成员在，开发一套好的框架和组件库，提供一种对后端友好的开发模式，是能够避免相当多的问题，比如，建立统一运行模型、数据模型等。另外，要不要使用跨界绑定，将服务器端对象的方法直接绑定到前端对象上，让前端接口调用就像本地调用的感觉一样？（只是一种思考）这考验框架和组件的封装能力，但对于降低开发难度，统一开发规范非常有价值。

呵呵，乱谈了一把，希望能有所启发，祝好。

from aralejs.github.io.

@bigtreexu 非常感谢你的分享，很有借鉴意义。

from aralejs.github.io.

参考flex开发模式？

from aralejs.github.io.

@lifesinger ，你前面说

如果能通过框架、工具等方式，做到让前端兼容性的绝大部分隔离，让后端可以基于前端组件、工具写出页面，这对后端开发来说会是很不错的开发体验，我接触过的后端开发是愿意去尝试的

就这一点，我担心会不会这个框架到时候变成了 ExtJS ？

from aralejs.github.io.

恩，赞同@bigtreexu：人决定开发模式

from aralejs.github.io.

一口气读完，对于我非常有意义，有了一些新的思路，多谢多谢。
这个课题也是我目前遇到的问题：
我们整个team：３个后端程序员，一个前端制作。
我们的工作流程是：每次有新功能，先页面制作做成html后，交付给再由一个人开发整个功能：后台功能开发＋套页面翻译成jsp。。。中间这个环节总是很多余，前端制作后，再由一个人重新套一边，很容易出错。个人非常不喜欢jsp。。。

from aralejs.github.io.

@imanman 不喜欢是因为不会么?

from aralejs.github.io.

＠rekey 多谢回复。

我总碰到觉得jsp写久了就会变得很丑陋，一些必不可免的逻辑在页面端存在或者一个页面include一个页面的，不过一直也没有其他的好解决办法，总觉得模版语言好像也不能解决这些问题。现在也再考虑，把页面组件化是否可行，因为必不可免的会遇到一些组件之间的通讯，没有这方面的经验，正在摸索中。

而且我最理想的工作方式是：前端html写好后，通过js或者其他方式直接跟后端的api进行通讯，以最小的成本实现整个过程，不需要重新使后台程序员再套一遍。。。。

from aralejs.github.io.

@imanman 对你说的理想方式，一些大公司都要求那样。很多都是要前端与后端沟通好数据接口后，通过JS或某后端语言模拟好数据后，把前端逻辑写好，再把完整的前端交付物给后端。这样就可以节省很多时间。

from aralejs.github.io.

Typo:

--- 核心是：解藕，让更合适的人做更合适的事。
+++ 核心是：解耦，让更合适的人做更合适的事。

from aralejs.github.io.