-
Notifications
You must be signed in to change notification settings - Fork 333
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
研发模式的思考 #50
Comments
特别同意关于在web app 方向做为前端对于数据需要有非常好的了解 !正如“我们该怎么做”中提及的backbone,其model、以及依托model在对数据进行数据change监听的时候,都需要对数据本身需要有很好的了解。 而这就会是一个比较大的问题,当model 数量足够多,且依赖关系足够深的时候如何梳理数据关系 以及多人协同开发就会是一个很大的问题 。 有时候不得不涉及组件与组件的数据共享与通信,以及view层更多细节性的问题 。 |
做了一个后端,说下浅见:后端按照REST方式的约定开发接口,前端开发足够多的组件给后端用,对公司研发效率的提升会有很大帮助;后端也愿意组装各个组件,跟自己的接口结合起来,完成功能的开发。 |
本人抛下砖~~ |
感谢以上各位的建议。 初步思路
开发人员的职责
理想情况假设:业务线 A 有 项目1,项目2,项目3 早期:每个项目依旧要配备 1-2 名前端,负责耦合框架化的开发工作,这期间后端工程师需学习前端知识,逐步学习更多知识,直到可独立承担。 理想情况:项目 1 - 3 不再配备前端开发,直接由后端开发独立负责。针对整条业务线 A,配备 1-2 名前端,对整条业务线做前端支撑(不参与具体项目开发,主要工作是该业务线的前端通用组件的梳理,以及样式的开发和维护。) 需要的支持
|
关于 耦合框架化 的部分,有两种思路:
今天和团队成员一起讨论了下,觉得第一种方式更妥当,流程为: 保持现有研发模式不变 ---》但调整人员职责,将更多工作交给后端独立承担 --》 在这过程中,甄别出通用问题,沉淀到前端通用类库或工具规范里 --》 进一步推进前行直到达成理想情况 这种方式下,前端需要做到:
后端开发需要做到:
通过上面的方式,达成后端开发往全能的 Web Developer 的转变。 |
总觉得后端开发往全能的Web Developer发展的曲折程度要大于前端开发呢,最终两种角色还是会分久必合。 |
让后端成为前端的mysql吧. |
这个工作我们失败过,前端的难点在于通用库庞大之后的维护和升级(各个业务线都会有自己的版本),主要看功力。 |
我还是觉得直接培养前后端都有兴趣的开发人员来的比较靠谱。。。 |
@sundayu 说的有道理,互联网开发的基本特点是“变化”,如果你的架构无足够强的“应变”能力,在web开发领域难于持久。所以,结构和解偶不是解决问题的关键,而是基础,关键是JS超强的灵活性能否在框架中有更极致更放松的表现。现在我们的思路过于纠结各种“约束”,这和快速变化的web开发有时是相背的,约束太多,反到增加执行难度~ 培训倒是个好方法,只是成本有点高,还是花点事件培养人才吧,呵呵 |
其實研發模式本身應該是切合人員配置,你的新研發模式是因爲前端是瓶頸,所以讓後端的救火。倘若一個公司後端爲瓶頸,那前端需要切合到後端去協助。這種相輔相成才是真正的理想狀態。除非你們覺得你們公司的後端都很悠閒無聊,想讓他們提高下工作效率,否則我認爲最好的方式還是招聘。 對於轉變方面,設置一個討論前提,在無資源缺乏的情況下: 對於後端來說,Java也好,PHP也好,至少都是同步的,但是你要求後端直接掌握js知識(雖然很好掌握)卻實際上是兩種思維方式的轉變了,相反前端一直都在同步異步之間鍛鍊,對內存方面也很計較,轉後端是相對簡單的。因此我個人的看法是,讓後端知道前端知識,不如讓前端熟悉後端的基本數據調用。 對於接口約定方面,當然是REST的最好了,最好的是前端約定好json格式,然後讓後端嘗試輸出就好了。前端給測試用框架。無需後端熟悉js。 |
针对阿里现有的业务,总结出几套符合情况的前后端开发连调规范,对前后端人员进行培训。或者分发手册。 |
感谢大家的参与讨论。 一期 Arale 将专注于前端通用组件的打造,让 utilities 和 widgets 更简洁易用,让后端开发都能快速学会使用。 一期 Arale 不考虑前端应用框架,不试图通过 widget/view 的构建方式来改变研发模式。研发模式的改变,更多的会去从人的角度去考虑,着力点在:
感谢。 |
个人认为,就程序的发展历程来看,前端是从后端分离出来的,因为前端变得越来越复杂,需要专门的人手去处理,本人就是一个例子。所以个人认为让后端的开发人员写前端代码不会是一件很难的事情,现在javascript经过那么多年的发展,其编码规范,设计模式越来越有章可循,让后端开发人员学会js语言本身,个人认为难度不会很高,不过后端和前端有一些比较大的不同在于: |
@rekey 的思路与我的想法一致,要找一个人来做相关思路的鼓吹! |
继续细分开发者角色分工吧! |
这个问题,深感受,而且兄弟们,正大部分被拆到业务线去了。前端人的痛啊。 |
我觉得前端就应该是前端后端就应该是后端,必须要区分开! 我咋感觉大家讨论的有些偏题了呢,有兴趣的朋友可以阅读Google小组研发模式分析 软件开发模式概述 |
我赞同 @xhowhy ,搞一份前后端开发连调规范还是需要的 |
@mui-lychi 前端跟后端分离我赞同.毕竟搞惯了数据库东倒西倒的人,让他来做UI的东西,不习惯,甚至是没概念.前端一定程度上对于后端的各种中间件之类的其实也是不太能有概念的. |
@mui-lychi 唯一不敢苟同的就是把js和html,css分开操作.难道搞javascript大多数时候不是在处理dom之类的东西么?难道javascript可以好好的变成一个纯数据操作么? P.s : 前后端其实真的只需要一份api.据说数字公司的同行要写smarty.我在我公司也写jsp.我们都没有所谓的文档这一说.自己查阅api就可以了.无非就是数据是啥. |
@rekey 这一点,你多从事复杂性的前端工作应该有所感悟:展现与互动分离 ; html负责任何js执行前应该展现的代码;而js负责与用户交互 不知道是不是这个意思 |
页面是前后端共同操作的主体,但页面的职责又不是单一的(展示+互动+数据),就要有一个共同的交流平台(通常为前端调用模板或者后端调用模块化的组件),所以最后划为谁来管理制作这个页面的问题。 假设二,后端人员负责管理这个平台(页面) 好吧,我也赞成zjb82930的建议,就让开发变成 |
过程艰辛,路途遥远,能否得到支持是个问题。不过可以慢慢的朝这个方向努力。和我期待的模式差不多,其实每个有过3年以上经验,并且经历过项目,并且有思考意识的开发者,都会思索研发如何才能更快,更少重复,过程更愉悦,人员成长更快。结论大多相同,只是有细节不同,方向还是一致的。 |
希望Arale能包含Css开发与部署,利用好Less或Sass的模块化编程能力。 |
@zicjin css 部分,会在 Alice 里系统考虑 |
Web Pages 和 Web Apps很大的一个变化就是职责重心的偏移,以前的话,前者前端开发人员也许只要切割下页面,实现些效果,做些简单的页面逻辑就好了,而现在服务端的一部分任务转移到了前端,他们不得不深深的涉及到到业务逻辑内部,如果没有一定的思维能力,即使有完善的接口文档、丰富的组件库,依然难以保证开发质量和进度,这也是前端资源很容易紧张的根本原因。 我们尝试过将后端开发人员培训前端知识,不得不说这个难度超出想象。从心理上讲,后端开发属于正统开发,前端开发属于花拳绣腿,会有抵触。从技术上讲后端开发平台确定,不用过多考虑兼容性,可以专注于业务本身,而前端涉及技术芜杂又过于灵活,动不动还要为一两个浏览器兼容性的小bug折腾几个小时,这些不确定性考验着人的耐力。作为前端工程师,没有个一、两年的积累,入门可能都算不上,这个确实还要要看人的潜质如何。 总的来说,人决定开发模式,没有统一模式。后端资源多就把更多的处理放在后端,前端多就放在前端,初级前端工程师多就多利用模板特性,放在页面模板上。 |
很认同 @bigtreexu:人决定开发模式 目前阿里的困惑是,人短时间内无法发生很大的改变,在这种现状下(后端开发很多但了解前端的不多,前端开发一直很紧张),如何去做到项目开发不受前端制肘。 根据和后端开发交流的经验,我觉得后端并不排斥学习前端,特别是学习 JavaScript,后端排斥和难以精通的是前端的兼容性问题,这不是后端开发的强项所在。如果能通过框架、工具等方式,做到让前端兼容性的绝大部分隔离,让后端可以基于前端组件、工具写出页面,这对后端开发来说会是很不错的开发体验,我接触过的后端开发是愿意去尝试的。如果能做到这一步,也能让前端开发更专注于展现层、体验层的开发和创新,于己于公司,都是更好的。 Arale 项目的核心,是尝试去构建一套前端组件库,基于这套组件库,不光前端可以极大提高工作效率,后端开发也可以直接使用起来。尝试中前行,行进中开火ing |
@lifesinger 恩,这两年我们已经做了这样的尝试,有不少经验和教训,可以做借鉴。
呵呵,乱谈了一把,希望能有所启发,祝好。 |
@bigtreexu 非常感谢你的分享,很有借鉴意义。 |
参考flex开发模式? |
@lifesinger ,你前面说
就这一点,我担心会不会这个框架到时候变成了 ExtJS ? |
恩,赞同@bigtreexu:人决定开发模式 |
一口气读完,对于我非常有意义,有了一些新的思路,多谢多谢。 |
@imanman 不喜欢是因为不会么? |
@rekey 多谢回复。 我总碰到觉得jsp写久了就会变得很丑陋,一些必不可免的逻辑在页面端存在或者一个页面include一个页面的,不过一直也没有其他的好解决办法,总觉得模版语言好像也不能解决这些问题。现在也再考虑,把页面组件化是否可行,因为必不可免的会遇到一些组件之间的通讯,没有这方面的经验,正在摸索中。 而且我最理想的工作方式是:前端html写好后,通过js或者其他方式直接跟后端的api进行通讯,以最小的成本实现整个过程,不需要重新使后台程序员再套一遍。。。。 |
@imanman 对你说的理想方式,一些大公司都要求那样。很多都是要前端与后端沟通好数据接口后,通过JS或某后端语言模拟好数据后,把前端逻辑写好,再把完整的前端交付物给后端。这样就可以节省很多时间。 |
Typo:
|
产品形态
目前遇到的问题
利用业界现有的解决方式:
这两种,需要前后通吃的 Web Developer 来达成。在阿里,目前很难。
我们期待的方式
核心是:解藕,让更合适的人做更合适的事。
我们该怎么做
目前 Arale 的发展方向,可以很好的支撑:
目前 Arale 没想清楚如何支撑第三种模式:
还有一个很现实的问题,如果体验类的研发模式可行,意味着要投入大量前端资源去做,这对产品是利好的,但这一研发模式,很可能会加剧前端的资源瓶颈问题。有无可能培养后端成为体验类的前端开发?让部分后端也可以独立承担开发?
越想越觉得迷茫,我们期待的研发模式,究竟靠不靠谱?如果要做,具体究竟该如何做?
集思广益,大家发表点建议。
The text was updated successfully, but these errors were encountered: