We (the team) just had a chat about some ideas we should follow when it comes to source control and code ownership. Here is a short summary.
Code ownership
”Shared code ownership: ” To ensure that more than one person is familiar with a certain part of the code base we have shared code ownership. This will make the team more flexible, and making change easier. It is always allowed to refactor code to make it better. It is actually required to prevent the code base from deteriorating over time. That said, there might be people who knows more about the code base than you do. Also, somebody else might be working with the code right now. ”Consult before making radical change.” Communication is always important.
Check in
”Check in early, check in often: ” The code is what is in source control, not what is on your computer. By keeping the code in isolation on your computer you are setting yourself (and the team) up for big trouble. By updating(first) and checking in (second) often, you prevent merging and communication problems. Partition your current work into sub problems, and check in when each feature is created or updated. Work on one problem at a time. If you find yourself working on 10 features, where each one is impossible to check in, you are doing it wrong. It’s a code management anti-pattern. The philosophy behind this is simple. Problems are easier to fix right after they occur. In a day, or a week, solving the problem becomes exponentially harder. Considering this philosophy, keeping the code on your machine to avoid problems MAKES NO SENSE !
”If the code isn’t checked into source control, it doesn’t exist”
Write tests
Write tests for the expected behaviour and your usage of the code. This will ensure that new features and refactoring is compatible with existing usage.
Standard
“Standard” is what we do right now (or should do). The standard can be changed as we find better ways to solve our problems. However, we should all follow the current standard.