如何使重构成为我团队的优先事项？

我每天使用的代码库没有自动测试，命名不一致以及大量注释，例如“为什么在这里？”，“不确定是否需要此方法”或“此方法的名称不正确”，并且代码乱七八糟尽管我们使用源代码控制，但仍存在“ Changelogs”。可以说，我们的代码库可以使用重构。

我们总是有修复错误或添加新功能的任务，因此没有时间将代码重构为更好和更模块化的代码，而且似乎也不是优先考虑的事情。

我如何证明重构的价值，以便将其添加到我们的任务列表中？在我进行重构时，请求宽恕而不是允许是值得的吗？

“请求宽恕比允许更好”是事实。

为什么要担心呢？只需重构最恐怖的部分。

您已经知道最昂贵的错误是什么，对吧？

如果您没有这样做，那么第一步就是要明确明确地定义最昂贵，最复杂，最易出错，且出没虫子的问题代码。

确定故障单的数量，调试时间以及其他非常具体，非常可衡量的成本。

然后修复该清单中的高成本问题。

当您不得不请求宽恕时，可以指出降低成本的目的。

如果您不知道，则重构需要进行 单元测试以证明前后行为匹配。理想情况下，这应该是自动化的编码测试，例如单元测试。

这意味着选择一件事。编写单元测试。解决那件事。您已经进行了两项改进。（1）编写了测试，（2）修改了代码。

重复。

遵循童子军规则：将营地（代码）比发现的要好一些。我从未听说有人写过“在他们在那里的时候”对小代码进行改进的文章。

我会采取一种过于愤世嫉俗的观点。

重构是如此难以吞咽。您将承担责任和承担责任，而您的工作成果通常会转移到基于您的纯净代码库的其他人身上。

我要说的是，如果这种工程实践已成为贵公司的文化，那么您可能需要在更高层次上进行斗争。您并不是真正在为重构而战，而是在为卓越的工程而战，而这种变化只有在管理人员将其付诸实践时才浮现出来。在这种情况下，他们可能会向外部寻求最佳实践沙皇，无论如何您的所有好主意都会被包含在内。

考虑加入另一家公司，他们会更加重视工程实践。

我注意到，这里的许多张贴者似乎都相信管理中的问题-尽管问题没有提及。

我会走得更远：在我看来，糟糕的代码库几乎永远不会直接是管理的错误。管理层没有写代码，开发人员写了代码（我公司有些例外，我们目前的一些管理层实际上是在写初始代码库）。因此，文化问题在于开发人员-如果他们想改变文化，他们自己就必须改变。

我也尝试将这种认识和态度转变带给“我的”开发人员。每当他们问我“我们什么时候有时间重构？”时，我都会惊讶地回答，“您应该一直在重构！”。我认为可以保持代码库健康的唯一方法是三方面：

1. 仅添加健康代码。
2. 始终在看到错误代码后立即对其进行修复。
3. 如果出于截止日期的原因而不能执行1或2，则始终具有“截止日期之后立即修复”问题的列表，并且不接受任何借口，因为未在截止日期之后浏览该列表。

开发人员的下一个评论总是“但我们如何有时间这样做-我们现在没有时间？”。唯一正确的答案（再次恕我直言）是“您没有时间不这样做”。如果您不保持代码库的健康，您会发现周转时间越来越长，日程安排变得更加不可预测，错误变得更加棘手，价值也越来越低。

您需要在开发团队中实现的最大态度转变是，“质量”不是您在特定时间（“我们有时间重构时”）要做的事情-这是您始终必须做的事情。

最后，一个警告的故事。如果按下，我将否认这种情况曾经发生过。在我供职的一家公司中，有一个长期存在的应用程序，其源于10年前的大型旧代码库。包括我在内的许多开发人员都认为该旧版代码库很糟糕或至少已经过时，而不是最新技术。因此，我们成功地游说了一个大型的重构​​项目，并开始了重写项目，之后我们相信一切都会更好。
我们使用新的库和新的语言功能，长期努力地以新的和现代的方式实现几乎所有内容。在接近尾声时，我们付出了巨大的努力将所有内容整合在一起，以允许使用具有改进的新代码库的新版本发布长期存在的应用程序。
不出所料，由于我们还不熟悉新库，并且我们的代码中还没有预见到一些交互，因此新版本存在一些初期问题。但是，我们最终设法使该发行版与以前的发行版达到相同的标准，并大为宣传。我们为自己的“成功”松了一口气。然后，一组开发人员回到管理层，要求一个新的重构项目，因为我们的新代码还不是他们期望的万灵药，而且他们看到了一些机会来完全重写一些东西...

