法则——或者说法则——可以指导我们，让我们从同行的错误中吸取教训。在本文中，我将介绍每次设计或实现软件时脑海中浮现的五项法则。其中一些与开发有关，一些与系统组织有关。他们可以帮助你成为一名合格的软件工程师。墨菲定律“可能出错的事，一定会出错。”这条定律来自爱德华·墨菲——一位航空航天工程师在50年代初期对火箭试验失败的反应。这个规律的启示就是在系统的关键部分永远采用防御性设计，因为系统的某些部分总是会出错！该定律可以很容易地引入软件工程领域。当您向最终用户公开软件时，他们会发挥创意并输入意想不到的内容，这会使系统崩溃。因此，您需要让您的软件足够健壮，以检测和警告意外行为。当您在机器上运行软件时，问题可能发生在任何地方——从硬盘上的系统到数据中心的电源。因此，您必须确保设计的架构能够处理每个级别的故障。我有机会体验墨菲定律几次。例如，我曾经在批处理框架中使用字符串“null”来表示空值。直到一个叫“Null”的用户提交了一个交易订单，我才觉得这是个问题，我们的报告流中断了几个小时……还有一次，在另一个项目上。当一切都准备好部署到生产环境时，突然的Azure基础设施故障导致我们运行自动化脚本的服务器宕机。现实世界的教训让我想起了生活的艰辛——“任何可能出错的事情，都会出错”。因此，在设计稳健的软件时要牢记墨菲定律。Knuth定律“在（至少大部分）编程中，过早的优化是万恶之源。”DonaldKnuth的经典名言之一，这条法则警告我们不要过早地优化我们应用程序中的代码，直到有必要进行优化。的确，简单易读的源代码可以满足99%的性能需求，并且可以提高应用程序的可维护性。从一个简单的解决方案开始，还可以在以后出现性能问题时更轻松地进行迭代和改进。字符串连接通常是垃圾收集编程语言中过早优化的一个例子。在Java或C#中，String对象是不可变的，我们学习使用其他结构动态创建字符串，例如StringBuilder。但实际上，直到你分析一个应用程序，你才知道String对象被创建了多少次，它对性能的影响有多大。因此，首先编写尽可能干净的代码，然后在必要时进行优化通常更有意义。但是，这条规则不应阻止您学习编程语言性能权衡和正确的数据结构。而且，像所有其他性能问题一样，您在优化之前测量开销。诺斯定律“每一个决定都是一种权衡”好吧，我承认这是取自丹·诺斯的演讲Decisions,Decisions，它还不是公认的法律。但是这句话会影响我做出的每一个决定，所以我把它放在这里。在开发人员的日常生活中，我们每天都会做出无数大大小小的决定。从命名变量到自动化（手动）任务，再到定义平台架构。这句话强调，无论你做出什么选择，你总会放弃一个或多个选择，但这不是最重要的。最重要的是做出明智的决定，了解其他选项，并了解您不选择它们的原因。你总是根据你目前拥有的信息权衡和做出决定。但如果后来你了解到新的信息并意识到之前的决定是错误的，那也没关系。关键是要记住你为什么做出那个决定，重新评估新的选择，然后做出新的理性决定。重复“每一个决定都是一种权衡”所以做出选择并了解所有选择。康威定律“系统设计的架构受生产设计的限制，反映了公司组织的通信架构”60年代，一位名叫MelvinConway的工程师注意到公司的组织影响了他们开发的系统的设计.他在一篇名为“康威定律”的论文中描述了这个想法。这个规律非常适用于软件开发领域，甚至体现在代码层面。交付软件组件的各个团队的组织结构直接影响组件的设计。例如，一个集中的开发团队将开发一个组件耦合的单体应用程序。另一方面，分布式团队开发单独的（微）服务，每个服务都有明确的关注点分离。这些设计都没有好坏之分，但它们都受到团队沟通方式的影响。在世界范围内拥有大量独立开发人员的开源项目，通常是模块化和可重用的库，都是令人信服的例子。如今，将大型集成应用程序解耦为微服务已成为一种趋势。这很棒，因为它加快了项目的交付。但是你也应该牢记康威定律，并在公司的组织上投入与技术开发一样多的工作。琐碎法则（Parkinson'sTrivialLaw）“组织成员将大量精力投入到琐碎的事情上。”这个定律的论点是，开会的时间与事物的价值成反比。的确，人们更愿意关注和看待他们熟悉的事物，而不是复杂的问题。帕金森举了一个会议的例子，成员们讨论了两件事：为公司建造核反应堆和为员工建造车棚。建造反应堆是一项庞大而复杂的工作，没有人能完全控制它。他们完全信任流程和系统专家，并迅速接受了该项目。另一方面，搭建车棚是一般人都能做的事情，每个人都可以对颜色有意见。事实上，会议的每个成员都会表达自己的意见，因此建造车棚的决定比建造反应堆的决定要花费更长的时间。这条定律在软件行业广为人知，这个故事从此被称为车棚效应。例如，开发人员花更多时间讨论正确的缩进或函数命名，而不是讨论类职责或应用程序架构。这是因为每个人都认识到一些字符变化，但项目架构变化需要巨大的认知负荷。您可以注意到的另一个车棚效应示例是Scrum演示。不要误会我的意思，我喜欢演示，我认为这是面对用户并获得应用程序反馈的好机会。但Scrum演示期间的讨论通常会转向琐碎的问题，而不是着眼于大局。这些讨论也很重要，但你应该注意权衡更重要和更复杂的问题。一旦理解了这种模式，您就会在会议和交流中注意到这种行为。我并不是要你在每次讨论中避免“小”问题，提高你的意识可以帮助你专注于真正的问题并为这些会议做准备。结论这五项法律只是我们行业经验教训的几个例子。随着我们的软件开发经验的增长，我们将学到更多。尽管其中一些规律现在看来似乎是常识，但我始终相信理解这些原则可以帮助您识别并应对这些模式。
