How do you organize your development environment [closed]

Question

I've got a folder with all my projects, in different languages. Then I've got the libraries that I might eventually use in my code (mostly jar files). I'm sure there is an accepted practice, right? What do the professionals do?

Answer 1

For me, it's the following list of directories under the project root:

1. src for .java files, using the package hierarchy
2. lib for 3rd party JARs, unless I'm getting them from a repository (e.g., Spring distro)
3. test for JUnit or TestNG test files
4. resources or config for .properties, .xml, etc.
5. web if it's a web application, which contains WEB-INF and all its attendants
6. docs if I have any documentation

I like the structure that the Spring folks have evolved.

I use IntelliJ, so I want whatever structure I have to play nicely with it.

I have a directory /work that keeps all my Subversion working copies.

Answer 2

This really depends on what tools you use, and how you like to organize it.

For example, I have seen people that use Eclipse but put every project in a single workspace, or use one single workspace for each project. The actual storage of projects can also vary. So, I don't think there is an accepted practice.

I think you will need to figure out what works the best for you.

Answer 3

I have a folder called Work. Under this folder, I have Projects.

Project contains all my developed software, one directory for each one, with a conventional name. Each directory is a full bazaar respository, contaning tags, trunk and branches (heritage of my old svn style, probably I am going to change soon).

I also develop specific runtimes for the projects. Each runtime is downloaded and installed via a makefile that downloads and compiles everything is needed (libs, interpreter, and compiler in the worst case scenario that some lib requires a specific version of it).

As my job mainly involves small code, I also have a Archived and Outdated subfolders into Project, where I put stuff I don't use anymore (the first) or has been superseded by a better program (Outdated). I never throw away old code, as it could be useful tomorrow.

For deployment and use, I have a python script that goes into each Project subdir and download dependencies, compiles everything, and packages it as a nutz file (a sort of jar file for the Chestnut Package Manager utility, also a product of mine).

In most cases, however, professionals use IDEs that do everything for them. I don't like this approach because often using and learning the IDE takes more time than doing what I did. The IDEs are implemented with the idea that you have business clients out there and a potentially large software project with a team involved. I am out of this scale at the moment, and to me, using a complex IDE would be like being handed a transatlantic for a nice weekend on the sea. Completely out of scale for my current needs.

Answer 4

It highly depends on the programming language you use. I'm programming in java and the best structure I've seen there is given by maven.

You don't need to mess around with dozens of jar files because of the great dependency management of maven. You can use existing plugins to accomplish nearly every goal you can imagine. And you can structure your projects in small subprojects for optimal reuse.

Answer 5

I have everything in a version control repositories (nb: a very reassuring set of files to have, and to have tested backups of). On my dev machines, I have Projects folder for checked out current/recent work, and a Projects/Archives folder for older checkouts which I'm not currently working on. When I need third-party libraries for a project, they go into a third_party folder inside each project. These are tracked a git submodules, which gives me the exact software versions that are known to work with that project, but also easy updating in different projects, hacking if some library doesn't do quite what I need, etc. The idea with that is that each project should be self-contained and portable between machines as far as reasonable for reliability etc.