我的工程学公理（翻译）

我的工程学公理

原文在这里

几个月前，我做了一个演讲，在其中我分享了我的个人工程学公理列表 — 这些是我多年来在编写代码、构建东西和与他人合作时认为普遍正确并且在心中认为有用的事情。

"公理"这个词可能听起来很高级，但如果我们深入探索它的词源，我们可以轻易地找到古希腊词汇ἀξίωμα，意思是“被认为适合或有价值的东西”。我喜欢这个定义，并认为列表上的每一项至少都值得考虑。

当然，这些都是我的工程学公理 — 基于我自己的经验，我认为它们很有用。您的经验可能完全不同。也许您已经知道了零终止，或者您有比剪刀更好的工具来从程序中去除错误。

无论如何，我认为在这里分享这个列表并简要澄清一下会很有趣。有些事情可能一点也不出乎意料，但希望其他的会引发一些富有启发性的思考和/或有趣的分歧。

1. 变化是常态。

这一点应该不太有争议。几乎所有事物都在不断变化，包括变化的速率本身。我们不仅需要承认我们应对变化的能力至关重要，而且我们做得有多好（时间、成本、质量、可靠性）常常是我们竞争力的一个维度。

2. 你的产品是一种资产，但代码是一种负债。

你的产品解决了你客户的问题，因此它是你的资产。代码本身是创造这种资产的成本。你有的代码越多，就需要更多地阅读、测试、更改和理解。当你考虑到第一个公理时，这一点尤为重要。保守地接受新代码（和对外部代码的依赖）。最好的代码是你不必写的代码。

3. 重复的成本低于过早的抽象。

除非你对你的抽象能够为自己支付代价非常有信心，因为它解决了你真正面临的一个真实、抽象的问题，否则不要这么做。等待并学习更多。在此之前，重复的代码可以帮助避免依赖，这本身使代码更容易独立地改变或删除。过早的抽象通过依赖和间接性创造了复杂性，并可能成为你应对变化的瓶颈。

4. 代码应该容易删除。

编写容易被移除的代码，这在很大程度上就是说"解耦"。当然，并非所有代码都需要具有相似的可移除性，但最小化依赖、通过明确定义的接口设定清晰的边界，并有一个经过深思熟虑的整体系统设计，可以让部分更容易被移除/更改。我曾听到有人使用"代码代价"这个表达，作为"代码编写"的替代，我非常喜欢这个说法。我喜欢这种暗示：删除代码是降低未来的成本。

5. 现有的代码具有强大的影响力。

它的存在本身就暗示它是正确和必要的。希望它是，但并不总是这样。我们需要保持改变它的信心，以及思考我们是否应该这么做的能力。不要让代码的存在本身产生疑虑，认为它不能被删除。正如第四条公理所说，它应该容易删除，系统设计应该足够好，使我们能够理解我们是否还需要它。

6. 偶发的复杂性是最大的风险之一。

偶发的复杂性是可以避免的复杂性，它由于诸如设计不佳、决策失误以及在系统内部没有优先考虑适当的简单性等因素而发生。如果简单性不是一个目标，那么随着系统的增长，偶发的复杂性更有可能发生，并逐渐对从改变系统到甚至理解系统的几乎所有事物产生负面影响。2006年的论文《走出沥青坑》是关于这个主题值得一读的资料。

7. 技术的卓越性可能会被糟糕的个人技能掩盖。

除非你完全独自工作，否则不仅仅是你解决技术问题、编写优秀代码等的能力很重要。相反，如果你让周围的人感到不快和效率降低，它们甚至可能不那么重要。就像学会写出好的代码一样，你也必须学会很好地“与人相处”。同情心是这其中很大的一部分，同时也要认识到人与人是不同的 — 要关心、要理解、帮助他人并自己寻求帮助、要友善。成为他人想要与之合作的工程师。

8. 你不是你的代码。对程序员友善，而不是对代码友善。

代码只是捕捉我们对某件事所知的某一时刻。它不是你。你可能写了它，但从那一刻起（即使是3分钟前），你已经成长了，但代码没有。关于代码的讨论，无论是好是坏，都不应该涉及个人。保持专业性。谈论代码或问题，但不要涉及到写代码的那个人。使用“我们”而不是“你”。有时我试图假装我写了其他人写的代码，这有助于我避免不小心带有个人情感的发言。

