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

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

墨菲定律

“凡是可能出错，就必定出错。”

这条定律来源于 Edward Murphy —— 一名航天工程师在 50 年代初对火箭测试失败的回应。这条定律给咱们的启示是永远在系统关键地方使用防护性设计，由于系统某些地方总会出错!

这条定律很容易引入软件工程领域。当你将软件暴露给终端用户，他们会创造性地输入一些出人意料的内容，使系统宕机。因此你须要让你的软件足够健壮，可以检测并警告非预期行为。

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

我曾经有机会领略过几回墨菲定律。 举个例子，我曾经在一个批处理框架中使用字符串“null”来表示空值，我并不认为这有问题，直到有个名字叫“Null”的用户提交了一个交易订单，咱们的报表流程中断了几个小时…… 还有一次，在另外一个项目中。当全部东西都准备好部署到生产环境了，忽然 Azure 基础设施故障致使咱们运行自动化脚本的服务器宕机了。

现实世界中的经验教训提醒着我生活的艰难 —— “凡事可能出错，就必定出错”。 因此，心中牢记墨菲定律，设计健壮的软件。

Knuth 定律

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

这条定律是高德纳(Donald Knuth) 的经典语录之一，它告诫咱们不要过早优化应用程序中的代码，直到必须优化时再优化。

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

垃圾自动回收的编程语言中，字符串的链接经常是过早优化的例子。在 Java 或 C# 中，String 对象是不可变的，咱们学会使用其余结构动态建立字符串，好比 StringBuilder。但事实上直到你分析完个应用程序前，你并不知道 String 对象建立了多少次并对性能的产生多大影响。因此首先编写尽量整洁的代码，以后在必须的时候再优化，每每这样作更有意义。

然而，这条规则并不该该阻止你去学习编程语言的性能权衡和正确的数据结构。而且，正如全部其余性能问题，你在优化前要测量开销。

North 定律

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

好吧，我认可这是取自 Dan North 的演讲 Decisions,Decisions，它目前还不是公认的定律。 但这条语录影响了我作的每一个决定，因此我把它放在这。

开发者日复一日的生活中，咱们天天都作无数个大大小小的决定。从命名变量到自动化(手动)任务，再到定义平台架构。

这条语录强调不管你作的选择是什么，你总会放弃一个或多个选项

但这不是最重要的。 最重要的是理智地作出决定，了解其余选项，清楚你为何不选择它们。你要始终根据当前你掌握的信息来权衡并作出决定。

可是若是后来你了解到新的信息，并发现以前的决定是错误的，这也不要紧。关键是记清楚你为何作出那个决定，从新评估新的选项以后再作出新的理智的决定。

重复一遍

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

因此，作出选择并对全部选项心知肚明。

Conway 定律

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

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

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

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

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

现在，将大的集成应用解耦成微服务已成趋势。这很棒，由于这能够加速交付使用项目。但你也应该牢记 Conway定律，在公司组织构建中投入与技术开发一样多的工做。

琐碎定律(帕金森琐碎定律)

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

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

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

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

这条定律在软件行业十分出名，这个故事随后也被称为车棚效应

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

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

一旦你了解这种规律，你将在会议和交流中发觉这种行为。 我并非让你在每次讨论中避免“小”问题，提升你的意识能够帮助你关注真正的问题，并为这些会议作好准备。

结论

这五条定律只是咱们行业中总结出的教训中一些例子。随着软件开发经验的增加，咱们将会学会更多。 尽管其中某些定律如今看起来是常识，我始终坚信了解这些原则能够帮助你识别这些模式并作出反应。

 

原文链接：http://click.aliyun.com/m/34021/