什么是T级交互？在讨论如何开发和提升T级交互效率之前，我们先定义一下什么是T级交互。T级互动是一号互动的简称。它不同于其他较小的S级交互和A级交互。具有流量大、金额大、时效性强的特点。三个特色电商节点驱动集团用户增长和转型。T级交互最大的特点就是整合了多端资源。需要在站内和微信上进行闭环。开发时需要同时进行H5和小程序端，并保证两者的体验相似。二是打造全民私域，打造商家专属页面，增加流量。T级交互需要我们注意什么T级交互有这么多内容，结合了双端和私域，而且每次都会有不同的玩法，所以要保证开发效率高，开发体验好，以及开发阶段的双端体验。持续的;在测试阶段，要保证测试质量高，及时解决问题；上线阶段要保证项目顺利运行，没有错误就没有错误。如果有错误，有及时的纠错机制。容错和自下而上的机制。所以我们可以得出结论，我们需要的是双端高效开发的工具，良好的开发体验，及时修复问题的系统，保证项目顺利运行的系统，以及容错能力。那么我们就通过全运会、双十一情游记、2022年拜年兽三个互动来解读以上内容。Taro——为什么需要双端高效开发工具？在目前的电商环境下，仅仅APP的单端开发已经不能满足我们的需求。还是需要在微信域打通进程。但在多端开发中，存在多个团队各自独立开发、多种技术栈共存、页面表现形式不同、代码重复等问题。所以我们需要转变思路，从多个团队使用多个技术栈开发，转变为多个团队使用一个优秀的技术栈进行协同开发。此举不仅解决了代码重复率高、页面体验参差不齐的问题，也保证了不同团队的人可以互相帮助、互相配合，也解决了一些人的效率问题。太郎为我们提供了什么？Taro作为一个优秀的多端开发框架，完全有能力开发一个大型的交互。但是要想在精狗小程序中正常运行，就需要做一些适当的调整。我们这里提供一个插件让Taro3项目在精狗小程序中运行——《使用Taro3将项目作为独立分包运行在京购小程序中》以上插件解决了小程序开发过程中的一些问题，但是还有很多问题需要我们继续完善探索解决。我们第一次使用这个插件是在2021年的618互动中，当时项目中包含了插件代码。开发过程中需要同时运行项目本身和精狗小程序项目。我们将自己项目中的编译内容通过插件复制到精狗项目中，使用精狗项目中的环境进行运行、开发和测试。在京东游戏项目中延续了这种方式，为了提高复用效率，将代码抽取出来做成一个Taro3插件，可以在任何Taro3项目中使用。我们遇到了什么问题？但是，在双十一爱游记项目中，我们遇到了操作系统兼容性问题。在部分开发者的Windows系统中，插件无法正常运行。在解决兼容性问题的同时，我们调整了开发模式，以提高开发效率。插件的存在是为了能够正常使用精狗小程序中的功能，但是这部分使用场景在项目中比较少，所以我们可以暂时摆脱对精狗小程序的依赖，这样该项目可以由开发人员独立使用，在工具中运行。调整方法非常简单。我们原来是通过插件引用精狗小程序中模块的相对路径。为了摆脱这种依赖，我们可以在项目中创建一个虚拟的精狗小程序文件夹，这样我们打包的相对路径就可以指向项目中的一个虚拟文件夹。在这个文件夹下，只需要在相应的路径下创建一个空函数，让路径指向相应的方法即可。这种开发方式的好处是不需要关心操作系统的差异。Windows和macOS均可正常运行项目，独立运行使得只编译一次即可运行，缩短编译路径，加快开发调试速度。.缺点也很明显，无法调试精狗小程序中的功能。但是通过这一步，我们还是暂时解决了开发问题，让我们的流程顺利进行。并且在丧年兽交互开发之前就完善了插件，让后续开发更加高效。同时，Taro3也在着手升级Webpack5。在Webpack5中使用ModuleFederation，我们在后续开发中可以完全不依赖本地精狗小程序的代码，而是直接远程引用其功能模块，帮助我们进一步提高开发效率。业务组件库——复用代码解决人的效率问题我们下一个问题是什么我们现在手头有一个优秀的双端开发工具，有一个适合业务的插件，大大提高了我们的开发效率和体验。但是T级交互的开发周期短，开发内容仍然是我们需要面对的问题。事实上，工时多工少、人手不足并不是我们互动独有的特点。大家在大多数业务中都会遇到这样的问题。但是T级交互的流量和范围放大了这个问题。那我们就得注意了。一个T级交互往往需要90到100个工作日左右的开发时间，也就是说3个同时开发也需要30个工作日。然而，一个大型的交互idea从讨论到交互设计最后到视觉落地往往需要很长时间，而从最终开发到开发的工时往往不到30个工作日。那么接下来发生的事情可想而知，要么加班加点解决问题，要么交付任务质量低下，要么两者兼而有之。但这不是我们想要的。那么解决人的效率问题就成了我们的重中之重。如何解决人的效率问题直接解决问题的方法不外乎两种。当前时间，要么增加人手，要么提高个人发展效率。直接来说，增加人手是最简单有效的方法。事实上，并非如此。随着不熟悉项目的成员的加入，他需要花大量时间学习项目的开发模型、技术栈、原始代码和工作流程。这些其实都是隐藏的时间成本。所以要想解决问题，还是要提高个人开发效率，对新人要非常友好。然后我们想到了大多数开发都做过的事情——组件化。用组件来提高效率是家常便饭，但结果往往不尽如人意，最后落空。为了避免出现这种吃力不讨好的情况，还是先磨刀霍霍吧，不要直接动手了。组件化的问题经常出现在两个地方。一是组件复用率不高，有些组件开发出来没人用；二是“通用”与“好用”难以结合。它不工作。但是从T级交互开始的业务组件就没有太多这样的麻烦。首先是复用率。经过多次T级交互，我们对从设计到开发的交互模式有了一个大概的把握。很多模块从交互到视觉风格都非常固定，所以我们可以发现基本上每个每次都会用到的“劳模”模块都是组件化的。二是我们在业务组件中不需要考虑一个组件的扩展性和通用性。它主要服务于业务，其根本要求是易用性。那么基于以上的思考，我们可以得出我们的结论——基于多次T级交互的经验，找出重复的模块，在保证主要功能和交互固定的情况下，进行复用改造。组件库开发1231自然是选择我们需要开发哪些组件，具体就不说了。就说我们把组件分为两类，有UI的和没有UI的，没有UI的又分为业务逻辑、非业务逻辑、纯函数等，这些组件是通过统计模块在过去交互中出现的次数来计算的。二是选择技术栈。不用说，泰罗肯定是领先的；那么为了提高开发组件的质量，自动化测试也必须跟上，团队中另一款双端自动化测试产品Tiga紧随其后；为了能够轻量级地打包组件，我们选择了Rollup作为快速打包工具；最后用lerna统一管理这些组件，让它们有统一的依赖关系，统一管理版本和发布。具体的实现内容和代码这里就不贴出来了。仅展示了根据技术栈的选择，组件库的开发过程。第三个是一个组件库最不起眼却最有灵魂的内容——文档。很多开发者一提到文档就头疼。他们经常写完代码忘记文档，写完忘记更新文档。没有文档对于组件库来说是致命的，没有文档的组件等于没有开发的组件。用户不知道是否有自己想要的组件，也不知道去哪里找，最终导致组件复用率低或重复开发。最后说一句，组件库真的很难用。谁想到这个烂主意，还不如抄代码。一、二、三这三个步骤不是我们只做，而是三个步骤都可以防止一个组件库成为一个鸡肋。一个大锤的小测试，当然，我们上面啰嗦了一大堆，没有结果大家肯定是不服气的。经过两个月的零碎组件开发，我们第一批沉淀了十个组件，在元旦交互中使用了其中的七个，节省了10多个man-days，保证了我们的人员在过年之余还有充足的时间节庆项目还支持了春晚合作项目。可以看出我们的组件库已经初见成效。纠错和自下而上上面两部分很大程度上缓解了我们的人为效率问题。距离解决还有一定的距离，还需要不断的优化和探索。那么我们就不得不将目光转向另一个问题——缺陷。基本上可以说没有bug就没有项目，但是要看bug会不会被发现，发现的bug多不多，严重不严重。我们反复强调了大型互动的内容复杂、流量巨大。内容繁杂，意味着地方多，可能性多，自测和测试会遗漏；巨大的流量会给我们的玩家群体很多找bug的机会。两者结合成了我们最怕的线上问题和客户投诉。第一次遇到大问题是在京东小游戏的交互中，凌晨出现了45分钟的白屏。原因是上游数据发送错误，但前端没有完全理解错误，导致页面出错。没错，一个成熟的开发已经想通了，我们很快就把责任甩给了上游（不是）。相反，我们应该尽快解决问题，让页面尽快恢复正常。然后分析问题，改进。以及如何分析，如何改进？先来看一下线上问题的两步：一是上游数据突然出错，那么为什么顺畅运行多日的项目突然数据出错了呢？原来每天0:00会更新数据，刚更新了一批错的；二是前端没有做好覆盖错误数据的工作，代码不够健壮。它只需要隐藏一些模块就可以成为整个页面报错。让我们从第一步开始。我们不能要求上游没有问题，那怎么办呢？只能看好自己的宝宝了。0:00切换数据时，作为家长，我们需要在线值班，查看页面所有功能，看完后安心入睡。如果出现问题，可以及时纠正，使页面恢复正常。第二步有点神秘，提高代码的健壮性。每个人都会这么说，但事情不一定做到。我们不能对自己的代码过于自信，所以我们在地板上包裹了一层口袋组件，以捕获地板中的错误并隐藏地板。当然，这种方法是解决线上问题的好方法，但并不是开发者的终极策略。作为开发者，真正能解决问题的应该是提高自己的代码水平，体贴，全面自测，避免过度自信。在双管齐下之后，我们在随后的双十一、元旦、春晚项目中避免了严重的线上问题和客户投诉。从刁钻到闪亮，一开始的T级交互开发总是背着沉重的龟壳蹒跚前行。面对各种问题，我们经常加班加点，拆东墙补西墙，完成一个项目。缺陷多不说，开发人员都已经累坏了，最后只想休个假。随着项目的回顾和开发体验意识的兴起，我们明白用户体验是我们的目标，但开发体验也是我们的目标。只有良好的开发体验才能为我们带来更高效的工作流程和更轻松的工作体验。而这种效率通常意味着我们最终会生成更高质量的代码，并腾出更多时间进行优化。所以古语常说磨刀不误砍柴工，而我们却时常抱怨自己没时间磨刀，跌跌撞撞砍柴。不如停下来看看，为什么任务总是紧追不舍，而我们似乎总是深陷泥潭无法前行。从一个难题到开发生涯中值得书写的经验，我们需要的只是仔细思考，花点功夫，发现问题并解决问题，而不是说“道理我懂”。
