如何鼓励团队重构

Question

我是一个由20人组成的团队，这是一个很大的组织的一部分。我们使用相同的代码库已经有5年了，并且已经发布了多个衍生项目。

我和团队成员进行了大约1:1的对话，他们中的大多数人也知道不同的代码气味，并且不喜欢它们，但是重构很少发生，因为总是有更重要的事情要做。我还问过管理层，我们是否可以对代码库进行更周密的规划或清理，但我基本上被拒绝了。团队中的每个人都以自己的方式进行规划，没有任何协调。

这里我不是在要求重构技术；我是在问有什么方法可以帮助创建一种为可维护性而不是纯功能而编写的文化。注:我不是经理，所以我不能只是口授。

Answer 1

不要要求管理层允许进行重构。不关他们的事。你最好先征得许可才能削铅笔。

管理层不理解重构。这不是生意上的需要。管理层不应该需要理解它。这不是他们的工作。这是你的了。

重构是您用来满足管理需求的工具。不要让管理层考虑这个问题。如果我的机械师问我汽车上用什么牌子的扳手，我会非常担心的。关心的不是工具而是机修工。

你需要做的是带领这个团队进行良好的实践。不要让管理层来指手画脚。即使他们尝试，他们也会把它弄得一团糟。

你需要与团队建立信任，向他们展示好处和成本，并接受改变不会立即发生。

有时候，横切关注点会扫过许多类，需要重构。有时候你现在做这件事是没有道理的，因为现在你只需要改变这一点。

很疼。你必须忍受在垃圾代码中工作，因为你没有时间。所以它需要越来越长的时间。

人们经常引用亚伯·林肯的话说：“给我六个小时砍倒一棵树，我会用头四个小时把斧头磨尖。”

在与管理层打交道时，不要争辩要磨尖斧头。争论六个小时。别指望把斧头磨尖就能得到表扬。完全不要为管理而做。这样你只需要花两个小时和这棵该死的树搏斗。

Answer 2

理解简单重构和重写之间的区别。当真正的意思是有针对性的重写时，人们经常使用“重构”这个词。用这种方法(按风险的顺序)来考虑不同之处：

• 重构是一个小的、容易逆转的更改，没有功能影响。
• 目标重写是对影响代码多个部分的应用程序的一个方面的重点重写。
• 全面重写就是抛弃旧的源代码，从头开始。

这里区别的原因是，一些代码修复对计划有真正的影响。任何时候，如果你想做一些影响计划的事情，你就需要买进。有一个方法可以买到，但你必须把它作为一个机会来出售。

重构应该只是一种很好的实践。就像一个童子军离开营地时的状况比他发现的要好(收拾别人的烂摊子)，事情就这样发生了。许多Java和C# IDE都有内置的重构工具，因此在整个应用程序中都会更新诸如重新排序参数列表和重命名代码之类的小东西。只要您正在修改的是内部API (而不是第三方交互的内容)，就没有任何实际的限制。

我认为，重要的是要认识到，一系列目标明确的重构可以产生与目标重写相同的效果，但不涉及相同程度的风险。我还相信，如果除了所谓的重构之外，在sprint中无法完成任何其他工作，那么您真正谈论的就是有针对性的重写。你不能把项目资金(即开发人员花在做一件事情上的时间和其他事情的时间)投入到影响如此大的事情上，而不需要从那些工作的人那里买到钱。重构是一种不会导致产品错过截止日期的工作类型。

需要确定目标重写的范围并对其进行规划。这就像改造厨房，你必须拆除一堵墙。在工作完成和添加新的支持之前，您需要做一些事情来支持现有的基础结构。这通常是一个可以接受的风险，它带来了一些优势，你以前没有。代码在过程中是混乱的，但是当它完成时，整个应用程序会更好。

出售目标重写的最佳方法是根据重写将使您的团队能够执行的新特性来限制它。

除非真的没有选择，否则应该避免整个范围的重写。这就像在用完全不同的东西取代房子之前，先拆除一所房子。除非你很清楚那所房子是如何被使用的，否则你会冒着新房子无法满足客户需求的风险。

有时候，确实需要进行一次大规模重写，但需要进行大量的研究才能确保您在完成任务时满足客户当前的所有需求。在现有代码中有很多细节是为一些长期被遗忘的特性编写的，这些特性仍然很重要。这类工作也有一些战略。

整个规模重写的一个概念是使用斯特兰格勒 模式。本质上，您正在与旧应用程序一起构建新应用程序，并在可能的情况下使用新应用程序。旧应用程序的存在越来越少，直到它被完全替换。这允许客户提供反馈，这样您就不会错过任何关键的细节。

Answer 3

重构应该作为开发的一部分进行。当您更改行为或添加新特性时，如果有必要，应重构受影响的代码，以干净地支持更改。遵循童子军的规则:总是把代码放在比你发现的更好的位置。

您不应该重构不需要更改行为的代码。您不应该执行与错误修复或新开发无关的重构。不要将重构与开发分开来估计或安排重构。就像编写单元测试和执行代码评审一样，它应该是所有开发的一个自然集成的部分，而不是一个单独的可协商的选项。

您鼓励将重构作为代码评审的一部分。只需问一个简单的问题，如果更改后的代码至少与更改前的代码一样干净。如果没有，则在编写代码之前进行改进。

不要做一个完美主义者--至少一开始不是这样。只要每次提交都能稍微改进代码，从长远来看，事情就会变得更好。