本文翻译自"Improve Code by Removing It",来自于《程序员应该知道的97件事》一书中的某个章节。

少即是多。这是一句有些陈腐的短小格言,但有时它确实是正确的。

在过去的几周里我对代码库所作的改善工作之一就是删除了其中的几大块代码。

我们编写软件时一直遵循着XP的(译注:极限编程,eXtreme Programming)原则,包括YAGNI(即You Aren't Gonna Need It,你不再需要它了)。不过人类的天性就是这样,我们不可避免地在一些地方无法达到这些要求。 

我观察到,某些产品在执行一些任务时耗时太长,这些任务原本是可以立刻执行完毕的。这是因为它们被过分实现(overimplemented)了;附加了许多其实并不需要的特性,但在当时看来这似乎是一个不错的想法。

因此,我简化了代码,提高了产品的性能,删除了代码库中那些引发问题的特性,降低了全局代码熵(global code entropy,译注:一般指软件中代码的混乱程度)的级别。我的单元测试结果告诉我这些操作没有对产品造成任何破坏。

一个简单且非常令人满意的体验。

为什么起初这些不必要的代码留在了代码库中?为什么程序员感觉到需要编写这些额外的代码呢?还有这些代码是如何通过评审或结对过程的?几乎可以肯定是这样:

·额外的代码会带来一些乐趣,程序员渴望编写这些代码。(提示:写代码,是因为它增加了软件的价值,而不是因为它可以取悦你。)   

·有人认为:这些代码可能是将来需要的,所以觉得最好现在就编写这些代码。(提示:这不符合YAGNI原则。如果你现在不需要它,那么现在不要编写它。)

·这些"额外"的功能看起来似乎都不大,所以与将它们返回给客户确认是否真正需要相比,直接实现它们更为容易。(提示:通常实现和维护一些额外的功能耗费时间更长,而客户实际上则非常容易接近与沟通。一小片额外功能的代码就像一个小雪球,随着时间的推移将变成一大块需要维护的工作。)

·程序员发明的额外需求,既没有写入文档,也没有经过正式的讨论。这些需求实际上是伪造的。(提示:程序员不应设定系统需求;那是客户的职责。)

你现在在做哪些事?这些事是否都是客户需要的?

By Pete Goodliffe

© 2011, bigwhite. 版权所有.

Related posts:

  1. 代码评审
  2. 持续学习
  3. 专业程序员
  4. 知道如何使用命令行工具
  5. 把一切都纳入版本控制