软件应服务于业务，而不是相反。

Source: Dev.to

问题

我见过太多次这种情况：为业务尚未验证的问题构建了完美、可扩展的架构。结果呢？一个没人使用的技术杰作。

在创业世界里，代码在解决业务问题之前都是负债。

你的客户并不在乎你使用的是 Clean Architecture 还是混乱的单体架构。他们在乎的是按钮是否能正常工作并解决他们的痛点。

如果业务转向（它迟早会），你的代码需要足够灵活以跟随——而不是僵硬到阻碍转变。

我们常常为 100 万 用户构建，却只有 10 用户。这就是“软件主导业务”。

为什么业务应该领航

• 拥有“凌乱”代码但成功的业务，总好过拥有“完美”代码却失败的创业公司。
• 高级开发者的工作不仅是写函数，还要理解业务模型。如果你不知道公司如何赚钱，就无法为其编写有效的软件。
• 停止问“我们怎么实现这个？”而是先问“我们应该实现这个吗？”让业务目标驱动 git 提交。

关键要点

• 将软件开发与已验证的业务需求保持一致。
• 优先考虑灵活性，以适应业务转向。
• 注重为客户交付价值，而不是追求架构的纯粹性。

最初以更随意的本地语言（马来语）在我的博客中分享：Read the original here.