1、量两次，切一次(Measure twice and cut once)
如果你只能从这篇文章中学到一个原则且最重要的一个，那么就是这个。 开发人员，架构师和经理人经常因为个人情绪、以及其他问题而难以集中注意力。
就工程师来说，这个原则意味着选择正确的解决方案，选择正确的方法来解决问题，选择正确的工具来解决问题，对建立的解决方案必须充满信心。
选择这里意味着投入一些思考，找到必要的资源，组建合适的团队，思考设计，思考方法，设定任务，控制结果，并为此承担责任。 这就是“活在当下”。 我认为我自己还没有准备好用正确的词汇来描述它。
2、不要重复自己(Don't Repeat Yourself)
这是一个相当简单但非常有用的原则，它说在不同的地方重复同样的事情是非常糟糕的。 首先，它涉及到进一步支持和修改代码的必要性。 如果某个代码片段在程序中的几个地方被复制，那么很有可能出现两种灾难性的情况:
当对源代码进行哪怕是很小的改动时，您需要在几个地方更改相同的代码。 这需要额外的时间、精力和注意力，而这件事件通常也非常不容易。
第一项紧随第二项。 团队中的其他开发人员可能会意外地错过其中一个更改(只合并了控制系统中的分支) ，并将面对应用程序中随后出现的一系列错误。 这些 bug 可能会让您感到沮丧，因为您已经听说这样的 bug 似乎已经被修复了。
在这方面，有一个建议ーー如果在清单中发现任何代码超过两次，则应以单独的方式来处置。 这是通用做法。 事实上，即使再次遇到重复的bug，您也应该考虑创建一个单独的方法。
3、奥卡姆剃刀(Occam’s Razor)
这是一个非常普遍的想法，它来自于哲学编程。 这个原则得名于奥克姆的英国修道士威廉。 这一原则表明: ”没有必要，不得增加实体”。
在工程学中，这一原则被解释为: 没有必要创建不必要的实体。 因此，首先考虑添加另一个方法 / 类 / 工具 / 流程等的好处不见得总是一个好主意。 毕竟，如果您添加了另一个方法 / 类 / 工具 / 流程等等，除了增加复杂性之外，您没有得到任何其他好处，那还有什么意义呢？
4、保持足够简单(Keep It Simple Stupid )
这是一个与上面非常类似的原则，但它的含义略有不同。 这个原则要求代码必须尽可能简单，不能有复杂的结构，否则会使代码的调试和维护复杂化。
此外，对于另一个程序员来说，理解代码的逻辑将会更加困难，这反过来也将需要额外的时间和精力。 这就是为什么您应该始终尝试使用简单的构造来尽可能多地解决问题，而不需要使用大量的分支、深层嵌套和过度重载的类结构。
通过这样做，你将使自己和同事的生活更加轻松，因为复杂性会产生错误。 记住 Peter Hintiens 说过的话: “简单永远比功能好”。
5、你不会需要它（You Aren’t Gonna Need It ）
这是许多程序员都会遇到的问题。 从项目一开始就希望立即实现所有必要的(有时甚至是不必要的)功能。 也就是说，当开发人员从一开始就将所有可能的方法添加到类中并实现它们时，甚至可能在未来永远不会使用它们。
因此，根据这个建议，首先，只实现您需要的东西，然后，如果必要的话，再扩展相应功能。 这样，您就可以节省调试代码的工作量、时间以及精力，而实际上这些代码却并不需要。