前言在工作中，我们经常会遇到界面的数据格式与页面布局/交互不匹配的情况，需要前端进行处理。我想：“数据处理和业务无关，还是单独写一个模块吧”。于是，转换层诞生了。第一个版本设计当我设计一个模块时，第一步是明确模块的职责。转换层——顾名思义，将界面数据格式转换成页面需要的格式。第二步是制定与其他模块对接的规则。因为它是从页面模块中提取出来的，所以只有页面模块可以引用它。且逻辑单一（处理输入数据后输出），只能参考工具模块。第三步，划分子模块。模块主要是处理数据，所以按照数据类型的维度来划分子模块。第一版设计完成//消息通知信息的转换方法//transform/notice.jsexportdefault{show(data){....returnret;}}//仪表板页面使用//page/dashboardimportnoticeModelfrom'model/notice.js';//发送消息通知请求类importnoticeTransformfrom'transform/notice.js';//转换为页面需要的接口格式constdata=awaitnoticeModel.show().then(res=>noticeTransform.show(res));缺点！！！在第一版的设计中，我们很难看出是哪一页或哪几页使用了哪种转换方式。随着项目复杂度的不断增加，以后接手的小伙伴根本不敢改/删转换层的代码。在第二个版本的设计中，在第一个版本的设计中，存在转换方式与使用页面对应关系不明确的问题。思前想后，决定调整子模块的划分方式，改成按页面维度划分。第二版成品//面板页消息通知信息的转换方法//transform/dashboard.jsexportdefault{noticeShow(data){....returnret;}}//面板页面使用//page/dashboardimportnoticeModelfrom'model/notice.js';从“transform/dashboard.js”导入dashboardTransform；constdata=awaitnoticeModel.show().then(res=>dashboardTransform.noticeShow(res));再次缺陷！！！虽然可以清楚地识别页面的转换方式，但是如果页面A和B，C...需要将相同的数据转换成相同的格式。这样的模块划分对于类似代码的分离并不友好。第三版设计在第二版设计中，遇到了相似代码难以复用的问题。在第三版设计中，我们也从调整子模块的划分方式入手，改回数据类型的维度划分，同时规范方法的命名。对页面模块使用方法名=模型名+'for'+页面名，私有方法名='_'+模型名+格式语义。第三版成品//A、B页面需要将消息通知信息转化为提示//transform/notice.jsconsttransform={_showOneTip(data){....returnret;},showForA(data){返回这个。_showOneTip（数据）；},showForB(data){returnthis._showOneTip(data);}}导出默认转换；总结业务会迭代优化，但是代码也需要迭代优化。在此过程中不断思考，并使项目设计尽可能结构化。当然，更新项目的底层设计需要做大量的工作，在此感谢团队的支持。难度相同的数据在不同的页面可能有不同的格式。如何让模块之间的联系更加清晰。如何重用具有相同逻辑的代码。细节转换方法不能修改传入的数据。江湖应急作者拥有两年多前端开发经验（居住地北京），擅长Vue和性能优化。希望加入一个有Geek精神的团队，一起折腾，一起做有趣的事情。
