How do you ensure that the code will be kept consistent for a long period of time?
Our first step, was code formatting (language specific, since we use a few languages). I put a formatter together in IntelliJ that makes code readable for me and shared with the team. I also shared a couple of git pre-commit hooks (one for Windows, one for Linux), so that git will format all source just before commit. Thankfully we all use IntelliJ.
Then I've told the team "if you think we should change the formatting, lets talk about it - this is just a starting point to get us going, formatting should work for the team average."
After that, is automated code-quality metrics - we use SonarQube as part of the build/review process. As with formatting, the whole team are welcome to add/change/remove rules over time.
But that's the easy part.
The next step, was to get the team to separate commits - for each unit of work, I expect at least two commits. The first, or first few, will be "make the damn thing work" and the last, or last few, should be refactoring. Of course, if you pick up a legacy project and you're struggling to read it - refactor it first, then make it work (and then probably refactor again). There's also times when PMO are breathing down our backs, because we live in the real world, so sometimes skipping refactoring is OK, but if we're doing that too often, it's my job to tell PMO to back off a little.
The much harder part, is frameworks and design patterns. Those tend to be discussions over time, and we don't always get it right, but who does?
You covered some real good points here. I find it really hard to get a consciousness on these things. When a team of 7 uses 7 different editors and are not comfortable with following a single formatter its always a battle.
I'd suggest there that the team leadership (Lead/Architect/Manager etc) needs to adopt a "god complex" approach.
"I have spoken, therefore you will do."
When the team all pull in the same direction, consistency is easy (our discussion about code consistency lasted a grand total of 15mins). When each individual likes to impart their own personality on the code base, you'll never achieve consistency, unfortunately.
Our first step, was code formatting (language specific, since we use a few languages). I put a formatter together in IntelliJ that makes code readable for me and shared with the team. I also shared a couple of git pre-commit hooks (one for Windows, one for Linux), so that git will format all source just before commit. Thankfully we all use IntelliJ.
Then I've told the team "if you think we should change the formatting, lets talk about it - this is just a starting point to get us going, formatting should work for the team average."
After that, is automated code-quality metrics - we use SonarQube as part of the build/review process. As with formatting, the whole team are welcome to add/change/remove rules over time.
But that's the easy part.
The next step, was to get the team to separate commits - for each unit of work, I expect at least two commits. The first, or first few, will be "make the damn thing work" and the last, or last few, should be refactoring. Of course, if you pick up a legacy project and you're struggling to read it - refactor it first, then make it work (and then probably refactor again). There's also times when PMO are breathing down our backs, because we live in the real world, so sometimes skipping refactoring is OK, but if we're doing that too often, it's my job to tell PMO to back off a little.
The much harder part, is frameworks and design patterns. Those tend to be discussions over time, and we don't always get it right, but who does?
You covered some real good points here. I find it really hard to get a consciousness on these things. When a team of 7 uses 7 different editors and are not comfortable with following a single formatter its always a battle.
I'd suggest there that the team leadership (Lead/Architect/Manager etc) needs to adopt a "god complex" approach.
"I have spoken, therefore you will do."
When the team all pull in the same direction, consistency is easy (our discussion about code consistency lasted a grand total of 15mins). When each individual likes to impart their own personality on the code base, you'll never achieve consistency, unfortunately.
Thanks for commenting, I've found your answer very informative ;)