9. 对知道的比你少的人要尊重和有耐心。

我们都从某个地方开始，当你周围都是希望你成功的有耐心的人时，旅程会更加愉快，而不是那些让你感觉自己不属于这里的人。如果你在这方面有困难，记住新手程序员几乎肯定在某些方面比你做得更好——也许他们能流利地使用另一种语言，或者烹饪得很棒，或者打球。只要想象一下自己在相反的角色中。你希望他们如何对待你，一个完全的新手呢？再次强调：成为他人想要与之合作的工程师。

10. 真正的权威来源于知识，而不是职位。

对问题、领域、客户的知识和理解比你名片上的前三个字母都要重要。即使它上面有水印。从基本原理出发了解某物的工作方式，建立坚实的理解，权威就会随之而来。

11. 教学实际上是一种伪装的学习。

如果你认为你知道某事，试着去教它。往往试图向他人解释你所知的事情会迫使你更清楚地形式化自己的思想。写下东西似乎也有类似的效果。我已经数不清有多少次在开始解释某事时发现我并不像我想的那样了解它。

12. 提高周围人的技能，而不仅仅是你自己。

一个伟大的团队永远不会因为一个了不起的人而伟大。它之所以伟大，是因为每个人都在挑战对方，每个人都在一起成长。当你学到一些很酷的东西时，分享出去——帮助你周围的人变得更好。当他们也这样做时，每个人都会受益，没有人会被落下。这也更有趣。次要好处：第11公理。

13. 你等待的时间越长，你知道的就越多。

我仍在学习并努力避免我的几乎默认的快速决策欲望。事实是，你延迟非必要决策的时间越长，当决策时你可以依赖的信息就越多。当然，你不能总是拖延决策，但往往你可以，至少你应该考虑现在不知道答案是否真的没关系。

14. 一个好的类型系统值得其重量再加一些。

在我的职业生涯中，我在各种静态和动态语言之间来回切换，我目前的观点是一个好的类型系统值得其开销。一个好的类型系统不应该有太大的开销。如果类型系统设计得当，它几乎可以像动态语言那样感觉（通过诸如推断和流分析之类的特性），同时消除了编译器可以比你处理得更好、更快的一整类问题。像Rust中的所有权这样的开发是一个很好的例子，展示了这一点已经比几年前人们想象的走得更远。

15. 合适的团队胜过一切。

拥有一个只想一起工作并建设伟大事物的团队使许多其他问题变得更容易应对。这里的“合适”是非常主观和情境的，但至少从经验上说，同情、尊重和友情是我所参与的伟大团队中反复出现的元素。

16. 坚持使用乏味的技术，除非有充分的理由不这么做。

乏味的技术往往是旧的和被更好地理解的技术。关于如何有效地使用它，有经过严格考验的经验，对其故障模式有更好的理解，而且更容易找到关于如何最好地应用它的人和资源。我非常喜欢丹·麦金利的创新代币的想法。你只有3个。用它们来采用或构建全新的东西-理想情况下是能让你在核心竞争力上变得更好的东西-但是超过3个就会增加永远无法达到稳定/成熟的风险。

17. 尽量保持团队规模最小，但不要过小。小心地发展它。

这是一个众所周知的引用的变体，每个人的体验可能会有所不同。在我到目前为止的职业生涯中，我可靠地看到，较小的团队比较大的团队更为有效。当然，需要找到一个平衡，这取决于你要解决的问题的大小和复杂性。话虽如此，小团队受益于较少的沟通开销，较少的沟通失误的空间，以及每个人的声音都能被听到的更多空间。在一个较小的团队中，它也感觉更加亲密，我觉得更有责任心，我喜欢这种感觉。

18. 休息。

我很高兴看到“全天候工作才能成功”的态度逐渐去性别化，更多的关注放在心理健康和幸福上。当你感到疲惫时很难感到快乐，而当你不快乐时更难以发挥最佳水平。为了能够最好地工作，我们必须花时间不工作。我喜欢把休息看作是我工作能力的关键部分，就像对身体锻炼的重视一样。

