Your SlideShare is downloading. ×
天祁《交易线》
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

天祁《交易线》

367

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
367
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Transcript

    • 1. 天猫交易系统的过去,现在和未来 by tianqi@天猫
    • 2. 交易线是个神马?• 交易包括三个部分:• 购物篮• 下单• 订单详情
    • 3. 交易线做神马?• 支持整站的交易行为• 为垂直业务线作支持,例如IPAD,线下 体验店。• 为垂直市场特殊业务作支持,例如电器 城家装馆服务,跨店活动优惠。
    • 4. 交易线的特殊性• 业务逻辑 杂• 价格计算必须一分不差• 前后端耦合严重,通过接口耦合
    • 5. 积分换购 积分加钱购 货到付款单品优惠 数量 免邮 运费险 运费 店铺优惠 送积分服务 使用积分数量 商品 积分加钱购 子订单 活动优惠 商品 分期付款在UI上 活动订单 商品有所体 子订单 主订单 商品现的逻 商品辑 子订单 商品
    • 6. 前后端耦合
    • 7. 前后端耦合普通的耦合
    • 8. 前后端耦合 VM由 发维护,里面有大量后台业务逻辑,例如为了普通的耦合 呈现某一块内容, 发书写了大量ifelse,其实这部分
    • 9. 前后端耦合 VM由 发维护,里面有大量后台业务逻辑,例如为了普通的耦合 呈现某一块内容, 发书写了大量ifelse,其实这部分接口的耦合
    • 10. 前后端耦合 VM由 发维护,里面有大量后台业务逻辑,例如为了普通的耦合 呈现某一块内容, 发书写了大量ifelse,其实这部分 大量使用接口,在一条整体逻辑中,前端负责一部接口的耦合 分, 发负责一部分,二者通过接口交互,其实前端
    • 11. 前后端耦合 VM由 发维护,里面有大量后台业务逻辑,例如为了普通的耦合 呈现某一块内容, 发书写了大量ifelse,其实这部分 大量使用接口,在一条整体逻辑中,前端负责一部接口的耦合 分, 发负责一部分,二者通过接口交互,其实前端逻辑的耦合
    • 12. 前后端耦合 VM由 发维护,里面有大量后台业务逻辑,例如为了普通的耦合 呈现某一块内容, 发书写了大量ifelse,其实这部分 大量使用接口,在一条整体逻辑中,前端负责一部接口的耦合 分, 发负责一部分,二者通过接口交互,其实前端 大量业务逻辑堆积在前端,前端的逻辑和代码比 发逻辑的耦合 只多不少
    • 13. 价格计算以服务为例,其中一条非常小的子线 初始化, 发计算服务价格 改变服务选择 改变数量 商品价格 服务单价 服务总价 切换优惠 子订单价格 活动订单价格 主订单的价格
    • 14. 历史-里程碑尝试独立 线上下单 购物篮 选型 订单详情 活动优惠摸索很痛苦 服务 代码小范围重构家装馆下单
    • 15. 历史-遗留问题
    • 16. 历史-遗留问题 逻辑清晰了,但是维护困难,模块化不
    • 17. 历史-遗留问题过度模块化 逻辑清晰了,但是维护困难,模块化不
    • 18. 历史-遗留问题过度模块化 逻辑清晰了,但是维护困难,模块化不逻辑混乱
    • 19. 历史-遗留问题过度模块化 逻辑清晰了,但是维护困难,模块化不逻辑混乱 至今仍然没有整理清楚所有逻辑。文档
    • 20. 历史-遗留问题过度模块化 逻辑清晰了,但是维护困难,模块化不逻辑混乱 至今仍然没有整理清楚所有逻辑。文档前端逻辑太多
    • 21. 历史-遗留问题过度模块化 逻辑清晰了,但是维护困难,模块化不逻辑混乱 至今仍然没有整理清楚所有逻辑。文档前端逻辑太多 大量逻辑控制在前端,代码混乱,容易
    • 22. 历史-遗留问题过度模块化 逻辑清晰了,但是维护困难,模块化不 逻辑混乱 至今仍然没有整理清楚所有逻辑。文档前端逻辑太多 大量逻辑控制在前端,代码混乱,容易扩展性和性能
    • 23. 历史-遗留问题过度模块化 逻辑清晰了,但是维护困难,模块化不 逻辑混乱 至今仍然没有整理清楚所有逻辑。文档前端逻辑太多 大量逻辑控制在前端,代码混乱,容易扩展性和性能 逻辑和耦合造成扩展性较差。性能也较
    • 24. 现在
    • 25. 现在 动手术!
    • 26. 前后端解耦 前端负责展现 发负责数据前端维护最基本的逻辑 初始数据 初始订单结构数据只负责展现和交互 数据接口 大部分特殊业务逻辑维护一个固定的数据结构无逻辑的前端模板 解耦的最终目标,是前端只负责展现,而且能保存最纯洁的数据 结构,不管如何交互,前端只 心后台需要谁的属性值,我需要 后台返回谁的新的属性值,而不 心其中的具体逻辑。数据结构 不会增加新的标示。
    • 27. 逻辑整理项目 始之前, 个周整理时间效果:随意口述,说一条交互,口头算出价格文档化,交互 系图表,特殊逻辑说明等等。跟主线功能无联动 系的抽取,模块化。主线逻辑耦合太深,作为整体模块,而附加功能通过独立模块化插入主线,通过接口交互。
    • 28. 性能优化去多余逻辑去iframe 选择地址后 步刷新所有数据,本地重新 染, 少请求和服务器 染压力逐步 染?基本:数据+模板->基本框架-> 染到浏览器->更多数据+计算订单总价等信息->完整的dom->绑定事件 通过接口 步更新数据后->尽量更新最小涉及范围最大需求满足的数据以及DOM。梦想:还没想好
    • 29. 扩展性代码的扩展性主要是模块化的方式,按照功能模块化,还是视觉模块化?将交互频繁和联系紧密的部分放在一个模块中。但是要提供足 活的接口,根据以往项目的经验,预期未来一段时间内需要 些类型的接口将组件抽象化可遇见的组件:选择地址,运费和优惠的下拉框。后续可能会做大的优化,例如自定义组件,还有ipad等平台上的特殊定制。将组件抽象化,当做一个虚拟对象,以询问和回答的方式实现。
    • 30. 前端平台化?尝试各业务线维护自己的模板和js但是 发提供的数据是一致的,不同的只是模板和部分逻辑
    • 31. 交易的将来• 完善文档,清晰逻辑,稳定的代码,易于维护。• 稳定,安全,抗破坏。• 交互 杂但性能卓越,扩展性强,更优雅的界面和交 互效果。• 更好支持各垂直业务,平台化,将工作量分散,提高 效率。
    • 32. THANKS

    ×