上周末和LP一起到一家烤肉店吃饭。这家店在本地算是一家很有名气的以经营韩式烤肉为主的饭店了。记得在LP怀孕前我们经常在周末光顾这家店。那时这家店生意甚是火爆，门庭若市。烤肉量足且好吃，环境整洁，服务员业务也是十分熟练。后来LP怀了果果，再加上果果出生后一直母乳喂养，我们也就好久没有去过这家店了。这次又和LP来到这家店，不过我们看到的却是另外一番景象：门庭若市换成了门可罗雀；服务员早已经换了一批，服务员的脸上早已用冷漠代替了以前的笑容，业务也不熟练，给我们点菜的那个男侍者居然对菜单上的菜品还不如我们熟悉；餐具也有些脏兮兮的，看着让人就没食欲；好不容易上菜后，居然还发现少一道菜，之前那个服务员居然忘记给我们记下了；另外菜量已大不如前了，虽然味道与之前差距不大。饭后，我和LP的一致想法就是下次再也不来这家店了。

在回家的路上我一直在思考这样一个问题：为什么这家店的生意和服务会变成如此模样了呢？我得到的一个结论就是：不是顾客放弃了这家店，而是这家店自己先放弃了自己的标准。想象一下如果饭店依旧能按照之前的标准持续提供优质服务，甚至是比之前更好的服务，那么食客们能不来光顾吗？其实不仅是饭店，这个结论适用的范围很广，甚至可以应用到你的生活、学习和工作中。

生活中你总是可以发现一些从优秀到平凡，从模范到普通，从闻名到堕落的例子，而这一切的发生的缘由：不是大家放弃了这些人，而是他/她自己先放弃了自己的标准。我所处的这个行业也是这样的。很多人说程序员是吃“青春饭”的，过了而立之后就会渐渐失去竞争力了。这个问题见仁见智。不过首先不可否认的事实是中国程序员的外部生存环境确实是不如欧美同行。不过我们还是应该从自身找些原因。想过而立之年后的你是如何学习和工作的吗？你是否还在坚持着你在“黄金时代”时养成的良好习惯以及工作和学习的标准呢？如果你没有，那是你先放弃了你自己，然后你才被大家所放弃的。当你放弃你的标准后，你的学习会放松下来，你的工作会变得随波逐流，你的生活会变得失去激情。久而久之，父母长辈和老师失去了对你的信心，你的领导和同事失去了对你的耐心，甚至你自己也会失去人生的方向标。当然在年龄增长后依旧保持标准是需要付出代价的，但不付出一些又哪里会有回报呢！

俗话说：“由俭入奢易，由奢入俭难”。一旦你长时间放弃了你的标准，再想回到从前重拾标准就会变得十分困难。

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

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

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

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

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

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

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

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

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

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

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

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

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

By Pete Goodliffe