我的工程公理（译）
前言
几个月前，我进行了一次演讲来分享我个人的工程公理清单。多年以来，我认为这些公理都是非常正确的，并且在编写代码、构建东西时牢记在心来和他人一起工作。
公理（Axiom）是一个奇特的词语，但是从词根中走出几层，我们可以得出一个更合适的古希腊词语ἀξίωμα，或者是“被认为合适或值得的”。我喜欢这样，并且认为清单上面的每一项都值得参考。
当然，这些都是我个人的工程公理——根据我自己的经验，我认为这些公理是很有用的。针对每个人的体验可能不同。
无论如何，我很乐于在这里分享我的清单，并简要的说明一下。有一些可能并不令人惊讶，但是希望其他的可以产生出一些思想的碰撞和有趣的讨论。
1.一切总是在不断变化的
这个应该没有太多的争议。几乎所有的东西都在是不断的变化中，包括变化率自己。我们不仅需要承认应对变化的能力至关重要，而且我们的表现（时间、成本、质量、可靠性）往往是我们竞争力的一个方面。
2.你的产品是一种资产，而代码是一种负债
你的产品可以解决了用户的问题，因此它是你的资产。而代码本身则是创建资产所使用的成本。你拥有的代码越多，就越需要去阅读、测试、更改和理解它。尤其是当考虑第一点时，这一点尤为重要。保守地接受新代码（以及对外部代码的依赖）。最好的代码就是你不必编写的代码。
3.复制成本远低于过早的抽象
除非你高度确信你的抽象解决了一个真正的问题，并且自己会为它买单，否则不要轻易的这样做。你可以等待并进行更多的了解。在此之前，重复的代码可以帮助避免产生依赖关系，这样可以使得代码本身更容易地进行独立修改和删除。过早的抽象通过依赖性和间接性造成了更大的复杂性，并可能成为影响你应对变化能力的瓶颈。
4.代码应该易于删除
编写易于删除的代码，换句话说和“解耦”意思差不多。当然，并非所有的代码都需要做到同样地易于删除，但是可以做到最大限度的减少依赖性，通过定义良好的接口并定义明确的边界，并且在整体的系统设计上深思熟虑可以更轻松地删除/更改部件。我曾经听说过“花费代码“这一词语作为”编写代码“的替代词语，我非常喜欢这样，我喜欢删除代码可以降低未来成本的意思。
5.现有的代码具有强大的影响力
代码存在于那里就表明它是正确且必要的。希望如此，但不总是这样。我们需要有改变它的信心，以及思考我们是否具有这样做的能力。不要让代码本身的存在让人们质疑它是无法删除的。根据公理4，它应该是容易被删除的，系统应该被设计的足够好来让我们了解我们是否仍然需要它。
6.意料之外的复杂性是最大的风险之一
意料之外的复杂性是可以避免的，其大多发生在由于设计不佳，决策错误以及未优先考虑系统中适当的简单性等原因造成的。如果不把简单性作为目标，那么随着系统的成长，意料之外的复杂性更有可能发生，并且逐渐会对几乎所有事物造成负面影响，从改变系统系统到理解系统。2006年的论文《走出焦油坑》是关于这个主题的，并且很值得一读。
7.技术卓越的人可能会被糟糕的个人技能所掩盖
除非你能独自工作，否则重要的不仅仅是你解决技术问题、编写优秀代码的能力。相反，如果你让周围的人不开心，效率降低，技术就不那么重要了。就像学习编写好的代码一样，你也必须学会“对人”好。同情心是其中最重要的组成部分，认识到人们是与众不同的——要关心，理解，帮助别人，帮助他人和自己寻求帮助，要友善。成为其他人想要与之合作的工程师。
8.代码不能代表个人。善待编程人员，而不是代码
代码只是我们认为我们知道了某事的时刻。它并不是你本身。你可能编写了它，但是从那一刻起（即使是3分钟前），你已经有所成长了，但是代码可没有。关于代码的好坏，永远不是个人导致的。保持专业的态度，探讨代码本身和遇到的问题，但是不要去谈论编写这段代码的人。更多的使用“我们”而不是“您”。有时候我会试着假装我写了别人的代码，这样有助于我避免意外的听起来很个人化。
9.尊重和耐心的对待比你了解的少的人
我们都是从某个地方开始的，当你被那些希望你能够成功的的充满耐心的人包围的时候，你的旅程会更加的快乐，而不是那些让你觉得自己不属于其中的人。如果你为此而痛苦挣扎，一个小建议，记住新手程序员几乎肯定比你在这点做的更好——也许他们精通另一门语言，或者烹饪技巧很出色，或者很善于玩一项运动。想象一下，如果自己处于相反的位置。你希望他们如何对待你，把你当成完全的新手？再次强调：成为其他人想要与之合作的工程师。
10.唯一的权威来自于知识，并非地位
对于问题、领域、客户的了解和理解都比名片上的前三个字重要的多。即使它确实有（权威的）水印。 第一原则是了解事物是怎样运作的，并且建立扎实的了解，权威自然随之而来。