每个程序员都该知道的五大定律

定律 - 或称法则，可以指导我们并让我们在同伴的错误中学习。这篇文章中，我将介绍我每次设计或实现软件时出现在我脑海的五大定律。其中有些和开发有关，有些和系统组织有关。它们可以帮助你成为合格的软件工程师。

墨菲定律

“

“凡事可能出错，就一定出错”

”

“墨菲定律” 是一种心理学效应，是由爱德华 · 墨菲（Edward A. Murphy）提出的。他的主要内容是：（1）任何事都没有表面看起来那么简单；（2）所有的事都会比你预计的时间长；（3）会出错的事总会出错；（4）如果你担心某种情况发生，那么它就更有可能发生。

墨菲定律根本内容是：如果事情有变坏的可能，不管这种可能性有多小，它总会发生。即 “凡事可能出错，就一定出错。” 而墨菲定律很容易引入软件工程领域。例如：

当你将软件暴露给终端用户，他们会创造性地输入一些出人意料的内容，使系统宕机。所以你需要让你的软件足够健壮，能够检测并警告非预期行为；

当你在机器上运行软件时，任何地方都有可能发生问题 —— 从硬盘上的系统到数据中心的电力供应。所以你必须确保你设计的架构在每个层级都可以应对故障。

在举个具体的例子，我曾经在一个批处理框架中使用字符串 “null” 来表示空值，我并不认为这有问题，直到有个名字叫 “Null” 的用户提交了一个交易订单，我们的报表流程中断了几个小时…… 还有一次，在另一个项目中。当所有东西都准备好部署到生产环境了，突然 Azure 基础设施故障导致我们运行自动化脚本的服务器宕机了。这些正是 “凡事可能出错，就一定出错” 的最好体现。

Knuth 定律

“

在 (至少大部分) 编程中，过早优化是万恶之源

”

“现代计算机科学的鼻祖”Donald Knuth 曾说过 “在 (至少大部分) 编程中，过早优化是万恶之源”。这条定律是高德纳 (Donald Knuth) 的经典语录之一，它告诫我们不要过早优化应用程序中的代码，直到必须优化时再优化。因为：让正确的程序更快，要比让快速的程序正确容易得多。

的确，简单易读的源码可以满足 99% 的性能需要，并能提高应用的可维护性。最开始使用简单的解决方案也让后期性能出现问题时更容易迭代和改进。

在项目开发中，总是有程序员浪费宝贵的时间去改进那些不需要改进的代码，而没有通过所做的改进增加价值。在对项目进行优化时，究竟哪些地方应该优化，应该如何优化，哪些不应该优化呢？你需要先来了解一下这 7 件事。 究竟要优化什么？究竟要优化什么？优化在刀刃上；优化层次越高越好； 不要过早优化； 依赖性能分析，而不是直觉；优化不是万金油，这样优化往往更有意义。

过早优化是万恶之源

North 定律

“

“每一个决定都是一次权衡”

”

严格的说它目前还不是公认的定律，这是取自 Dan North 的演讲 “Decisions”,Decisions 这条语录强调无论你做的选择是什么，你总会放弃一个或多个选项，但这不是最重要的。最重要的是理智地做出决定，了解其他选项，清楚你为什么不选择它们。开发者日复一日的生活中，我们每天都做无数个大大小小的决定。从命名变量到自动化（手动）任务，再到定义平台架构，你要始终根据当前你掌握的信息来权衡并做出决定，记清楚你为什么做出那个决定，重新评估新的选项之后再做出新的理智的决定。

Conway 定律

“

“系统设计的架构受限于生产设计，反映出公司组织的沟通架构”

”

在 60 年代，一位名叫 Melvin Conway 的工程师注意到公司组织结构影响到他们开发的系统的设计。他用一篇论文描述了这个观点，并命名为 “Conway 定律”。

这条定律很适用于软件开发领域，甚至体现到代码层面上。交付软件组件的各个团队组织结构直接影响到组件的设计。

例如，一个集中式的开发者团队会开发出各组件耦合的整体应用。另一方面，分布式的团队会开发出单独的（微）服务，每一部分关注点分离清晰。

这些设计没有好坏之分，但它们都是受到团队沟通方式的影响。在全球有大量独立开发者的开源项目，通常是模块化和可重用库，这就是很有说服力的例子。

当前，将大的集成应用解耦成微服务已成趋势。这很棒，因为这可以加速交付使用项目。但你也应该牢记 Conway 定律，在公司组织构建中投入与技术开发同样多的工作。

琐碎定律

“

“组织成员投入大量精力到琐碎的事情上”

”

琐碎定律 (帕金森琐碎定律) 源于英国著名历史学家诺斯古德 · 帕金森 1958 年出版的《帕金森定律》一书中。帕金森琐碎定律是时间管理中的一个概念。帕金森定律表明：只要还有时间，工作就会不断扩展，直到用完所有的时间。

这条定律论点是在会议中花费的时间与事情的价值成反比。的确是这样，人们更愿意把注意力和观点放在他们熟悉的事物上，而不是复杂的问题上。

帕金森给出一个例子，一场会议中，成员们讨论两件事：为公司建核反应堆和为员工建车棚。建反应堆是一件巨大而复杂的任务，没有人能完全掌控全局。他们完全信赖流程和系统专家，并很快接受了项目。

另一边，建车棚是一般人都可以做的，每个人都可以对颜色有意见。事实上，每个会议成员都会表达自己的意见，使得建车棚的决议所花费的时间远远超过建反应堆的。

这条定律在软件行业十分出名

举个例子，开发者会花费更多时间到讨论正确缩进或函数命名，而不是讨论类的职责或应用架构。这是因为每个人都能认知几个字符的变动，但项目架构的变动则需要巨大的认知负载

你能注意到的车棚效应的另一个例子是 Scrum 演示。不要误会我，我喜欢演示，我认为这是一个很好的机会来面对用户并获得对应用程序的反馈。但通常 Scrum 演示过程中的讨论会转向琐碎问题，而不是审视全局。这些讨论也很重要，但你应该注意权衡更重要更复杂的问题。

随着软件开发经验的增长，我们将会学会更多。尽管其中某些定律现在看起来是常识，但是了解这些原则可以帮助你识别这些模式并做出反应。

如果想要高薪人生

请关注我

「蓝鸥教育 」 一个做IT行业 「定岗直招」的学校