首页>>技术前沿>>网站/软件行业动态
墨菲定律：“凡事可能出错，就一定出错。”
这条定律来源于 Edward Murphy —— 一名航天工程师在 50 年代初对火箭测试失败的回应。这条定律给我们的启示是永远在系统关键地方使用防御性设计，因为系统某些地方总会出错！
这条定律很容易引入软件工程领域。当你将软件暴露给终端用户，他们会创造性地输入一些出人意料的内容，使系统宕机。所以你需要让你的软件足够健壮，能够检测并警告非预期行为。
当你在机器上运行软件时，任何地方都有可能发生问题 —— 从硬盘上的系统到数据中心的电力供应。
Knuth定律 ： “在（至少大部分）编程中，过早优化是万恶之源。”
这条定律也是 Donald Knuth 的经典语录之一，它告诫我们不要过早优化应用程序中的代码，直到必须优化时再优化。
的确，简单易读的源码可以满足 99% 的性能需要，并能提高应用的可维护性。最开始使用简单的解决方案也让后期性能出现问题时更容易迭代和改进。
垃圾自动回收的编程语言中，字符串的连接常常是过早优化的例子。在 Java 或 C# 中，String 对象是不可变的，我们学会使用其他结构动态创建字符串，比如 StringBuilder。但事实上直到你分析完个应用程序前，你并不知道 String 对象创建了多少次并对性能的产
生多大影响。所以首先编写尽可能整洁的代码，之后在必须的时候再优化，往往这样做更有意义。
North定律：“每一个决定都是一次权衡”
开发者日复一日的生活中，我们每天都做无数个大大小小的决定。从命名变量到自动化（手动）任务，再到定义平台架构。
这条语录强调无论你做的选择是什么，你总会放弃一个或多个选项
但这不是最重要的。 最重要的是理智地做出决定，了解其他选项，清楚你为什么不选择它们。你要始终根据当前你掌握的信息来权衡并做出决定。
但是如果后来你了解到新的信息，并发现之前的决定是错误的，这也没关系。关键是记清楚你为什么做出那个决定，重新评估新的选项之后再做出新的理智的决定。重复一遍，每一个决定都是一次权衡，所以做出选择并对所有选项心知肚明。
Conway定律： “系统设计的架构受限于生产设计，反映出公司组织的沟通架构”
在 60 年代，一位名叫 Melvin Conway 的工程师注意到公司组织结构影响到他们开发的系统的设计。他用一篇论文描述了这个观点，并命名为“Conway定律”。
这条定律很适用于软件开发领域，甚至体现到代码层面上。交付软件组件的各个团队组织结构直接影响到组件的设计。
举个例子，一个集中式的开发者团队会开发出各组件耦合的整体应用。另一方面，分布式的团队会开发出单独的（微）服务，每一部分关注点分离清晰。
这些设计没有好坏之分，但它们都是受到团队沟通方式的影响。在全球有大量独立开发者的开源项目，通常是模块化和可重用库，这就是很有说服力的例子。
如今，将大的集成应用解耦成微服务已成趋势。这很棒，因为这可以加速交付使用项目。但你也应该牢记 Conway 定律，在公司组织构建中投入与技术开发同样多的工作。
琐碎定律（帕金森琐碎定律）：“组织成员投入大量精力到琐碎的事情上。”
这条定律论点是在会议中花费的时间与事情的价值成反比。的确是这样，人们更愿意把注意力和观点放在他们熟悉的事物上，而不是复杂的问题上。
帕金森给出一个例子，一场会议中，成员们讨论两件事：为公司建核反应堆和为员工建车棚。建反应堆是一件巨大而复杂的任务，没有人能完全掌控全局。他们完全信赖流程和系统专家，并很快接受了项目。
另一边，建车棚是一般人都可以做的，每个人都可以对颜色有意见。事实上，每个会议成员都会表达自己的意见，使得建车棚的决议所花费的时间远远超过建反应堆的。
这条定律在软件行业十分出名，这个故事随后也被称为车棚效应
举个例子，开发者会花费更多时间到讨论正确缩进或函数命名，而不是讨论类的职责或应用架构。这是因为每个人都能认知几个字符的变动，但项目架构的变动则需要巨大的认知负载
其实，不论是做程序还是生活，这五条定律总能让我们受益匪浅。
【全文完】
版权声明:
1、陕西弈聪网站内容中凡注明“来源：XXX（非陕西弈聪网站）”的作品，转载自其它媒体，转载目的在于传递更多信息，其中涉及的网站建设，网站优化，百度关键词优化，西安软件开发等技术细节并不代表本站赞同支持其观点，并不对其真实性负责。对于署名“陕西弈聪”的作品系本站版权所有，任何人转载请署名来源，否则陕西弈聪将追究其相关法律责任。
2、本站内容中未声明为“原创”的内容可能源自其它网站，但并不代表本站支持其观点，对此带来的法律纠纷及其它责任与我方无关。如果此内容侵犯了您的权益，请联系我方进行删除。
企业动态
