为99%的开发商建造

你应该搬到无服务器吗？GraphQL是解决API问题的答案吗？您是否应该遵循最新的DevOps手册来提高系统可靠性？在科技工具的世界里，有很多嗡嗡声。但它并不总是反映程序员的日常现实。

作为一家开发工具初创公司的创始人，我在过去几年的常规用户研究过程中与数百名（如果不是数千名的话）软件开发人员进行了交谈。这些对话中的共同主题，甚至比我们正在构建的产品的需求更大，是一个目前未得到充分服务的总体需求：为真正的开发者构建，或者我喜欢称之为99%的开发者。

这些是在热门公司和框架之外完成工作的开发人员，他们在关于“开发人员想要什么”的对话中经常被忽视“开发者影响者”谈论的内容与大多数开发者的日常现实之间存在巨大差距。当你看到科技媒体或顶级科技会议上的演讲者报道的内容时，往往是来自Airbnb或Stripe等高增长宠儿的人，或FAANGs等老牌高利润公司的人。

事实上，长期以来，人们一直认为，除了少数硅谷独角兽之外，企业应该渴望拥有“婴儿FAANG”的流程但这一点越来越不正确。我们的用户往往会不好意思地告诉我们，他们的做法与他们“应该”的完全不同但对于这些微软的斯科特·汉斯曼（Scott Hanselman）所称的“暗物质开发者”，Facebook或Pinterest的做法毫无意义。他们的用户需求不同，团队需求也不同。

谈论99%的开发人员很重要，因为这些开发人员正在开发为我们的生命提供动力的软件——保险、医疗保健、零售和银行，仅举几例。不仅是小公司不能轻易采用现代科技领先公司的流程；大多数公司都不是围绕着技术而建立的，它们有几十年的遗留软件实践。这些公司中的很多都会转移大量资金。这些公司中的许多都处理我们相当多的个人数据。如果技术创新没有让这些软件团队受益，我们就失去了对每个人的生活质量的许多有意义的改善。

在这篇文章中，我将介绍一些企业软件购买者和建设者都可以接受的真理，以消除有害的神话，并改善所有开发者的体验。

由于Facebook、Netflix、LinkedIn、谷歌和亚马逊等公司提供了大量的写作和工具，许多人认为这是一种涓滴效应：有钱的公司的伟大工程师会想出好的解决方案，解决其他人有朝一日会遇到的问题。你典型的中小型企业或财富500强公司遇到与亚马逊或Facebook相同的问题只是时间问题。

类似FAANG的公司在很多方面都不同于SMB或典型的财富500强公司，包括规模需求、建筑与购买的立场，以及工程团队的组成。少数资本雄厚的大型公司拥有全世界专家组成的团队，致力于可观察性、测试、开发人员生产率等方面的工作。除此之外，值得注意的是，FAANG正在围绕一小部分从一开始就数字化的产品进行优化，这在大多数软件商店中是不正确的。

许多非FAANG团队都有一个小型的非专家团队，甚至是非专家工程师的一小部分，来做FAANG类公司有多个专家团队要做的事情。这些组织主要依赖外部工具和服务，它们几乎没有用于定制的带宽。

首先，科技行业需要认识到，不同规模、不同工程预算的组织将有不同的需求。一家每天处理数百万用户请求的公司不需要像Netflix或谷歌那样优化其系统。大多数公司没有延迟、数据存储和其他问题导致他们编写自己的定制基础设施组件和工具，比如Facebook使用其Tao data store和Hive data warehousing工具所做的事情——而且他们可能没有任何问题可以保证他们使用这些工具。

承认不同的需求将为讨论各种组织的不同需求提供空间。例如，那些遗留系统无法迁移到最新体系结构的公司需要采用不同于较新公司的新工具，或者那些可以专门组建团队进行大规模迁移的公司。

认识到没有一个理想的公司简介可以帮助建设者在理解用户时超越通常的怀疑。这对于以可实现的方式弥合软件需求和软件工具之间的差距至关重要。

现场由@jeanqasaur报道。例如，big tech在其他地方很少出现的内部平台团队中投入大量时间。

例如：在优步，移动平台团队发现了我的团队编写/拥有的运行缓慢的测试*&；告诉我们该怎么修。

如果你看了足够多的会议演讲或阅读了足够多的博客文章，就会发现有许多软件团队采用了原始的编码标准、非脆弱的单元测试、反映生产环境的临时环境，和/或平滑的人员流程来应对事故。要做到这一点，只需要上级的强烈指示和整个工程团队的纪律。