19. 在你想到至少一个其他方案之前，不要选择一个解决方案。

当你的脑海中出现某种想法，并且你意识到找到了解决问题的方法时，这是非常吸引和令人兴奋的。也许对于一个微不足道的问题来说，这是很酷的，而且真的没有更多的事情要做。然而，如果问题不是微不足道或重要的，那么值得考虑的是，可能还有其他你还没想到的解决方案。

为了避免在从没有解决方案到有一个解决方案的兴奋中沉浸，以及简单地选择第一个进入你脑海的想法，尝试至少再想一个。寻找第二种解决方案通常会迫使你换种思考方式，一旦你有了两个，你将被迫考虑权衡以选择一个。这样的对比权衡往往也可以帮助更清晰地定义问题。

20. 有观点，但避免以使他人认为你不会改变它们的方式来表达它们。

表达我们的信仰和观点是很重要的，我们都应该有这样做的空间。然而，在分享观点与听起来像分享一个不可动摇的事实之间有一条很细的界线。在一个团队中，每个人都能够挑战一个观点并有可能改变它，或者他们自己的观点，这是非常健康的。

我收到的一个很好的建议是，表达你的信念，并告诉你有多么确定。"我有95%的把握认为使用Visual Basic是个坏主意。"即使是95%，这既是一个开放的机会让别人质疑这个信仰并开始对话，也是一个机会让你在了解到新的信息时简单地修正你的确定性。

21. 说“我不知道”或“我需要研究一下才能回答”是可以的。

老实说，我们中的没有人知道我们在做什么。你知道？好吧，我不知道。我们的行业发展迅速，虽然有很多旧的东西，但也有很多新的东西。我们每天都在学习，没有答案是完全可以的。我们的价值不在于知道一切，而在于学习、发现、回答这些问题并提出新的问题。

当有人告诉我“我不知道”时，我很兴奋，因为现在我知道我们可以一起探索这个问题并都学到一些东西。不要隐藏它，好像你是唯一不知道的人。往往没人知道，但你的诚实使每个人都能公开参与并共同努力。

22. 为了探索问题而编写的可抛弃代码是被低估的。

完全错误地尝试几次并重新开始可能比第一次就尝试做对要快。有时，探索问题的最佳方法是在其附近尝试并尽可能多地学习。

也许你还不真正了解问题，但通过尝试几种方法，你可以发现高层次的设计讨论或读文档完全会错过的东西。在最后可以随意犯错并全部抛弃的自由下，你可以非常快速地学习。

23. 小心管理状态。

每个程序都有状态，但如何管理这种状态可能会产生天壤之别。状态管理不善是系统复杂性的一个巨大贡献因素，通常是因为在问题变得更加严重之前没有足够早地思考它。

有很多不同的策略可以帮助，从在给定环境中处理状态的特定方法，到使用函数语言和/或方法来围绕状态如何改变创建更严格的约束。无论你做什么，都要有意识地决定你的系统中的状态如何变化。

24. 都是关于权衡的。

在你做的几乎每一个决定中，你要么有意识地、要么无意识地权衡一个东西和另一个东西。有时权衡是明显的，但有时它们离我们面前的事物有几层。如果权衡不是立即明显的，总是要考虑它们可能在哪里。

一个很好的例子是Go语言。Go有一个相对较差的类型系统（目前），而且是一个小语言。权衡在哪里？由于其大小和对花哨支持的限制，我的代码看起来像你的代码，我读其他人的代码时少了“哇，我需要尽快重写这个”的感觉，我感觉更有生产力。总会在某个地方有一个权衡。寻找它，你就会处于做出更好决策的位置。

25. 一个好的设计是，在不改变太多代码的情况下你可以改变主意的设计。

正如公理1所述，变化是常态。这意味着为了成功，我们需要很好地处理变化的情况——不仅仅是发生在我们周围并带我们一起变化的外部变化，还有来自转变、新功能、扩展挑战等的内部变化。

一个好的系统设计应尽可能地适应我们改变解决问题方法的需求，而不是强迫我们从头开始。换句话说，我们必须更改或删除的部分越少（根据公理4，这应该很容易），我们在变化面前移动得越快；设计越好。