需求

读取医保卡/电子凭证，获取患者信息

WechatIMG1246.png

原有的方案: 通过微医生（c++）客户端WebView嵌入云HIS，通过彼此暴露在window上的api 进行数据通信
image.png

image.png

如图所示，整个过程非常简单，我们只需要弄清楚2件事：

  1. 客户端定义在window对象的api，入参格式

  2. 自定义在window上的回调函数，了解清楚客户端返回给我们的出参格式

    重构之前的代码

    image.png
    image.png
    image.png
    image.png
    image.png
    我们再次点击进入readCard方法：
    image.png

    重构之前代码存在的问题

  3. 可读性极差

相信不用我说，让你们一个从未接手的人来看此代码都是头皮发麻，就像我上文所说的本来是一个简单的需求，搞清楚两件事暴露的API入参及出参即可。但是这块读卡的代码，却涉及500+行代码，其中涉及到类、继承、发布订阅设计模式。不可否认，这些设计模式在大量的优秀前端库中都有应用，但在这段业务代码中却非常难读懂，没有使用TS等类型检测系统，大量的this并没有足够的字段类型说明，也缺乏注释，变量的命名也让人猜不透究竟是要做什么…而且花费了大半天时间我竟然还找不到客户端暴露的API叫什么…

  1. 可维护性/扩展性极差

这段代码是克东医保读卡，我第一次阅读的是因为要接入杭州医保。这两者的共同点：都是把云His系统嵌入在微医生工作站中使用。也就是说，这两者读卡调用的api都是相同的，只是说可能入参及出参格式有说不同，但是在上述的代码中，且不说耦合性太强, 为了兼容另外一个城市的读卡不得不去改大量的基础类方法

  1. 调试难，错误排查困难

这一点不用我说，代码中就有所提示：
image.png

优化后的代码

针对优化的点也就是上述业务代码的痛点：

  1. 代码可读性
  2. 代码可扩展性
  3. 代码健壮性
  4. 优雅简洁
  5. 开发体验：代码调试方便、线上错误能及时排查到

image.png
可读性:

  1. 函数、变量的命名 可以不用注释就可以读懂
  2. 魔法数字
  3. 函数内容行数的控制
  4. 纯函数应用，尽量避免产生副作用

健壮性：
尽可能给予友好的错误提示
继续看对读卡代码的封装:
image.png
image.png

需求背景

门诊看病需要刷医保卡读取患者医保信息。
现有的模式：通过微医客户端调用医保局提供的硬件设备接口（DLL）
现有模式的缺点:

  1. 微医客户端暴露的API 返回的参数不够友好，前端需要做大量的数据转换工作，使得前端的代码较为冗余不易维护
  2. 需要依赖C++ 开发人员开发，增加了开发与联调的成本
  3. 现有的客户端操作体验不够好，不易调试(还有些难以修改的历史bug)
  4. 内嵌的浏览器版本还停留在69版本

针对以上问题，产出了Electron桌面端，并有以下优点：

  1. 读卡及数据转换操作均在Node端操作，暴露给前端的API更简洁易懂，减少了前端涉及读卡的冗余的代码，更易维护。
  2. 无需C++人员介入开发，缩减了开发联调周期
  3. 最新的Chrome内核，性能更好 用户体验更好

  4. 调试也更加方便且有完整的日志链路

    要解决的问题及难点

    我们知道Electron可以理解为提供了Node和Chrome两个环境的桌面应用，那么我们要实现上面的需求其实就是要解决以下两个问题:

  5. Node如何读取DLL文件

  6. 我们的业务代码（渲染线程）如何与Electron的主线程进行数据通信

    node如何读取DLL

    渲染线程如何与主进程通信

    Electron在更多业务的展望

  7. 前端工具链的融合（如集合Switch Host/构建/发布，从开发涉及到的工具到测试再到发布，所有涉及的提效工具都可以融合到一个桌面端中）

  8. 所有涉及到硬件设备的读写操作（如读卡、智能医务室的扫描仪等）都可以替换为Electron客户端

  9. 视频流的接入以用来给医生良好的视频体验

    …..