Teamworking in software development etiquette

Question

A lot of the coding I do at work (when lucky enough to be assigned some...) is usually individual projects. As I only run source control locally, what are the best practices for working with source control and generally working in a software development team? Etiquette, best practices, what NOT to do, etc.

Answer 1

Etiquette in general varies wildly from team to team, but here are three tips (from strongest consensus to weakest):

• you shouldn't push code to a shared repository if it won't compile
• in shops where unit-testing is considered important, you should also generally refrain from pushing changes the break unit tests
• it is generally considered poor form to reformat large chunks of the code just because you don't like the way it looks

Answer 2

ALWAYS keep your source-control trunk in working compiling state - that means you should never ever check in code with compilation errors.

What i usually do is write a script that is able to run tests, and only check in after running it. This script makes a clean compilation and then runs all unit tests/system tests and verifies correctness. Also have regressions tests, to show everything that initially worked stays this way.

Other than that, have as frequent as possible check ins. Then you can rollback to nearly every possible state. Also, for the same reason, write informative comments when checking in.

Answer 3

Pretty generic, but I'd say generally

• Subdivide the work into modular components with well-defined interfaces
• Communicate early-and-often about how code should interface/communicate.
• Hold regular code reviews to update the team on other's code
• Balance giving people the space they need to get their work done vs not allowing someone to develop in a vacuum
• Create an open environment where issues can be discussed

Answer 4

• Leave Code Cleaner than you found it
• Do not check in code that will not compile unless you have coordinated with your team
• Always double check the files required for your change are checked in. Sometimes, a .dll may be left out when it is needed, and the next person pulling down the code will not have.
• Have your team create a standard and follow the agreed on or established standard. This will limit the amount of time one developer from another needs to understand you changes.
• Use comments when the code is not clear what you are doing. This includes specialized business logic that may not be easy to understand. However don't comment code that is obvious (i.e. say you are creating a index and then using the index in a for loop.)
• Understand you are not the only one going to be reading these files. Keep it professionally, code is not the place to bash people or ideas.

Answer 5

• Learn how branching works in your source control system. when you want to work on something that will temporarily "break" the build, check things in to your branch until things work, then merge your changes into the main trunk.

• Do everyone a favor and decide on some formatting rules, no matter how simple, so you don't end up wasting time reformatting each other's code on every checkout.

Answer 6

I have a number of suggestions for you, many also suggested by others:

1. Communicate with your teammates as much as you can.
2. Setup a source repository that your coworkers can access and invite/encourage them to use it. Subversion, Git, Mercurial are all good options.
3. If you don't have a bug tracker, set that up too. (As a Trac dev, I'd suggest looking at Trac of course. ;) )
4. Make sure the repo and tracker get backed up regularly
5. 'trunk' should always work. Aim to have everyone on the team agree on what 'works' means -- compiles, passes unittests, etc.
6. Learn to branch for development so you can reap the benefits of source control as you're tearing things up without hurting your teammates.
7. If you are coding in a language that has a style guide, follow it, even if you don't agree with some of the finer points. You want those who know the language to feel at home in your code when they start. If the language does not have a style guide, try to find one that works for you and see if you can find a code beautifier that can format code to your chosen style.
8. Setup automated builds and tests.