前后端解耦项目总结
项目介绍1.时间,地点,人物。
时间地点人物・2012.3 ~ 2012.6・华星时代24楼・前端,PM:天祁。 开发:乌禅,拓海。 测试:均量。 参谋:渔隐,震中。
项目介绍1.时间,地点,人物。2.为什么?目的?从何而来?
为什么项目?1.遇到了一些问题需要解决。    前端业务过于复杂,难维护・页面性能差・    逻辑没有完全理清・开发效率低・难以维护・    前端自耦合高・难适应视觉自定义的个性化需求・    开发看不懂前端代码・类似单页面应用复杂度更上一层楼...
为什么前后端解耦?终极目的:减轻前端工作量 ・前端逻辑向开发转移  ・前后端分离的开发模式,直接省略demo转化这一步,只需要约定并各自开发即可。 ・前端自解耦,逻辑清晰更易实现需求,提交效率
项目介绍1.时间,地点,人物。2.为什么?目的?从何而来?3.项目进程,迭代开发?臭屁的词。。。
项目进程1.持续 三个月2.页面逻辑拆分三部分。分三部分迭代推进。 ・logic:render,cal,action ・前端制定方案->数据约定->前后端并行开发->联调->迭代三次。 ・理想状态而已,呵呵!
项目进程测试:(一个月)一个半月 :提交一次开发的接口测试。两个月   :提交展现部分的功能测试。两月一星期:开发代码合并主干。两月二星期:提交所有功能测试。还有一个周预发测试。
经验收获1.制定几个基本目标。定时回去思考自己的实现能不能符合基本目标。经验不足不要紧,重要的是这种在这种思考中不断成长。
经验收获2.计划赶不上变化原则就是保证发布时间,实现项目目标。其他可以随机应变。
前后端解耦                        约定         前端                         发          js            数据         java         模板    ...
部分更新的时候 前端                                                                              发                                 ...
开发模式的改变基本已经没有了demo的概念。前后端评估需求-》数据约定-》前端开发并行开发-》联调-》OK
前端自解耦1.并非采用MVC。 MVC有自己的使用场景,适合于有很多条分支逻辑,和后台交互频繁的场景。MVC可以帮助梳理这些逻辑。2.订单页的场景:一条逻辑走到底。更适合以逻辑为主线的解耦方式。
前端自解耦以逻辑为主线,逻辑也可以拆分成几个部分。其他的功能模块,再   插到逻辑中。最后形成一   单线结构。
前端自解耦
模块化方法原则1.基本原则:互不关心。 包括事件,接口,实现方式,完全互不关心。 模块之间的关系完全是父级管理。 想知道逻辑走向只需要看父级的代码, 想知道模块的实现只需要看模块自己的代码
模块化方法 corerender       cal    action    addressamount      promo   postage   service    insurecheckcode   gbook   invoice ...
模块化方法横向按照逻辑拆分 logic纵向按照功能拆分 mods切勿过度模块化;鉴定:实现一个功能需要在模块间不断跳跃,大量约定、接口、交互。解耦并非越细越好,而是有一个度。
前端模板速度并非瓶颈,可大规模使用分为无逻辑和有逻辑。选用无逻辑是希望模板是简单的展示,逻辑应该写在js中。只是对数据会有破坏。渲染树状结构:http://www.html-js.com/?p=1376
谢谢!
前后端解耦项目总结,前端自解耦,模块化方式
Upcoming SlideShare
Loading in …5
×

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

6,943 views

Published on

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

