前后端解耦,前端自解耦,模块化方式

1. 前后端解耦项目总结

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17. 前端自解耦

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

19. 模块化方法
core
render cal action address
amount promo postage service insure
checkcode gbook invoice usepoint others

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

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

23. 谢谢！