I’ve done a lot of development projects over the years and I’ve constantly experimented with different organization schemes. I’d like to share my thoughts about them with you. Please note that the scheme that I’m currently using is not final by any means and is open to improvement and experimentation.
First, I’d like to share my goals for good code organization. A good code organization scheme should ultimately reduce the amount of time I have to think about where to put things, where to find things, and how to find related things. When it reduces time on non-coding, I can spend more time coding and fixing problems.
So, how do you reduce time not coding while still having definitive answers to location questions that are easy to figure out? I have a two-point theory on how I gather knowledge. Information that I have memorized, is intuitive, or is on my computer screen is easy to access. Information that is not in those places is much harder to access and stops the flow of work. So to keep the flow of work moving we can do a lot of things. Personally, you could try to memorize more things or get a bigger screen, but these solutions only affect your productivity instead of the entire team. Instead we should focus on making information as intuitive as possible and making the means in which to find the information as easy as possible.
Another hierarchy I see people follow is to group files by feature. That is to have all the code, no matter what the file type, related to one part of the program all in one folder. This scales a lot better because you don’t have to go all over the place trying to remember where files are. The only drawback to this approach is that you have to be disciplined when making new files to follow the same scheme. You can also get into problems if there is reused code and it’s not clear where to put it.
Now that we’ve covered some common organizations, here’s the structure we use on the front-end of both Mobilizer Canvas and Mobilizer Device Lab. It’s fairly close to the feature approach, but there’s always room for improvement.
- app (containing all of our code for our apps)
- canvas (all the code for canvas)
- core (all the code shared for canvas and device lab)
- deviceLab (all the code for deviceLab)
Within a project (such as canvas or device lab) we have the following structure
- _app.scss (contains all of the app specific css that doesn’t fit anywhere)
- style.scss (contains all of the app css and core css)
- style.min.css (compiled and minified from style.css)
- project.min.js (all of the css in the app minified and bundled)
- Example Feature
- Example Feature
- project.js (contains angular module for the project)
However, there are a couple of downsides to this scheme. Assets isn’t entirely descriptive. Sure that’s where I’d think images are, but I’m not so sure I’d assume that that’s where most of the compiled stuff (CSS and JS) would go. I think it might be better if there was a separate build folder for all of the compiled things to go. Another downside is that there is more of a cost when adding a new feature because I have to modify the style.scss file to include my new feature’s scss file. However, one could argue that most of the time developers aren’t creating new files, just modifying existing ones so it is a fair tradeoff in my opinion.
The way we’re organizing the Mobilizer code is by no means the best code organization ever. However, I feel like it’s a solid base on which to experiment on. I’ve tried a couple of other things on other projects, but I’m not sure if they’re ready or not. If I find anything new, I’ll write another article. Please share your thoughts on code organization in the comments below.
Increase revenue and customer engagement with Mobile1st. Easily identify display issues, monitor mobile performance metrics, and optimize the customer experience.