在 2020 年刚加入公司的时候，我就确定要持续推进基建的建设，经过这几年的沉淀，完成了从 0 到 1 的跨越。

　　基建的目的是解决各类技术或业务问题，沉淀通用技术能力，提升工作效率，降低开发成本，直接或间接助力业务开展。

　　接下来会围绕项目重构、组件化、标准化、工具化、自动化、文档化和页面规范化几个方面来探讨基建。

一、项目重构

　　项目重构一方面是为了延缓代码的腐烂，另一方面也是为了能享受新技术带来的新体验。

　　刚进公司时发现共存着好多个技术栈，有 jQuery、React、Vue 等，还遗留了许多祖传代码，还有混合式架构。

　　所谓混合式架构就是类似于老早的 PHP 写法，一张 php 页面中混杂着前端代码和 PHP 后端代码。

　　还有 jQuery 这块，是最老旧的代码，本来想制订一份迁移计划，消灭 jQuery 和混合式架构，但发现成本巨大。

　　因为很多项目都不再维护了，只要稳定运行即可，所以就放弃了大规模的迁移，只是不在做新增，只做存量维护。

　　对于业务方来说，他们并不关心你的技术栈是新还是旧，他们只要求业务能保持稳定，并且还能持续迭代更新。

　　所以在做技术栈升级时，需要保证能达到这两点。

　　Vue3 正式版发布后，自己团队也跃跃欲试，原先是计划直接升级，但调研后发现成本比较高。

　　所以仍然采取之前的策略，现在重新创建一个项目，新需求往这里塞。

　　当出现巨石应用时，可以引入微前端，将应用切分，让其更容易维护。

二、文档化

　　文档匮乏，这是我进公司的第一印象，刚进公司的那几个月，我就开始着手搭建文档体系，一直到现在还在补充中，这是一个长期的工作。

1）文档分类

　　刚进来，就有一个小伙要离职了，我让他在走之前补充了各个项目的文档，因为他是个老员工，都比较熟悉。

　　我在此基础上，又分别新增了规范、业务逻辑、技术文档、疑难杂症等栏目，规范包括代码规范、协作规范、开发流程等规范。

　　开启周会制度，每周五早上小组成员在一起开个短会，信息同步，沟通问题，大家都彼此都能有更进一步的了解。

　　在会议中将探讨本周遇到的各类问题，以及解决策略，近期公司动向也会与成员同步，自己也会时不时的强调文档的重要性。

　　在自己的影响下，组内成员也在慢慢完善各类文档，也会有意识的去补充没有的文档，并且去将开发过程中遇到的问题做单独记录，汇总到各个项目的疑难杂症中。

　　2022 年 5月中旬，公司将之前存放在 wiki 中的文档整体迁移至飞书文档中，我对整体的目录也做了一次细致的归类，便于查看。

　　改成飞书后，有个很大的好处，就是可以直接用手机浏览文档了，文档格式也比之前的 confluence 美观。

2）活文档

　　最近还学到了个新名词：活文档，就是将记录写在事物本身中，例如代码中的注释、版本提交时的 message 等。

　　我们组今年也在进一步规范这类活文档，减少信息障碍。

3）技术分享

　　技术分享一开始是整个技术部参与，但是参与度不高，后面就改成了我们组内部做技术分享。

　　每个人都会轮到，两周一次，技术范围不限制，这样大家都能参与进来，已经进行了六十多场，每场结束后，都会将内容留档。

　　大家对此类技术分享并不排斥，都会积极准备，有源码分析、案例分享、库的使用等。

4）Code Review

　　2022 年的 5 月份的时候发生了几场事故，问题虽然低级，但造成的危害却不小，如何有效的进行规避，在当时我进行了思考。

　　我想到的一点就是 Code Review，大家坐下来，一起检查下代码的写法，一起判断业务逻辑是否合理，很容易就能发现那几个事故中的问题。

　　今年不定期的举办了 15 场 Code Review，发现了很多问题，例如逻辑错误、理解误差、写法优化等。

　　还有很重要的一个举措就是推广代码注释，成员们普遍对注释比较吝啬，你自己显而易见的写法，别人可能难以理解。

　　况且好记性不如烂笔头，注释也能帮助自己理解比较复杂的代码。

三、组件化

　　组件化其实就是创建物料库，物料库的有无会非常影响我们这边的日常开发效率。

　　2022 年我每个双月都会订一个 OKR， 那就是整理 10 个组件，大家都很给力，组件在持续的增加中，并且都做了配套的 H5 演示页面。

　　我们的物料库包括业务组件、JSBridge组件、模板组件等，其中模板组件专用于后台管理系统。

　　组内的小伙伴会将各类业务组件封装（包括榜单、支付等）并配置说明文档以及演示网页，为了与客户端调试 JSBridge，组员自己还新建了一张页面专门为客户端服务。

　　在我到公司的第一个月就发现后台管理系统的研发占据着我们组大量的时间，而每次开发都会建文件、加权限、加接口等方面，尤其页面布局占据着大头。

　　之后整理发现，几种常规的布局大概占总页面数的 80% 以上，只有很小一部分的页面需要专门定制，那么就能抽象出常规布局中包含的组件。

　　模板组件呼之欲出，经过一周多时间的调试，在组内开始推广。在开发这套组件的时候，预留了许多回调，可根据不同场景做自定义的逻辑。

　　在模板组件上线后，就将页面的开发从 3 天降低至 1 天以内，有些简单页面两三个小时就能布局完成。

