历史上曾有两个著名的短语，虽然与软件工程毫无关系，我们却总是不停地听到它们："我有一个梦想"和"是的，我们能"。无论是马丁·路德·金还是巴拉克·奥巴马，都和软件架构或编写代码没有任何关系。绝。对。没有。然而，我回看这些年的软件开发，意识到我们所有人一直在做的------尤其是在 AI 出现之后------就是梦想驱动的开发。我们可以简称它为 DDD 吗？
欢迎关注我的公众号OpenFlutter，感谢
两面性的陷阱
尽管我非常热爱软件工程------毕竟我把一个爱好变成了一份职业------但无论我如何去接触它，它总是一个陷阱。十家初创公司中有九家都证明，光有梦想不足以让一个成功的技术创意起飞。而软件工程师在足够的压力和金钱下，会对任何事情说"好"。这不可避免地导致失败的次数远远多于成功。
虽然我也是一个非常有创业精神的软件工程师，但每当我听到那些承诺时，我还是忍不住想笑。无论是谁向谁做出的承诺，都无关紧要。它可以是向客户推销未来根本未被工程师评估过的功能，可以是向工程师推销在创纪录短时间内用创纪录低资源完成的迁移，也可以是公司将宝押在那些连"走路"都还不会的技术上。到底承诺了什么，并不重要。
你得喜欢这些凭空想象出来的开发目标，它们在现实中的依据，就跟 2000 年的飞行汽车一样少得可怜。
重要的是，它最终出现在了演示文稿里，出现在了幻灯片里，出现在了公司务虚会上，出现在了你的 Jira 看板上，甚至还出现在了新闻里。出于某种原因，所有这些都被认真对待了。就因为有人做了这个梦。就因为有人相信这是必须发生的事情。
如果你仔细审视这个问题，你会发现你以前见过。这就是**"好、便宜、快"**这三者不可兼得的悖论。我们都知道这是不可能的。至少在过去的半个世纪里，这一点已经被一遍又一遍地证明，然而每年，每个季度，总有人对他们的"梦想"足够相信，去尝试它，并让其他人也对它说"好"。
而我们确实这么做了。不知何故，我们软件工程师，要么变得越来越容易轻信，要么对软件开发的现实变得麻木不仁------某些事情必须在某个日期前完成------以至于我们只是说"好"，然后无论如何都去尝试了，即使我们完全清楚，这根本不可能完成，因为"好、快、便宜"之所以是悖论，是有其原因的。
说"好"的代价
技术债对我们来说并不陌生。事实上，这是所有工程组织都在努力控制的问题。关于它的书写了无数，播客录了无数，会议和大会也开了无数。这是一个现实。但我不禁要问自己：有多少技术债，是因为工程师们在应该说"不"的时候说了"好"而造成的？
当一些事情没有按时交付时，领导层通常只会把目标往后挪，然后就当没事发生了。然而，工程团队却留下了成堆的永久性技术债。
不可否认，由于技能不足，确实有一些代码最终会充斥着代码库。也有一些代码因为开发者的冷漠而溜进了生产环境，但还有很大一部分代码，只是**"一个又一个的妥协"。换句话说，这些代码之所以存在，是因为我们对一个无法实现的梦想说了"好"。
你可能会觉得这是别人的错。你可以去指责那个梦想，但有一件相当奇怪的事情，我意识到，我们许多工程师一直在做，没有任何其他原因，只是为了取悦别人------无论是另一个工程师、产品经理、工程经理，还是天知道是谁。我不想这么说，但我们都是"取悦者"。不管你喜不喜欢，我们都讨厌让别人失望。部分原因是我们真的不想让别人失望------因此我们在规划会议中，常常会在五秒钟的沉默之后就提出各种变通方案；部分原因是我们是软件工程师，我们本应有足够的创造力来找到不止一种解决问题的方法。
对无法实现的梦想说"好"，正是 Mikado 架构的根源。这是梦想驱动开发的必然产物。
Mikado是一个游戏。在匈牙利，它被称为"Marokkó"。这是一个非常简单的游戏，里面有一堆不同颜色的木棍或塑料棍。你让它们随意地落在桌子上。结果就是一堆互相支撑、摇摇欲坠的棍子。玩家必须尝试在不影响其他棍子的情况下，抽出一根；或者用之前取出的棍子去挑起其他的。底线是，你尝试取出一根棍子时，不能影响到其他的。根据颜色，奖励也更高或更低。
Mikado 架构
如果这都不能让你联想到软件架构，那我不知道还有什么能。事实是，在软件开发了几十年后，很难不遇到无休止的遗留代码、技术债，以及一个又一个的变通方案。2017 年的 "TODO" 注释？司空见惯。文件越来越长，嵌套的分支逻辑多到没人敢碰？司空见惯。
找到你代码库里最糟糕的分支逻辑，你就会发现多年来业务所经历的需求变更和方向调整有多少次。
当引入功能开关（feature switches）这个概念时，每个人都认为："终于有了一些稳健性和可扩展性，连产品经理都会同意了。"然而，在五百个开关之后，情况却完全不是这样。你可能会想，没问题，单元测试会挽救一切。它们才不会呢。我敢保证，你的测试覆盖率根本达不到能让你抽出那根 Mikado 木棍，而不会让所有东西都崩溃的程度。
但至少还有回归测试，对吧？也许吧。如果你够幸运的话。好吧，那至少 TypeScript 能挽救一切。然而，TypeScript------或者任何其他静态类型语言------都不是能神奇解决问题的神仙教母。它充其量只是一根拐杖（对于那些懒得学习 JavaScript 的人来说）。
这是一种相当令人困惑的局面。作为一名软件工程师，我感觉越来越焦虑，每当我在日常生活中需要做一些涉及软件的重要事情时。除了意识到我的数据与恶意攻击者之间的安全屏障是多么薄弱，除了意识到我的数据被到处收集，我还知道我们所有应用和网站的背后是什么------一堆 Mikado 架构。
现在我们有了 AI......
别误会，生成式 AI 对软件开发确实有积极的贡献。不相信我的人，应该拿起一个注入了 AI 的 IDE，比如 Cursor，然后试着玩玩。请注意，我这么说是一个 AI 怀疑论者，而不是一个狂热的追捧者。但是，AI 的到来带来了一种对代码的态度转变。代码变得更加短暂------这本身不一定是件坏事------它也不再是工程师的骄傲之源。但我认为，从一开始就不应该这样，这就是为什么在一个 AI 承担了大量繁重工作的时代，我鼓励工程师们采取一种更系统化的思维方式。
你以前见过这种场景。在白板上匆忙画出的图表。几个矩形和几条线。那就是梦想。那个遥不可及的梦想。因为那些矩形从来都不是空的，而那些线也从来都不是简单的线。放大来看，背后隐藏着大量的复杂性。这就是梦想驱动的开发从未真正审视过的东西，也是为什么在一个人一厢情愿的想象中应该"足够简单"、"一周内搞定"的东西，既不简单，也无法按时交付的原因。
软件工程师需要学会理解系统是如何工作的，并在功能的早期阶段、迁移，甚至是全新项目中，就突出其中的复杂性。否则，梦想驱动的开发只会一路走向失败。
我们软件工程师需要学会理解系统是如何工作的，并在功能的早期阶段、迁移，甚至是全新项目中，就突出其中的复杂性。否则，梦想驱动的开发只会一路走向失败。
我们不应该为了打击产品经理或工程经理的梦想，而是为了防止沉没成本，或促成一个现实的交付。我们软件工程师，需要做好准备，接过记号笔，擦掉白板上那些过于简单的销售说辞，画出真正复杂的系统图。而且，这需要我们立刻做出反应。
我们那些漂亮，甚至是"手工打造"的代码，几天内就会被 AI 重写，但我们创建、改进或简化的系统，生命周期要长得多，这才是工程师真正的骄傲之源。这些系统将是那种，触碰其中一部分，不会导致其他所有东西都崩溃；一次简单的库更新，不会让整个公司停摆；每次你合并代码时，你都不会觉得自己是在玩 Mikado。
对梦想驱动的开发说不。对 Mikado 架构说不。构建真正行之有效的系统。