Name your features, modularise and brand

Posted by: Alex on June 9, 2016

No doubt you’ve heard of DRY coding before (don’t repeat yourself) – whereby your code and logic should be succinctly structured so functions/classes etc generally only do one thing, do it well and can be reused throughout projects. If you haven’t… read up on general DRY coding practices first.

Any web or development project that is of any respectable size logically should have a very good structure of classes, functions and modules. At a certain size, a project really begins to feel like a book or library with clear sections, areas and sometimes separate projects within itself.

For this blog post, Twitter is going to be the best analogy and example. Twitter started as a very basic 140 character text-sharing site, it has ballooned massively, both with its features and code base. One thing Twitter does incredibly well, however, is structuring and even branding modules within its code. You only have to glance at the Twitter git repo to see all of the different modules with separate forks and more.

From that Twitter Git page, pick pretty much any repo, scan the code and you’ll see their clever thinking. By modularising and even branding logical sections of code, each repo becomes it’s own accountable module, with its own commit channel it’s clear to see the module progress and plan its future.

I’m personally beginning to adopt this structuring process in some of my larger projects and it’s working amazingly. Each module really begins to feel like it’s own important sub-project and if you begin to think of each one as its own API you begin to treat them with more respect and most importantly it helps to ensure everything stays sterile and un-opinionated.
If you get to the stage where the separate module can have its own git repo without too much hassle I believe you’ve truly created an unbiased and re-usable code section, in the future, you then know any further modules that will have interaction with this module should not require any custom work.

In short, think with modules, and build your code sideways – not top down. If you can code a module that you can brand, give a name and create a git repo you can even reap the rewards of the open-source community.