refactoring javascript. decouple markup or separate modules

I'm trying to make a large (~10K lines) javascript code base more maintainable. Pretty much all of the code is contained in one massive class. I want to do some refactoring, but I don't want to completely rewrite the code.

I have two ideas for how to re-organize the code, but I'm not sure which one is best. (I'm very open to other ideas too) What do you think about each of these approaches? How would you decide which is best?

Idea 1 – Decouple markup from business logic. We have a somewhat complicated set of rules for what and how things should be displayed to users. This approach would split that into "What do we display?" and "How do we display it?"

Idea 2 – Break apart separate com开发者_开发知识库ponents into their own class. There are several somewhat disjoint components in this code. If this code base were Facebook's – this approach would involve pulling apart the code for photos and the newsfeed.

If we are talking about Javascript, chances are you are using it in a browser. That being the case, most of your code is about views. A MVC pattern won't help you that much because most of your code will handle views.

Remember Javascript is not class based but prototype based. It is also functional. Functional programming excels in manipulating data. Try using the functional aspects of Javascript when doing so.

I suggest you try to split your project into a common framework for retrieving, manipulating and pushing data for all your views; and then splitting your view code into components.

If we are talking about 10k lines, you had to develop some sort of backbone to handle common tasks. If you don't use jQuery, after reorganizing your code, compare your implementation to jQuery's solutions and if you see an improvement, you can start refactoring inside your code.

If you have a chance take a look at Ext JS source code: http://www.sencha.com/products/extjs/download/ext-js-4.0.2a/213

To answer your question: Yes.

I'm not sure what you mean by 'refactor, but not rewrite'. Refactoring code shouldn't change external behaviour, but refactoring will certainly involve some sort of moving code around and whatnot.

Generally, separating the markup from the business logic is a good idea: it's following the model-view-controller pattern, effectively making your markup code 'view' code, and your business logic 'controller' code.

Breaking your code apart into separate components is likewise a good idea. Breaking your code into individual classes supports the idea of having classes with high cohesion and low coupling, and generally moves you towards more SOLID object-oriented design.

If you're asking which one will be more beneficial, that's something that can't be evaluated by the SO community, that's something you have to decide.

Oversimplified, you need to first figure out, in technical terms, what your desired architecture definition is. What is your main file (high-level) responsible for, what your low-scale modules are, and how they will be communicating (directly or vicariously). Should you abstract away the external frameworks at this stage? I am a fan of EDA's (Event-Driven Architectures), Fractal Hierarchies, and Mediation (Mediator Pattern), but many other definitions exist. Choose one that suits the scale of your project and can scale out.

Derive a blueprint and procedure for how you'll get your architecture from A to B. You may want an Abstract Procedure to entail a convention. For instance, "Redundancies: use Decorators" and so on. Do you favor composition over inheritance? However, you should have a Concrete Procedure for how to execute your game plan. E.g: "Replace references to 'X' with Mediator", "Let Save() dispatch a signal on the 'validation' channel", etc.

Make sure you're reflecting your views precisely with your JavaScript compositions. Because it's always a pain to balance unparallel hierarchies -- this ALWAYS leads to entropy. And try to embrace the (noted above) SOLID principles.

I wished to elaborate more, but I hope this is a good start for you.