本文列举了一些可以应用于软件开发的最流行的规则和原则。对于每条定律，我们将快速讨论其主要命题，然后探讨如何将其应用于软件开发。 帕累托原则（80/20 规则）帕累托原则指出，通常80% 的结果来自 2.

2010 年代是软件工程史上的一个转折点。在本世纪初，Eric Ries 通过The Lean Startup(精益创新)颠覆了构建数字产品的传统方法。在这十年末，Matthew Skelton 和 .

新型产品技术团队模型简述： 没有孤岛，团队专注于了解客户的问题和市场挑战（环境），并由此发现和塑造他们应该如何构建和发展他们的产品（技术系统）。（他们显然在业务/公司使命和目标之间取得了平衡）。 这并.

是业务决定技术？还是技术决定业务？是人决定IT，还是IT决定人？这是康威定律与敏捷的区别：一位叫Melvin Conway学者进行了社会学观察：组织中IT 解决方案的结构遵循组织结构。弗雷德里克·布鲁.

随着时间的推移，不同的人以各种不同的方式阐明了康威定律。这是我最近在阅读康威定律文献时发现的变化的概述。Melvin Conway对康威定律的原始定义：设计系统的组织被限制生产设计，这些设计是这些组织.

假设有一个农业机械零件的批发商。他们建立了一个 B2B 网上商店，供经销商和机器维修公司订购。在他们无处不在的统一语言与术语中，订单代表了这个自动化流程：它使客户能够挑选产品，应用正确的折扣，并将其推.

领域驱动设计的主流思想是关于实体、值对象、聚合、存储库、服务、工厂……各种技术模式。因此，大多数人认为他们不需要领域驱动设计，因为这对他们的领域来说很复杂。为什么你需要所有这些“东西”？好吧，也许你不.

当前人们对大脑自身的认识深入促进人工智能和认知科学等方面发展，仿真人类的大脑思考模型称为启发很多创新方法研究的源泉，例如人其实是神经元交互聚合的产物，人类群体是否可视为神经元集合的延伸？如何借鉴神经元.

当您公司的整体Web应用变得太大而脆弱时，部署变得缓慢而令人恐惧。因此，作为一家软件公司，您已决定遵循许多其他公司所采用的方法——将这个整体/单体架构拆分为微服务架构。这个迁移旅程可能漫长而艰难，潜伏.

很多团队没有专职的架构师，但是实际上有一些角色参与了架构决策，根据康威定理，组织架构决定了技术架构，如果管理者确定了系统的体系结构，那么他们实际上就是其架构师。如果程序员确定了体系结构决策，则实际上是.

Uber核心平台技术最初押宝Thrift和Mesos，这种两种技术后来分别被gRPC和Kubernetes主流技术替代。当初您做出技术路线决策的上下文已经时非今日可比，问题：技术决策的上下文半衰期是多.

1.康威定律也称为：“您将承载组织结构。 ”“任何设计系统的组织都将产生其结构是组织通信结构副本的设计。”您可能认为可以通过跨职能的站立会议、利益相关者更新和决策矩阵来避免这种情况，但是最终且不可避免.