想象一下：大约400万行PHP代码，由低薪、有时不太流畅的自由职业者和学生在8年的时间里编写。CEO写了很大一部分，但他在2004年左右停止学习新技术。这是技术债务在初创公司运营时可能造成的糟糕状态，而不考虑所有这些混乱的捷径最终都必须清理。如果您曾在一家初创公司担任技术职务，您就会知道避免技术债务并不像听起来那么容易。初创公司通常有许多发展里程碑需要在短时间内实现。在人员和预算有限的情况下，让初创公司获得MVP有时需要走一些捷径，因为你知道你必须在路上进行一些重构。但适度很重要。当你承担技术债务时，你就是在建造一座山，在你的公司扩大规模之前你必须攀登它。您现在节省的所有工程时间都必须偿还，通常是连本带利。许多从事过具有重大技术债务的项目的开发人员都有这样的故事：我曾处理过几个庞大而混乱的代码库，我们在这些代码库中进行了重大重构，并且花费的时间比预期的要长，然后在完成之前将资源拉到其他事情上。最终结果：更大、更混乱、更难理解的代码库！换句话说，当技术债务变得太大时，即使你有很多资源来解决它，修复起来也会变得非常棘手。你能为初创公司做的最好的事情就是避免承担任何不必要的技术债务，所以让我们来看看初创公司可以做的六件事，以尽量减少或消除他们在扩大规模之前必须偿还的技术债务。不要承担你不需要的债务这个建议听起来不错，但遵循它可能具有挑战性。您需要什么样的债务并不总是很明显。建立一家初创公司几乎总是需要在早期做出一些妥协，但随着工具和技术的变化和发展，可能很难弄清楚你真正需要做出哪些妥协。例如，事务数据库。就在几年前，初创公司不得不做出一个艰难的选择，一个不可避免地涉及妥协的选择：您会选择一个可以快速轻松扩展的NoSQL数据库，并处理潜在的一致性问题和潜在的更高成本吗？或者，您会选择像PostgreSQL这样可靠、简单且免费供您的开发人员使用但将来可能难以扩展的数据库吗？这两种选择都不理想。NoSQL方法可能会引入不愉快的后续问题，例如脏读、幻读、写倾斜等。但是Postgres方法也带来了一种债务，因为它必须在以后手动扩展。正如教育初创公司Kami在大流行期间了解到的那样，扩展Postgres可能会很痛苦：“我们知道在Postgres中坚持和设置分片是多么复杂。管理多个数据分片一直拖累我们。我们的团队世界上没有人愿意经历那种体力劳动。即使我们设置分片，我们也无法将业务增长10倍。”今天，虽然我们可以通过选择正确的技术堆栈来避免承担大量技术债务。但什么是“正确的”在很大程度上取决于你正在构建和你已经熟悉的东西。几乎在任何技术堆栈中，不妥协的选项允许初创公司获得两全其美。当然，事务数据库只是你技术堆栈的一部分，并且存在类似的解决方案现在几乎在每一层。例如，您的应用程序的业务逻辑可以迁移到基于云的无服务器服务，例如AWSLambda、GoogleCloudFunctions或AzureServerlessFunctions，从而实现几乎无限的可扩展性，而无需大量的前期时间或金钱投资.因此，对于初创公司来说，明确他们的选择是至关重要的。由于新工具的出现，像Kami这样的公司被迫做出的妥协现在可能完全可以避免。特别是服务器的扩散其在整个技术堆栈中的产品使初创公司能够在必须为规模付费之前进行扩展。这反过来又使他们能够避免承担使用难以扩展的技术构建的技术债务，仅仅因为它们是获得MVP的最便宜和最快的方式。团队现在可以使用免费且易于获得MVP的无服务器选项进行构建，同时还提供云原生自动扩展以保持成本最小化和应用程序性能一致，无论有多少并发应用程序正在处理用户仍然是360，000并发用户。因此，在初创公司的早期阶段避免技术债务有时是一个让你保持警惕并了解所有选择的主题。不到一年前，还没有免费的无服务器分布式SQL数据库可供选择。现在有。了解这些选项可以帮助您避免承担技术债务和做出不必要的妥协。尽量减少运营工作在初创公司的早期阶段，开发人员“身兼数职”是很常见的。例如，初创公司的开发人员通常会兼顾开发和运营，直到公司规模大到足以负担专门的IT运营或DevOps员工为止。但是初创公司的开发时间通常很短。产品路线图上有很多功能。时间紧迫，需要快速迭代。开发人员花在操作上的任何时间都是他们不会花在构建应用程序上的时间，而且他们构建程序的时间越少，他们就越有可能偷工减料以满足最后期限。每个切角都是一小部分技术债务。出于这个原因，选择托管服务有时可能是经济的选择，即使这意味着产生更高的前期成本。您可能并不总是通过托管来省钱——这是您必须自己计算的结果——但重要的是要考虑与让您的开发人员了解和管理操作相关的成本。此成本超出了开发人员进行运营工作所错过的开发时间。选择托管服务会将操作交给专家，他们通常会提供优先技术支持以促进集成，这可能意味着更顺畅的集成过程、更好的应用程序性能以及出现操作问题时更快的响应时间。修复它们。保持灵活性当您做出设计选择或选择以后难以更改的服务时，您可能会在不知不觉中承担技术债务。虽然有很多这样的例子，但最常见的例子之一是将自己锁定在单一云的生态系统中。首先这样做通常有令人信服的理由，例如当您将AWSLambda函数连接到其他Amazon服务（例如Aurora、ElastiCache或Redshift）时，您可以利用这些服务提供的效率优势。但从长远来看，如果GCP或Azure成为更实惠的选择呢？或者，如果您意识到向用户提供更可靠的服务将需要多云怎么办？突然间，巨额债务到期，您的团队将不得不弄清楚如何迁移他们仅限Amazon的数据库以支持AWS和GCP，同时又不会引起许多其他问题。这就是为什么尽可能灵活地设计和选择工具是值得的。有时需要权衡取舍，但有时您只需选择不同的工具即可获得相同的性能和更高的灵活性。因此，即使您的功能仍在AWS上构建和部署，拥有与云无关的数据库也能让您在未来灵活地切换到另一个云或迁移到多云，而无需更改数据库。不要解决已经解决的问题作为工程师，我们总是想尝试重新发明轮子。持续改进的动力是许多创新背后的动力，但初创企业要想成功，就必须结合实用性。虽然自定义解决方案可能是完美的，但通常有一个即插即用的解决方案可以为您提供99%的所需功能，而无需花费任何开发时间。例如，Starburst是一种数据分析引擎，可为客户提供对所有数据的单一快速访问点。为确保为客户提供良好的性能，Starburst需要一个多区域关系数据库。公司当然可以尝试构建定制解决方案。但正如Starburst工程副总裁KenPickering所说，“当工程团队已经构建了可靠的解决方案时，我为什么要让我的工程团队尝试解决多区域问题？”“我们需要做出防御性的智能、智能技术解决方案选择，”皮克林说，“因为我们要对客户的数据负责。”大多数初创公司也是如此，即使你还没有被很多客户困住，你也需要做出明智的选择来保护你的开发人员的时间。为了快速成长，初创公司需要专注于解决他们的核心问题团队正在努力解决。如果您的开发人员被迫为其他人已经解决的问题构建自定义解决方案，那么他们的时间将非常紧迫，以至于他们将不得不偷工减料来开发您产品的核心功能。这就是您最终欠下的技术债务必须回报。尽早建立最佳编码实践虽然我们专注于使用您为技术堆栈选择的解决方案避免技术债务，但许多技术要么难以追溯到源代码（通常是因为它是匆忙编写的）或者技术文档令人困惑（通常也是因为它是仓促写的）。如果你的目标是避免技术债务，那么确保你遵循编码最佳实践是很重要的从第一天开始或尽可能接近第一天。我们不会过多谈论这些，因为您可能已经很清楚它们的重要性，但这应该包括可重复的格式化系统以确保所有代码都是。虽然所有开发人员都知道这一点，但当您的开发团队只有几个人（甚至只有一个人）时，很容易忽略这些最佳实践。当截止日期临近时，很容易不评论和记录你的代码，但每次你跳过这样的事情，你都会招致一点技术债务，公司总有一天会偿还的。当然，开发人员是否有时间遵循所有这些最佳实践并不总是掌握在他们手中。通常，开发时间表是从高层传下来的，所以我们最终会提出连CEO都需要接受的最后一条建议。想想你的未来，但活在当下避免技术债务的真正关键是善于平衡你现在的需求和你未来的目标。实际上，这样做具有挑战性，需要整合我们在本文中讨论的所有内容，并将这些知识带入有关公司目标和时间表的更广泛讨论中。例如，如果您的CEO设定了具有挑战性的开发截止日期而不产生某种形式的技术债务，那么技术人员需要能够识别和传达这些权衡，以便将它们纳入预算和计划中。如果替代方案意味着整个下一个季度都在处理令人头疼的客户支持问题并仓促重构错误代码。想要在本季度发布两项主要功能的CEO可能更愿意只接受一项功能发布，并且在平衡有限的时间、技能和预算的同时尝试优化以获得最佳结果是一个真正的挑战。创业很难！你不太可能完全避免承担技术债务，尤其是在创业初期的匆忙时期。但是，如果您可以在您的技术堆栈中做出正确的选择并建立良好的内部护栏以避免编码偷工减料或解决您不需要的问题，那么您至少可以确信自己正朝着正确的方向前进。译者介绍范晓波，51CTO社区编辑，高级网络安全工程师。精通SDN、SD-WAN、VPN、NFV等网络相关技术。精通二层和三层网络转发。熟悉DPDK、VPP、OVS高性能网络开源框架。喜欢打羽毛球，做饭。原标题：6ThingsStartupsCanDotoAvoidTechDebt，作者：CharlieCuster
