天祁《交易线》
- 7. 积分换购 积分加钱购
货到付款
单品优惠 数量 免邮
运费险 运费 店铺优惠
送积分
服务 使用积分
数量 商品
积分加钱购
子订单 活动优惠
商品 分期付款
在UI上 活动订单
商品
有所体 子订单
主订单
商品
现的逻
商品
辑 子订单
商品
- 10. 前后端耦合
VM由 发维护，里面有大量后台业务逻辑，例如为了
普通的耦合 呈现某一块内容， 发书写了大量ifelse，其实这部分
- 11. 前后端耦合
VM由 发维护，里面有大量后台业务逻辑，例如为了
普通的耦合 呈现某一块内容， 发书写了大量ifelse，其实这部分
接口的耦合
- 12. 前后端耦合
VM由 发维护，里面有大量后台业务逻辑，例如为了
普通的耦合 呈现某一块内容， 发书写了大量ifelse，其实这部分
大量使用接口，在一条整体逻辑中，前端负责一部
接口的耦合 分， 发负责一部分，二者通过接口交互，其实前端
- 13. 前后端耦合
VM由 发维护，里面有大量后台业务逻辑，例如为了
普通的耦合 呈现某一块内容， 发书写了大量ifelse，其实这部分
大量使用接口，在一条整体逻辑中，前端负责一部
接口的耦合 分， 发负责一部分，二者通过接口交互，其实前端
逻辑的耦合
- 14. 前后端耦合
VM由 发维护，里面有大量后台业务逻辑，例如为了
普通的耦合 呈现某一块内容， 发书写了大量ifelse，其实这部分
大量使用接口，在一条整体逻辑中，前端负责一部
接口的耦合 分， 发负责一部分，二者通过接口交互，其实前端
大量业务逻辑堆积在前端，前端的逻辑和代码比 发
逻辑的耦合 只多不少
- 16. 历史-里程碑
尝试独立 线上下单 购物篮
选型 订单详情 活动优惠
摸索很痛苦 服务 代码小范围重构
家装馆下单
- 22. 历史-遗留问题
过度模块化 逻辑清晰了，但是维护困难，模块化不
逻辑混乱
至今仍然没有整理清楚所有逻辑。文档
前端逻辑太多
- 23. 历史-遗留问题
过度模块化 逻辑清晰了，但是维护困难，模块化不
逻辑混乱
至今仍然没有整理清楚所有逻辑。文档
前端逻辑太多
大量逻辑控制在前端，代码混乱，容易
- 24. 历史-遗留问题
过度模块化 逻辑清晰了，但是维护困难，模块化不
逻辑混乱
至今仍然没有整理清楚所有逻辑。文档
前端逻辑太多
大量逻辑控制在前端，代码混乱，容易
扩展性和性能
- 25. 历史-遗留问题
过度模块化 逻辑清晰了，但是维护困难，模块化不
逻辑混乱
至今仍然没有整理清楚所有逻辑。文档
前端逻辑太多
大量逻辑控制在前端，代码混乱，容易
扩展性和性能 逻辑和耦合造成扩展性较差。性能也较
- 28. 前后端解耦
前端负责展现 发负责数据
前端维护最基本的逻辑
初始数据 初始订单结构数据
只负责展现和交互
数据接口 大部分特殊业务逻辑
维护一个固定的数据结构
无逻辑的前端模板
解耦的最终目标，是前端只负责展现，而且能保存最纯洁的数据
结构，不管如何交互，前端只 心后台需要谁的属性值，我需要
后台返回谁的新的属性值，而不 心其中的具体逻辑。数据结构
不会增加新的标示。
- 29. 逻辑整理
项目 始之前，
个周整理时间
效果：随意口述，说一条交互，口头算出价格
文档化，交互 系图表，特殊逻辑说明等等。
跟主线功能无联动 系的抽取，模块化。
主线逻辑耦合太深，作为整体模块，而附加功能通过独立
模块化插入主线，通过接口交互。
- 30. 性能优化
去多余逻辑
去iframe 选择地址后 步刷新所有数据，本地重新 染， 少请求和服务器 染压力
逐步 染？
基本：数据+模板->基本框架-> 染到浏览器->更多数据+计算订单总价等信息->完整的dom->绑定事件
通过接口 步更新数据后->尽量更新最小涉及范围最大需求满足的数据以及DOM。
梦想：还没想好
Editor's Notes
- 颜色的意思：灰暗的过去，火热的现在，稳定的未来\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