故事的寓意：通常事情并没有看上去那么破灭，“重新开始”通常意味着您将以一系列已知的问题与一组最少的未知问题进行交易。一次重构一个部分！

曾经有人告诉我，当我去面试时，我不应该忘记我也在面试公司。这是我要工作的地方吗？他们会进行代码审查吗？他们有自动集成测试吗？单元测试？他们如何看待结对编程？就我个人而言，我会找到另一份工作，这次不要忘了问一些问题。

老实说，找到另一家公司。对开发过程的这种改进需要巨大的文化飞跃，每个人都需要花费大量时间才能进入同一页面，届时您将不再那么在乎。

如果您觉得自己仍在打架并且还没有失败，那么请进行最后的推动。尝试从志同道合的团队成员那里获得尽可能多的支持，向关心您的福祉的上司披露您的精疲力尽，直截了当地绕开并疏远任何可能反对您的信念的人，并尝试在一些强制性的重构时间中投入新的计划项目/功能。

如果您对自己的工作充满热情并关心公司，那将是您值得赞扬的努力。如果不了解它，那么请尊重自己并摆脱困境，然后再变成一个空洞的程序员。

如果我不得不引入一种实践来使这种情况下的事情变得更好，那就是代码审查。代码审查是

• 通常被开发人员直观地认为是获得更好的代码，减少错误等的因素。
• 合作民主
• 如果您对它们进行适当的计时，不会太耗时
• 如果您在“正常”开发期间没有时间进行重构，那么这是一个很好的地方
• 一个非常有效的特洛伊木马，可以逐步在代码设计，单元测试方面引入各种最佳实践...

您不必系统地进行代码审查，仅在最初提交大型/复杂代码部分时才需要。

当然，如果您认为在引入代码审查之前需要获得官方的认可，则可能必须先说服您的老板，如果情况保持原样，代码库可能会崩溃。

这是我在这种情况下的工作（在作为开发人员的15年间，我几乎每天都遇到这种代码）

1. 以身作则-我确保重构我接触的代码。我无情地删除了旧的注释代码和大段注释。
2. 每次要求我检查代码更改时都要求进行重构，否则，我将不批准代码检查。
3. 当代码变得更精简，更易读并减少错误时，人们慢慢看到了更改。这需要时间，但是整个团队逐渐赞赏并采纳了这种做法。

管理层从不为重构代码留出时间（他们永远没有足够的资源！），因此，缓慢而稳定地执行代码是一种正确的方法。

让管理层对“技术债务”进行一些研究。还请他们参考“破窗理论”，这两种影响都直接影响效率，质量和士气。

“干净的工作场所是安全且生产效率高的工作场所”，对混乱的每一个贡献都以指数方式（而不是线性的）使混乱变得更加复杂。

如果这种情况得不到解决，最终您将越过无可挽回的地步，在经济上变得不可行，在此之前逐步进行处理，好处就会反弹，从而为您解决问题提供更多的动力。

听起来您的问题更普遍。
重构问题既是症状，又是部分问题的潜在缓解。

软件负责人和团队分配团队的时间

根据我的经验，我认为您可能会遇到一个我称之为“每个人都是软件经理”的问题。产品经理，项目经理，有时还包括系统工程师和测试人员，可能会因为试图微观管理可能已经拥有经验丰富的软件经理的开发人员而臭名昭著。您甚至可能在团队中有一些成员相信他们的角色是管理。

如果您是软件经理，请为所需的重构分配任务，或者更好的是，让您的团队建议重构以供您批准。为了避免微管理，您可能有关于重构的年龄/作者/大小/上下文的准则，这些准则可以自由重构与需要批准。如果您的团队中的一个成员想要大规模重构他没有编写的，不是他编写的复杂的旧代码的四大类，那么他两周的转移就是您的问题，因此您需要有机会说不。

