争论：编写可维护的代码

作者 Hartmut Wilms译者 郭晓刚 发布于 2007年6月26日 上午1时11分

社区

Java,

Agile,

.NET,

Ruby

主题

编程

标签

文档,

最佳实践,

测试驱动开发

在.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，这种说法假设了代码与文档存在某种关联，但代码才是实际运行的东西，因此对任何系统来说，代码才是权威的。

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

查看英文原文：Writing Maintainable Code

1. 返回顶部

   争论：编写可维护的代码

   2007年7月4日 下午7时56分 发表人 pan baokun

   中庸，使用见名知意的方法名，代码中多加注释，写详细的测试用例，

   回复

• 更早的 >