重构javascript。分离标记或分离模块

我正试图使大型（约10K行）javascript代码库更易于维护。几乎所有的代码都包含在一个大型类中。我想做一些重构，但我不想完全重写代码

关于如何重新组织代码，我有两个想法，但我不确定哪一个是最好的。（我对其他想法也很开放）你对这些方法有什么看法？你如何决定哪一个是最好的

想法1–将标记与业务逻辑分离。 对于向用户显示内容和方式，我们有一套比较复杂的规则。这种方法将其分为“我们显示什么？”和“我们如何显示它？”

想法2–将单独的组件分解为各自的类。

---

这段代码中有几个不相交的组件。如果这个代码库是Facebook的——这种方法将涉及到分离照片和新闻提要的代码。

回答您的问题：是的

我不知道你说的“重构，但不是重写”是什么意思。重构代码不应该改变外部行为，但重构肯定会涉及某种代码的移动等等

一般来说，将标记与业务逻辑分离是一个好主意：它遵循以下步骤，有效地使标记代码成为“视图”代码，而业务逻辑成为“控制器”代码

将代码分解成单独的组件也是一个好主意。将代码分解为单独的类支持具有高内聚性和低耦合性的类的想法，并且通常会将您推向更多的设计

---

如果你问哪一个更有益，这是SO社区无法评估的事情，这是你必须决定的事情。

如果我们谈论的是Javascript，很可能你正在浏览器中使用它。在这种情况下，大多数代码都是关于视图的。MVC模式对您没有多大帮助，因为您的大多数代码将处理视图

记住Javascript不是基于类的，而是基于原型的。它也是功能性的。函数式编程擅长处理数据。进行此操作时，请尝试使用Javascript的功能方面

我建议您尝试将项目拆分为一个通用框架，用于检索、操作和推送所有视图的数据；然后将视图代码拆分为组件

如果我们谈论的是10k线路，那么您必须开发某种主干来处理常见任务。如果您不使用jQuery，在重新组织代码后，将您的实现与jQuery的解决方案进行比较，如果您看到改进，您可以开始在代码内部进行重构

---

如果您有机会看一看ExtJS源代码：

过于简单化了，您需要首先从技术角度弄清楚您想要的架构定义是什么。您的主文件（高级）负责什么，您的低规模模块是什么，以及它们将如何通信（直接或替代）。在这个阶段，您是否应该抽象出外部框架？我是EDA（事件驱动体系结构）、分形层次结构和中介（中介模式）的粉丝，但还有许多其他定义。选择一个适合您的项目规模并可以向外扩展的项目

为如何从a到B构建体系结构制定蓝图和程序。您可能需要一个包含约定的抽象程序。例如，“冗余：使用装饰器”等等。你喜欢构图而不是继承吗？然而，你应该有一个具体的程序来执行你的游戏计划。例如：“用Mediator替换对“X”的引用”，“让Save（）在“validation”通道上发送信号”，等等

确保您使用JavaScript组合精确地反映您的视图。因为平衡不平行的层次结构总是一件痛苦的事——这总是导致熵。试着接受（上面提到的）坚实的原则

---

我想详细说明一下，但我希望这是一个好的开始。

这两个想法并不相互排斥。两者都要实现……ExtJS是一个很棒的框架，但建议您看看它，这与您之前关于javascript功能强大、擅长处理数据的评论形成了鲜明对比。ExtJS似乎更多地采用了经典继承和面向对象编程，而不是javascript的函数式编程根源。ExtJS并不是我所说的最好的例子。但我认为@will可以像ExtJS那样（面向对象）处理视图组件，并对数据框架/层使用函数式编程。我也喜欢ExtJS组织代码的方式，不管使用什么编程模式。你似乎在推广函数式JS。但是JS允许继承，为什么不使用它呢？