大多数软件工程师，尤其是从事基础设施系统工作的工程师，都将不可避免地陷入不必要的复杂性，究其原因主要是本文所讨论的三条基本定律所致原文链接：https://maheshba.bitbucket.io/blog/2024/05/08/2024-ThreeLaws.html未经允许，禁止转载
作者 | Mahesh Balakrishnan 责编 | 夏萌第一定律：随着时间的推移设计良好的系统必然会退化为设计不良的系统首先，我们给出一个主观的定义：设计良好的系统指的是在一段时间内易于修改的系统；而设计不良的系统指的是很难修改的系统假设X是一款设计良好的系统有人想要修改X，根据定义，这项工作应该能够快速且轻松地完成，假设修改后的系统为X'接下来，X'的发展有两种可能性：第一，继续保持设计良好，即再次快速且轻松地修改为另一个系统X''；第二，变成设计不良的状态，即很难修改举个例子，假设有一个设计良好的数据库使用了RocksDB，并拥有整洁的存储引擎API此时，有人添加了一个getLevelSize调用，于是这个数据库就很难再轻松地变成非LSM存储引擎因此，对于系统来说，设计良好只是不稳定且短暂的状态；而设计不良则是稳定且持久的状态因此，在现实中，各个系统会不断退化为设计不良的状态代码的二阶导数总是负数：代码的变化速度会随着时间的推移而下降根据这一定律，大多数系统都会随着时间的推移而变成设计不良的系统，因此大多数工程师从事开发的也是设计不良的系统第二定律：复杂性是一道护城河（充斥着漏洞百出的抽象）设计一个良好的抽象需要应用程序在提供实用性与隐藏实现细节之间取得微妙的平衡当各个系统为了市场份额而相互竞争时，这种微妙的平衡就会被打破，设计者通常会选择提供应用程序所需的一切这种选择带来的影响有利有弊：通过吸引应用程序开发者来增加市场份额；同时各个竞争系统很难替换不同的实现纵观全球，一些取得了巨大成功的系统API都面临一个问题：几乎无法以任何其他方式实现，例如ZooKeeper介于顺序和线性化之间的一致性，基于TCP/IP的临时节点语义，以及Kafka的幂等性生产语义根据这一定律，大多数成功或流行的系统都是设计不良的系统，因此大多数工程师从事开发的也是设计不良的系统第三定律：软件复杂性没有基本上限在现实世界中，由大型团队经长年累月构建的系统，其复杂性仅受限于人类的创造力最终的系统由开发人员的能力、理念和个人癖好决定，每个人都身处复杂的激励机制中举个例子，为什么有些副本数据库使用自己的Gossip层来检测故障，而不是依赖Kubernetes？可能是因为技术负责人A和开发人员B同意使用Gossip来进行故障检测，但在B编写完代码后，A意识到容器化的环境并不适合，但经理C已经批准了B的升职加薪，于是A在办公室政治的压力下被迫妥协或者，这个系统如此设计，是因为B认为非容器化的环境是一个很好的选择又或者，B的博士论文讨论的就是基于Gossip的协议这些原因都有可能导致系统出现一些“有趣的”交互每个现有系统可能都包含若干你一无所知的DoS攻击，就像一个充满复杂性定时炸弹的宫殿，而这些炸弹都是在你进入项目多年之前埋下的根据这一定律，设计不良的系统具有无限的复杂性，而工程师在这些系统上工作时会特别痛苦那么，我们应该如何应对这种状况呢？在我的职业生涯中，我采用了一种特别的方法，那就是从头开始构建新系统，尽管这种方法的难度非常大
由 CSDN 和 Boolan 联合主办的「2024 全球软件研发技术大会（SDCon）」将于 7 月 4 -5 日在北京威斯汀酒店举行由世界著名软件架构大师、云原生和微服务领域技术先驱 Chris Richardson 和 MIT 计算机与 AI 实验室(CSAIL)副主任，ACM Fellow Daniel Jackson 领衔，BAT、微软、字节跳动、小米等技术专家将齐聚一堂，共同探讨软件开发的最前沿趋势与技术实践
0 评论