On Building A New Feature

For a long time, I had no workflow to integrate new features into an app. I just opened the master branch of my git repository and worked straight into it.

It was enough for small projects, but I quickly ran into issues as some of them grew bigger. Releasing a hot fix while I was in the middle of re-organizing some code was impossible, for example.

I then got used to creating new git branches for each new feature. It was simple, straightforward, and a child’s play to merge new code into the main branch and directly to production. It allowed me to ship fast and get feedback quickly without the pressure of having a clean working branch at all time.

My new workflow is slightly better though. I now create a standalone repository that allows me to write modular, testable, and reusable features. By putting each feature in its own package, I can directly use it in other projects and experiments.

The code can be run in its own self-contained environment, so it’s much easier to maintain and extend. When a bug occurs, its source can be immediately isolated and fixed without disrupting the surrounding business logic. It’s also shareable: whether you want to make it open source or sell it as a standalone product, the code can live past the duration of your project.

Packaged code located in external modules also helps alleviating the bloating of most projects, as long as the module correctly implements the single-responsibility principle. It’s a bit like building a microservice architecture where each dependency is a microservice and your project is the main application.