在“理解需求，明白架构”是一切工程化软件开发的前提，那么 TDD 就是目前已知的工程效能最高的办法
- 为什么 TDD 具有工程效能：
- 从团队协作的角度： TDD 不光表示我理解了需求，也向其它人证明我的确理解了这个需求，同时还有此时的支撑。这是在团队协作中证明员工靠谱的基本点。
- 从长期稳定的角度： 我们生产效率越来越慢，越来越不敢改动祖传代码。是因为所做的修改一旦出错，就难以定位究竟是因为什么出的错。TDD 中由列表任务产生的测试，既是我们实现软件过程的记录，也可以帮助我们发现软件中存在的问题，以及更快地去定位到问题。
- 从持续提高水平的角度： 在使用 TDD 开发的过程中，我们对需求和架构会有越来越清晰的认知，而需求和架构也会直接反映到任务列表中。在任务列表中，我们产生了越来却清晰的任务。
- TDD 的整体工作流程：
- 首先将需求分解为功能点，也就是将需求转化为一系列可验证的里程碑点；
- 如果已经存在架构或架构愿景，则依据架构中定义的组件与交互，将功能点分解为不同的功能上下文；
- 如果尚不存在架构愿景，则可以将功能点作为功能上下文；
- 将功能点按照功能上下文，分解为任务项。也就是进一步将可验证的里程碑点，分解为功能上下文中可验证的任务项。
- 将任务转化为自动化测试，进入红/绿/重构循环，驱动功能上下文内的功能实现；
- 如果重构涉及功能上下文的重新划分，即提取/合并组建，即视作对于架构的重构与梳理。需调整后续功能点中对于功能上下文以及任务项的划分。
- 如此往复，直到所有功能完成。
- TDD 的工程优势：
- 看测试降低判断一个人是否理解了需求的成本：写不出测试就是不理解需求，不理解需求就只能在各种拉通会议中，反复宣讲确认，鸡同鸭讲，消磨精力。
- 看测试降低了十分需要进入探索模式的成本：在有限的时间（可能是一两天），判断需求是否被正确理解，并通过可管控的工程化方式交付。以此追求低成本及时止损。而不是在形成进度阻塞、延期或大量返工的时间，才发现根本原因是不能确定实现方式
- 看功能上下文拆分来判断团队是否对架构达成了共识：对于相同的功能点，团队中所有成员拆分出的功能上下文应该也相同。否则所谓架构就是一句空话，或者一堆空话。
- 看功能上下文拆分来判断架构是否能实现当前需求：如果无法拆分出合理的功能上下文和任务项，那么这个需求，就是当前愿景不易实现的需求。那么就可以通过重构抽取架构要素，演进式调整当前架构。
- vibe codeing 是完全与 tdd 相反的实践： 所谓 vibe codeing，就是把需求告诉 ai，让 ai 去实现，如果运行错误，就把控制台的报错，贴给 ai 去修复，然后循环往复。 这个和我们平时的“跑一下，看看效果，再修改”的 debug 编码模式并没有任何区别，整个软件开发过程中，开发者始终处于 Complicated 认知模式1下，并没有理解业务和代码的过程（这也是我们平时重复工作感的来源），在这种模式下写出来的代码，自然也不会有什么可读性。