I recently asked the following question – What does good team code ownership look like?
- Everyone adding (good) test coverage
- Discussing the code
- Design strategy
- Adhere to code standards
- Tool box of patterns
Everyone adding (good) test coverage
This is especially important, tests make everyone feel secure when making changes to the code base. Everyone in the team must know the benefits of tests, so must maintain them and add other good tests.
Discussing the Code
The code is essentially a living entity, i.e. we add functionality, we have to look after it, it is often sick! So it’s important that the team talks about the code base. This is powerful because it gives people are deeper understanding of the code base.
A way to improve the design – most code bases have areas that don’t give us the necessary ways to change the code, or they are hard to test. So they need to be refactored & improved upon. We are currently doing this with our UI – using MVP.
Adhere to code standards
Currently we don’t have any standards, however, I do think we have a good code style. This is mainly garnered from Uncle Bob’s clean code videos – which are excellent by the way – you should watch them if you’ve not (or read his book Clean Code)!
Toolbox of Patterns
You’ve got to be able to change the code, this becomes linked to discussing the code. Patterns can help with discussing the code… Having a design strategy – links to this!
This is not a comprehensive list but it’s a good start…
“It’s important not to own code you’ve written in a code base; however it’s important that people respect the way the code was written”