重构的javascript.解耦标记或分离模块

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

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

我建议你试着把你的项目分成一个共同的框架来检索、操作和推送所有视图的数据;然后将视图代码拆分为多个组件。

如果我们谈论的是10k行，你必须开发某种骨干来处理常见任务。如果你没有使用jQuery，在重组你的代码后，将你的实现与jQuery的解决方案进行比较，如果你看到了改进，你可以开始在你的代码中重构。

如果你有机会看看Ext JS源代码:http://www.sencha.com/products/extjs/download/ext-js-4.0.2a/213

回答你的问题:是的。

我不确定你所说的"重构，但不是重写"是什么意思。重构代码不应该改变外部行为，但是重构肯定会涉及到代码的移动和诸如此类的事情。

一般来说，将标记与业务逻辑分离是一个好主意:它遵循模型-视图-控制器模式，有效地将标记代码变为"视图"代码，而将业务逻辑变为"控制器"代码。

将代码分解为单独的组件也是一个好主意。把你的代码分解成单独的类，可以支持拥有高内聚和低耦合的类的想法，并且通常会使你走向更坚实的面向对象设计。

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

过于简单，您需要首先弄清楚，用技术术语来说，您想要的架构定义是什么。你的主文件(高级)负责什么，你的低规模模块是什么，以及它们将如何通信(直接或间接)。在这个阶段应该抽象掉外部框架吗?我是EDA(事件驱动架构)、分形层次结构和中介(中介模式)的粉丝，但还有许多其他定义。选择一个适合您的项目规模并可以扩展的。

派生一个蓝图和过程，用于如何将架构从a转换到b。您可能希望抽象过程包含约定。例如，"冗余:使用装饰器"等等。你喜欢作曲还是喜欢继承?然而，你应该有一个具体的程序来执行你的游戏计划。例如:"用Mediator替换对'X'的引用"，"让Save()在'validation'通道上调度一个信号"，等等。

确保你的JavaScript组合准确地反映了你的视图。因为平衡不平行的层次结构总是很痛苦——这总是导致熵。并尝试接受(上面提到的)坚实的原则。

我本想详细说明，但我希望这对你来说是一个好的开始。