技术债务

by Gabriel Colombo

加布里埃尔·科伦坡(Gabriel Colombo)

如何处理技术债务并节省理智 (How to deal with technical debt and save your sanity)

When was the last time you found yourself working in a file containing 7,000+ lines of code?

您上次发现自己在包含7,000多行代码的文件中工作的时间是什么时候？

I’m doing exactly that at this very moment. Refactoring some functionality from a legacy project along with writing this article.

我正在此刻做这件事。 在撰写本文的同时重构旧项目的某些功能。

Trust me, this sucks.

相信我，这很糟糕。

Unfortunately this is a reality for tons of developers. Projects grow out of control for various reasons. A particular change might not fit the current process or become ineffective in the long run.

不幸的是，对于许多开发人员来说，这是现实。 由于各种原因，项目无法控制。 从长远来看，特定的更改可能不适合当前的流程或无效。

These situations often lead to developers implementing temporary solutions to keep things running. There’s nothing wrong with that.

这些情况通常导致开发人员实施临时解决方案以保持运行。 没有错。

The problem starts to aggravate when these solutions get reused in different functionalities.

当这些解决方案在不同功能中重用时，问题开始恶化。

Re-using a solution without understanding the conditions under which it was developed, and what problem it was to solve, only increases your technical debt.

在不了解解决方案开发条件和解决问题的情况下重复使用解决方案只会增加您的技术负担。

什么是技术债务 (What is technical debt)

The following statement reflects my favorite definition of technical debt:

以下陈述反映了我最喜欢的技术债务定义：

A set of intentful trade-offs made during various development stages of an application.

在应用程序的各个开发阶段进行的一系列有意的权衡。

But what does it mean?

但是这是什么意思？

When creating a new product, important decisions must happen at every stage. Each decision holds a particular weight that affects the development process. Trade-offs must occur.

在创建新产品时，必须在每个阶段做出重要决策。 每个决定都具有影响开发过程的特定权重。 必须进行权衡。

“Do we sacrifice coding standards so we can ship faster?”

“我们会牺牲编码标准，以便我们更快地发货吗？”

“How do we create this feature without over-engineering? It doesn’t need a complete architecture right now, but we’re gonna have to improve it later on.”

“我们如何在不过度设计的情况下创建此功能？ 它现在不需要完整的体系结构，但是我们稍后必须对其进行改进。”

As we make more decisions, these trade-offs start to impact the development process. Maintenance problems arise and new features aren’t shipped as fast as they used to be.

随着我们做出更多决策，这些权衡取舍开始影响开发过程。 出现维护问题，并且新功能的发布速度没有以前那么快。

This is the moment where motivation goes down the drain.

这是动机消退的时刻。

I worked on projects based on the following premise:

我基于以下前提从事项目：

“We’re going to switch to a different technology and everything will get discarded. For now, as long as it works, don’t worry too much about coding standards.”

“我们将切换到另一种技术，一切都会被丢弃。 就目前而言，只要可行，就不必担心编码标准。”

If it doesn’t sound too bad for you, let’s look at it from a different angle:

如果听起来对您来说还算不错，让我们从另一个角度来看它：

“We’re all going to die at some point, so while you’re alive, do whatever you want and don’t worry about the consequences.”

“我们都会在某个时候死去，所以当你还活着的时候，做任何你想做的事，不用担心后果 。”

See what I mean?

明白了吗？

Each project should have a set of standards, so that everyone knows how they should do things. These standards should always matter while there’s people working on the project.

每个项目都应该有一套标准，以便每个人都知道应该如何做。 当有人在项目上工作时，这些标准应该总是很重要。

为什么要重构？ (Why refactor?)

Back when I was a junior developer at my first job, we were a team of 5, so everyone had to wear many hats at once.

当我刚开始担任初级开发人员时，我们只有5人一组，因此每个人都必须同时戴很多帽子。

I started developing both front and back-end with Laravel. It took time to learn the framework and understand the PSRs (PHP Standards Recommendations), since I’ve never dealt with it before. During this period, some of the code I wrote didn’t meet the standards.

我开始使用Laravel开发前端和后端。 由于我以前从未处理过该框架，因此花了一些时间来学习该框架并了解PSR (PHP标准建议书)。 在此期间，我编写的某些代码不符合标准。

Every Monday I went back and took a look at the code I wrote the week before and everything met the standards. My boss refactored weekly, and sometimes daily if something seemed outrageous.

每个星期一，我都会回去看看前一周编写的代码，所有内容都符合标准。 我的老板每周进行一次重组，如果有些事情看起来令人发指，则有时每天进行一次重组。

This constant refactoring made the project’s structure somewhat unpredictable. Things did break from time to time, especially when working on different branches. Oh well, you know what they say:

这种不断的重构使项目的结构有些不可预测。 事情确实有时会中断，尤其是在不同分支上工作时。 哦，你知道他们说什么：

So one day we were having lunch together and I decided to ask why he refactored our code so often. His answer was something like this:

