产品架构：技术栈变化时的基础原则与潜在陷阱

---

无论哪种公司都需要管理资金、技术，以及风险。其中，初创公司所要面临的巨大风险使其不得不转变传统理念，将风险转化为前进的动力，以更快地获取经验。初创公司的起始可以选择绿野仙踪测试法，或者是从一个不被大公司看好的 MVP 落地页开始。

我在创业之初时，对自己无法更快地做出技术栈相关决策非常不满。如今，我已经在 TeamViewer 工作了好几年，在给五百强公司做过几个项目后，学到了不少技巧，并愿意在此分享出来。

这篇文章将引用《独角兽项目》这本书中的虚构角色 Erik，以采访的形式进行分享。Erik 是创建了“DevOps 的三种方法的”的传奇人物，希望在这次采访中他能够帮到我们。

Stefan Miteski：Erik，让我们开门见山直切入主题吧。团队在构建 MVP 时，什么时候可以从“尽可能快”的理念转换为构建可延展性更强、更适于维护、可持续性更高的模式呢？

Erik：首先，不是所有的构想都需要代码来实现，用最便宜、最快的就行。我更倾向于选择能够最快完成任务的技术，哪怕这意味着我要用的某个低代码平台需要我在后续重写全部的代码，也都不是问题。所以这其实是一个基于团队技术背景的决定。如果团队中有人懂 NodeJS，那就选择 NodeJS，如果有人会 Python 那就用 Python。在这个阶段你不需要考虑最佳的质量过程、CI/CD，或者最佳敏捷方法。这些多余的累赘是初创公司在起始阶段不应思考的问题。在 MVP 阶段，你只需要做在黑客马拉松里会做的事。

简单来说，只有在拥有可能的收入资金后，可扩展性和流程才会变得重要。

Miteski：假设钱不是问题，那么在大公司中开发新项目这种情况呢？

Erik：这种情况也类似。