

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

I work for a large e-commerce company. We routinely find ourselves, despite our best intentions in the following situation:<p>1. We have an incomplete schema for our API, it&#x27;s mostly stable but some changes will happen.
2. We know most of the front-end interactions we want, but more will be discovered and some might be changed.
3. Despite 1 and 2, we want to begin front-end development right away (in Angular or Backbone).<p>We can&#x27;t be the first team to have encountered this pattern of software development. Are there technical solutions you&#x27;ve seen&#x2F;implemented&#x2F;read about to solve these issues? I&#x27;m talking more along the lines of app architectures, gang of four patterns or scripts&#x2F;tasks etc.<p>I realize this is an open ended question, but while we pursue process and social solutions (more communication, earlier stakeholder engagement etc), are we missing out on technical solutions as well?
======
hex13
_we want to begin front-end development right away_

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.

------
hex13
_Are there technical solutions you 've seen/implemented/read about to solve
these issues?_

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.

