（给
伯乐在线
加星标，看经典文章
）
编译：伯乐在线/孙腾浩
定律或称法则，可以指导我们并让我们在同伴的错误中学习。这篇文章中，我将介绍我每次设计或实现软件时出现在我脑海的五大定律。其中有些和开发有关，有些和系统组织有关。它们可以帮助你成为合格的软件工程师。
墨菲定律
“凡事可能出错，就一定出错。”
这条定律来源于 Edward Murphy —— 一名航天工程师在 50 年代初对火箭测试失败的回应。这条定律给我们的启示是永远在系统关键地方使用防御性设计，因为系统某些地方总会出错！
这条定律很容易引入软件工程领域。当你将软件暴露给终端用户，他们会创造性地输入一些出人意料的内容，使系统宕机。所以你需要让你的软件足够健壮，能够检测并警告非预期行为。
当你在机器上运行软件时，任何地方都有可能发生问题 —— 从硬盘上的系统到数据中心的电力供应。所以你必须确保你设计的架构在每个层级都可以应对故障。
我曾经有机会领略过几次墨菲定律。举个例子，我曾经在一个批处理框架中使用字符串“null”来表示空值，我并不认为这有问题，直到有个名字叫“Null”的用户提交了一个交易订单，我们的报表流程中断了几个小时…… 还有一次，在另一个项目中。当所有东西都准备好部署到生产环境了，突然 Azure 基础设施故障导致我们运行自动化脚本的服务器宕机了。
现实世界中的经验教训提醒着我生活的艰难 —— “凡事可能出错，就一定出错”。所以，心中牢记墨菲定律，设计健壮的软件。
Knuth定律
“在（至少大部分）编程中，过早优化是万恶之源。”
这条定律也是 Donald Knuth 的经典语录之一，它告诫我们不要过早优化应用程序中的代码，直到必须优化时再优化。
的确，简单易读的源码可以满足 99% 的性能需要，并能提高应用的可维护性。最开始使用简单的解决方案也让后期性能出现问题时更容易迭代和改进。
垃圾自动回收的编程语言中，字符串的连接常常是过早优化的例子。在 Java 或 C# 中，String 对象是不可变的，我们学会使用其他结构动态创建字符串，比如 StringBuilder。但事实上直到你分析完个应用程序前，你并不知道 String 对象创建了多少次并对性能的产生多大影响。所以首先编写尽可能整洁的代码，之后在必须的时候再优化，往往这样做更有意义。
然而，这条规则并不应该阻止你去学习编程语言的性能权衡和正确的数据结构。并且，正如所有其他性能问题，你在优化前要测量开销。
North定律
“每一个决定都是一次权衡”
好吧，我承认这是取自 Dan North 的演讲 Decisions,Decisions，它目前还不是公认的定律。但这条语录影响了我做的每个决定，所以我把它放在这。
开发者日复一日的生活中，我们每天都做无数个大大小小的决定。从命名变量到自动化（手动）任务，再到定义平台架构。
这条语录强调无论你做的选择是什么，你总会放弃一个或多个选项
但这不是最重要的。最重要的是理智地做出决定，了解其他选项，清楚你为什么不选择它们。你要始终根据当前你掌握的信息来权衡并做出决定。
但是如果后来你了解到新的信息，并发现之前的决定是错误的，这也没关系。关键是记清楚你为什么做出那个决定，重新评估新的选项之后再做出新的理智的决定。
重复一遍
“每一个决定都是一次权衡”
所以，做出选择并对所有选项心知肚明。
Conway定律
“系统设计的架构受限于生产设计，反映出公司组织的沟通架构”