　　不仅如此，在活动页面组件化后，各类常规活动的研发也大大提速，配合标准化后，一些常规活动只要在后台可视化的配置就能快速上线。

四、标准化

　　标准化是指在经济、技术、科学和管理等社会实践中，对重复性的事物和概念，通过制订、发布和实施标准达到统一，以获得最佳秩序和社会效益。

　　我的理解就是在制订统一标准后，实现利益最大化。

1）榜单标准化

　　公司有一类常用的打榜活动，对其进行定制化的设计后，立竿见影的提升了工作效率。

　　先说说此系统的价值，当它完成后，受益方将包括设计组、Web 组、产品组、QA 组和数据分析组。

1. 设计组不用再考虑界面模块，只需将精力集中到配色和插图上。
2. 产品组不用再跟进此类活动，她们可以置身事外，设计做好的图可以直接给配置人员。
3. QA 组不用再过一遍测试，她们只要查看页面表现是否正常即可。
4. 数据分析组不用再为每个活动手动制订报表，根据存储的信息，可自动生成。
5. Web 组不用再投入人力去研发界面和接口了，只要页面稳定运行，都不用修线上BUG了。

　　原先这么一个活动，人力时间包括 2 天开发，3 天测试，1 天产品，6 天时间，而现在可以浓缩到几十分钟，大大提升了生产力。

　　设计组虽然不会减少页面设计的时间，但是切图的时间绝对能少很多。

　　数据分析组本来创建报表也不会费时间，但是会打断他们的工作，自动生成后，运营就完全不用找他们了。

2）前后端分离

　　上述是技术研发范畴的一次标准化，还有一次开发协作范畴的标准化，叫前后端分离。

　　因为历史原因，这边的前端会负责一些业务的后端工作，这就会出现职责边界模糊，工作内容不清晰的问题，有时候还容易发生互相推诿的情况。

　　团队成员也无法集中精力关注前端技术，为此，在一个契机发生后，强势推进此标准，已顺利的开始执行。

　　先在管理后台试点，我们提供权限和操作日志的接口，这样就能适配之前的验签和日志逻辑。

　　活动页面的分离，也在稳步进行中，接下来就是我们出页面，服务端出接口。

五、工具化

　　工具主要是为我们开发自己所服务的，这些工具可以帮助我们提升工作效率。

　　例如 Redis 工具，为了便于查看缓存数据而制作的工具，包括查询和删除功能。QA 在测试活动或功能时，可以方便的观察缓存的变化，以及测试完后不用叫我们帮忙清理数据了。

　　再有是脚本执行工具，为那些临时处理数据的脚本提供一个统一入口，不用再上传脚本到服务器中执行，只要将代码放到执行接口中，就能完成脚本逻辑。

　　还有一个通用配置工具，将一些可变的常量存在数据库中，可随时读写，我们已经将活动中可配的参数（例如开始时间、结束时间等）都写在其中，便于 QA 测试的时候修改。

　　为了提升管理后台的开发效率，先后研发了后台编辑器第一版和第二版，第一版组员接受度并不理想，第二版已经上线了两个菜单。

　　开发了一款 VSCode 智能索引插件，因为框架写法的原因，使得路由层的代码不能自动跳转到服务层，因此写了插件扩展功能。

　　在功能上线前，可以对新功能加个开关，万一有问题，就直接关闭新功能，粒度可以是页面级别的。

　　不过前端发版不像客户端那么困难，毕竟做开关是要成本的。灰度和 A/B 测试，在前端也可以执行。

六、自动化

　　为了规范代码编辑，引入了 ESLint，对冗余代码和会存在隐患的代码进行标注，帮助我们写出更健壮的代码。

　　将 Cypress 集成到管理后台的项目中，就能进行 E2E 的测试了。

　　虽然工具很强大，可以模拟用户的任何一个动作，但是奈何维护成本巨大，因为要写非常多的测试用例。

　　而公司 QA 的重心都 APP 端，没有多余的人力来做这种自动化测试。

　　还有一点就是，后台都是公司员工使用的，大家的适应性都比较强，有点小毛小病也不会抓着不放，能用即可。

　　在 Node.js 代码发布的流水线中，加入了基本的单元测试，以免服务不可用。

　　在单元测试中，写一些代码验证服务是否连通，若无法连通就断言失败，从而阻止后续的构建和部署。

　　需要注意的是，在单元测试中不能在数据库中增加数据，以免造成线上数据的混乱。

七、页面规范化

　　页面规范化其实也是在不断的演进中。大到整个页面的结构，小到一张占位图，一个弹框。

　　标签栏预请求，就是在空闲时间去请求隐藏菜单栏的接口，在用户切换时，能瞬间将隐藏部分渲染完毕。

　　在用户等待时，提供合适的 loading 动画，加载动画就是为了弥补服务器加载过慢的问题而设计的。

　　一个好的加载动画可以从两个层次分析，第一个层次是满足用户心理基本需求，缓解用户烦躁情绪，第二个层次是给予用户惊喜感，增加用户对产品的好感度。

　　有专业人士做过实验，如果请求需要花 2m，那么有一半的人等到 8.5s 就会离开，而增加了 loading 后，离开时间会加至 20s。

　　骨架屏（Skeleton Screen）是一个页面的空白版本，通过这个空白版本来传递一种信息，即页面正在渐进式的加载中。

　　骨架屏的布局能与页面的视觉呈现保持一致，这样就能引导用户的关注点聚焦到感兴趣的位置。

　　如果有条件的话，还可以对页面进行无障碍优化，让特殊人群在使用该网站时，也能有很好的体验。