您可以偷偷摸摸，但是我认为最好是花一些时间仔细地分析，设计，编码，进行多种形式的测试（至少是单元和集成），重构和风险，并根据历史判断和缺乏风险来进行估算。与任务相关的经验或清晰度。如果您对团队的工作过于开放（或团队中有成员），那么缩小沟通渠道是明智的选择，这样他们可以与您讨论资源和结果，而不是方法。

早期的项目选择会为重构带来恶性循环

软件维护很困难。如果组织中的其他人以您为代价进行选择，这将非常困难。这是错误的，但这不是新的。Barry Boehm已经解决了这个问题，他是我们的杰出软件作家之一，他提出了他描述为Theory W的管理模型。

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

通常，软件开发人员会因按Theory-X管理方法进行生产而受到重创，该管理方法表示工作人员基本上是懒惰的，除非进行提交，否则他们不会执行。Boehm总结并对比了他提出的模型，如下所示：

“除了将管理者描述为独裁者（理论X），教练（理论Y）或促进者（理论Z）之外，理论W还描述了经理在各个选区与项目解决方案打包者之间的主要谈判角色。除了为各方争取胜利的条件之外，经理还是目标制定者，目标达成情况的监督者，并且是寻求日常输赢或输输项目冲突，与之面对的积极主义者，并将它们转变为双赢局面。”

快速与肮脏通常就是肮脏

Boehm继续指出，对于维护团队中的开发人员来说，事情如此痛苦的原因。

“对于软件开发人员和客户来说，构建快速，草率的产品可能是低成本，短期内的“胜利”，但对用户和维护者而言则是“失败”。” 请注意，在Boehm模型中，客户更多是合同管理员，而不是最终用户。在大多数公司中，将产品经理视为客户代理，或者将购买产品的人员视为其功能列表。

我的解决方案是在代码重构为至少满足编码标准之前，不释放原始开发团队（或至少原始领导）。

对于客户而言，我认为将产品经理视为客户的代理人是合理的，并且因快速而肮脏的交付而获得奖励的人群肯定可以扩大，因此有很多选民以错误的方式做事。

重构不可商议

请不要放弃您作为软件经理的角色。您应具有权力和酌处权，以使用团队的时间进行过程和产品改进。担任该职位时，您可能需要协商选择，以使您的团队更加专业。但是，关于流程，不要与营销进行谈判，因为根据我的经验，那是一场失败的游戏。与工程管理部门协商。它表明你有远见。建立专业的软件团队是他们角色的延伸，并且更有可能被视为双赢。

您随时可以等待。最终，团队将错过足够的截止日期，并生产出足够多的错误软件，管理层将全力以赴，并说，天哪，有更好的改变了！

好吧，这是一个冒险的主张。但这实际上是几年前在我们商店发生的事情（部分困难是与管理层沟通有关截止日期的问题，但这是另一回事了），这也是我们现在拥有成千上万的自动化测试，共享代码所有权，重构的自由，删除无效代码的意愿以及我们拥有的最高质量的版本。

也许最令人惊讶的是，没有人在此过程中丢掉工作-我要感谢老板为我们而战，还有一位顾问代表我们为重构和持续整合辩护。当有人从外面说出来时，这听起来总是更有说服力的。

我认为如何找到时间的答案取决于您为什么要重构代码。

如果可行，则不需要特殊的重构，而您只需触摸代码的那一部分即可。因此，您不需要特别的时间。

如果这会减慢团队的发展，则需要与团队负责人讨论，并创建特殊的任务进行重构，这样您就会有时间。

对于运行速度和其他情况，如果重构可以改善某些方面，而不仅仅是“看起来不错的代码”或您的意见，代码的外观如何，并提供真正的好处，创建任务或与负责的人交谈，则同样如此。

我对您描述事物的方式有些笑，因为这听起来与我正在研究的代码库非常相似，所以我认为我们的情况非常相似。幸运的是，在我的情况下，我有一个有远见的经理，他决定使代码库更好的最佳方法是使用现代Web开发框架进行模块化，而不是仅仅重构整个代码库。这样，可以将主应用程序中的麻烦点重写为单独的模块，然后将其集成到主应用程序中（但仍然是基本独立的）。这可能是您要提出的一种方法，因为它不需要重构正在使用的整个（大概很大？）代码库。

当然，我可能与您所说的有些出入，因为您的代码库可能不如我使用的代码库那么糟糕，在这种情况下，我会说为什么不随便进行一些小的优化？我团队中的开发人员可以轻松地删除愚蠢或过时的注释和此类内容，并且我认为这不需要管理人员的投入，因为通常开发人员会获得一些根据需要进行优化的权力。

