structuring large web application for multiple developers

Question

I've got several developers about to start working on the front end of a jquery-based web application. How can we structure the application so that multiple developers can work on the ui at the same time. The end result for the user will just be one web "page", but I don't all of the client development to occur in one file. There is already another team working on the back end.

Answer 1

If you're starting completely from scratch, you could break it up into the standard 3 tier architecture.

Have one person working on the database structure and creating the appropriate access libraries to the data.

Have one person working on the business/workflow tier, setting up all the interaction of data.

Have the third person doing all of the front end work with jQuery.

I'm sure following this there would be minimal collision, and each could work with some mock data/methods until the official stuff comes online.

Answer 2

If you're going to have multiple people working on the same files your SCM should be able to manage that for you.

However, if you want to make things easier you can always break down your javascript files into multiple pieces, which you can either include dynamically or during your build/deploy phase can combine and then minify.

Answer 3

Factor out pieces of your target page markup into server-side includes or other composable pieces, each one wrapped in a DIV (or other appropriate tag) with a unique ID, then add separate CSS and JS references for the CSS styles and jQuery bits that style and animate each piece.

While CSS rules do cascade and jQuery queries can collide (as they are CSS-selector-based), careful use of IDs and Classes can go a long way towards creating rough "sandboxes" on your final page in which each front-end developer can work relatively independently.

At the same time (or as the individual pieces begin to stabilize) you can devote some energy towards developing an integration strategy for deployment that includes concatenating your separate CSS and JS files into single resources (wherever possible) and gzipping, minifying, etc.

You'll want to watch out for the order in which you concatenate your CSS files due to the inherent cascade, but if you isolate them well by confining all your style selectors to within a given ID'd tag for each piece, you should be fine.

Answer 4

Try to model an object-oriented approach to the problem so that one group of developers can code the necessary functionality inside of the objects while others build on features that objects would provide.

JavaScript is great for this approach: developers that build upon agreed object interfaces can develop simple mock-up prototypes which will be discarded when real objects are written.

Of course, as jonnii said, you should rely on some SCM to manage concurrent changes to your codebase. Even if the tasks are split appart, a developer may need to change others' code. I'd recommend git or SVN if you're under Windows (because it has TortoiseSVN which is pretty sweet if you're just starting with SCM).

Answer 5

It sounds like you already know which portion of the product you want which developers working on, and have planned the workloads to prevent overlap. Something like subversion will allow you track who added which item to what document when, as well as undo unwanted changes or merge what was previously an overwrite, and more. It's free and its a life saver. :) HTH

Answer 6

I know this may not be an option, but this is where MVC or MVP archiecture shines. It removes the "webpage" approach to your website development, and moves to a strongly-typed model code design, using "methods" to call the logic you want. In other words, "physical pages" do not exist in MVC, only methods on objects.

(Note: I am NOT a Java developer, C# actually, but u can get the idea)

The url:

    /products/532

With Url re-writing, it would be a "webpage" and its compiled "code" like:

/products/showproduct.jsp?productid=532
/products/showproduct.java (code behind)

But with pages in MVC, it would be:

/Controllers/ProductController.java <- ProductController.ViewProduct(int id)
/Models/ViewModels/Product.java <- Product() class
/Views/Product/Index.html <- very simple display of html.

The ProductController looks-up and obtains the ViewModel of Product(), wires up the Index view, replacing any variables to be displayed, and finally the ProductController returns the completed html to the client.

This approach abstracts the webpage logic into code that can be managed, versioned, merged, branched, etc in your source repository.