创作者 | Stefan Miteski

译员 | 马可薇

方案策划 | 丁晓昀

我还在创业之初时，对自己不能更有效地做出技术栈有关决策十分不满意。现如今，我已经在 TeamViewer 上班了很多年，在为五百强公司做过几个新项目后，明白了许多方法，并且乐意在这里分享给大家。

本文列举了一个虚构角色 Erik，以访谈的方式进行共享。

Stefan Miteski：Erik，使我们直截了当直进入主题吧。团队在搭建 MVP 时，什么时候能从“尽量快”的发展理念转换成搭建可可塑性比较强、更适合维护保养、可持续更高的方式呢？

Erik：最先，并非所有设想都要编码来达到，用最划算、速度最快的就可以了。我偏重于挑选可以更快达到目标的技术，就算这就意味着我会用某个低代码平台需要我在后期重新写过所有的编码，也都不是事。因为这其实是一个根据团队技术背景确定。假如团队中有些人懂 NodeJS，就选择 NodeJS，当有人会 Python 那就用 Python。在这个时候我不需要考虑到最理想的品质全过程、CI/CD，或是最好敏捷方法。这种多余累赘是创业公司在开始环节不可考虑的问题。在 MVP 环节，你只要做在黑客马拉松中会做的事情。

实质上，仅有在有很有可能收入资产后，扩展性和程序才也会变得关键。

Miteski：假定钱不是问题，那在大企业中开发新项目这样的事情呢？

Erik：这样的事情也类似。在保证生存力后再去考虑可可塑性。假如新项目仍在通水环节，那还是按照 MVP 规划的运作。倘若新项目早已稳定下来，那这时候再考虑到可可塑性。

Miteski：的确，这样说就确立。我经常在具体指导前期创业人时，遇到几个的失败案例都是由于太早的在可可塑性上消耗了不少时间精力。因为搭建的商品没有人必须而造成的失误率（35%）要远远高于不正确的技术决策导致的负债累累（8%）。

那在扩充环节呢？现在我们有了稳定收入，终于能抛下前期乱糟糟的编码垃圾站了，这时候我们要选什么技术呢？

Erik：依据康威基本定律，“设计工具的部门受到限制生产设计，这种是这种组织通讯构造的团本。”因此在这个时候，我们应当关注的是机构整体上的总体设计，而不只是技术栈或软件体系结构。机构所需要的团队总数、团队间深度合作模式是什么？怎样保持团队之间统一性？测试的流程是啥？CI/CD、发觉对策如何制订？如何做到营销和研发工作的一致性？怎样保证企业文化持续发展？怎样获得并优化优秀人才？

每一个技术全是是建立在解决问题的前提下，自然新项目亦是如此。但是，网页应用的后面要用 Java 或是 C# 开发设计？数据库系统要用 SQL 或是 MySQL？这种正确的答案就真并不是那么的强烈了。最直观的答案就是在“紧急构架标准”和“最终义务时时刻刻”标准前提下，将决策权交到团队，并且从多功能性和非功能性两个方面深入分析。

在其中，非功能性需有：

线上社区规模。你可以选择了 C# 而非哪些新颖的计算机语言，那样除开完备的文本文档以外，你也将有着来源于 Jon Skeet 等的大力支持，她在 StackOverflow 上已经有超出一百万的威望积分。换句话说，你可以在网络上寻找 C# 语言表达有关问题答案的机率要远远高于别的冷门语言表达。此外你还要考虑到这类语言表达可利用的库有多少个，适用是不是完善等诸多问题。

用人市场经营规模。周边大学的学生学的都是什么语言？自然，你就可以对于所需要的技术对团队开展培训，但这到底要搭进很多项目实施时长。加上如果你想应用的言语并不常用或者落伍好久了，那样我们还需要更高的费用预算以付款更高的薪资。

系统软件的使用寿命。人类的寿命大约 70 年之后，并且必须 9 个月才能从胚胎发育过程成年人。假如我们要让系统软件长久生存，也要相似的方式。这大概是长久的技术对策，而非在于大家所作的第一个决策。

