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