Ask HN: Strategies to develop front-end apps with incomplete requirements

I think that beginning of the development is pretty easy task. Maintaining and modifying existing codebase it’s hard. If project is starting and codebase is small you can rewrite whole project from scratch in few days. But when project grows it is wiser to refactor than rewriting. But if you want to refactor your project has to be maintainable.

We know most of the front-end interactions we want, but more will be discovered and some might be changed.

You can make quick prototypes before you begin serious coding. Start new branch in your repository and don’t try to write some beautiful code. Just hack and tweak features. Mock some features if you need it. I think that prototype phase / sandbox phase is often necessary to gain technical knowledge and gather business requirements, to decide which features are useful and which are not (off course you may need to consult these decisions with your stakeholders, your client, etc. But having working prototype makes this easier than operate on *.psd based designs and unclear guidelines).

And after prototype phase you can delete your sandbox branch and start some serious coding for production.

There is no silver bullet but from my experience these things let you to maintain (and modify) project more easily:

1. Separation of concerns

We have an incomplete schema for our API, it's mostly stable but some changes will happen

It's better to create some specialized service/module to connect with backend API end-points than have something like $.get('/get/user/' + id) spread across the project. If you follow SoC, when backend API changes you have to update only one file.

2. Modularize

If you have proper modularization (achieved by proper design or/and incremental refactoring) you can make global changes very quickly (you have to update just one module to apply changes everywhere) but you can also make local changes also quickly (you just have to decide what submodules you have to use in your parent module). If you treat project not as a monolith but as a interconnected set of decoupled components/modules developing is like building with Lego bricks.

3. Refactor constantly

Is there some code that can be written better? Refactor. Avoid unnecessary complexity. Simple and succinct code is easier to maintain and modify. And make your code reusable.

4. File/directory structure based on components rather than filetype.

I never understood why so many people create directories like “controllers”, “directives”, javascripts”, “stylesheets”. The truth is that if you work on some part of your code you will usually edit all of these files. And you end up jumping over 3-4 different directories to make very small change. Directory structure based on components / views / modules / other logical part of project / seems to be better than put 10 files in one directory only because they all have .js or .css extension.

5. keep third part library code separate (if possible).

For example you need to inject some third party slider/carousel/chart etc. on one of sub-sites. It's better to make directive for this and insert 1 line of directive <my-slider> than just throw some 20 lines of code in your HTML and JS. Imagine that you need to change library X to library Y. Wrappers/adapters add some additional layer of complexity but I think that outcome is still positive in many cases.