从失败到成功：软件架构者的迷思

  每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/

在《Clean Architecture》中，Robert Martin 对 Kent Beck 的著名格言“先让它工作，再让它正确，再让它快速”作了一些评论：

- “首先，让它工作。” 如果它不起作用，你的业务将走向末路。
- “然后，让它正确。” 重构代码，以便你和其他人可以理解和随着需求的变化或更好的理解进行演变。
- “然后让它快速。” 重构代码以获得“所需”的性能。

我曾经参与过两个项目团队，一个做对了，另一个则错得离谱。

3000万美元的失败

我曾在一家公司工作，他们开发了一个B2B SaaS产品。这个旧的、基于Java的单体产品是公司的摇钱树，连续八年每年带来1500万美元的收入。公司聘请了一位新的工程总监，他承诺使用最新技术（当时，这意味着“Kubernetes可以解决所有问题”）构建一个下一代产品，将公司带向更高的高度。他只需要30名工程师和全权进行完全重写的许可。

这个产品是工程奇迹。总监得到了他想要的30名工程师，他们构建并部署了162个Microservice（或许称其为“超微服务”更为合适），支持从CAN-SPAM到具有早期自然语言处理（NLP）功能的聊天机器人。

只有一个问题：它不起作用。

在两年的开发和3000万美元的“研发”费用后，没有一个客户能从Java单体迁移到新系统。页面加载需要几分钟。事件在队列中卡住数小时，因为调用扩展并验证数据。

毫不意外地，总监被解雇了。这个项目被视为彻底失败。在两年后，公司重新回到对Java单体系统的迭代，这套系统他们至今仍在使用。

让它工作的团队

我曾在另一个团队工作过，这个团队有一个核心原则：让用户满意。这个核心原则驱动了我们所有的决策，尤其是在构建新功能时。我们听取用户反馈，快速实施，并在几天内发布。

我们关注清洁架构、通过测试和可扩展服务。但我们的主要关注点是产品能否工作。

这个团队的成果就是这样：一个能正常工作的产品。我们在一个伟大的产品上不断迭代，让用户满意，并构建了一个十年后仍在运行的盈利系统。（为SyncTimes喝彩！）

也许这个项目没有太多戏剧性。但“无趣即美”（致谢 Ben “The Hosk” Hosking 在《软件开发中的无趣即美》一文中提出的观点，值得一读）。

优先让它工作

首先，让它工作。然后，让它正确。这与“快速行动，打破常规”并不相同。让它工作始终是第一优先。当你知道你想写什么时，就去写。改进留待以后。

“但技术债务怎么办！？”

这种“稍后再清理”的态度与我通常所说的完全相反。细微的差别在于：不要以“让它工作”的代价去“让它正确”或“让它快速”。

保持你的优先级清晰。你的最终用户可能是付费客户，其他工程师，或者整个C-suite。优先考虑能工作的产品，而不是看似伟大的工程设计。