什么时候最好更改代码以符合标准？
我最近负责调试两个不同的程序，它们最终至少需要共享一个 XML 解析脚本。 一个是用 PureMVC 编写的，另一个是从头开始构建的。 虽然最初从头开始编写是有意义的（它节省了大量内存，但内存问题已得到解决）。
移植非 PureMVC 应用程序将花费大量时间和精力，这并不需要使用，但它将使文档和代码共享变得更容易。 它还将降低整体学习曲线。 考虑到这一点：
1. 在考虑是否最好将事物转移到一个标准时应该考虑什么？
（相关说明）
有些代码有点奇怪。 由于解释应用程序必须将命令从一种语法转换为另一种语法，因此拥有解释器对象是有意义的。 因为需要与外部环境进行通信，所以让一个对象与环境交互更有意义，并且为此专门与解释器打交道。
实际上，创建了一个反单例模式。 该对象只会与解释器交互，仅此而已。 如果另一个类的成员尝试调用其公共方法之一，该对象将引发异常。
有更好的方法可以实现这一点，但这确实有点奇怪。 有更标准的方法可以完成同样的事情，尽管它们通常涉及创建非常大的类或类文件。 我能找到的唯一符合标准的解决方案将涉及当前所需的尽可能多的评论和解释，甚至更多。 考虑到这一点：
2. 如果某些代码很古怪，但很有效，那么是否最好对其进行更改以使其不那么古怪，即使它变得更加笨拙？
I have recently been put in charge of debugging two different programs which will eventually need to share an XML parsing script, at the minimum. One was written with PureMVC, and another was built from scratch. While it made sence, originally, to write the one from scratch (it saved a good deal of memory, but the memory problems have since been resolved).
Porting the non-PureMVC application will take a good deal of time and effort which does not need to be used, but it will make documentation and code-sharing easier. It will also lower the overall learning curve. With that in mind:
1. What should be taken into account when considering whether it is best to move things to one standard?
(On a related note)
Some of the code is a little odd. Because the interpreting App had to convert commands from one syntax to another, it made sense to have an interpreter Object. Because there needed to be communication with the external environment, it made more sense to have one object interact with the environment, and for that to deal with the interpreter exclusively.
Effectively, an anti-Singleton was created. The object would only interface with the interpreter, and that's it. If a member of another class were to try to call one of its public methods, the object would raise an Exception.
There are better ways to accomplish this, but it is definitely a bit odd. There are more standard means of accomplishing the same thing, though they often involve the creation of classes or class files which are extraordinarily large. The only solution which I could find that was standards compliant would involve as much commenting and explanation as is currently required, if not more. Considering this:
2. If some code is quirky, but effective, is it better to change it to make it less quirky, even if it is made a more unwieldy?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在我看来，这种类型的重构通常不会被纳入日程安排中，只能在有额外时间的情况下进行。
通常，运输代码的标准是它是否有效，不一定是最好的代码解决方案。
因此，在回答您的问题时，当我有时间时，我会尝试进行重构。 首要任务仍然是生成一段功能性代码。
In my opinion this type of refactoring is often not considered in schedules and can only be done when there is extra time.
More often than not, the criterion for shipping code is if it works, not necessarily if it's the best possible code solution.
So in answer to your question, I try and refactor when I have time to do so. Priority One still remains to produce a functional piece of code.
需要考虑的事项：
正如高威吉安所说，这是许多商店的唯一标准。 然而，在我看来，同样重要的是：
如果您正在维护它，那么请考虑：
这很难猜测，但考虑到许多代码库的寿命远远超过了其原作者设想的有用性。 （Y2K 有人吗？）我逐渐形成了一种感觉，即什么时候值得重构，什么时候不值得，主要是因为经常犯“不”的错误，然后后悔。
Things to take into account:
As Galwegian notes, this is the only criterion in many shops. However, IMO just as important is:
If you're maintaining it, then instead consider:
That's hard to guess, but consider that many codebases FAR outlive the usefulness envisioned by their original authors. (Y2K anyone?) I've gradually developed a sense of when a refactoring is worthwhile and when it's not, mostly by erring on the side of "not" too often and regretting it later.
仅当您无论如何都需要进行更改时才更改它。 但减少古怪总是一个好的目标。 花在特定软件上的大部分时间都花在维护上，因此如果您可以采取一些措施来简化维护工作，那么您将减少花在该代码上的总时间。 尽管如此，如果某些东西正在运行并且不需要任何修改，就不要对其进行更改。
Only change it if you need to be making changes anyway. But less quirky is always a good goal. Most of the time spent on a particular piece of software is in maintenance, so if you can do something to make that easier, you'll be reducing the overall time spent on that piece of code. Nonetheless, don't change something if it's working and doesn't need any modifications.
如果你有时间，现在就去。 如果你没有时间并且可以避免的话，稍后再说。
If you have time, now. If you don't have time and it can be avoided, later.