如何应对不良代码

bit*_*onk 47 refactoring

作为开发人员,我在一整天的生活中遇到的最令人不快(也是最不常见的)情况之一就是我必须修复错误或在设计糟糕的代码中添加功能.现在作为一个优秀的工匠,我想让代码保持比我发现的更好的状态.如果我不重构设计,通常无法实现新功能.嗯 - 他们可以,但这会使代码更糟糕.

不幸的是,这正是我经常遇到的困难.我觉得如果有一件事情很难,那就是重构坏代码,尤其是在你有最后期限的情况下.触及或多或少工作的糟糕而复杂的代码是可怕的.因此,当我在代码中修改新功能而不修改现有代码时,我会引入更多的混乱.

现在我的问题是我如何学会应对不良代码?我怎样才能学会理解巨大的代码库,然后在不破坏已经工作且不超过截止日期的情况下重构其中的部分代码?你有没有可以推荐的文献?你有什么一般的提示吗?

ale*_*rus 24

一般提示:

if (it is working)
   Do (not touch it);
else
{
   Make (as few modifications as possible)
   Or (it will stop working at all);
}
Run Code Online (Sandbox Code Playgroud)

这是几代人的经历.

  • 我同意,但是看到它有多糟糕,难道不让你感到沮丧吗?这就像我必须修复它! (10认同)
  • 每个程序员都有;)但是时间和金钱都不会允许它. (3认同)
  • ......这就是为什么泥球大球越来越糟. (3认同)
  • 这将引入更多丑陋的hack和变通办法来杀死错误或引入新功能。如果多年后我总是走阻力最小的路线,那么代码会变成一个不可触碰的黑匣子(即黑洞) (2认同)
  • @bitbonk:这比netscape路线更具商业可行性:http://www.joelonsoftware.com/articles/fog0000000069.html (2认同)

Ode*_*ded 22

Michael Feathers完全写了一本关于这个主题的好书.

有效地使用遗留代码.

另一本伟大的着作是Martin Fowler,Kent Beck和其他人:

重构:改进现有规范的设计.

  • 书是一对.我建议先阅读*重构*.它会激发和挫败,因为你会说,"但我需要做出改变以使其可测试.如何在不破坏代码的情况下做到这一点?" 这就是Feathers书中出现的地方. (2认同)

Dan*_*ott 9

重构需要单元测试套件的安全带来消除"我有没有破坏它?" 感觉.在一系列测试中覆盖不良代码将有助于您在努力获得良好的清洁代码时.

Pex是一个我觉得有用的工具(如果你在.NET世界中),用于为遗留代码创建测试.

旧版代码==没有测试的代码!

善良,


Luk*_*ský 7

当我不得不处理为坏代码添加功能时,我通常的做法是:

  • 为必须工作的每个重要功能编写自动化测试(因为大多数不良代码没有任何测试).
  • 代码更改.
  • 确保测试仍然有效.

这给你至少一些信心,你没有打破一切.至于如何学习应对不良代码,我想这只是关于经验.

  • 通常代码设计得很糟糕,很难为它编写测试. (8认同)
  • 您至少可以针对最高级别的接口编写测试.如果没有好的接口,添加一个包装器**给出一个好的接口,然后针对它编写测试. (2认同)

Oxy*_*ron 5

好吧,如果您要在项目中重构大量代码,我建议您使用一些不错的版本控制,这样您就可以轻松分支和回退。鉴于,这可能是一扇敞开的门,但在我看来至关重要。

此外,在开始复杂的面向对象之前,请尝试将方法和函数分解为更小的方法和函数。确保每个函数具有一定程度的原子性,这使得代码更容易维护、阅读和管理。这都是关于小东西的,将其分解为逻辑操作单元,我正在对 1k 行方法进行重构操作。它可以做各种奇特的事情。我的第一个目标是从更小的部分中获得尽可能多的东西,完成后我将开始考虑更好的面向对象设计,这更容易,因为我对事物有了更好的掌握。

阿司匹林也有很好的效果。