初创企业购买企业邮箱

by Trey Huffine

通过Trey Huffine

什么是技术债务？ 为什么几乎每个初创企业都拥有它？ (What is technical debt? And why does almost every startup have it?)

Technical debt is any code added now that will take more work to fix at a later time — typically with the purpose of achieving rapid gains.

技术债务是现在添加的任何代码，以后需要花费更多的时间来解决，通常是为了快速获得收益。

Learn how to code with programming tutorials on >

<使用上的编程教程来学习如何编码>

But what does that mean?

但是，这是什么意思？

Technical debt is like any other kind of debt. Let’s compare it to buying a house. Most people don’t have hundreds of thousands of dollars in the bank to buy a house. Thus, people take out a mortgage. Buyers have to repay it over the next 15 to 30 years with interest added. If buyers don’t pay their mortgage on time, then they lose their houses.

技术债务就像任何其他种类的债务一样。 让我们将其与购买房屋进行比较。 大多数人没有几十万美元的银行买房。 因此，人们进行抵押。 买家必须在未来15到30年内偿还该笔利息，并支付利息。 如果买主不按时还清抵押贷款，那么他们将失去房屋。

Technical debt is no different. It allows companies to create software faster, with the understanding that they will slow down software development in the future. Companies will eventually be forced to spend more time fixing the debt than the amount of time it took them to produce the best solution at the beginning.

技术债务也不例外。 它使公司可以更快地创建软件，并了解他们将来会减慢软件开发的速度。 公司最终将被迫花费更多的时间来偿还债务，而不是花费一开始就产生最佳解决方案所花费的时间。

The optimal solution to any software engineering problem typically requires a large investment up front. It takes more time to write code without getting results, and it is done before the robust and scalable results are actually realized.

解决任何软件工程问题的最佳解决方案通常需要大量的前期投资。 在没有获得结果的情况下花费更多的时间来编写代码，并且要在实际实现健壮和可扩展的结果之前完成此过程。

Technical debt can create a grueling experience for developers and inhibit long-term scalability. But nearly all startups incur technical debt. Many use it as a catalyst for short-term growth. So technical debt isn’t always a bad thing.

技术债务会给开发人员带来痛苦的体验，并抑制长期可扩展性。 但是几乎所有的初创公司都要承担技术债务。 许多人将其用作短期增长的催化剂。 因此，技术债务并不总是一件坏事。

Coding News for Developers | gitconnectedThe developer homepage - join the programming community from gitconnected. Discover and share coding news, with the…

开发人员编码新闻|gitconnected开发人员主页-从gitconnected加入编程社区。通过发现和共享编码新闻

您如何判断技术债务是否存在 (How can you tell if something is in technical debt)

Technical debt isn’t just some abstract concept. It can be explained in concrete terms and depicted graphically. A great analogy (don’t hate me for this one) is Big O algorithmic complexity. As the size of a code base increases, we can measure the effort required to add new features and/or code.

技术债务不仅仅是一些抽象的概念。 可以用具体术语进行解释并以图形方式进行描述。 一个很大的类比(不要为此而讨厌我)是Big O算法的复杂性 。 随着代码库大小的增加，我们可以衡量添加新功能和/或代码所需的工作量。

Anything above the blue linear O(n) line is technical debt, and anything below it is not. This means technical debt makes writing code increasingly difficult because more code is added.

蓝色线性O(n)线上方的任何内容都是技术债务，低于它的任何内容都不是技术债务。 这意味着技术负担使编写代码变得越来越困难，因为添加了更多代码。

The scalable solutions below the blue line are typically abstractions, libraries, and tools that make building software easier. Examples of this can range from building application-specific features like internal dashboards to utilizing libraries and tools like React or Docker (imagine how painful it would be to rebuild them for every project). The right tools and abstractions can impact multipliers, while technical debt is an impact divider.

蓝线以下的可伸缩解决方案通常是抽象，库和工具，这些工具使构建软件更加容易。 这样的示例包括从构建特定于应用程序的功能(例如内部仪表板)到利用库和工具(例如React或Docker)(设想为每个项目重建它们都是多么痛苦)。 正确的工具和抽象可以影响乘数，而技术债务则可以影响乘数。

As the graph depicts, technical debt can initially be the optimal path, but it needs to be refactored quickly if the application feature is to be successful. This supports the startup concept of launching ideas quickly as an MVP, and then rapidly iterating and improving them.

如图所示，技术债务最初可能是最佳途径，但是如果要成功实现应用程序功能，则需要快速重构。 这支持了启动概念，即作为MVP快速启动想法，然后快速迭代和改进它们。

First figure out which ideas gained traction, and then iteratively build them in a way that they can become scalable. A feature can launch by imposingO(n²)complexity on the code base (technical debt), but can be refactored toO(n)andO(log n)over time. TheO(log n)allows one person or a small team of people to produce the same output as a larger team building in a brute force manner.

