simple update

Author: diktamxx

content/posts/正视测试驱动开发/index.md

@@ -15,7 +15,7 @@ TDD 的价值不在于测试（结果）本身，而在于通过“红-绿-重
 
 当与[领域驱动设计（DDD）]({{% ref "/posts/从敏捷开发的角度入门领域驱动设计/index.md" %}})结合时，因为 TDD 会切实地基于客户端角度来编写代码，这可能会令到开发者需要重新审视先前设计好的领域模型。该问题没有标准的答案，但应该得到重视。个人见解，应该尽可能遵循领域模型的设计。因为领域模型表达的是领域业务，其本身并不涉及技术成分，所以不应该单纯为了编码理由而改变领域模型。这里衍生出另一个问题“是否应该完全依赖 TDD 来进行代码设计？”。答案是否定的。因为重构本身并不会改变外部行为[^3]，所以有关领域概念的抽象、关系和交互等都需要提前进行设计和定义。
 
-TDD 并非灵丹妙药，它并不适合所有场景。特别是在面对一次性代码[^4]、需求不明确或不稳定，以及需要快速开发系统原型的时候，TDD 很可能会拖慢进度。另外，与性能相关的场景也不太适合。因为性能优化相关操作通常无法遵循良好设计，甚至可能大幅度降低代码的可读性（这也是为什么包括我在内的一些人极度不提倡过早优化的原因）。最后值得一提，不要死脑筋认为 TDD 必须在整个项目中使用。其实完全可以仅在关心代码质量的地方使用。
+TDD 并非灵丹妙药，它并不适合所有场景。特别是在面对一次性代码[^4]、需求不明确或不稳定，以及需要快速开发系统原型的时候，TDD 很可能会拖慢进度。另外，与性能相关的场景也不太适合。因为性能优化相关操作通常无法遵循良好设计，甚至可能大幅度降低代码的可理解性（这也是为什么包括我在内的一些人极度不提倡过早优化的原因）。最后值得一提，不要死脑筋认为 TDD 必须在整个项目中使用。其实完全可以仅在关心代码质量的地方使用。
 
 ## 参考资料
 - 《测试驱动开发：实战与模式解析》Kent Beck