我目前正在构建一个包含大量 JavaScript 的小型 Web 应用程序。当我对最初的想法进行原型设计时，我只是将几个函数拼凑在一起，以展示应用程序最终将如何表现，并打算继续以面向对象的性质重新编写 JavaScript。
现在我进入了实现阶段，我发现为了面向对象而创建面向对象的 JavaScript 似乎有些矫枉过正——该项目未来不太可能需要进行任何重大修改，以保证和面向对象的设计。相反，我发现一组简洁、有凝聚力的函数运行良好。
那么，话虽如此，并试图坚持 KISS 原则，当一组函数为问题提供合适的解决方案时，是否还有其他理由值得考虑将我的代码转换为面向对象的设计？
不，虽然我个人觉得 OOP 更好吃，但它是达到目的的一种手段，而不是目的本身。在许多情况下，过程编程比 OOP 更有意义，如您所说，为了转换而进行转换可能是矫枉过正。
不，顺其自然，继续前进——在我看来，这样更有成效。
如果您的代码结构良好、布局合理、注释完善，并且完成了所需的工作，那么除了添加功能之外，出于任何其他原因弄乱它是不明智的。
虽然说该程序非常适合 OOP 等可能会很好，但如果不需要更改它即可工作，那么我肯定会保持原样。
如果它没有坏，不要烦躁:)
如果此代码已经实现并且不需要维护或 - 更好的是 - 升级，请坚持使用它。如果您现在要实现它并且它可能会变得复杂，请考虑 OO 方法。
经验告诉我，在复杂性较低的情况下编写和维护过程代码非常容易，但是在一定的阈值之后，在使用过程编程时，增加复杂性的难度开始呈指数级增长，而 OOP 虽然更难开始，但保持复杂性要高得多可管理。
底线：如果任务足够简单或已经实施，请保持简单。如果它可能变得更复杂，请考虑 OOP。
我会说在做出决定之前仍然值得审查您的代码。“重写”代码的明显缺点是需要测试成本来确保您的代码与以前一样工作。你有任何单元测试吗？如果没有，那么您的测试成本会更高。所以总的来说，我反对重写工作代码，除非它服务于另一个目的，这是为了让你更容易地编写现在需要的新功能（即重构常用功能等）
但是，任何时候有人说“我一起黑了”，我建议总是值得再看看你的代码。为什么它首先被黑客攻击在一起？我知道很多人说面向对象的代码本身并不是目的，但它是一种方法，之后也不必考虑。你只是自然而然地开始这样做。
也许您的 js 相对简单，因此 OO 脚手架确实是额外的开销。美好的。但我仍然建议您始终对您称为“被黑”的任何代码进行代码审查（尤其是让其他人审查）。也许这是弗洛伊德的失误……但它确实失误了。
从现在开始将其视为遗留代码。当您想更改某些内容时，请对其进行重构，以便代码在头脑中变得更容易。如果您需要一点 OOP，请使用它。如果你不这样做，不要。
OOP 是一把锤子，请不要把螺丝问题当作钉子。
如果它有效，并且易于维护，我不会为了转换而费心转换它。一定有更多有趣的事情要做。
请记住，在 javascript 中创建对象相当昂贵。
将对象的构造保持在最低限度。