争论:编写可维护的代码

阅读数:150 2007 年 6 月 26 日

话题:Java敏捷.NETRuby最佳实践语言 & 开发架构文化 & 方法

在.NET 社区里,Sam GentileOren 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