技术债务_技术债务的10倍解决方案

Case study on an early-stage startup’s React.js front end

早期创业公司React.js前端的案例研究

You blame high technical debt for low velocity. You get asked: How much time do you need to address it? Unknown. But when will you start seeing a tangible improvement in productivity? If you do it right, from day one.

您将技术欠佳归咎于速度慢。 您会被问到： 您需要花多少时间解决？ 未知。 但是，什么时候开始看到生产率的切实提高？ 如果做得对， 从第一天开始 。

This is a compilation of practical advice on how to get the fastest, front-loaded ROI during this process.

这是有关如何在此过程中获得最快的前端投资回报率的实用建议的汇总。

明智地选择您的重构战斗 (Choose your refactoring battles wisely)

识别 (Identify)

Use product-driven bugs, new features or change requests as opportunities to identify refactoring candidates.

使用产品驱动的错误，新功能或变更请求作为识别重构候选者的机会。

跟踪 (Track)

Prefer a tool that facilitates communicating this work with the business and provides transparency.

建议使用一种工具来促进与企业的交流，并提供透明度。

划分 (Divide)

You don’t have to refactor modules or even components in full. Break work down to smaller tasks and prioritize separately.

您不必完全重构模块甚至组件。 将工作分解为较小的任务，并分别确定优先级。

The same principle applies for new code too; it doesn’t have to be “state of the art”, it’s okay to reuse patterns that you are planning to change but not just yet.

同样的原则也适用于新代码。 它不必一定是“最新技术” ，也可以重用您打算改变的模式，而不仅仅是现在。

优先排序 (Prioritize)

Some of the parameters you’ll need to consider:

您需要考虑的一些参数：

1. The frequency of change requests

   变更请求的频率

   If a certain feature is not frequently touched, the value in refactoring it, is minimal.

   如果不经常触摸某个功能，则重构它的价值将很小。

2. The product roadmap

   产品路线图

   Refactoring a soon to be a deprecated module, even if it’s frequently changed, could be mostly a throwaway.

   即使将其频繁更改，将很快重构为已弃用的模块也可能会很容易被丢弃。

3. Onboarding and mentoring

   入职和指导

   New developers tend to follow patterns found in the existing codebase; this is acceptable and desirable. Removing code smells from modules that you use as a reference can save you and your team time.

   新的开发人员倾向于遵循现有代码库中的模式。 这是可以接受和期望的。 从用作参考的模块中消除代码异味可以节省您和团队的时间。

4. The cost of identifying, tracking, and prioritizing itself

   识别，跟踪和确定自身优先级的成本

   If you see a quick win, it’s better to go for it immediately and avoid the overhead of re-identifying, tracking, and communicating the issue. Just be sure it is indeed quick.

   如果您看到了捷径，最好立即采取行动，避免重新识别，跟踪和传达问题的开销。 只要确保确实如此即可。

5. Future technical debt

   未来技术债务

   Adapting to an evolving product and new technology, or even to your own improved skills and domain knowledge means that regardless of how much thought you put on a design today, you are also introducing the technical debt of tomorrow. Avoid refactoring something until you see clear value in doing so.

   适应不断发展的产品和新技术，甚至适应您自己提高的技能和领域知识，意味着无论您今天对设计有多大的想法，都在介绍明天的技术债务。 避免重构，直到您看到这样做的明显价值为止。

Our phase 1 refactoring was a mix of critical architectural issues (e.g. extensive prop drilling — poor component wiring), quick wins (e.g. converting magic numbers to semantically named constants), and building the most commonly used core components (buttons, form fields, etc).

我们的第1阶段重构是混合了关键的架构问题(例如，广泛的道具钻Kong-不良的组件布线)，快速的胜利(例如，将魔术数字转换为语义上命名的常量)以及构建最常用的核心组件(按钮，表单字段等) )。

Looking for some quick wins? Here’re 5 good tips that mostly aim to reduce cognitive complexity.

寻找一些快速的胜利？ 这里有5条很好的技巧 ，主要旨在降低认知的复杂性。

回归分析 (Regressions)

