安卓项目重构减少多余代码_何时重构遗留代码与何时专注于当前项目-CSDN博客

安卓项目重构减少多余代码

by Sihui Huang

黄思慧

何时重构遗留代码与何时专注于当前项目 (When to refactor legacy code vs. when to stay focused on your current project)

When I work on projects, I often run into legacy code that can be improved — to be more readable, more testable, or more compliant with the current coding style. My urge to refactor the code is especially strong after spending a good amount of time trying to understand a piece of obscure code. That code hurts my brain, and I don’t want the same thing to happen to other developers. There is (the adaptation of) the famous Boy Scout Rule: Leave Code Better than You Found It.

当我从事项目时，我经常遇到可以改进的遗留代码-更具可读性，可测试性或更符合当前的编码风格。在花费大量时间试图理解一段晦涩难懂的代码后，我对代码进行重构的强烈愿望尤其强烈。这段代码伤了我的大脑，我不希望其他开发人员发生同样的事情。有(著名的)童子军规则(改编)： 让代码比您发现的要好 。

But at the same time, I also want to stay focused and make progress on my current projects. I worry that I might get distracted and spend too much time refactoring.

但同时，我也想保持专注并在当前项目中取得进展。我担心我可能会分心并且花费太多时间进行重构。

This is a dilemma I often face. I want to be the good samaritan leaving code better than I found it, an engineer turning all the messy code I come across into something clean and elegant. But I also want to stay pragmatic and ship projects quickly.

这是我经常面临的困境。 我想成为一名优秀的撒马利亚人，留下比我发现的更好的代码，一名工程师将我遇到的所有凌乱的代码转换为简洁明了的代码。 但我也想保持务实并Swift交付项目。

Balancing between refactoring the legacy code I come across and staying focused on my current project can be hard.

在重构遇到的遗留代码与专注于当前项目之间很难保持平衡。

A recent conversation with my manager on this topic provided me guidance to find that balance. Here are a few points I find helpful.

最近与我的经理就这个话题进行了交谈，为我提供了寻找平衡的指南。这里有几点对我有帮助。

您不必使代码完美。小改进仍然有用。 (You don’t have to make the code perfect. Small improvements are still useful.)

After I read a piece of legacy code, my brain immediately thinks about how it should be ideally. But refactoring that code from its current state to the ideal state sometimes requires an extensive refactoring. At its best, the required refactoring can be time-consuming. At its worst, it can turn into a rabbit hole that causes a big delay on the project.

阅读一段旧代码后，我的大脑立即想到了理想情况下的代码。但是有时会将代码从当前状态重构到理想状态需要大量的重构。最好的情况是，所需的重构可能很耗时。在最坏的情况下，它可能会变成一个兔子洞，导致该项目的大量延迟。

When I face cases like this, I used to either take a chance and do the extensive refactoring anyway or hold my nose and let the code stay stinky. Now I realize there is a happy middle point: I don’t have the make the code perfect. I can spend as much or as little time as I can afford to make the code a bit better.

当我面对这样的情况时，我曾经要么冒险，要么进行广泛的重构，要么or之以鼻，让代码保持臭味。现在，我意识到有一个快乐的中间点： 我没有使代码完美的方法。 我可以花更多或更少的时间使代码变得更好。

Small improvements I do can be still useful for the developers that come next. And those developers may have time to improve the code further, building upon the improvements I make.

我所做的一些小改进对于接下来的开发人员仍然有用。那些开发人员可能有时间根据我所做的改进进一步改进代码。

(PS: There’s no perfect nor ideal code. The moment you make a change, you see more improvements you can make.)

(PS：没有完美的代码也不是理想的代码。进行更改后，您会发现可以进行更多的改进。)

对您的重构进行时间限制。 (Time-box your refactoring.)

Time-boxing is a great technique to avoid rabbit holes. Before starting to refactor, do a quick estimation about how much time you can spend on refactoring legacy code without delaying the project too much. Write that number down.

时间拳击是避免兔子洞的好技术。在开始重构之前，请快速估算一下可以花多少时间来重构遗留代码，而不会延迟太多项目。写下那个数字。

Time-boxing your refactoring gives you the peace of mind knowing the main project will stay on track. And that makes the refactoring experience more enjoyable.

对您的重构进行时间装箱，使您可以放心，因为知道主要项目将继续进行。这样一来，重构体验将变得更加愉快。

将重构时间纳入项目估算中。 (Bake the refactoring time into the project estimation.)