Published in: Technology
0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,943
On SlideShare
0
From Embeds
0
Number of Embeds
1,715
Actions
Shares
0
Downloads
42
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 前后端解耦项目总结,前端自解耦,模块化方式

    1. 1. 前后端解耦项目总结
    2. 2. 项目介绍1.时间,地点,人物。
    3. 3. 时间地点人物・2012.3 ~ 2012.6・华星时代24楼・前端,PM:天祁。 开发:乌禅,拓海。 测试:均量。 参谋:渔隐,震中。
    4. 4. 项目介绍1.时间,地点,人物。2.为什么?目的?从何而来?
    5. 5. 为什么项目?1.遇到了一些问题需要解决。 前端业务过于复杂,难维护・页面性能差・ 逻辑没有完全理清・开发效率低・难以维护・ 前端自耦合高・难适应视觉自定义的个性化需求・ 开发看不懂前端代码・类似单页面应用复杂度更上一层楼・ 详细的问题和解决:http://wiki.ued.taobao.net/doku.php?id=team:b2c:tmallbuy-jieou:20
    6. 6. 为什么前后端解耦?终极目的:减轻前端工作量 ・前端逻辑向开发转移 ・前后端分离的开发模式,直接省略demo转化这一步,只需要约定并各自开发即可。 ・前端自解耦,逻辑清晰更易实现需求,提交效率
    7. 7. 项目介绍1.时间,地点,人物。2.为什么?目的?从何而来?3.项目进程,迭代开发?臭屁的词。。。
    8. 8. 项目进程1.持续 三个月2.页面逻辑拆分三部分。分三部分迭代推进。 ・logic:render,cal,action ・前端制定方案->数据约定->前后端并行开发->联调->迭代三次。 ・理想状态而已,呵呵!
    9. 9. 项目进程测试:(一个月)一个半月 :提交一次开发的接口测试。两个月 :提交展现部分的功能测试。两月一星期:开发代码合并主干。两月二星期:提交所有功能测试。还有一个周预发测试。
    10. 10. 经验收获1.制定几个基本目标。定时回去思考自己的实现能不能符合基本目标。经验不足不要紧,重要的是这种在这种思考中不断成长。
    11. 11. 经验收获2.计划赶不上变化原则就是保证发布时间,实现项目目标。其他可以随机应变。
    12. 12. 前后端解耦 约定 前端 发 js 数据 java 模板 序列化 对象 cal renderaction 完成
    13. 13. 部分更新的时候 前端 发 据 触 的 数 新 数据发请求 后 台 到 送 发 据 数 中 分 构 部 结 出 据 滤 数 过 单 订 到 盖 覆 据订单数据 将 数reRender cal action 完成
    14. 14. 开发模式的改变基本已经没有了demo的概念。前后端评估需求-》数据约定-》前端开发并行开发-》联调-》OK
    15. 15. 前端自解耦1.并非采用MVC。 MVC有自己的使用场景,适合于有很多条分支逻辑,和后台交互频繁的场景。MVC可以帮助梳理这些逻辑。2.订单页的场景:一条逻辑走到底。更适合以逻辑为主线的解耦方式。
    16. 16. 前端自解耦以逻辑为主线,逻辑也可以拆分成几个部分。其他的功能模块,再 插到逻辑中。最后形成一 单线结构。
    17. 17. 前端自解耦
    18. 18. 模块化方法原则1.基本原则:互不关心。 包括事件,接口,实现方式,完全互不关心。 模块之间的关系完全是父级管理。 想知道逻辑走向只需要看父级的代码, 想知道模块的实现只需要看模块自己的代码
    19. 19. 模块化方法 corerender cal action addressamount promo postage service insurecheckcode gbook invoice usepoint others
    20. 20. 模块化方法横向按照逻辑拆分 logic纵向按照功能拆分 mods切勿过度模块化;鉴定:实现一个功能需要在模块间不断跳跃,大量约定、接口、交互。解耦并非越细越好,而是有一个度。
    21. 21. 前端模板速度并非瓶颈,可大规模使用分为无逻辑和有逻辑。选用无逻辑是希望模板是简单的展示,逻辑应该写在js中。只是对数据会有破坏。渲染树状结构:http://www.html-js.com/?p=1376
    22. 22. 谢谢!

    ×