Open tcstory opened 5 years ago
接手了一个商户后台的订单相关的业务，商户通过这个后台，可以在 PC 端完成接单和订单查询等和订单有直接关系的操作。如果你在店里听到了饿了么的接单提示声，那就是商户正在使用这个后台。 接手了一段时间，也做过一些需求，我想，是时候整理一下自己的一些思考了。 这个项目的架构是这样的：整个项目是通过一个壳子(你可以把它理解为页面的容器)包裹起来的，后台的左边的导航栏里展示各个页面的入口，当用户点击某一个入口的时候，会通过 iframe 的方式来加载对应的页面。我接手的项目，在壳子里有两个入口，一个是「订单处理」，另一个是「订单设置」。总之，和订单相关的，整个后台最重要的功能，都在这个项目里。 刚开始交接的时候，我就发现，我很难去了解这个项目里面到底有哪些逻辑和哪些交互，即使他们都写在代码里。为什么呢？因为项目里包含太多的业务，很多灰度的逻辑，很多复杂的交互等。我刚开始，一边看代码，一边和负责交接的同学沟通，问了他很多很多问题才逐渐地对这个项目有所了解。后面接需求的时候，我也不敢估算比较短的开发时间，因为我根本不知道那一坨代码里有什么坑。甚至，当产品问我能不能支持 xx 功能的时候，我也不清楚，还是测试的同学告诉我这个功能后台已经实现了。当然了，熟悉项目的过程可以靠时间来熬。 对于这样的中台前端项目，我们开发者到底需要的是什么？我发现，目前网上的讨论中台前端的很多文章，都只是把焦点集中在通过 redux 或者 vuex 来设计数据流上。而我觉得，他们并没有面对下面两个问题： 1. 当项目的业务复杂起来以后，代码逻辑会膨胀到没人能了解系统里到底会发生些什么 2. 没人敢轻易地修改原有代码的逻辑，新增功能也会变得小心翼翼 其实我们新增逻辑的时候，往往选择通过“堆砌”的方式，这样的代码抽象程度底，充满大量的重复和冗余，长期下去，会让整个项目更混乱。但这已经是最好方式了，因为当你写完新功能，给测试同学提测的时候，总不能说“hey，之前的xx功能也被我改掉了，这一次你也顺便一起测试吧”。 那这个混乱的现状如何解决呢？ 实际上，我没找到整体的解决方案，但是局部的优化，还是可以的。比如，可以用 rxjs 来优化一些事件处理。
商户后台为什么要通过 iframe 来加载页面呢？ 主要是因为很多页面所承载的业务很复杂，而且页面很多，全部放在同一个项目里，发布和回滚都不方便。举个例子，我接手的另外一个项目，就是所有东西都放在同一个项目，这个项目 build 一次需要将近 10 分钟，而且每一次发布都要排队，等前面一个人发布完毕。而且需要回滚的时候，要提交一个 git revert 来重新发布，这又要等待 10 分钟左右(如果你发布之后没有别人也发布了代码的话，才可以直接回滚，这个过程也就话费几秒钟而已)。但是通过 iframe 来拆分其实我觉得不是很好，原因有几个：
其实这个可以通过 remote component 来解决。
有一个场景是这样的，有新订单到来的时候(消息通过 ws 下发)，我需要在「订单处理」页面上展示提示，但是如果订单到来的时候我没有打开「订单处理」页面的话，等到我回到「订单处理」页面后，也依旧看不到提示。我想了一下，这个问题的解决思路有两个：
不过我更倾向于使用第一种方法。
有一种说法随是“数据驱动视图”。当使用 redux 这类的数据管理方式记录下整个应用的状态后，确实能很方便的通过数据还原现场，甚至能像录屏一下回放用户的操作。
项目使用了 vuex 来管理数据，不过我接下来说到的问题，在 redux 上应该也是会出现的。
我们假设一个简化的订单的生命周期是这样的： 来订单 -> 商户接单 -> 商户出餐 -> 骑手接单 -> 用户收到餐品 -> 订单结束
我们会在 vuex 里面写一大堆和后端有交互的 action， 比如发起请求来"接单"和发请求来"出餐"。看起来这样就能通过观察 action 来了解业务的情况了，但实际上不是的。举个例子，你能通过观察 action 的代码，了解到只有商户出餐后，骑手才能接单的这个逻辑吗？很明显是不能的，那你什么时候会知道这个逻辑呢？ 你在没有出餐的时候，直接掉了骑手接餐的接口，然后接口响应会提示你出错了。实际上，订单业务里，有很多这样的有先决条件的逻辑器，并且难以通过代码来了解到。所以这也是为什么我刚接手项目的时就觉得很困惑，弄不清楚订单业务到底是这么一回事。不过，我很少看到网上有类似的讨论，感觉好像使用了 redux 就万事大吉了。
我在一段时间内曾经想过要这样做，通过高度抽象的代码来描述一个订单的生命周期，选择的技术方案是 rxjs，但是不久后就遇到问题了：
遇到的一个问题是，如果一个订单已经处于"出餐"状态，那么当用户刷新页面后，我没法让这个订单在 rxjs 里面处于"出餐"状态了。之所以这样，是因为rxjs 是拿来描述事件的和组合事件的，而不是描述生命周期。
我需要修改代码的结构和编写业务逻辑的方式，这一块我没有找到很好的解决思路。可以参考的思路是 Flow Based Programming，试图完全用数据流向的角度来诠释业务中的逻辑。
下面的这篇文章其实也有类似的讨论，值得一看： https://zhuanlan.zhihu.com/p/34790596?utm_source=qq&utm_medium=social
简介
接手了一个商户后台的订单相关的业务，商户通过这个后台，可以在 PC 端完成接单和订单查询等和订单有直接关系的操作。如果你在店里听到了饿了么的接单提示声，那就是商户正在使用这个后台。 接手了一段时间，也做过一些需求，我想，是时候整理一下自己的一些思考了。 这个项目的架构是这样的：整个项目是通过一个壳子(你可以把它理解为页面的容器)包裹起来的，后台的左边的导航栏里展示各个页面的入口，当用户点击某一个入口的时候，会通过 iframe 的方式来加载对应的页面。我接手的项目，在壳子里有两个入口，一个是「订单处理」，另一个是「订单设置」。总之，和订单相关的，整个后台最重要的功能，都在这个项目里。 刚开始交接的时候，我就发现，我很难去了解这个项目里面到底有哪些逻辑和哪些交互，即使他们都写在代码里。为什么呢？因为项目里包含太多的业务，很多灰度的逻辑，很多复杂的交互等。我刚开始，一边看代码，一边和负责交接的同学沟通，问了他很多很多问题才逐渐地对这个项目有所了解。后面接需求的时候，我也不敢估算比较短的开发时间，因为我根本不知道那一坨代码里有什么坑。甚至，当产品问我能不能支持 xx 功能的时候，我也不清楚，还是测试的同学告诉我这个功能后台已经实现了。当然了，熟悉项目的过程可以靠时间来熬。 对于这样的中台前端项目，我们开发者到底需要的是什么？我发现，目前网上的讨论中台前端的很多文章，都只是把焦点集中在通过 redux 或者 vuex 来设计数据流上。而我觉得，他们并没有面对下面两个问题： 1. 当项目的业务复杂起来以后，代码逻辑会膨胀到没人能了解系统里到底会发生些什么 2. 没人敢轻易地修改原有代码的逻辑，新增功能也会变得小心翼翼 其实我们新增逻辑的时候，往往选择通过“堆砌”的方式，这样的代码抽象程度底，充满大量的重复和冗余，长期下去，会让整个项目更混乱。但这已经是最好方式了，因为当你写完新功能，给测试同学提测的时候，总不能说“hey，之前的xx功能也被我改掉了，这一次你也顺便一起测试吧”。 那这个混乱的现状如何解决呢？ 实际上，我没找到整体的解决方案，但是局部的优化，还是可以的。比如，可以用 rxjs 来优化一些事件处理。
壳子的设计思路
商户后台为什么要通过 iframe 来加载页面呢？ 主要是因为很多页面所承载的业务很复杂，而且页面很多，全部放在同一个项目里，发布和回滚都不方便。举个例子，我接手的另外一个项目，就是所有东西都放在同一个项目，这个项目 build 一次需要将近 10 分钟，而且每一次发布都要排队，等前面一个人发布完毕。而且需要回滚的时候，要提交一个 git revert 来重新发布，这又要等待 10 分钟左右(如果你发布之后没有别人也发布了代码的话，才可以直接回滚，这个过程也就话费几秒钟而已)。但是通过 iframe 来拆分其实我觉得不是很好，原因有几个：
其实这个可以通过 remote component 来解决。
一些可优化点
错过了消息
有一个场景是这样的，有新订单到来的时候(消息通过 ws 下发)，我需要在「订单处理」页面上展示提示，但是如果订单到来的时候我没有打开「订单处理」页面的话，等到我回到「订单处理」页面后，也依旧看不到提示。我想了一下，这个问题的解决思路有两个：
不过我更倾向于使用第一种方法。
replay 功能
有一种说法随是“数据驱动视图”。当使用 redux 这类的数据管理方式记录下整个应用的状态后，确实能很方便的通过数据还原现场，甚至能像录屏一下回放用户的操作。
订单的生命周期
项目使用了 vuex 来管理数据，不过我接下来说到的问题，在 redux 上应该也是会出现的。
我们假设一个简化的订单的生命周期是这样的： 来订单 -> 商户接单 -> 商户出餐 -> 骑手接单 -> 用户收到餐品 -> 订单结束
我们会在 vuex 里面写一大堆和后端有交互的 action， 比如发起请求来"接单"和发请求来"出餐"。看起来这样就能通过观察 action 来了解业务的情况了，但实际上不是的。举个例子，你能通过观察 action 的代码，了解到只有商户出餐后，骑手才能接单的这个逻辑吗？很明显是不能的，那你什么时候会知道这个逻辑呢？ 你在没有出餐的时候，直接掉了骑手接餐的接口，然后接口响应会提示你出错了。实际上，订单业务里，有很多这样的有先决条件的逻辑器，并且难以通过代码来了解到。所以这也是为什么我刚接手项目的时就觉得很困惑，弄不清楚订单业务到底是这么一回事。不过，我很少看到网上有类似的讨论，感觉好像使用了 redux 就万事大吉了。
通过代码来描述生命周期
我在一段时间内曾经想过要这样做，通过高度抽象的代码来描述一个订单的生命周期，选择的技术方案是 rxjs，但是不久后就遇到问题了：
遇到的一个问题是，如果一个订单已经处于"出餐"状态，那么当用户刷新页面后，我没法让这个订单在 rxjs 里面处于"出餐"状态了。之所以这样，是因为rxjs 是拿来描述事件的和组合事件的，而不是描述生命周期。
我需要修改代码的结构和编写业务逻辑的方式，这一块我没有找到很好的解决思路。可以参考的思路是 Flow Based Programming，试图完全用数据流向的角度来诠释业务中的逻辑。
其他讨论
下面的这篇文章其实也有类似的讨论，值得一看： https://zhuanlan.zhihu.com/p/34790596?utm_source=qq&utm_medium=social