因此，有一天我们一起吃午饭，我决定问为什么他如此频繁地重构我们的代码。 他的回答是这样的：

“If I don’t refactor, no one will.

“如果我不重构，没人会。

We have a very small team, but eventually it will grow.

我们的团队非常小，但最终会成长。

If you go to our codebase and find it messy and out of standards, you probably won’t take the time to make things right, you’ll simply add another if statement and move on, but if everything is neat and tidy, you’ll feel like doing something wrong by not following the standards”.

如果您进入我们的代码库，发现它凌乱且不符合标准，则可能不会花时间将事情做对，您只需添加另一个if语句并继续进行，但是如果一切都整洁，则您可以如果不遵循标准，就会觉得自己做错了。”

That conversation changed the way I see things, not only as a developer, but as an individual. For that I’m grateful.

对话不仅改变了我作为开发人员的身份，而且改变了我个人的观点。 为此我很感激。

James Q. Wilson and George L. Kelling explored the general concept of his explanation with the Broken Windows Theory.

詹姆斯·Q·威尔逊(James Q. Wilson)和乔治·科林(George L. Kelling)通过“破碎的窗户理论”探索了其解释的一般概念。

Broken windows theory — WikipediaThe broken windows theory is a criminological theory of the norm-setting and signaling effect of urban disorder and…en.wikipedia.org

窗户破损理论—维基百科 窗户破损理论是一种犯罪理论，主要涉及城市混乱和……的规范制定和信号传递作用 。en.wikipedia.org

Their theory presents the following concept:

他们的理论提出了以下概念：

An ordered and clean environment, one that is maintained, sends the signal that the area is monitored and that criminal behavior is not tolerated. Conversely, a disordered environment, one that is not maintained (broken windows, graffiti, excessive litter), sends the signal that the area is not monitored and that criminal behavior has little risk of detection.

一个有序，整洁的环境(可以维持的环境)会发出信号，指示该区域受到监视，并且不容忍犯罪行为。 相反，没有维护的混乱环境(破窗，涂鸦，乱扔垃圾)会发出信号，表明该区域未受到监控，犯罪行为几乎没有被发现的风险。

This makes so much sense when related to programming. If no one cares, low quality code gets shipped and the project gets harder and harder to maintain in the long run.

与编程相关时，这非常有意义。 如果没有人关心，从长远来看，低质量的代码将被交付，并且项目将变得越来越难维护。

Knowing this little backstory, let’s have a look at when to consider refactoring your code.

了解了这些小故事，让我们看看何时考虑重构代码。

何时重构代码库 (When to refactor your codebase)

Constant refactor provides consistency, higher productivity and more control over the codebase.

常量重构可提供一致性，更高的生产率以及对代码库的更多控制。

You should consider refactoring your code if:

在以下情况下，您应该考虑重构代码：

• The project will continue to run for a long time.该项目将继续运行很长时间。
• You’re having maintenance problems. (Difficulty on finding and solving problems or making changes to a particular feature).您遇到维护问题。 (难以发现和解决问题或对特定功能进行更改)。
• Certain functionalities are inconsistent (The same component behaves differently on different pages).某些功能不一致(同一组件在不同页面上的行为不同)。
• There’s too much code duplication.代码过多。
• Your functions have way too much business logic.您的功能有太多的业务逻辑。

何时抵制重构的冲动 (When to resist the urge to refactor)

• The project won’t grow and doesn’t need much maintenance.该项目不会增长，也不需要太多维护。
• You lack automated testing and isn’t planning on implementing them.您缺乏自动测试，也没有计划实施它们。
• You wanna migrate to a different technology because it’s trendy.您想迁移到其他技术，因为它很时髦。
• When refactoring will consume too much time.重构时会消耗太多时间。

结论 (Conclusion)

Technical debt is a huge deal on any project, especially on legacy projects. The earlier we take action to keep it under control, higher the end quality will be.

技术债务对任何项目而言都是一笔巨款，尤其是在遗留项目上。 我们越早采取行动来控制它，最终质量就会越高。

Constant refactoring helps you reduce dependencies and increase maintainability. The codebase becomes easier to test and reason about.

常量重构可帮助您减少依赖性并提高可维护性。 代码库变得更容易测试和推理。

As a starting point, try spotting some of the situations listed above and think about how to improve them. Here’s a great article to help you get started.

首先，尝试找出上面列出的一些情况，并考虑如何改善它们。 这是一篇很棒的文章，可以帮助您入门。

Thanks for reading! I hope you enjoyed this article.

谢谢阅读！ 希望您喜欢这篇文章。

If it helps you in any way, please help me spread the word by sharing it :)

如果它以任何方式对您有帮助，请通过分享来帮助我传播：)

Oh! Also, say hello to me on twitter — @gcolombo

哦! 另外，在Twitter上对我问好- @gcolombo

翻译自: https://www.freecodecamp.org/news/tame-your-tech-debt-by-refactoring-more-often-fcc34dd24a33/

技术债务