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

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

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

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

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

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

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

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

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

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

By Diomidis Spinellis

本文翻译自”Automate Your Coding Standard“，来自于《97 Things Every Programmer Should Know》一书中的某个章节。

也许你也曾经经历过。在一个项目开始阶段，每个人都有着很多良好的意愿，我们称这些意愿为“新项目决议”。多数情况下，这些决议都会被记在文档中。关于代码的那些决议最终成了项目的编码标准。在项目启动会议上，主程序员带着大家一起浏览一遍文档，最好的情况下，大家都同意在项目中遵照这些标准。不过一旦项目开始，这些良好的意愿就被丢弃了，每次一个。当最终项目交付的代码看起来一团糟的时候，似乎没有人知道项目是怎么变成这个样子的。

什么时候出的问题呢？也许就在项目启动会上。一些项目组成员不专心，其他一些组员不理解。更糟糕的是一些组员反对这个标准，并已经规划好了它们自己的编码标准。最后，只有一些人理解并赞同使用这个标准。但是，当项目压力太大时，这些人也不得不放松要求。毕竟格式良好的代码并不能帮你从急需更多功能的客户那里赚取更多的分数。此外，如果没有自动化，遵循一个编码标准将是一件非常枯燥的任务。试试手工缩进一个格式凌乱的类你就会体会到这点。

但是如果这确是一个问题，那么我们为什么还要在一开始制定一个编码标准呢？其中的一个原因就是按照统一格式格式化代码可以避免一些人拥有使用私人方式格式化的代码片断。我们要阻止开发人员使用特定的反模式（译注：反模式是指能导致问题的典型做法），这样可以避免产生一些bug。总之，一个编码标准可以使得你在项目中工作更容易，并从头到尾的保持开发效率。由此可见，每个人也都应该就制定编码标准这件事达成一致。如果一个开发人员在某一行用三个空格缩进，而在另一行中用四个空格缩进，那么即使这么做了也无能为力。

现在有很多工具可以用来生成代码质量报告、记录并维护编码标准。不过这不是全部的解决方案。编码标准应该被自动化，并且在可能的情况下强制执行。下面是几个例子：

· 确保将代码格式化作为构建过程的一个环节，这样大家每次编译代码时就会自动执行代码格式化。 

· 使用静态代码分析工具扫描代码中有害的反模式，一旦扫描到，立刻中止构建。 

· 学会配置这些工具，这样你就可以扫描你自己的特定项目的反模式了。 

· 不要只度量测试覆盖率，还要自动检查度量的结果。同样如果测试覆盖率的度量结果过低，则中止构建。

尽可能地对每件你认为重要的事情采用上述方法。 你无法自动化所有你真正关心的事情。对于你无法自动标示或修正的事情，考虑将它们作为自动化的编码标准的补充参考，不过要接受这个现实：你和你的同事可能不会努力地遵守它们。

最后，编码标准应该是动态的而不是静态的。随着项目的进行，项目的需求会发生变化。开始阶段看似聪明的想法，几个月后就未必是这样了。

By Filip van Laenen