为了解决这一矛盾点，这背后需要有强大的基础设施及长期的习惯培养做支持。这里将难点分为如下几个类型，大家可以针对这些难点做一些考量，来确定是否有必要采用主干开发的方式。
1）完善且快速的自动化测试。只有在单元测试、集成测试、E2E 测试覆盖率极高，且通过变异测试得出的测试用例质量较高的情况下，才能对项目质量有一个整体的保证。但这需要团队内所有开发人员习惯 TDD（测试驱动开发）的开发方式，这是一个相当漫长的工程文化培养过程。
2）Owner 责任制的 Code Review 机制。让开发人员具有 Owner 意识，对自己负责的模块进行逐行审查，可以在代码修改时规避许多设计架构上的破坏性修改与坑点。本质上难点其实还是开发人员的习惯培养。
3）大量的基础设施投入。高频的自动化测试其实是一个相当消耗资源的操作，尤其是 E2E 测试，每一个测试用例都需要启动一个无头浏览器来支撑。另外，为了提升测试的效率，需要多核的机器来并行执行。这里的每一项都是较大的资源投入。
4）快速稳定的回滚能力和精准的线上及灰度监控等等。只有在高度自动化的全链路监控下，才能保证该机制下发布的新版本能够稳定运行。这里的建设我会在之后的文章里详细介绍。
