|photo by Yang and Yun’s Album|
I admit it, this is a trick question. There can’t be one correct answer. It depends on too many things. What I want to do here is to talk about things that affect decisions about structure of your project and find out principals that let you do what you want, while steer you away from too much trouble.
Simple is ALWAYS better than complex.
There are conventions for those type of things. In different communities there are different tools and different conventions. Most of those are known to the members of those communities. Very often those conventions are too general and complex. When you work in a team it is wiser to follow those conventions since that saves on communication overhead. You don’t have to explain where parts are. If you are working by yourself — go crazy, but know why.
The Only Thing That Is Constant Is Change
The structure will change. Usually things grow as your project grows. There is no point in setting up all the bells and whistles up front. You might not need them. But at the same time you don’t want to end up writing your own build scripts. That is a waist as well. So what is the balance?
Use a tool that is accepted in the community of the language you are using, but is flexible enough to extend it later.
Here are things that I want from my project structure:
- To be simple.
- To be easy to modify.
- Have dependency management.
- To run my tests and package my application.
Since we are talking about web applications here we will have two parts — the part that runs in the browser and the server part.
There are a lot of alternatives, but I found that the simple grunt script on the browser side and paver on the server side do the trick. I can add commands if I need to, but it is easy to set up simple build scripts that do the minimum that I need.