Modularizing web applications

Question

I was wondering how big companies tend to modularize components on their page. Facebook is a good example:

There\'s a team working on Search that has it

Answer 1

This isn't something that should happen on the fly, it's baked in the company structure. No telling how Facebook or any other specific site/company does it, but it can be as simple as maintaining a single database table. Like:

project_namespace

• id
• namespace
• directory

So, you've got your core application (1, 'core', '/htdocs/core'). There's probably a PM or senior in charge of it, and some monkeys to create & maintain it - an extra database table if HR isn't already managing that relation, but that's irrelevant here. Each namespace would require a common structure, ./css for CSS files, ./templates for HTML templates, ./js, ./images, and so on. Again, there can be a db table for that, but irrelevant to this example. Add any number of other teams - search (2, 'search', '/htdocs/search'), accounts (3, 'users', '/htdocs/users'), the web services guys (4, 'services', '/htdocs/services/') and so on. Each value is unique, and I'm just making this up so please ignore the lack of detail.

Now you've got your build process - a script or series of scripts that pulls everything from source control, runs the CSS and JS minifiers, and generally compiles all the disparate parts into a website. It loads the namespaces from the db table and prepends them (or just the unique IDs) to every relevant CSS rule, HTML element ID, Javascript class, or whatever is needed. The "core" namespace would probably have some special rules, allowing other namespaces to call on it, sort of a meta-API (again not so relevant to the example, but realistic).

That's the gist of it at least, but it doesn't necessarily involve anything I just mentioned. For some teams that could just be an email reminder of "FTP your changes here, but jerk you best not overwrite my stuff," and for others it's a 3-ring binder of rules implemented with a rigid assembly line, wired to any number of bug trackers and code review tools, of automata performing unit tests and processing makefiles and checking permissions and so on and so forth. I'd guess Facebook leans more to the latter.

Long story short: information organization and a build process to maintain it.

So yes, everyone can (and should) be aware of what others are naming their div tags & JS functions and everything else important, thanks to this ominous MCP-looking entity maintaining the rules and handing out the names. With the right process and tools, you'll never not know.