首先确定哪些构想获得了关注，然后以可以扩展的方式迭代构建它们。 可以通过在代码库上增加O(n²)复杂度来启动功能(技术债务)，但是随着时间的推移可以将其重构为O(n)和O(log n)。O(log n)允许一个人或一小群人以蛮力方式产生与大群人相同的输出。

After reaching a sufficient company and code base size, you’ve reached a point that I’ve defined as the scalability threshold. At this point, the tools you have built versus the reward that it yields requires less effort than the linear approach. You should no longer build on top of the linear approach after crossing this threshold. Instead, invest in code that will allow you to produce more results while requiring fewer people and less effort.

在达到足够的公司和代码库大小之后，您已经达到了我定义为可伸缩性阈值的程度。 在这一点上，与线性方法相比，您所构建的工具与其所产生的回报所需要的精力更少。 超过此阈值后，您不应再基于线性方法。 相反，请投资代码，这些代码将使您产生更多的结果，同时需要更少的人员和更少的精力。

Theoretically, the linearO(n)solution is not technical debt. For every additional man hour you add, you will receive an equivalent payoff. However, this doesn’t always work in practice. Time, money, and human willpower are all limited resources. You will eventually hit a limit to the number of people you can hire. And workers burning out on repetitive tasks is a real concern. Software solutions that appear to scale linearly become technical debt when it requires people to build them.

从理论上讲，线性O(n)解不是技术债务。 每增加一小时工时，您将获得同等的收益。 但是，这在实践中并不总是有效。 时间，金钱和人力都是有限的资源。 您最终将达到雇用人数的上限。 而工作人员在重复性工作上精疲力尽是一个真正的问题。 当需要人们进行构建时，看起来可以线性扩展的软件解决方案就变成了技术债务。

一个真实的例子 (A real world example)

Imagine you’re building a revolutionary new service, called Citybrook, that create profiles for cities. Identify five key markets that interests you, let’s say San Francisco, Seattle, Austin, New York, and Nashville. Build some simple webpages using plain HTML and CSS, and then find a fit for the product in the market.

假设您正在构建一项革命性的新服务，即Citybrook，可为城市创建配置文件。 找出您感兴趣的五个主要市场，例如旧金山，西雅图，奥斯丁，纽约和纳什维尔。 使用纯HTML和CSS构建一些简单的网页，然后找到适合市场的产品。

Assume that users love the content. All cities in the U.S. are begging you to build pages built for them. You also realize your Amazon Web Services (AWS) bill is going to sky rocket because of all the traffic you are receiving. So you start placing ads on each webpage by pasting links for different merchants for the different cities. You quickly realize that the simple HTML solution isn’t going to scale. It’s anO(n²)complexity because you can’t feasibly build and maintain an HTML page with unique content for every city.

假设用户喜欢该内容。 美国所有城市都在请您建立专为他们而设计的页面。 您还意识到由于收到的所有流量，您的Amazon Web Services(AWS)账单将一飞冲天。 因此，您可以通过粘贴不同城市的不同商家的链接开始在每个网页上放置广告。 您很快意识到简单HTML解决方案将无法扩展。 这是O(n²)复杂性，因为您无法切实可行地构建和维护每个城市具有唯一内容HTML页面。

To solve this problem, you use React to template your pages and to render dynamic content. At this point, you’ve reduced the technical debt and made it more feasible to scale your company. You can now allocate time to generate content as opposed to building a unique page for every city.

为了解决这个问题，您可以使用React来模板化页面并呈现动态内容。 在这一点上，您已经减少了技术负担，并使扩大公司规模变得更加可行。 现在，您可以分配时间来生成内容，而不必为每个城市都建立唯一的页面。

You work long hours with your team, with the goal to create a profile for each city within a few months. However, you’ve become a victim of your own success. Competitors in other countries start to launch their websites, but you don’t have the capacity to expand.

您与团队一起工作很长时间，目标是在几个月内为每个城市创建个人资料。 但是，您已经成为自己成功的受害者。 其他国家/地区的竞争对手开始启动他们的网站，但是您没有扩展的能力。

Instead you try to hire quickly, but you can’t keep up. Some cities are requesting that their content be changed, but advertisers can’t afford your fees with the increased traffic, so their advertisements need to be swapped out. Manually creating and updating the profile for every city no longer makes sense. There just isn’t enough manpower to keep up with the scale.

相反，您尝试快速录用，但跟不上。 一些城市要求更改其内容，但广告商无法承受流量增加带来的费用，因此需要将其广告换出。 手动为每个城市创建和更新配置文件不再有意义。 只是没有足够的人力来跟上规模。

Thus, you decide to build a dashboard to allow cities to create and update their own pages. The total number of profiles on the site temporarily stops growing during development, but based on your popularity, you’re not losing any customers. Once completed, it requires only minimal effort to add a new city. Instead of spending many hours writing content, your team only needs to maintain and build the tool to empower your clients.