在发布后再做出系统软件重要修改有时候就好像在航行时维修飞机场。因而，将系统对来讲非常重要的决策推迟了“最终义务时时刻刻”是最明智的。

Miteski：那样什么叫“最终义务时时刻刻”呢？

Erik：这一概念来自精益生产开发设计。返修代价要远远高于延迟时间成本。而迭代开发倡导实用主义——在实践中学习。假如你太早的做出不可避免的决策，那么就要承担风险还会翻倍。因而，大家一定要谨慎决策，将在其中可以学习的一部分挑出，在做出重要决策前减少风险。

Miteski："延迟时间"听上去是和精益生产初创期原则有悖？终究速率也是我们的关键核心竞争力。

Erik：延迟时间确定并不代表站着不动地独立思考。我们应该紧紧围绕这一决策对构架开展探寻，掌握业务开展情况、客户需求，让自己在最终义务时时刻刻做出最好的选择。大家也可以做个系统模拟，并贯穿其搭建各种各样 API。

Miteski：那样，业务开展情况又是如何危害技术栈所选择的决策呢？

Erik：能够有许多方面：

明确你核心竞争力，及其能够为这类优点给予最好是鼓励的技术。

将和机构核心竞争力不相干的各种各样技术解决方法交给第三方处置，操控并搭建属于自己技术栈，后面一种才算是核心竞争力的一部分。这类核心理念适合所有技术及不必要服务项目。但注意，不必使你的服务商发展为自已的竞争者。当初微软公司和intel可都曾经是 IBM 的服务商。

要不是必须使用原装机得话，那样云经销商是一个不错的选择。但是该怎么选经销商呢？总之一句话，那应该在于业务实质。假如你的客户很在意云服务器在安全事故阶段的反应速率，那就仔细分析它们 SLA 及其能够创建的战略伙伴关系种类。要不是，那便以他们能提供服务的为基准参照。从基础的 CloudWatch 到主题鲜明的 Kubernetes 这类，哪一种能够持续加速你布署速率？最终，不要忘记价格因素。挑选云合作方如同选择我新成立公司的合作伙伴，别着急，不要急功近利，那样也便于未来深层集成化他的服务项目。

Miteski：那样，伴随着机构成熟的发展趋势，可能我们要面临什么陷阱吗？

Erik：关键在于电动车圈套。这类圈套一般出现在不正常的机构自然界中。我听说过的一个实例是，曾有位技术工程师负责了某一互联网巨头工程中绝大多数的基本功能，并借此机会威胁企业加薪。在无法得到最期待的结果后他离开了企业。最后企业迫不得已无人能维护保养而只有改版全部新项目。

造成立井的原因之一是高管对迅速交付施加压力。毕竟在髙压条件下，有着特殊技术背景开发人员会高效率更高，因此在对待技术债务时，还需要将反立井列入考虑到范围之内。

但不管立井为什么会有，我们都应该意识到了他们的出现是非常危险的。而且很多大企业都是会做出把多名行业领域的技术工程师放到同一个口袋里错误，万一这一竹篮出了什么事，会严重影响到企业的生死存亡。假如这是你的企业已经做的事情，那样现在是时候考虑到换个方式办事了。将技术知识传播开，运用代理商对策，让没有在这一口袋里的许多技术工程师也做起这一部分工作，只能在“代理商技术工程师”们被难题卡死的时候再资询口袋里的专业人士。此方法会短暂性减少高效率，但是它保证了长久的可扩展性，并且后面大家工作效率会更高，你看看是否人生的真谛？

Miteski: 的确。