就像其他领域的影响者一样，开发者影响者经常描述一个现实，即使对他们自己的公司来说也是令人向往的。写理想过程的人可能生活在一个理想化的环境中，在这种情况下，他们是提供规则的例外。但大多数时候——即使在一个组织的某个部分或某个时刻是真的——这种现实并不适用于他们的整个公司，也不会永远适用。

例如，Spotify承认，一旦他们的团队达到一定规模，他们对DevOps的崇拜方式就无法扩大规模。我们还看到一些公司采用了新的热门技术，然后在事情没有按计划进行时恢复——例如，细分市场从微服务转向整体服务。

当观众为这一切提供动力时，开发人员在询问真相时应该更加挑剔。我们应该欢迎关于“真实软件过程”的帖子，就像我们渴望理想化的内容一样。如果有人在一个理想化的过程中工作，有一个世界级的ops团队和一整支支持改进软件质量的团队，那么观众应该意识到这一点！我们应该欢迎更多为“真正的软件环境”提供指导的讲座、博客帖子和书籍：在人员短缺的团队、没有专门的devops专家的团队以及最初构建系统的所有人都离开的团队中，编码、测试和发布是什么样子的。

另一个小秘密是：大多数“开发者影响者”说的很多话都是相当有抱负的。

他们自己的公司做事情不一定像他们对别人说教那样顺利。

这在大型公司尤其如此，在这些公司中，组织/团队之间的文化差异可能很大https://t.co/FW2aI8lppu

太多人认为，追求良好的软件质量意味着你需要完全采用这种新技术，无论是微服务、GraphQL还是分布式跟踪。在完全切换到理想技术之前，您还没有完成。

如今，“真正的开发人员”团队的位置与给出的主流建议之间的不匹配意味着，在提高代码质量或系统可靠性方面，许多团队不知道从哪里开始。对于99%的开发人员来说，他们的大部分代码永远不需要扩展到数千人或数十亿用户的组织。这些开发人员中的许多人的代码基础比他们整个职业生涯都要老。这些组织中的大多数在内部没有专门的开发人员工具或开发人员生产力团队。

原始代码不是目标——相反，目标是在其他约束条件下，尽可能可靠和安全的代码。例如，如果您的公司没有跨多个云运营，每天部署数百个更改，那么像Netflix的Spinnaker这样的连续交付系统可能是不必要的。类似地，与没有专家团队的公司相比，拥有devops专家、知道如何设置和维护可观察性“电动工具”的公司的开发人员使用这些工具的时间可能会更好。

认识到需要取得进展——从那些投入整个团队来完善流程的公司那里可以吸取教训——但在大多数情况下，完善是不现实的。与其全盘取消流程，不如看看哪些流程适合资源较少的团队和目标不同的团队。

例如，这篇谷歌博客文章提供了60%的测试覆盖率为“可接受”，75%为“值得称赞”，90%为“模范”的指导原则如果你是一家像谷歌那样成熟的公司，拥有谷歌工程团队的规模和才干，这可能是有道理的。但对于大多数规模较小、处于早期阶段的公司来说，不管公司的目标是什么，实际的测试覆盖率都会低得多。随着面向服务的体系结构和外部API（在谷歌之外更为普遍的做法）的兴起，生产测试正在成为传统单元测试和集成测试技术的可行替代方案，在这些技术中，“代码覆盖”作为一个概念是有意义的。

在许多现代系统中，正如蜂巢联合创始人Charity Majors所写，“一旦部署，就不再测试代码，而是测试系统——由用户、代码、环境、基础设施和时间点组成的复杂系统。”

人们很容易陷入这样一个陷阱：假设演示和上线都是日复一日使用产品的体验的象征。人们必须相对快速地做出购买新产品的决定，因此我们默认根据产品的演示来判断产品。

开发者工具帝国是通过巧妙的GIF和视频剪辑建立起来的。在几分钟的演示之后，团队会致力于开发工具——有时会持续数年。投资者根据演示进行投资。建设者被告知要把重点放在演示上——以及在演示之后的前60秒使用——作为产品的成败部分。但是，虽然能够在演示中很好地执行可能意味着团队可以在日常使用中执行开发人员体验，但这两者并不一定相关。

