2

我正在做一个项目，它的代码库大约有 3500 个文件，可能比实际少几百个。这个项目是用 PHP 编写的，非常混乱，在这种情况下，这意味着文档很难理解 OOP 并且过程编程是混合的，依赖项不明确，并且那些制作系统的人是初学者程序员所需要的。

老实说，他们所做的令人印象深刻，它是一个有效的产品等等。但是调试和添加新功能是一件真正的苦差事。

现在我的问题是什么是我们应该重构整个项目或进行完全重写的一些好的标准。我应该提到，在我们进行时重写系统的某些部分可能是不可行的，因为一切都是相互依赖的。

4

3 回答 3

3

如果应用程序很大、成功并且做了一些有趣的事情，那么手动重写它的尝试很可能会失败。重写永远不会有足够的质量来取代原件，并且在它完成之前你不能扔掉原件，这意味着你将继续增强原件直到替换准备好。两倍的工作量，没有额外的价值。你可能会好得多，保留应用程序并清理它。

您可能会考虑两个想法来帮助减少代码库的大小：

  • 对代码运行测试覆盖率。通常人们使用它来验证应用程序的功能，但如果你运行测试覆盖并简单地运行应用程序代码很长一段时间，它会告诉你哪些代码没有被执行，因此很可能死了。如果系统一团糟，它可能有很多死代码，这是找到候选人的简单方法。有一些测试覆盖工具可以以低开销收集整个应用程序的数据；您可以在生产代码中使用它们。

  • Run a clone detector. This will find duplicate code. Outright duplication is easy to remove. A good clone detector will find not just identical clones, but parametric clones, that is, code which has been copy/paste/edited but in a way that can be summarized with parameters. Parametric clones require more finesse to remove, but finding them tells you of likely missed abstractions, and removing them (by replacing with objects or methods) inserts those missing abstractions into your code, making further maintenance involving that idea easier. (It isn't a very well known fact, but clone removal also raises test coverage rates, if you are really using test coverage to verify functionality!)

于 2012-12-11T14:40:26.320 回答
0

如果应用程序已经工作并且没有重大故障，那么我会保留大部分内容，因为从头开始重写所有内容总是很昂贵。

也许您应该考虑在您看到重复的代码制作对象/函数的地方减少文件/行的数量，以尽可能集中所有内容。这对最终的维护有很大帮助，并且不需要大量的时间来完成。尤其是如果它是由初学者所说的那样编写的，您将很容易找到改进的“错误方法”。

于 2012-12-11T12:24:35.010 回答
0

The basic criteria will probably be the time ( = money).
The estimation is always hard when something is big. Split it to the smallest chunks.

Mind the point of view. Your estimation will probably differ from the estimation of the previous programmers, as it will be biased by the style you prefer. Maybe a better choice would be to hire the previous programmers to "fix" the code.

Anyways, you should state the minimum requirements to call the app well written and easy to maintain, discuss this with the boss and the team, split to smallest possible sprints and estimate the time required for all of them.

If you are able to convince your boss that the rewrite will return in better ROI overall, do rewrite. Otherwise, learn the "new style". If you have the comfort to stop the business for the time of the rewrite, or a spare time to do it, you're lucky. You're even more lucky if the code is testable, or you have at least some unit tests. If this is not possible, you should implement functional tests at least to help with both cases (refactoring or rewrite).

Note, that each one of us will probably prefer to rewrite from scratch, than to refactor. Then rewrite this rewritten...

So refactoring is always a good choice, assuming you already have tests or you are able to easily implement the tests.

于 2012-12-11T15:09:04.990 回答