Erik：另一个需要注意的是小奶狗圈套。有时天真无邪的念头能让我们沉浸在其中不能自拔。就好像是看见超级可爱的奶狗，我们也会因为它那时候超级可爱的表面和一瞬间的动心来决定收留他们，但却忽视了他们不久的将来十多年中的发展，而且在此期间必须不断照顾。在大多数情况下，技术解决方法也将持续存有超出十年，在做技术决策的时候也需要把这一点列入考虑范围。大家不能为了某一技术工程师喝醉酒异想天开的念头或产品运营在飞机上看杂志而脑洞大开的设计灵感，还把将来所有奉献进来。Visual FoxPro 在上个世纪九十年代听上去是一个绝赞新的技术，但是它并没经得起时间的洗礼。类似的事例在科技墓地里并不罕见，不过随着如今最前沿高新科技发展趋势的脚步，不久的将来那片墓地应该是不会寂寞了。

但换个角度来看，把所有新点子和试验性新项目所有避而不见也很危险。用微服务架构或低耦合系统软件，把系统内单独的一部分作为新技术的实验场，此方法非常适合试验性自主创新。如此一来，我们就能在制造自然界中试验新技术，而因为实验场并不和基本功能挂勾，且部位也不是特别重要，后面必要时关掉这一部分作用也不影响到消费者应用。还是处于设计阶段的技术非常危险，但你可以用这一实验场来获取技术实际操作积累的经验，检测技术栈在实际情景上的表现并健全对它认知能力。

Miteski：假如遵循“最终义务时时刻刻”标准，然后让机构中所有团队挑选自己喜欢的技术栈，大家就会遇到一个窘境，该如何平衡团队所选择的主体性与公司技术栈的统一性呢？

Erik：组织高管理应设定一个技术方位，并开设一套广泛原则以做决策。企业全部团队都采用相似的技术栈所产生的优点非常明显：在软件购买所有权时能得到更好的讨价还价；在潜在需求出现的时候，团队能够快速重新组合，提升组织适应能力；技术考验一经处理，技术知识要点传达给企业左右全体人员。

这样做也是有缺陷。伴随着市场的需求与公司所提供解决方案复杂，对团队技术栈的多样化规定也越高。换句话说，基本原则建立一个技术栈方位，同时也应给予团队做出偏移标示的基层民主水平。但是团队也需要论述清晰不遵照企业技术方向的原因所在。

Miteski：微服务架构什么的低耦合方式能让不一样团队应用不同类型的计算机语言搭建服务或系统软件构件，这类层次的协调能力确实能够带来一定的优点，那我们需要在什么时候运用这类优点呢？这样的情况下是不是也有基础规则？一般来说技术工程师都是会了解应该怎么做，但建立一个新的技术栈时他的目地可能并不纯粹。我见过有些技术工程师想要 Go 来撰写服务项目，只是因为他们觉得 Go 这一新语言看上去很帅，想学习 Go。

Erik：低耦合基本上不会错，而多种多样计算机语言还会推动企业发展。最主要的是转变，从一个细微的转变逐渐，假如效果明显，那就从这当中学习培训，激励别的团队则在前提下发展趋势。结合公司及编码规模不一样，企业整体上的技术栈向一个新趋势变化需要时长也不尽相同。持续不断的演化与渐进的转换远比一刀斩重新开始的苦楚要低。这样的情况下大家基本原则是，限定并整体规划这种新语言或新技术的实践探索，在设备或者服务的非关键一部分进行测试。随时随地断开这种试验服务项目且不危害基本功能。让发展和技术转型从服务项目末梢神经逐渐，从渺小的危害逐渐向服务站看齐，让所有系统及代码基础迟缓产生变化。在已经开始了向里促进且并未抵达系统核心的变动的浪潮后，大家几乎不会再开辟一个全新的发展趋势时尚潮流。

专注于使我们能以可持续发展的方法飞速发展的物品，与此同时也别忽略运维管理的功效，这样才可以迅速、更方便，也更加愉快地交货更高意义的产品。

Miteski: 多谢！我很享受这次的对话。我相信任何的公司都应该不时来读一读这篇文章。

Erik:谢谢，记得在你重温《独角兽项目》时再来看看我。