CFET HMI代码结构的变更以及现存问题阐述

回到主页

先阐述下现存的问题，也是最近比较迫切需要沟通的问题

  1. 对业务逻辑不清晰，对设计历史思维不了解，缺乏必要沟通。

    目前，我能看的的大多数资料是代码和论文，在代码逻辑上，大概知道是怎么回事，知道代码的功能是如何实现的，但是我对业务逻辑的认知比较模糊，对为什么之前要这样设计缺乏了解，这就导致，我可以debug和修改代码结构（其实这也有问题，后面再讲），不能做设计，不能清理出需求。

    举个例子：

    之前不知道关于参数以及参数值的来源，也就不明白poke的含义，只知道poke怎么用，怎么实现的，这就会导致对poke的理解有偏差，在改进的时候就容易误入歧途频繁返工，其实写了很多，又删了。

    看了上面两段介绍之后，发现自己的理解属实是有偏差，比较迫切的需要聊一下，了解一下设计上理念上的事情，不然现在都是零零碎碎的拼凑以及自己看代码根据功能反推使用场景和业务逻辑（其实就很有问题）

  2. 对阶段性目标和未来方向缺乏具体的想象

    一方面是背景的不准确，另一方面还是交流少了些，对后面具体要做成什么样，缺乏想象空间，导致更改方案拿不准（下文会具体阐述）。 缺乏对需求的把握：

    （1）第一种需求是后端的功能驱动或者数据驱动，这种需求就很清晰，一般不需要什么思考

    （2）第二种是大方向上，设计上的需求，但是这种需求还是需要交流的，前端是很难在不了解设计背景的情况下自己给自己提需求，就不太靠谱，容易想当然，落不到实处。

  3. 缺乏对具体实验环境的了解，对落脚点不清晰

    这个主要是没什么实感，比如波形图这个Widget，我还没有跑过一次，因为之前缺乏配置文件（数据）。

CFET HMI代码结构的变更

之前提过一个孙子组件的的思路，即把通用设置以及相关函数放进子组件中。现在其实也有改动。

之前“三层”的思路，我们沟通的也不充分，这个思路虽然会降低代码的冗余，但是会增加组件之前的参数传递，我拿不准后面的发展方向，我总怕会得不偿失。

我总结了我们目前这个项目的主要特点：

  1. 我们有频繁的dom操作

  2. 组件和组件之间需要共享状态又需要保持独立

  3. 我们需要具备可持续发展性

目前主要有以下问题，当然这些问题原本也是之前的代码就存在的问题，只是两层的时候没有三层那么突出：

  1. 传参的方法对于多层嵌套的组件将会非常繁琐，并且我们之前用的是prop等方式，本质上是用于组件初始化，并不是用于保持状态的

  2. 兄弟组件间的状态传递无能为力，导致联动需要广播，而不是数据驱动

  3. 经常需要并行事件和进行同步状态的多份拷贝，使得冗余代码量大，维护困难

针对以上问题，我的建议有以下三点

  1. 第三层只做html也就是样式和state的继承，提高管理成本

  2. 使用vuex来进行vue的状态管理，建立全局的底层数据，通过数据驱动dom在任何位置的移动的状态，最大程度优化结构，保持可持续发展，大面积减少参数传递

  3. 使用base.js即建立全局函数文件以及管理文件，减少父子组件中的相同函数的重复调用

以上的想法都是根据代码结构设想的，虽然看着比之前靠谱多了，但是存在的问题都是一样的，就是我还是仅仅根据代码来设计，其实是不够的，我还应该了解业务需求，真实的操作环境是什么样的和对未来有具体的想象，这样做出的设计才是合理的，设想的功能才比较符合实际，不用老是反复的改

下周：

  1. 要再读读vue的源码，以及ts（js也行，一样的）关于dom操作的部分

  2. 解决沟通的问题（方便的话），进一步阐述具体的方案，了解设计背景

本文章使用limfx的vsocde插件快速发布