最近在小红书的中台实习，技术栈是vue2 - vue3 的微前端，因为之前并没有正式的前端员工，代码很多都是后端或者前端实习生写的，由于实习生的流动性+没有明确的HC，之前的实习生感觉对代码并没有一定的责任感，结果就是大量2-3k行的文件，很多逻辑的耦合，配合上vue2选项式api的限制，代码的可读性很差。由于项目的功能还需要快速迭代，而历史代码已经给迭代带来了很高的变动成本，于是重构+迁移迫在眉睫。
日常工作也包括对之前的一些不良设计、实现问题的修复，而这种修复往往很难完整的理解它所有的业务需求，带来的问题就是，作为修复的改动，可能会影响到线上正常的功能，每一次改动都需要小心翼翼，不断重复和产品、测试确认。而今天的一个改动，因为自己并不熟悉代码面对的需求背景，改动之后只是和产品确认了（这里是把产品和测试的角色重叠了，不应该这样的），就直接提mr，合入，但在beta验证的时候才发现自己还有一部分逻辑没有实现！不得不重新提了两个mr来修正前面的错误，而总体的代码改动只有10行左右。
前几天组里面也有技术分享，主题就是如何写出高质量的代码。关于这个主题大家都分享了很多，我印象最深的是其中对TDD的一个演示：
在编写测试的过程中，你对你需要实现的需求的认知会逐渐体现在测试中，用测试来定义它应该是什么样，不能是什么样，越好的测试，也就意味越好的理解。
在测试的保障下，你可以自由的调整代码的结构，让它向更好的方向转化，而不用担心破坏它对外表现的功能。大家也讨论了很多关于它的优点，在我看来，它最重要的优点：增强了开发者改动原有代码的信心。
在传统的开发流程中，代码上的改动一般都需要专门的QA来进行测试，这部分测试需要时间，更需要测试的人力。越大、越复杂的模块，改动的测试成本就越高。
越大的项目，代码量就会越大，在到达一定的临界值时，就需要对代码的结构做调整，在业务迭代的压力下，往往很难有足够的测试、开发时间来处理这部分的需求，带来的结果就是代码变得复杂，在下一个周期需要的改动成本更高，测试成本也更高。
TDD一般通过自动化工具进行，最大的好处就是快，不依赖其他人员。开发者对代码的改动，可以在很短的时间内得到反馈…