Menu
I have been experimenting with directory structures and am currently using the one below:
| |_projects__ | | | |_blog.com_ | | |_mockups | | |_user stories | | |_.... | | | |_noteapp__ | |_mockups | |_.... | |_webs______ | | | |_dev______ | | |_blog.com_ | | |_app | | |_config | | |_.... | | | |_prod_____ | | |_blog.com_ | | |_app | | |_.... | |_qe_.... | |_uat_.... | | |_desktops__ | |_dev______ | |_noteapp_ | |_app | |_config | |_.... | |_prod... |_qe.... |_uat.... KEY dev - development prod - production qe - quality engineering uat - user acceptance testing
Webs store web applications, desktops store desktop applications. The dev directory is version controlled, while the other directories (prod, qe, uat) store their respective current releases. The project directory stores non-code related project items.
What is your software development directory structure and is there a reason you recommend that structure?
341
What is directory structure? The directory structure is the organization of files into a hierarchy of folders. It should be stable and scalable; it should not fundamentally change, only be added to. Computers have used the folder metaphor for decades as a way to help users keep track of where something can be found.
One folder structure best practice is to avoid having folders that compete with one another. Try not to create folders with overlapping categories. Instead, create folders which are distinct from one another, and use nesting to arrange them as needed.
Set up a folder for each type of document, then create subfolders for each topic under the parent folder. Place any file that does not fit into other folders, into an uncategorized folder. Colour code the folders on the diagram, so that everyone can understand the folder structure easily.
I do the following:
For some reason it helps me a lot to keep all the files grouped up by project, and keep my inactive projects (the ones I'm not currently working on) on a further down folder. I guess I get distracted by them otherwise.
193
I'm a big fan of your more granular leaves, but at the top level I perform much better having the filesystem organized by project. I'm much more likely to be in a code directory and think, "Hey, what was the spec for this?" than be in the spec directory and think, "Which project did I want the spec for?" To rearrange your diagram:
| |___webs____ | | | |_blog.com_ | | | | | |_docs_ | | | | | | | |_mockups | | | |_user stories | | | |_... | | | | | |_code_ | | | | | | | |_dev_ | | | | | | | | | |_app | | | | |_cfg | | | | |_... | | | | | | | |_prod_ | | | |_qa_ | | | |_uat_ | | | |_blah.com_ | | | | | |_... | |_desktop___ | | | |_noteapp__ | | | | | |_... | |_... KEY dev - development prod - production qe - quality engineering uat - user acceptance testing That said, the organization at my office follows your methods, and seems to support a largish development environment. Personally, I find it really frustrating to have to search for mockups and other cases in directories other than the one my project is in (specifically, as an analyst, having specs separate from Marketing models, but I digress), but from a process-delegation standpoint separating these concepts probably makes a good deal of sense.
Just my two cents.
24
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