You’ll often hear that to refactor some code, you should start by covering its functionality with automated tests first (if there aren’t any). We couldn’t do this. A trick to mitigate the risk of regressions is to always combine refactoring with some product-driven work. Then QA and UAT for that work will naturally cover the refactored code too.

您经常会听到，为了重构某些代码，您应该首先使用自动化测试(如果没有的话)介绍其功能。 我们做不到。 减轻回归风险的一种技巧是始终将重构与某些产品驱动的工作结合在一起。 然后，这项工作的QA和UAT也自然会涵盖重构的代码。

测试覆盖面不止一个数字 (Test coverage is more than a number)

Going from 0% to optimal test coverage takes time. During this journey, whatever your coverage is, make it as worthwhile as possible. Here’s how:

从0％达到最佳测试覆盖率需要时间。 在此过程中，无论您的覆盖范围是什么，都应尽可能使它值得。 这是如何做：

从集成测试开始 (Start with integration tests)

They will cover larger areas of functionality more quickly and provide you with more confidence. Read Kent C. Dodds’ blog for more best practices in testing.

它们将更快地覆盖更大的功能区域，并为您提供更多的信心。 阅读Kent C. Dodds的博客 ，了解更多测试最佳实践。

优先确定应首先测试哪些组件 (Prioritize which components should be tested first)

Some things to consider:

要考虑的一些事情：

1. Complexity

   复杂

   Overly complex components are more susceptible to regressions.

   过于复杂的组件更易于回归。

2. How popular is the user journey that the component belongs to?

   该组件所属的用户旅程有多受欢迎？

   A regression that manifests during a very common user journey can quickly and severely hurt the product’s credibility.

   在非常普通的用户旅程中出现的回归可能会Swift严重损害产品的信誉。

3. Business-specific importance factors

   特定于业务的重要因素

   If an admin-only platform configuration form is the first thing a user does when evaluating your product, although it doesn’t affect many users, it still could be relatively high-priority.

   如果用户在评估产品时首先要做的是仅管理员平台配置表单，尽管它不会影响很多用户，但它的优先级仍然较高。

4. Previous regressionsUsers are less forgiving when it comes to repetitive issues on things that they have already brought to your attention. The rule of thumb is that you should write tests asserting every bug fix you deploy.

   以前的回归对于涉及已引起您注意的问题的重复性问题，用户不太宽容。 经验法则是，您应该编写测试来断言所部署的每个错误修复程序。

监控与测量 (Monitor and Measure)

Yes! If you’re doing this right, your team velocity should be increasing every day and after a few months, the improvement should be significant.

是! 如果您做对了，您的团队速度应该每天都在增加，几个月后，改善应该是显着的。

If you really want to see the debt reduction progress in numbers, you can set up some tools, besides the test coverage report, that monitor the health of your codebase. This could also reinforce the business’s confidence in your approach.

如果您确实希望看到减少债务的进度，可以设置一些工具，除了测试覆盖率报告以外，还可以监视代码库的运行状况。 这也可以增强企业对您的方法的信心。

We’re using both the CodeClimate CLI and SonarQube. Both of these tools come with specific suggestions about what should be refactored, however, we mostly use them to get summaries and check how the code quality is trending over time.

我们同时使用CodeClimate CLI和SonarQube。 这两个工具都带有有关应重构内容的具体建议，但是，我们大多使用它们来获取摘要并检查代码质量随时间的变化趋势。

We went from 1490 issues in February 2019 to 786 in May 2020 (-47%). The results are even more impressive if we focus only on those categorized as “Major” (-57%). Note that despite the continuous development of new features, the total lines are down by 18%, which is another by-product of the ongoing refactoring.

我们从2019年2月的1490期增加到2020年5月的786期(-47％)。 如果我们只关注那些被归类为“主要”(-57％)的结果，结果将更加令人印象深刻。 请注意，尽管不断开发新功能，但总行数却下降了18％，这是正在进行的重构的另一个副产品。

外卖 (Takeaways)

优先，优先，优先。 (Prioritize, prioritize, prioritize.)

Addressing your technical debt means that you’re working today on improving your tomorrow’s productivity. In this context, timing is more important than anything else.

解决您的技术债务意味着您正在努力提高明天的生产率。 在这种情况下， 计时比什么都重要。