Things can be even easier if you bake the refactoring time into the project estimation before starting a project. While estimating how much time a project might take, take a quick look at the code you need to touch: when was it first written? How readable and extensible is it? How much test coverage does it have? Unless there’s a hard requirement about when the project needs to be shipped, you should bake some refactoring time into the project’s timeline.

如果在启动项目之前将重构时间纳入项目估算中，事情会变得更加容易。在估算一个项目可能花费多少时间的同时，快速浏览一下您需要触摸的代码：它是什么时候编写的？它的可读性和可扩展性如何？它有多少测试范围？除非对何时需要交付项目有严格的要求，否则应在项目的时间表中花费一些重构时间。

After all, as we keep building upon a legacy codebase, refactoring it as we go is the best way to keep it healthy. And a healthy codebase, in turn, makes building new features faster and safer.

毕竟， 随着我们继续建立旧的代码库，在进行过程中对其进行重构是保持其健康的最佳方法。 而健康的代码库又可以使构建新功能更快，更安全。

重构具有教育意义。 (Refactoring is educational.)

Refactoring a piece of code is the best way to understand it. Compared to staying aloof and just reading a piece of code, coming in and modifying it gives you a much deeper and intimate relationship with the code.

重构一段代码是理解它的最好方法。与保持超然状态和只阅读一段代码相比，进入并对其进行修改可以使您与代码建立更深层次的亲密关系。

When you try to add your touch to the code, you will start to notice things you missed before. You may see the constraints and may even understand why the author originally wrote the code this way.

当您尝试向代码中添加内容时，您将开始注意到之前遗漏的内容。您可能会看到限制，甚至可能了解作者为什么最初以这种方式编写代码。

Although refactoring a piece of code doesn’t seem to add any immediate value to the business, it’s an opportunity for you to gain a piece of domain knowledge you currently don’t have. Gaining that domain knowledge is invaluable to both you and the business.

尽管重构一段代码似乎并没有给企业带来任何直接的价值，但它为您提供了获得当前尚不具备的领域知识的机会。 获得领域知识对您和企业都是无价的。

重构是您可以建立的一块肌肉 (Refactoring is a muscle you can build)

The more you do it, the faster you become. One last reason to refactor legacy code is to use it as an opportunity to strengthen your “refactoring muscle”. Investing in building your “refactoring muscle” has a self-reinforcing compound effect: the more you refactor, the better you are at refactoring, making your next refactoring faster. The more you do it, the better the codebase is, making building future features faster.

您做得越多，您变得越快。 重构遗留代码的最后一个原因是将其用作增强“重构能力”的机会。投资构建“重构肌肉”具有自我增强的复合效果： 重构的次数越多，重构的能力就越强，从而使下一次重构更快。 您做得越多，代码库就越好，从而可以更快地构建将来的功能。

Luckily, my next project relates to code from almost three years ago. I expect to face many cases requiring me to balance between refactoring legacy code and making progress on the project. I will share my new learning on my personal blog (NOT medium). Subscribe to follow along!

幸运的是，我的下一个项目与将近三年前的代码有关。我希望面对很多情况，要求我在重构遗留代码和项目进展之间取得平衡。我将在我的个人博客 (非媒体)上分享我的新知识。订阅跟随！

My career plan for the year is to grow into a tech lead. I’m excited about all the learnings ahead and would love to share this journey with you in a brutally honest fashion. I will be sharing my weekly learning on my personal blog (NOT medium).

我这一年的职业计划是成长为技术领先者。我对未来的所有学习感到兴奋，并希望以残酷诚实的方式与您分享这一旅程。 我将在个人博客 (非媒体)上分享我的每周学习情况 。

In the next few months, I will focus on growing in the following areas, so you can expect to see posts related to them:

在接下来的几个月中，我将重点关注以下领域的增长，因此您可以期望看到与它们相关的帖子：

focusing on the big picture of the project instead of near-term implementation details;
着眼于项目的整体情况，而不是近期的实施细节；
balancing my efforts between leading projects and coding;
在领导项目和编码之间平衡我的努力；
work-life balance for long-term productivity;
工作与生活之间的平衡，以实现长期生产力；
the human side of software development: making sure everyone riding with me enjoys the ride and feels fulfilled and inspired.
软件开发的人性化一面：确保与我一起骑行的每个人都喜欢骑行，并感到充实和启发。

Originally published at www.sihui.io on February 1, 2019.

最初于2019年2月1日发布在www.sihui.io 。