Source trees: wide or deep

Question

After writing several appengine applications for python, I found myself torn between two approaches to organizing my source tree: wide or deep.

For concreteness, consider the internal application for a small consulting store to manage business operations such as contact management, project tracking and reporting, and employee management. The application can use key objects, such as: company, users, contacts, customers, projects, schedules, etc. Without going into details, one can imagine that these models are cross-cutting functions of the website. This probably means that there is some connection.

In this example, it is preferable to organize in a deep manner, for example:

models/ people.py accounting.py projects.py foo.py controllers/ reporting.py employeeops.py accounting.py crm.py views/ ... 

or broadly, for example, through an “application”:

 people/ models/ views/ controllers/ contact-mgmt/ models/ views/ controllers/ time-tracking/ models/ views/ controllers/ project-reporting/ models/ views/ controllers/ 

I know that the whole construction involves compromises, so when you answer, you can specify your preferences and some arguments (for example, assumptions, modulating problems, scope of limitations, scalability problems, considerations for maintaining the code, the influence of the structure of the development team, etc.).

Answer 1

Caveat: I did not work in python specifically. Having said that ...

Broadly, and I will tell you why: it never hurts to quickly remove things. In my career, I am often asked to add things and give a relatively reasonable schedule on which to do this, but when something needs to be removed, the request almost never comes with impact analysis or time to mess around. When you break basic functional modules, you tend to have a much less complex design. This can be a real pain in the ass, but for those cases when you absolutely need to disable the work order module by the end of the week, this is a life-saving life.

Answer 2

Too deep folder structure makes it confusing. Too wide, this is confusing. I prefer to maintain a balance between them. In the project I'm working on, we had no idea what we needed, so we did not prematurely create a massive folder structure. In the end, we just started with 5 files, so we don’t need a folder structure. As the project grew larger, we organized things to keep it clean as we walked; There are no folders with more than 10 files, clearly grouping things into folders. It will take several minutes to move everything around. Now we have over a hundred files, and it is always clear where this happens. My recommendation is to do the same - keep it neat, don't go too far either in depth or in width, or you are complicating things too much.

Answer 3

In your case, I think the “wide” model is better. You should try to create your applications so that they can be reused, even if you do not plan to reuse them anywhere, as this will help ease communication with several different applications and simplify maintenance in the long run.

Answer 4

In fact, I prefer the mix. The software is divided into horizontal and vertical components.
Horizontal components are reused in all modules and represent a common code that needs to be reused, and not specific to a particular application. Thus, I have folders for general utilities, frameworks, multiple infrastructure libraries such as Persistence, Communications, Security, logging, etc ...

Vertical components are individual use cases. For each use case, I have a folder with the UI, server, and under the UI. I have views and controllers. The model is often divided between them.

If your project is really big, you probably have different areas of responsibility, such as inventory management, sales, contact management, reporting, etc. Add them to your folder structure and apply use cases to them.

Feel free to have any reuse to move any components up the tree.