2

我最近负责调试两个不同的程序，它们最终至少需要共享一个 XML 解析脚本。一个是用 PureMVC 编写的，另一个是从头开始构建的。虽然最初从头开始编写它是有意义的（它节省了大量内存，但内存问题已经解决）。

移植非 PureMVC 应用程序将花费大量时间和精力，这并不需要使用，但它会使文档和代码共享更容易。它还将降低整体学习曲线。考虑到这一点：

1.在考虑是否最好将事物移至一个标准时应该考虑什么？

（在相关说明中）

有些代码有点奇怪。因为解释应用程序必须将命令从一种语法转换为另一种语法，所以有一个解释器对象是有意义的。因为需要与外部环境进行通信，所以让一个对象与环境交互并专门与解释器打交道更有意义。

实际上，创建了一个反单身人士。该对象只会与解释器交互，仅此而已。如果另一个类的成员试图调用其公共方法之一，则该对象将引发异常。

有更好的方法可以做到这一点，但这肯定有点奇怪。有更多标准的方法来完成同样的事情，尽管它们通常涉及创建非常大的类或类文件。我能找到的唯一符合标准的解决方案将涉及当前所需的评论和解释，如果不是更多的话。考虑到这一点：

2. 如果某些代码很古怪，但很有效，是否最好对其进行更改以使其不那么古怪，即使它变得更笨拙？

4

4 回答 4

2

在我看来，这种类型的重构通常不会在时间表中考虑，只能在有额外时间的情况下进行。

通常情况下，交付代码的标准是它是否有效，而不一定是它是否是最好的代码解决方案。

因此，在回答您的问题时，我会在有时间的时候尝试重构。优先级仍然是生成一段功能代码。

于 2009-01-22T17:43:14.557 回答
2

需要考虑的事项：

  • 它按原样工作吗？

正如 Galwegian 所说，这是许多商店的唯一标准。然而，IMO 同样重要的是：

  • 将要维护它的程序员有多熟练？他们有没有遇到过非标准代码？将他们学习它的时间成本（包括延迟发布的成本）与重构它的时间成本进行比较。

如果您要维护它，请考虑：

  • 在代码库的预期生命周期（例如，从现在到重写整个代码之间的时间），处理非标准代码会花费您多少时间？

这很难猜测，但考虑到许多代码库远比其原始作者所设想的有用性要长。（Y2K 有人吗？）我逐渐形成了一种重构的感觉，什么时候值得重构，什么时候不值得，主要是因为经常在“不”这一边犯错，后来又后悔了。

于 2009-02-17T03:20:48.227 回答
1

仅当您无论如何都需要进行更改时才更改它。但不那么古怪总是一个好目标。花在特定软件上的大部分时间都花在了维护上，所以如果你能做些事情让它变得更容易，你就会减少花在这段代码上的总时间。尽管如此，如果它正在工作并且不需要任何修改，请不要更改某些内容。

于 2009-01-22T17:42:08.070 回答
1

如果你有时间，现在。如果您没有时间，可以避免，以后再做。

于 2009-11-04T07:41:03.430 回答