背景
从当初决心加入我们的 wangEditor团队 到现在已经过了差不多三个月了，当我刚加入团队的时候，那时候对富文本这个领域还都在初步了解的状态，对加入这样一个社区团队也是抱着学习的心态。做技术的人有时候有这样的体会，你可能学到了某项技术，甚至学了一生武艺，但是因为公司业务场景的限制，技术栈的限制，没法施展拳脚。又或者是自己想实践，但因为驱动力不够，经常半途而废。在 github 上做项目练手，甚至去做开源项目，这是一个不错的想法，但是有时候大多数人能力和时间有限，并不一定有能力、有时间专职去做这样一件事，我们还得解决面包问题。所以。如果有一个开源项目团队提供这样的机会，让你能施展你的拳脚，给你舞台去做好一件事，那么千万不要错过。我们的 wangEditor 团队就是这样一个开源团队，大家都抱着学习的心态，对技术的热爱，一起做一个开源好用的编辑器这样一件事。既然决心加入一个团队，那你肯定希望发光发热，为团队做出贡献，既锻炼了自己的能力，也能给简历添上华丽的一笔。下面我从加入团队到三个月成为核心成员这样一个经历，告诉大家怎么在加入团队的时候找到自己的位置，并能通过学习、贡献成为核心成员，希望能给大家一些帮助。
发现问题
因为我们团队是从2020年初才开始建立，之前项目也是由我们老大 @王福朋 自己维护，所以团队也还比较新。而且团队成员也是来自五湖四海，之前大家也不认识，也没有合作过，所以要管理这样一个团队，而且让团队能够比较效率地运作起来，去解决项目的 issue ，还有包括新功能开发，这也是一件非常有挑战性的事。既然是新团队，大家也没太多这样的经验，所以那么肯定会有很多的问题需要去解决。所以，如果你有一双发现问题的眼睛，一颗敢于提出问题的心，那么肯定能发现一些问题。相信无论是社区团队，还是公司团队，都会或多或少存在一些问题，有问题不是问题，解决就完事了。下面从我个人的角度，总结下我所看到的几个问题。而且这几个问题，我是能通过我的能力去解决的，所以我就提出来了。
问题一
我首先发现的问题是项目规范和发版流程方面的，因为我所在公司的团队也有自己的基建，我们使用的一些规范和工具还是很好用的。我觉得还不错，可以直接拿来用在 wangEditor 团队里用，所以我就去实践了。我在刚加入团队的时候，发现虽然我们在规范文档里有写到 commit 规范，就是参考业界比较出名的 angular commit 规范 ，但是并没有从开发流程上去加上这个流程。于是，在平时开发中，有小伙伴没有注意，或者说手误，就有可能将不符合规范的 commit 提交上去，这就让我们的规范有时候没有发挥作用。于是，我就通过 commitlint 这个工具配合 husky 在提交 commit 的时候强制对每个人的 commit 进行校验，在 commit-msg 钩子加上校验，代码截图如下：
如果有不符合规范的，直接会提交失败，如下图：
这样就能从流程上保证提交 commit 的规范。大家有兴趣可以去我们的仓库查看 wangEditor。
另一个也是流程上的问题优化，因为跟规范差不多，所以我就在这里一起说了。刚加入团队的时候，我们的发布流程是合并好所有待发布的代码，然后通过 shell 脚本生成新的 semver 版本， 手动打上对应版本的 tag ，然后提交到远程，触发我们的CI流程发布到 npm 。因为这样一些手动的过程，也没法生成 changelog 。每次依赖人为的操作这些重复步骤，既效率低，也容易出错。于是，我借用了 release-it 这样一个 CLI 工具优化了这个流程。 release-it 就是帮你的项目自动化生成新版本、发布包、生成 changelog 这样一些任务，让你无需关心太多细节，一切都是自动化的。你只需要提前做好配置，并且做发版的时候做几个选择题，就轻松搞定了发版的流程。下面是一个 release-it 使用图：
使用这样的工具，就能使你的开发轻松快乐起来。所以，现在我也成为了我们项目的发版负责人。虽然这只是一个不大的优化，但它确实让我们的项目变得更好了。
问题二
我觉得可以优化的第二个问题是在解决一个 issue 的时候发现的，当时负责的一个 issue 涉及到一个公共模块的修改，虽然最后解决了 issue 对应的问题，然后叫其它小伙伴进行了交叉测试，期间并没有发现任何问题。最后丢给我们老大 review 也没有发现问题，于是PR被合并了，代码到了待发布的阶段。过了两天，就有小伙伴反映很多菜单功能有问题，追查下来，发现果然就是我的那个修复造成的。我很庆幸当时没有代码发出去，否则可能影响还是比较大的。从这个事当中，我就开始思考一个问题，我在想随着我们项目的功能越来越多，代码也越来越复杂，很容易出现这样的情况。我们在修复一个问题的时候，很可能会引入新的问题，而新的问题，有时候很难被发现。因为，你想我们编辑器十几个功能，每次修复一个 issue 你不可能手工回归所有的功能，代价太大了，而且也很影响效率。于是我在想有没有一种办法，能代替我们做手工测试，前期我们只要覆盖基本的菜单功能，它也能带给我们一定的价值，于是我引入了 E2E 测试。
端到端测试在前端的产品中还是很常见的，前端生态中也有很多这样的框架去做这件事，例如 Puppeteer 、 Nightwatch 、 Testcafe 、 Cypress 等。自动化的端到端测试，能在一定程度上代替用户对我们的产品进行测试，本质就是模拟用户操作，最后验证页面状态、UI或者功能是否正常。当时我想，如果能在我们的编辑器引入 E2E 覆盖基本的菜单功能，那么就能首先保证我们的编辑器基本功能的稳定，避免出现一些低级的问题，解决手工测试带来的效率问题。经过调研最后，我选了 Cypress 作为我们的 E2E 测试框架。 Cypress 作为一个后期之秀，在这两年获得不错的关注，它开箱即用，API简单，将测试运行在浏览器的架构使得调试非常方便，对前端开发也而非常友好。
目前，我们的端到端测试已经覆盖了所有的菜单功能，在前期阶段，我觉得算不错了。当然还有不足的地方，我们还在摸索怎么将端到端测试与单元测试结合起来，成为项目质量保障的安全网。还有就是我们团队基本也是第一次使用 Cypress 做端到端测试，所以怎么配合我们的项目，做出一些最佳实践也还在摸索当中。
问题三
说完了端到端测试，下面介绍的是我解决的第三个问题，也不能说解决，就是做了个还算有不错提升的优化。当时我刚加入团队的时候，我们的编辑器代码单元测试覆盖率大概是在 65% 左右。虽然这跟我们做的编辑器有些关系，毕竟富文本编辑器是涉及到很多交互、依赖用户行为的产品形态，包括我们项目核心依赖的浏览器API：Selection 、execCommand 在不同的浏览器的行为差异，这都给测试带来了很多的麻烦。然后过了一段时间，当我再关注这个问题的时候，我发现我们的单测覆盖率还在下降，降到了 62% 左右。这又反馈出另一个问题，因为前端开发这个职位，大多数伙伴在公司做业务开发，如果没做什么基建工作，实际上很少接触单元测试这一块的知识。于是在做了一些代码逻辑修改、增加，只要测试没有失败，是很少会主动去完善测试这一块的内容。于是，我就下了个决心，要做好项目的单元测试，并且提高单元测试的覆盖率到 85% 左右，做好了也正好可以给小伙伴做个分享，让他们引起这一块的重视。
定好了目标，我就开始了优化单测之旅。虽然之前我有写过一些单测的经验，但是说实话我也只是小白的水平。于是，我又重新刷了一遍 Jest 的官网，我们项目用的是 Jest 。并且在网上去淘了一本书，叫 单元测试的艺术 （五星推荐），边学边做。我的思路是先找出那些覆盖率都没到及格的模块，使用 Jest 的 --coverage 参数可以看到每个文件的覆盖率情况，不到 60% 的覆盖率就会被 Jest 用红色的样式标红。经过两周的奋斗，当然也不是全职，毕竟我平时还要上班，最后几乎把所有覆盖率未及格的模块都提升到了 85% 以上。此时项目的整体代码覆盖率到达了 82% 左右，虽然还没到达目标的 85%，但是我心里清楚，其实这没有什么难的，毕竟还有挺多我还没做优化，我优化面向的只是那些覆盖率未及格的。这时候，我也想停下来做个总结和反思，盲目去追求一个数字也没什么意义，关键是要带起大家的重视，还有就是帮助大家怎么去方便地进行单测的编写。于是我就封装了一系列的 util ，比如怎么去模拟不同的浏览器、模拟 Ajax 、模拟文件、模拟事件等等，同时，所有的优化也给大家可以参考，因为它们几乎覆盖了我们项目的所有测试场景。于是，我也在团队里面做了个分享，给大家普及单元测试的核心概念、怎么去测一些复杂的场景、怎么去编写优秀的单元测试等，下面是分享的文章总结，感兴趣可以顺便看一下：使用 Jest 编写单元测试 。
总结
解决、优化了这三个问题，我发现自己不仅帮助团队解决了一些痛点，同时自己也学到了很多新技术。比如就拿测试来说，之前说实话我对测试这一块并没有什么太多的深入了解，很多也只是略懂皮毛。但是，这次经历，我深刻认识到了测试对软件开发的重要性，你让我去聊聊单元测试，或者去看别人写的测试质量如何，我还是能说两句。从解决问题的过程中，你会发现，你不仅自己学到了知识，而且也帮助团队变得越来越好。
积极推进，勇于发表意见
前面说到解决和优化了项目的一些问题后，老大就已经把越来越多的工作交给我，那时候我刚加入团队两个月左右，目前我负责团队的所有测试工作和项目的每周发版。当然说这些，不是是为了说我有多厉害，我自己的水平怎么样我自己还是拎得清。只是为了让大家从我的这些经历和思考中，能有一些感悟。其实除了能发现问题，解决问题。在团队里，无论是公司的，还是社区的，如果你能积极推进一些工作，并且勇于提出不合理的现状，并给出合理的解决意见也是能让团队的小伙伴，包括你的 leader 对你刮目相看。其实，我在公司的团队，之前的老大给我的评价也是非常积极，对任何事都保持激情。有时候能勇于提出问题也不错，但是如果能顺便提出解决问题的方案那就更好了。比如我之前在 wangEditor 团队，就是有时候就会给大家一些建议，比如每次 issue 或者新功能开发，应该保持 commit 整洁，使用 rebase 合并 commit ，后面这条建议就被纳入了团队开发规范。
写在最后的话
这也是我加入 wangEditor 团队的2020工作总结，这也是我觉得我在 2020 做的最有意义的事之一。当时加入团队的那时候，正赶上项目最忙的一个版本，那时候也要准备加入团队的作品，差点就想放弃了，我很庆幸没有放弃。那段时间很忙，但是却也很充实。2021我们团队有更多的新规划，包括团队建设、提效、功能优化等，如果你对开源有兴趣，想要征服富文本领域，欢迎加入我们，我们持续招人：加入wangEditor 。最后希望这篇文章，能带给大家一些帮助，在团队中找到适合自己的位置。
