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

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

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

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

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

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

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

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

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

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

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

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

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

By Pete Goodliffe

本文翻译自"Put Everything Under Version Control"，来自于《97 Things Every Programmer Should Know》一书中的某个章节。

把项目中的一切都纳入版本控制。你需要的资源包括：免费的工具，比如Subversion，Git，Mercurial和CVS；充足的磁盘空间；便宜且性能强大的服务器；无处不在的网络；甚至包括项目托管服务。安装好版本控制软件后，为了将你的工作成果放入版本库中，你所要做仅仅是在一个包含你的代码的干净目录中敲入适当的命令。你只需要学习两个新操作：将你修改的代码提交到版本库中以及将版本库中的代码更新到你本地的工作版本中。

一旦你的项目纳入版本控制，你就可以跟踪它的历史，看看谁写了哪些代码，并且可以通过一个唯一标识引用一个文件或某个项目版本。更重要的是你可以大胆地修改代码。不用担心删除掉那些为了以防万一而被注释掉的代码，因为老版本代码很安全地待在版本库中。你可以（且应该）用一个具有实际含义的符号给一个发布版本打上标签，以便你在将来可以很容易地重新找到客户那运行的软件的确切版本。你可以创建分支来进行并行开发：大多项目都有一个主开发分支以及一个或多个用于积极支持发布版本的维护分支。

版本控制系统减少了开发人员之间的冲突。当程序员各自工作在独立的软件部件上时，他们的工作好似用了魔法一样被整合在了一起。当他们之间出现冲突时，版本控制系统会通知他们，并允许他们对冲突进行分类整理。通过一些其他设置，系统会将每次变更提交通知给所有程序员，让大家共同了解到当前项目的进展情况。

当你创建完项目后，不要吝啬：将你的所有项目资产都纳入版本管理。除了源代码外，还包括文档，各种工具，构建脚本，测试用例，美工作品，甚至是库。全部项目被安全地塞入（定期备份的）版本库后，硬盘损坏或丢失数据所带来的损失将减到最小。在一个新机器上配置开发环境只需简单地将项目代码从版本库中检出即可。这将大大简化软件在不同平台上的发布、构建和测试过程：在每台主机上一个简单的更新命令就可以确保你获得的是当前最新的软件版本。

现在你已经看到使用版本控制系统的好处了，遵循下面几条规则会使你和你的团队更加高效：

· 每次提交一个逻辑变更。在一次提交中包含许多变更会导致后续很难弄清楚其中每个逻辑变更所对应的内容。这点在你进行项目范围内的重构或风格改变时尤其重要，一起提交多个变更很容易掩盖其他修改。

· 每个提交都要包含一个解释性的信息。至少简要地描述一下你修改了什么。不过如果你还想记录这次修改的理由，那这里就是存储它的最好地方。

· 最后，避免提交那些会破坏项目构建的代码，否则你就会成为这个项目中不受欢迎的人。

版本控制系统下的生活是如此美好，一些疏忽和过失都无法轻易地破坏它。

By Diomidis Spinellis