这是来自radicalsimpli.city的技术极简主义宣言，对当前复杂技术的抱怨、批判。
我们好像很享受复杂性：我们使用 SPA、Vue/React、Transpiling、Typescript、Babel、Webpack、PureCSS、GraphQL、JSON 以及在后端使用微服务、protobuf、Kafka、InfluxDB 或 NoSQL 数据库创建复杂性。
这种复杂性是偶然的，而不是在业务问题域中。
这种复杂性导致需要一个解决方案来管理它——通常是 Kubernetes。
你需要运行这些东西，而且有很多微服务，你需要很多机器。这导致了 AWS。
这又带来了它自己的复杂性。
现在我们需要编写 React 应用程序的前端工程师，编写 REST 和 GraphQL 端点的后端工程师，以及手握 Kubernetes 的运维工程师。这导致使用模拟和本地数据库、Docker 映像和构建管道进行复杂的测试设置，运行需要数十分钟。
做一件简单的事情需要很多时间，比如向表单添加一个字段 - 例如向个人资料添加生日字段。需要几分钟的事情现在需要几个小时。然后事情发生了变化，你会花一整天的时间让你的微服务能再次运行： 在其他服务之上巧妙地平衡每个服务和每个框架和工具的每个版本。
开发人员能做的最后一件事就是编写业务逻辑。如果您查看自己在做什么并计算行数，那么最少的时间就是编写真正的业务逻辑，即代码中的 IF。
但是这涉及到带有 SQL 的数据库到对象到 JSON 的序列化，通过路由到 React 存储到 UI。GraphQL、SQL、Javascript 对象和 Python 对象中的数据定义。当您需要花费大量时间围绕框架、技术堆栈和序列化进行举办仪式时，留给处理业务逻辑的时间并不多。
我们为什么要构建复杂的系统和架构？因为我们想要接受挑战，而对业务领域却涉及不深入！所以开发人员自己就发明新的框架和系统来构建自己的挑战。他们想要尝试新事物。
出现的问题是多方面的。正如雷切尔·克罗尔( Rachel Kroll)所写： “代码运行在人身上。请保持简单。” 组件和系统也是如此。在代码在计算机上运行之前，它需要在您的头脑中运行。
“如果花一个小时来弄清楚发生了什么，那么，这一个小时就没有花在做其他更有用和有趣的事情上。”
最重要的是，技术将大量时间用于自身而不是提供商业价值。管理这么多系统和组件需要知识，而且由于存在边缘情况，因此存在许多错误。这些因素结合在一起会导致效率低下、开发人员过多和成本高。
极简主义Radical Simplicity来了
什么是极端简单Radical Simplicity？极简意味着拥有尽可能少的组件和活动部件。将技术重复用于不同的目的，而不是为每个目的使用新的移动部件。与其使用 Postgres 作为数据库、Druid 作为事件存储、Redis 作为缓存、Rabbit MQ 作为消息队列和 Elastic 作为全文搜索，不如使用托管 Postgres 作为数据库，用于全文搜索、html 缓存、发布/订阅和带有 TimescaleDB 的事件存储。
这使我们能够拥有更深入的知识、更快的行动、更快的新开发人员入职、更少的故障、数十个框架和组件的升级计划，以及更多的开发人员幸福感。开发的核心是进入流程。开发人员在流程内部比在流程外部更有效率。
Basecamp 是 Rails 的创造者，它做的是 Radical Simplicity。Basecamp 使用 HTML 编写了他们的 Hey 电子邮件应用程序，没有使用 React。Stack Overflow 通过使用少量真实硬件运行他们的服务来实现这一点。具有讽刺意味的是，所有 AWS 问题都由运行在真实硬件上的 Microsoft SQL Server 回答。没有 GraphQL，没有 React，没有 Kafka，没有 Webpack，也没有 Kubernetes。
您也可以使用 Radical Simplicity。激进的简单也是激进的。一个基于HTML的单体应用：在浏览器端使用 Hotwire Turbo 以最少的 Javascript 刷新；仅使用托管 Postgres 作为数据存储、JSON、作业处理、消息队列的数据库，并使用列式存储作为数据湖和数据仓库。如果您无法抗拒，请添加 Redis 进行缓存，因为 Redis 永远不会中断。
许多只有少数客户的初创公司拥有多个微服务、Redis、Postgres、Elastic、Kubernetes、Webpack、JavaScript SPA、REST API、带有 Apollo 和 Kafka 的 GraphQL 或用于消息队列或作业服务器的 RabbitMQ。
如果将此与仅使用托管 Postgres（而不是 PG、Redis 和 Elastic）、Unpoly的激进简单设置进行比较，极简主义是在整体式服务器上呈现渲染HTML，并使用BigQuery分析数据仓库 。
后者一个小得多的架构设置，实现相同但需要维护、学习和调试的移动部件少得多。需要监控的组件要少得多。
当某些公司拥有 50 多名开发人员和数百万用户时，才需要复杂的设置；大多数公司，尤其是刚成立的公司，需要那种复杂的设置吗？不！