如果代码库确实很脆弱，那么您需要小心，这可能就是为什么他们可能不想进行大型重构的原因，因为这最终可能会变成一个长达几个月的项目，并且可能需要分支一个项目并将开发人员放在该项目上项目，并摆脱其他开发任务，例如可能导致他们失去客户的即时错误修复等

考虑到所有事物，就其他人说您应该辞职等而言，我认为这取决于管理层如何看待事物，如果他们了解情况并意识到为什么某些事物可能花费比最佳状态更长的时间，那么一切都会好起来的。就工作环境而言，但如果他们不断积压工作积压，随着时间的流逝，这可能会变得有害。我很幸运的是，管理人员基本上意识到该应用程序是一堆废话，但它确实有很多客户并带来了收入，因此即使在短期内，它仍然很有价值并且值得修复错误。 。

您的主要问题是代码无法获得足够的可见性。

我建议使用诸如Jenkins之类的持续集成工具以及与之集成的静态代码analisys工具，该工具可以测量圈复杂度，命名标准，代码长度等。

当程序员进行更改时，Jenkins将运行单元测试，在其上运行静态代码analisys工具，并生成每个人都能看到的网络报告，并具有类似于交通灯的颜色状态。

当每个人（尤其是团队的领导者和老板）都可以看到代码质量时，版本控制和单元测试就可以为您提供支持……人们感到被鼓励进行重构。

在许多小的更改之后，代码就慢慢地采用了这种方式。它也需要以这种方式修复。

首先，您可以执行此操作-将所有估算值增加10％，以实现代码增强和长期维护。如果有人抱怨，问他们是否最好每周检查一次汽车发动机机油或等到发动机完全锁死。

开会并确定一致的编码标准。

介绍在使用过程中要使用的基本规则：

每当将新代码引入到类中时，都必须编写自动测试以证明该类有效（而不仅仅是新代码）。

只要修复了错误，就必须编写自动化测试来证明该类有效（而不仅仅是固定的代码）。

每当程序员修改文件时，他都必须修复该文件中的所有编译器警告并更新代码，以使其符合新的编码标准。

一段时间后，最常用的代码将是最新的，并由自动化测试覆盖。较旧的代码将在更改时进行更新，如果从未更改过，则无需担心。

重要的是将这些习性构建到标准编码任务中，因此它们都不会使“真实”工作花费大量时间，但它们都能带来真正的好处。不要试图通过重构旧代码来创建项目，这是一种可怕的，无聊的，轻率的痛苦，对于非技术人员来说，这似乎是很多时间的浪费！

获取所需资源（时间）的方法是专注于使能力和需求保持一致。您的老板受目标（通常是新功能的利润或交付时间）的驱动，并且随着工程师浪费时间并吃掉这些目标，他会进行重构。您需要找到一种方法说服他，如果您花费时间进行重构，将会达到并超出目标。

因此，第一步是找出老板感觉到的痛苦。确定他最大的问题是什么。然后弄清楚您想做什么与解决他的问题相一致，并提出一个强有力的业务案例。使用缺陷跟踪和项目计划系统（时间超支）来提供问题所在的证据。您需要事实，而不是感觉。如果没有度量标准（错误计数/模块，修复这些缺陷的成本），则重构仅是程序员自费而已。您的老板只有在您有足够的理由证明这样做的情况下，才会给您所需的资源。

废话代码通常修复起来不太昂贵。没有自动回归测试，测试重构代码的成本非常高。

大多数时候，我看到真正需要重构的不良代码，但需求中有大量未记录的功能和复杂性，这些需求从一开始就无法理解。这不是一件小事，而我的经验要比添加新功能更难估计一个重构工作的成本。

我会避免继续做下去，在老板的支持下做（如果它没有损坏，而您又摔坏了，它看起来如何）-修复仍然需要更改的代码，但是如果它没有损坏，请不要修复它。

奇怪的是没有人提到这一点：

要使事情成为优先事项，请使其变得容易：获得一个好的重构工具。

那里有出色的重构工具（至少对于.NET afaik而言）。哦，别忘了事先编写单元测试（正如其他人已经指出的那样）。

祝好运！