@tobi: 是的。但是：1. 这是关于重要的内部工具。团队陷入了他们自己造成的架构噩梦……

X AI KOLs Timeline 新闻
internal-tools architecture decision-making founder-mode engineering-practices shopify

摘要

Tobi Lütke 讨论了他通过快速架构决策简化 Shopify 内部工具的方法，强调创始人主导的干预以避免复杂性和技术债务。

是的。但是： 1. 这是关于重要的内部工具。团队陷入了他们自己造成的架构噩梦（用 Rails 但做无头模式，加上 GraphQL API 和 SPA React 应用，每次修改都需要前端工程师）。我称这种事为‘扮演企业级生产应用’。所有这些复杂性都是障碍，而直接使用 Rails 在这种情况下是完美的。 2. 我经常做这样的决定。通常是团队里有人请我来做。他们知道需要做什么，但不想当坏人。如果我同意前提，我很乐意直接做决定。这节省了大量的会议和变革管理等。在这里，这有时被戏称为‘创始人模式即服务’。 3. 十年来，我还主持了一个内部播客叫 Context，我在那里回顾像这样的决定并解释原因，以便每个人都能从中学习。这有助于让人们了解所有考虑过的变量，以及为什么在当时可用的信息下做出这个选择。我想教人们如何有效地做出这样的决定，而不需要我。沉没成本谬误是个问题。 4. 任何认为 Shopify 是尽管我这样做而成功的，而不是因为这个，我认为他们的论点很难成立 😄 那个‘两周后 tobi 得知……’的部分是胡说八道，而那个项目的转型是更成功的干预例子之一。但让公司以良好的架构和低技术债务包袱有效地向正确方向发展，字面意义上就是工作，所以我猜是有罪的。 但总是有这种应对故事在流传，因为它们比说‘不知怎么我们需要 tobi 停止做愚蠢的架构宇航员行为’更有趣。我完全能理解。
查看原文
查看缓存全文

缓存时间: 2026/09/11 16:38

是的，不过：

  1. 这涉及关键的内部工具。团队陷入了自己制造的架构噩梦（用Rails写无头应用，搭配GraphQL API和SPA React前端，任何改动都需要前端工程师介入）。我把这类情况称为“cosplay企业级生产应用“。那些复杂性成了绊脚石，而直接用Rails在这种场景下是完美的。

  2. 我经常做这类决策。通常是团队成员让我来拍板。他们明白该怎么做，但不想当坏人。如果我认同根本前提，很乐意直接决定。这样能节省大量会议和变更管理。有时这被戏称为“Founder-mode-as-a-service“。

  3. 过去十年我还运营着一个名为《Context》的内部播客，在其中重新审视这类决策并解释当时考量，让所有人能从中学习。这有助于向人们展示当时考虑的所有变量，以及在现有信息下为何做出这个选择。我希望大家能学会如何独立做这类决策，而不必依赖我。沉没成本谬误是个常见问题。

  4. 任何认为Shopify的成功是“尽管如此仍成功“而非“因此而成功“的观点，恐怕都很难站得住脚吧 😄

所谓“两周后Tobi才发现…“的说法纯属无稽之谈，而那个项目的转型实际上是更成功的干预案例之一。但带领公司以高效协作、优秀架构和低技术债务状态朝正确方向前进，正是我的本职工作——所以算是认罪吧。

不过总有这类传闻流传，因为它们比承认“不知怎的我们需要Tobi来阻止那些华而不实的架构冒险“更有意思。我完全理解这种心态。

Erfan@ErfanEbrahimnia·20h: 把这个留在这里吧 x.com/mustafa01ali/s…

相似文章