对于大多数值得付出代价的工具来说，开发人员经历的大部分事情——以及经历的痛苦——都发生在使用的第一分钟之外，这并不奇怪。首先，与开发人员的日常工作流程（例如，现有的代码审查、CI/CD工作流程和协作模式）的集成，是一个更好的指标，表明一个产品是否会比最初的产品更具粘性。例如，开发人员工具的创造者们都知道，与GitHub和GitLab的集成将有助于使您的工具更加有用和吸引人。

第二，有很多种类的工具，它们的有效性的真正测试不会在第一天进行。调试器就是一个例子。调试工具箱不仅是开发环境，而且是CI/CD环境，它是影响开发人员生活质量的最关键因素。当您在部署前解决问题时，您确信该问题不会出现在生产中吗？当你因为生产事故不得不加班或休息一天时，你是否能够快速找出根本原因并提出潜在的解决方案？由于这些工具的复杂性——并且因为它们通常在出现重大问题之前不会显示出它们的本来面目——调试工具通常会因为良好的开发人员体验而得到最少的宣传和回报。

工具建设者往往不成比例地关注第一天的体验，这是因为用户如何评估工具。所以我要给这里的用户一个特别的提示。用户需要：

在你或你的开发团队花时间日复一日地使用工具一段时间之前，不要使用那些让你承诺签订大型合同的工具。

根据对团队生产力至关重要的不那么“性感”的维度向其他人推荐工具，例如它们如何与工作流集成，或者它们如何减少团队内部和团队之间的协作摩擦。

人们通常认为，热门的新语言或框架就是某人系统中存在的全部。开发者和开发者影响者都会宣传新的工具，就好像它们是唯一被使用的工具一样：例如，微服务架构、GraphQL和基于OpenTelemetry的可观察性跟踪。“一个真正的框架”布道隐含地假设，组织有可能转向使用全新的语言、工具或框架。

我遇到过很多团队，他们说迁移将在“下一季度”进行现实情况是，即使迁移最终成功开始，迁移也已经变成了连续的过程，而不是离散的过程。一个拥有99%遗留代码的开发团队和一个精干的团队可能永远不会将他们的整个代码库转换为微服务或GraphQL。对于大多数组织来说，技术堆栈和工具链是异构的，是多年来逐渐形成的语言、框架和工具层的组合。

我们遇到的许多团队都会告诉我们，他们开始采用微服务、GraphQL或OpenTelemetry。当我问他们在新框架内已经提供了多少服务时，答案往往很小，尤其是对于几年以上的组织。其中一些组织会告诉我，他们实际上并不希望转换整个代码库。（例如，组织将期望与微服务一起维护其遗留的整体，或与GraphQL端点一起维护REST和gRPC端点。）对于许多其他组织来说，当我稍后查看一些季度时，他们在计划的迁移中往往没有预期的那么顺利——他们生活在跨各种框架和工具维护软件的现实中。

软件购买者，从个人开发者到董事和首席信息官，都知道存在异质性。但完全接受这一点意味着：

接受缓慢的迁移。我遇到过许多团队，他们认为一旦完成从过时的工具X到热门的新工具Y的迁移，他们的问题就会得到解决，每个团队都生活在自己的解决方案生态系统中。不幸的是，在热门的新工具是Z之前，到工具X的迁移可能不会完成——现在又出现了两个生态系统问题。

接受遗留子系统。我遇到过许多团队，他们专注于围绕系统的更新部分创新工具箱。不幸的是，遗留子系统并没有消失——而且为它们提供的工具更少，这意味着当出现问题时，您有更长的分类和调试时间。

接受您的API不太可能在GraphQL上聚合，这将导致您投资于更可持续的多API协议工具。认识到您的组织可能不会将其所有遗留的monolith转换为微服务，这将允许您投资于不会忽略对monolith或微服务中的代码进行监视和调试的工具。

在建设者方面，传统智慧认为，你努力追求“土地”的同质性，而拥抱“扩展”的异质性你是否计划异质性将极大地影响你的扩张速度。某些类型的开发工具需要为每种新语言或框架定制。例如，仅为GraphQL API提供洞察的工具可能不容易扩展到其他类型的API，尤其是因为GraphQL包含的信息比REST或gRPC更丰富。

其他类型的开发工具可以轻松地跨语言和框架扩展。只需要能够从不同编程语言调用的SaaS工具支持语言异构性，因为不必翻译主要核心组件来支持每种新语言。

🛑 不要再认为软件是由少数不具代表性的公司统一代表的