交流要先说背景和上下文，否则就是耍流氓。-- 🐤
核心矛盾
传统行业的信息系统中，几乎每个功能模块，都存在使用Excel文件批量导入和导出的场景。
相信有很多同学会讲了，这有毛闻风丧胆的？！如果前端或者Nodejs的服务端处理可以使用像xlsx.js，如果Java侧的服务端可以使用POI去处理。我只想回一句，呵呵，实际的场景远超想象，否则笔者也不至于专门设计，并去申请了专利了！至少笔者痛苦，痛苦，并“快乐”着，来来来，我们坐下来，瓜子花生米，要不再来点啤酒。
背景
笔者所在的公司，是一个电子元器件的代理商和贸易商，处在供需侧的中间关键地带，上接制造商或者顶级代理商，下接客户，目前处在数字化转型的关键阶段，因此数字化转型，在我们这里正在积极落地实现，目前有专业的PD，开发，测试和运维团队，践行Devops，核心成员来自华为，阿里，中兴等大厂，目前从事数字化转型的人员已经占到了全公司的5%以上，可见对自研和数字化转型的支持力度有多大哦，有兴趣的同学可以联系我哦。内推信息放在文章末尾了。
笔者作为公司的前端架构师，除了前端技术架构和技术产品的命题外，最重要的事情就是帮助业务开发，支撑起对内部交付的业务。如果说刻骨铭心的事情，绝对就是Excel在公司内部的使用和跟系统的对接了。
我们自研了CRM，电商，ERP的自研道路也在进行中，转型中面临最多的就是传统信息系统和这种类型的公司中员工对于Excel的使用。原来用户在Excel中进行了大量的数据操作，转化，处理，分析，由于笔者从业以来，对Excel几乎属于文盲的认识，也比较嗤之以鼻，有在线的界面进行操作，还导出成Excel干嘛，简直侮辱我们的成果，现在想想还真不是这么回事。抛开其用户长期使用Excel的历史习惯问题，的确有其道理，在于常规的系统无法让用户对数据进行批量加工处理，哪怕是现如今比较火的ETL+BI的组合也不能完全解决用户的问题，因为ETL+BI对于非专业软件行业的用户来说，根本无法直接使用，而Excel本身恰恰因为其学习门槛和长期使用的历史，符合用户的知识储备和使用习惯。我们说罗马不是一日建成的，数字化转型也不是一蹴而就的。因此在比较长的时间内，Excel和当前的自研系统会共存，因此笔者所在的团队，不管是前端还是后端，哪怕是PD，在做产品设计和系统实现过程中，必须考虑这件事情。
记得20年疫情初始之时，当时健康码，行程码还未上线，大量社区的网格员统计信息也是使用Excel进行线下处理，然后发现像阿里，腾讯有线上Excel的产品，随之使用。记得当时民工大叔也在朋友圈分析了这么个事情，也指出了对于普通用户，Excel的认知和使用成本是相对比较低的，也不存在信息系统部署的问题，当然Excel最重要的缺点就是数据离散，数据结构非标准化导致的一系列问题。
场景
笔者就拿实际遇到的场景，来讲下用户的诉求和实际系统面临的痛点--订单批量录入
公司的商务人员会就多个客户的订单，进行录入订单的操作，当然也有通过客户API对接直接进我们系统的场景。针对手工录单的操作，用户就会自己线下先维护一份Excel文件，对应了很多字段，大家猜猜有多少个？哈哈，经常有大几十个，其他场景下上百个也很正常。数据条数呢？几百到上千行不等。所以用户不可能在系统里面的表单一行行进行录入，那用户就疯了，几百条数据，以目前的表单录入，用户一两天都弄不完，还有一堆必填，数据的业务校验等等。就算是界面数据的操作处理，前端界面就算在有虚拟化加持的表格下，进行筛选排序等操作的性能和使用习惯，也是不满足用户要求的。
因此用户的场景就变成了，批量录单，在系统点击导入按钮，上传个Excel文件，然后等待校验结果。这里又存在了问题，系统是接受到文件后，在服务端异步执行校验和处理，那结果如何反馈给用户呢？处理个几分钟，然后发个邮件给用户，把错误数据反馈给用户，然后再把错误数据调整后，再导入，循环几轮？用户要么傻呵呵地在界面等结果，要么就等邮件，然后还不知道到底发生了什么。邮件里面返回的错误数据，改下再导入，那没有报错的数据就一定没有问题吗？当然不是，处理导入的这个模块还依赖上游的其他微服务去处理，从此看这个问题，近乎无解。
解决方案
这里面重点存在两个问题
- 用户导入和获得反馈的交互问题
- 系统批量异步处理的性能和健壮性
第二个问题，属于后端大佬们的思考范畴，不管怎么玩都得必须去考虑的问题。那我们作为前端，就想想第一个问题。我们问下自己，能不能用户导入的时候，在上传文件后，我们给出数据预览界面，毕竟结合批量校验的接口，对用户进行实时反馈，直接减少字段类型错误，数值越界，单号、料号等业务数据是否输错等，根据笔者团队的实践，此类错误数量占到了90%，如果我们先期在前端，通过预处理和校验减少这类型的问题，那么用户在真正执行导入的时候的成功率就要高出许多。
说干就干。这里我们借助的主要社区工具就是xlsx.js和canvas-datagrid，使用前者去解析excel文件，如果比较大型的文件，还需要webworker去多线程进行解析，后者用来呈现具体校验结果，并让用户在预览界面试试修改，修改后再一次执行校验，等基本校验都没有问题后，用户才可以去执行导入。具体效果如下图。
牵扯数据安全性，笔者只是拿测试数据进行效果展示，期间的核心代码也就不放出了，但是通过以上的demo图就能体现这其中的思路了。这个组件在笔者团队内部，已经大量推广和使用，起到了比较不错的收益。
上面提到的第二个问题，也在后端大佬们的支持下，通过优秀的后端方案进行处理执行，并在门户对用户进行反馈。
这就结束了吗？
当然没有！在实际操作中，还遇到了各种各样的细节问题，比如读取Excel文件中的时间类型，会有实际的偏移值，读取或者生成带公式带格式样式的场景，经常笔者跟后端Leader被各种“逼疯”，哈哈。
当然传统行业也有很多隐藏的“高手”，在Excel中嵌入VB，SQL，进行各种天花乱坠的操作，真的让笔者这个Excel文盲叹为观止。当然Excel产品本身的确是微软一款相当优秀的产品。笔者致力于解决数字化转型中Excel引起的数据孤岛，格式类型分散等问题，虽然有很多痛苦，但一定坚持做下去！以后有更多的心得，也会做进行的抽象后分享给大家。感谢大家支持！
更多内容可以关注公众号 - 喵爸的小作坊
