争论：编写可维护的代码

在.NET 社区里，Sam Gentile、Oren Eini（昵称 Ayende）和Frans Bouma正在就如何编写可维护的代码进行一场争论，还有不少人也加入了战局。争论的焦点集中在一个问题：测试驱动开发（TDD）、对象 / 关系映射（ORM）、Model-View-Presenter/Controller（MVP/MVC）以及其他最佳实践是否有助于提高软件的可维护性。

Jdn以他对可维护性的一些想法开始了这场争论，Jdn 表达了他对 TDD、ORM 和 MVP/MVC 可能妨碍而不是促进了生产效率和可维护性的担心：

我有一个问题（好吧，其实不只一个）。我清楚知道我将把这个程序交给别人。维护它的人不会是我。我了解将要接手的人，因此我知道他们掌握的技能，我知道他们对编码方式的偏好。

Oren Eini 以一篇《可维护，对谁来说？》作出了回应。他同意对于不熟悉 TDD、ORM、MVP/MVC 的开发者来说，维护一个采用这些实践和框架的系统是很困难的（甚至是不可能的）。但他认为保留坏的实践，而只为了方便别人维护是一个糟糕的借口：

走回头路在我看来是最失败不过的了……。这不过是“我们一直都这样做”的老生常谈。当然，你可以用骡子来耕田，没问题。但一架拖拉机可以做得更好，即便你要先学会驾驶它。

Sam Gentile 赞同 Oren 的说法，他也认为向开发者传授最佳实践，如 TDD、DDD 和 ORM 等，对“真实世界”的项目来说，是值得花的代价。他在博客上总结了这场争论，并对 Frans Bourma 写的《没有坚实的文档行不通》作出了回应。Bouma 认为 TDD 无助于理解软件内部的行为，并且“很可能缺乏有深度的设计文档，以来阐述为什么一段代码要这样写，以及比如为什么不采用 B 和 C 算法等等。这些都是提高软件可维护性的重要信息。” Sam Gentile 回应说：

并不是只有单元测试。这些代码都是经过结对编程高度重构过的。当人们谈论代码的可维护性和“可扩展性”时，并不是在说什么插件。而是持续地改进代码的内部实现，将之重构成简单和可维护的代码。我坚持认为这样开发出来的代码更具可维护性，也为将来的代码增长打下了基础，将来不需要破坏一切再重新开始。让我们换个说法：我可以一个月不去看代码库，只要有单元测试和构造良好的代码，在几分钟之内我就能够了解现在的进展。

Frans Bouma 接受了挑战，并反击到：“要正确地分析代码和完全理解代码需要耗费很多的努力。这是‘代码就是文档’流派经常犯的错误”。他认为“代码不能替代你的文档：它只显示了现在的实现是什么，而没有说明为什么没有采用另外一种实现；而且代码是糟糕的文档：它没有用人类最容易理解的方式来说明代码的工作原理。” Oren Eini再次加入战局并声称他对这个问题的解决办法是“投入很多时间来想出有意义的命名，以及在测试里涵盖基础设施的所有方面”。对于 Bouma 的论点“文档并不是与代码分离的实体：它是用某种 DSL（即人类可阅读和理解的语言）写成的对功能性的描述”，Oren 回应说：

文档不是 DSL，而且在很多情况下几乎可以肯定文档是难以理解的。文档可能有很多模糊不清的微妙之处。代码并不是某种 DSL，这种说法假设了代码与文档存在某种关联，但代码才是实际运行的东西，因此对任何系统来说，代码才是权威的。

虽然这场争论很大程度上是在重复“代码就是文档”的老争论，但仍然提出了许多值得深思的新想法和新论点。您的想法如何？