前后端解耦项目总结,前端自解耦,模块化方式

前后端解耦项目总结

项目介绍1.时间，地点，人物。

时间地点人物・2012.3 ~ 2012.6・华星时代24楼・前端，PM：天祁。开发：乌禅，拓海。测试：均量。参谋：渔隐，震中。

项目介绍1.时间，地点，人物。2.为什么？目的？从何而来？

为什么项目？1.遇到了一些问题需要解决。前端业务过于复杂，难维护・页面性能差・逻辑没有完全理清・开发效率低・难以维护・前端自耦合高・难适应视觉自定义的个性化需求・开发看不懂前端代码・类似单页面应用复杂度更上一层楼・详细的问题和解决：http://wiki.ued.taobao.net/doku.php?id=team:b2c:tmallbuy-jieou:20

为什么前后端解耦？终极目的：减轻前端工作量・前端逻辑向开发转移・前后端分离的开发模式，直接省略demo转化这一步，只需要约定并各自开发即可。・前端自解耦，逻辑清晰更易实现需求，提交效率

项目介绍1.时间，地点，人物。2.为什么？目的？从何而来？3.项目进程，迭代开发？臭屁的词。。。

项目进程1.持续三个月2.页面逻辑拆分三部分。分三部分迭代推进。・logic：render，cal，action ・前端制定方案->数据约定->前后端并行开发->联调->迭代三次。・理想状态而已，呵呵！

项目进程测试：（一个月）一个半月：提交一次开发的接口测试。两个月：提交展现部分的功能测试。两月一星期：开发代码合并主干。两月二星期：提交所有功能测试。还有一个周预发测试。

经验收获1.制定几个基本目标。定时回去思考自己的实现能不能符合基本目标。经验不足不要紧，重要的是这种在这种思考中不断成长。

经验收获2.计划赶不上变化原则就是保证发布时间，实现项目目标。其他可以随机应变。

前后端解耦约定前端发 js 数据 java 模板序列化对象 cal renderaction 完成

部分更新的时候前端发据触的数新数据发请求后台到送发据数中分构部结出据滤数过单订到盖覆据订单数据将数reRender cal action 完成

开发模式的改变基本已经没有了demo的概念。前后端评估需求-》数据约定-》前端开发并行开发-》联调-》OK

前端自解耦1.并非采用MVC。 MVC有自己的使用场景，适合于有很多条分支逻辑，和后台交互频繁的场景。MVC可以帮助梳理这些逻辑。2.订单页的场景：一条逻辑走到底。更适合以逻辑为主线的解耦方式。

前端自解耦以逻辑为主线，逻辑也可以拆分成几个部分。其他的功能模块，再插到逻辑中。最后形成一单线结构。

前端自解耦

模块化方法原则1.基本原则：互不关心。包括事件，接口，实现方式，完全互不关心。模块之间的关系完全是父级管理。想知道逻辑走向只需要看父级的代码，想知道模块的实现只需要看模块自己的代码

模块化方法 corerender cal action addressamount promo postage service insurecheckcode gbook invoice usepoint others

模块化方法横向按照逻辑拆分 logic纵向按照功能拆分 mods切勿过度模块化；鉴定：实现一个功能需要在模块间不断跳跃，大量约定、接口、交互。解耦并非越细越好，而是有一个度。

前端模板速度并非瓶颈，可大规模使用分为无逻辑和有逻辑。选用无逻辑是希望模板是简单的展示，逻辑应该写在js中。只是对数据会有破坏。渲染树状结构：http://www.html-js.com/?p=1376

谢谢！

http://www.html-js.com	1669
http://cache.baidu.com	3
http://feed.feedsky.com	2
http://translate.googleusercontent.com	2
http://www.fuck-qq.com	1

前后端解耦项目总结,前端自解耦,模块化方式

by xinyu198736 on Jun 13, 2012

Accessibility

Categories

Upload Details

Usage Rights

5 Embeds 1,677

Statistics

前后端解耦项目总结,前端自解耦,模块化方式 Presentation Transcript