因此，您决定构建一个仪表板以允许城市创建和更新自己的页面。 网站的配置文件总数在开发过程中暂时停止增长，但是根据您的受欢迎程度，您不会失去任何客户。 完成后，只需很少的工作即可添加新城市。 您的团队无需花费大量时间来编写内容，而只需维护和构建工具来增强客户能力。

The larger your team grows, the more ability (and obligation) you have to write bulletproof code and pay back the technical debt that allowed you to scale to the size that you have achieved.

您的团队规模越大，您编写防弹代码并偿还技术债务的能力(和义务)就越多，这些债务使您可以扩展到已达到的规模。

Technical debt multiplies other technical debt. Building on technical debt and/or adding more debt typically causes an exponential growth in bad code. This means adding more features makes it increasingly hard to pay back the debt.

技术债务乘以其他技术债务。 增加技术债务和/或增加债务通常会导致错误代码呈指数增长。 这意味着添加更多功能使偿还债务变得越来越困难。

什么时候可以接受技术债务？ (When is tech debt acceptable?)

Customers don’t care what your code looks like. They just want your product. A single perfect feature that was never released and failed is worth nothing compared to a scrappy startup that has a handful of features that users gravitate towards.

客户不在乎您的代码是什么样。 他们只想要您的产品。 与拥有一些用户喜欢的功能的草率的创业公司相比，一个从未发布过且不会失败的完美功能毫无价值。

This thriving startup can then iterate on the features that gain traction and refine them to become more scalable. Once the scrappy startup finds success, they can then build their engineering team and pay back the technical debt. This will position them for future success.

然后，这个蓬勃发展的创业公司可以迭代获得吸引力的功能，并对其进行完善以使其更具可扩展性。 一旦这家蓬勃发展的初创公司找到了成功，他们就可以建立自己的工程团队并偿还技术债务。 这将使他们获得未来的成功。

The return from the technical debt must be higher than the debt itself. That is, whatever it is that you’re able to achieve by acquiring the debt, it must have a greater impact than the debt itself.

技术债务的回报必须高于债务本身。 也就是说，无论您通过获得债务能够实现什么目标，它的影响都必须大于债务本身。

Technical debt is not an excuse to be lazy. It should be used tactically with a long-term vision in mind. Startups should move quickly and test their ideas in the marketplace. Once they validate an idea, they should seek to understand the problem and the proper abstractions to scale it. Companies should then pay back their technical debt.

技术债务不是偷懒的借口。 在战术上应牢记长远的眼光。 初创企业应该Swift发展并在市场上测试他们的想法。 一旦他们验证了一个想法，他们就应该设法理解问题和适当的抽象来扩展它。 然后，公司应偿还其技术债务。

Contrary to popular belief, acquiring technical debt may actually be the optimal decision in many instances. Facebook’s motto for a number of years was “move fast and break things.”

与普遍看法相反，在许多情况下，获得技术债务实际上可能是最佳决策。 Facebook多年来的座右铭是“快速行动，打破困境”。

Acquiring technical debt is a huge factor in Facebook becoming the juggernaut that it is today. But it also poses a problem in that Facebook is difficult to be maintained at its scale. The reason that it worked is that they were able to scale more quickly than the debt that they acquired.

获得技术债务是Facebook成为今天的主宰者的重要因素。 但这也带来了一个问题，即Facebook难以大规模维护。 它起作用的原因是，他们能够比获得的债务更快地扩展规模。

Don’t take on technical debt for the sake of doing so. It takes experience, mistakes, and communication to keep the technical debt on track. However, understand that managing it correctly can be a powerful catalyst for growth. Many times, technical debt is the best path forward. Until it’s not.

不要为此而承担技术债务。 它需要经验，错误和沟通才能使技术债务保持正常。 但是，请了解正确管理它可以成为增长的强大催化剂。 很多时候，技术债务是前进的最佳途径。 直到不是。

At that point it can become the biggest impediment to progress.

在那时，它可能成为发展的最大障碍。

Understand it, control it, and use it as a tool, and it will help you build your startup.

了解它，对其进行控制，并将其用作工具，它将帮助您构建启动公司。

If you find this article helpful, please tap?.Follow me for more articles on React, Node.js, JavaScript, and open source software. You can also find me on Twitter or gitconnected.

如果您认为本文有帮助，请点击？。跟着我阅读有关React，Node.js，JavaScript和开源软件的更多文章。您也可以在T witter或连接的g上找到我。

gitconnected - The community for developers and software engineersJoin the only network built for developers. Display your portfolio, engage in discussions, and post trending news.

gitconnected-开发人员和软件工程师的社区加入唯一为开发人员构建的网络。显示您的投资组合，参与讨论并发布趋势新闻。

翻译自: /news/what-is-technical-debt-and-why-do-most-startups-have-it-9a54458daabf/

初创企业购买企业邮箱