Keystone

http://www.codinghorror.com/blog/archives/000878.html
by Jeff Atwood
May 30, 2007

• Rich Skrenta writes that code is our enemy.

  Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean old code has to be adapted. The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take. The longer it takes a new employee to make sense of your system. If you have to refactor there's more stuff to move around.
  Code is produced by engineers. To make more code requires more engineers. Engineers have n^2 communication costs, and all that code they add to the system, while expanding its capability, also increases a whole basket of costs. You should do whatever possible to increase the productivity of individual programmers in terms of the expressive power of the code they write. Less code to do the same thing (and possibly better). Less programmers to hire. Less organizational communication costs.

  Rich hints at it here, but the real problem isn't the code. The code, like a newborn babe, is blameless and innocent the minute it is written into the world. Code isn't our enemy. You want to see the real enemy? Go look in the mirror. There's your problem, right there.

  As a software developer, you are your own worst enemy. The sooner you realize that, the better off you'll be.

  I know you have the best of intentions. We all do. We're software developers; we love writing code. It's what we do. We never met a problem we couldn't solve with some duct tape, a jury-rigged coat hanger, and a pinch of code. But Wil Shipley argues that we should rein in our natural tendencies to write lots of code:

  The fundamental nature of coding is that our task, as programmers, is to recognize that every decision we make is a trade-off. To be a master programmer is to understand the nature of these trade-offs, and be conscious of them in everything we write.

  In coding, you have many dimensions in which you can rate code:

  * Brevity of code

  * Featurefulness

  * Speed of execution

  * Time spent coding

  * Robustness

  * Flexibility

  Now, remember, these dimensions are all in opposition to one another. You can spend three days writing a routine which is really beautiful and fast, so you've gotten two of your dimensions up, but you've spent three days, so the "time spent coding" dimension is way down.

  So, when is this worth it? How do we make these decisions? The answer turns out to be very sane, very simple, and also the one nobody, ever, listens to: Start with brevity. Increase the other dimensions as required by testing.

  I couldn't agree more. I've given similar advice when I exhorted developers to Code Smaller. And I'm not talking about a reductio ad absurdum contest where we use up all the clever tricks in our books to make the code fit into less physical space. I'm talking about practical, sensible strategies to reduce the volume of code an individual programmer has to read to understand how a program works. Here's a trivial little example of what I'm talking about:

  if (s == String.Empty)
  if (s == "")
  

  It seems obvious to me that the latter case is better because it's just plain smaller. And yet I'm virtually guaranteed to encounter developers who will fight me, almost literally to the death, because they're absolutely convinced that the verbosity of String.Empty is somehow friendlier to the compiler. As if I care about that. As if anyone cared about that!

  It's painful for most software developers to acknowledge this, because they love code so much, but the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can't get away with no code, the next best thing is to start with brevity.

  If you love writing code-- really, truly love to write code-- you'll love it enough to write as little of it as possible.

http://www.yeeyan.com/articles/view/welovecs/1590
原作者: Jeff Atwood 译者: welovecs
08/19/2007

• Rich Skrenta在 代码是我们的敌人 一文中写到：

  代码时常令我们头疼。它会慢慢腐化，它需要不断定期维护，它有无穷尽的bug亟待发现。当新的特性出现，我们又要为旧的代码量体裁衣。我们编写的代码越冗长，bug的藏身之处就越多。代码的语法检查或编译的时间愈长，公司里的新来的员工，弄明白我们编写的系统所花费的时间就愈长。聪明的你可能想到了代码重构，可问题在于：需要的重构的代码就像长江后浪推前浪一样，向我们涌来。
  代码是软件工程师智慧的结晶，更多的代码需要更多的工程师。然而，工程师之间沟通的成本正比于工程师数量的平方。将新的代码加入已有系统，虽然扩展了系统的功能，但同时也使得生产成本大大增加。我们应当"不择手段"地提高程序员个体的生产力，使他们写出具有很好表达力的代码。用更短的代码，实现同样（更多）的功能；用更少的工程师，构建同样的系统；用更小的沟通成本，完成同样的项目--应成为我们孜孜以求的目标。

  Rich虽言代码之坏，但其"醉翁之意"并不在代码。软件工程师在代码编辑器中写出的代码，就像新生的可爱宝宝，是无辜的，无可责备的。事实上，代码并不是我们的敌人。你想知道真正的敌人是谁吗？不妨去照照镜子。你看到了什么？你自己，对了，这就是问题所在。

  作为一名软件开发者，我们最大的敌人不是别人，而是自己。

  我们越早认识到这一点，我们成长的步伐就越快。

  我知道，就算你写出了冗余代码，但你的本意是好的，大家都一样。我们是软件开发者，我们热爱编程。我们从来不会遇到无法用管道胶带 (duct tape) [1]、临时衣架 (jury-rigged coat hanger)或是一小撮代码（a pinch of code）[2]解决的问题。但是，Wil Shipley却持另一种观点：软件工程师，应当控制"编写更多的代码"这样一种自然倾向。

  对于一个程序员而言，编码工作的本质就是：我们在编码的过程中，做出的每一个决定，都是权衡、折衷的结果。一个大师级的程序员，能够看清这种权衡折衷后做出的决定的本质所在； 而且能够意识到，在我们写的每一行代码中，都有他们的影子。

  在编码过程中，我们可以从许多方面来评估代码的质量：

  * 简洁性

  * 特性丰富

  * 执行速度

  * 编码耗时

  * 健壮性（鲁棒性）

  * 灵活性

  请注意，这些方面是相互矛盾的。举例来说，你花了三天时间写出一个非常漂亮且高效的子程序，可以说，你将上述六个方面中的两个做的很好。但是，你花了三天的时间，所以"编码耗时"这方面，就无法兼顾。

  那么问题出来了：哪些方面值得我们花费经历去做好？我们该如何做出选择？一个明智、简单且富有创新性的答案是：编码初期注重简洁性，随后根据测试的需求去做好其他方面。

  Wil Shipley所言极是。在Code Smaller一文中，我曾给出类似的建议。我并不是在说：我们应当绞尽脑汁，用尽书中的技巧，来减小代码的体积。我想说的是：一个切实可行且通俗易懂的策略。通过实施此策略，我们得以减少程序员个体理解程序运行机制所需阅读代码的规模。下面是一个我将要讨论的一个小例子：

      if (s == String.Empty)
  
      if (s == "")
  

  在我看来，后一行代码显然更佳，仅仅因为它更为简洁。说到这里，我敢保证一定有开发者对我的说法持反对意见，更甚者会和我争论到底。因为这些他们完全相信冗长的String.Empty，从某种程度上来说，是编译器友好的。

  对于大多数软件开发者来说，承认这一点是痛苦的。因为他们深爱编程，但是，正如这篇文章的题目所言：无码胜有码。我们打算写出的每行代码，在写出来后，都要经过调试，都要被其他开发者阅读，都要提供对它们的维护与支持。所以，每次写新的代码时，就算有一百个不情愿，就算感到被人强迫，也请你把代码写的简洁一些。你别无选择，因为越是冗长的代码，越有可能成你的敌人。我们无法做到"Write no code"，但是我们至少可以在编码初期就注重代码的简洁性。

  如果你真正热爱编程，那么我敢肯定，你也会喜欢上简洁的代码。