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

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

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

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

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

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

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

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

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

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

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

By Filip van Laenen

本文翻译自"Before You Refactor"，来自于《97 Things Every Programmer Should Know》一书中的某个章节。

在某些时候，每个程序员都需要重构现有的代码。不过在你动手之前，请考虑一下下面的内容，因为这可以节省你和他人的大量时间（以及痛苦）。

· 重构开始的最好方式就是对现有代码库及其测试代码进行总结和评估。

这将帮助你理解现有代码的优点和不足，你也可以确保将优点保留住并避免错误。我们总是认为自己做的可以比现有系统更好…直到最终我们没能拿出更好的系统，甚至做得比系统的前身更糟，因为我们没有从现有系统的错误中汲取教训。

· 抵御重写一切的诱惑

最好尽可能多地重用现有代码。无论这些代码有多么丑陋，它们毕竟是经过评审和测试过的。扔掉旧代码，特别是那些运行在生产环境中的代码，意味着你扔掉了经过数月（或者数年）测试且久经沙场的代码，或许这些代码中还包含了一些你所不知道的特定的应对方案和Bugfix。如果你没有考虑到这些，你写的新代码最终就会出现出同样诡秘的bugs，而这些Bug在旧代码中都已经被Fixed了。这将浪费大量时间、精力以及多年来积累的知识。

· 多次增量改变优于一次巨大改变

增量改变可以让你更容易地通过诸如测试等反馈来评估对系统的影响。做出一次改变就导致上百个测试失败，这可不是什么好玩的事。这可能让你更加沮丧，压力更大，并会相应地导致错误的决策。三两个测试失败容易对付，并且也容易管理。

· 每次迭代后，确保现有的测试通过

如果现有的测试无法覆盖你所做出的改动，那就增加测试。不要不经思考就扔掉针对旧代码的测试。表面上其中的一些测试似乎不适合你新设计了，不过深入分析这个特殊的测试被添加进来原因是非常值得的。

· 个人喜好和自大不应该成为障碍  

如果东西没有损坏，为什么要去修正它呢？ 代码风格或结构不满足你的个人喜好，这不是一个重构的正当理由。认为你会做的比之前的程序员更好同样也不是一个正当理由。

· 新技术不足以成为重构的理由 

因为当前的代码落后于今天所有时髦的新技术，并且相信一门新语言或一个新框架可以使代码更优雅，这些都是最糟糕的重构理由。除非成本效益分析表明一门语言或一个框架将在功能性、可维护性以及生产力方面带来显著的提升，否则最好不要理会它。

· 请记住：人会犯错误 

重构并不总是保证新代码一定就更好，或者与以前的代码一样好。我看过并且亲身参与过许多次失败的重构尝试。漂亮并没有错，犯错的是人。

By Rajith Attapattu