Hi,
Even there are some coding conventions in a software development team, if there are more than 7-8 people coding on the same solution, who or what mechanism assures the standardizing and keeping the quality of the code?
How do they handle this in large projects, so that when a new programmer joins the team won't feel like Alice in wonderland?
thanks.
The team, through a solid code review process.
If a team is too large to have everyone code review every change, then break the team into smaller groups for the purposes of code reviews, making sure each group has at least one experienced developer.
If you've got some particular style document that specifies how code is laid out, then verifying that style should be part of the review process (perhaps incorporating automated tools to verify/fix adherence to the style document).
Making sure the new developer is involved in the code review process from day one (and making sure they feel their input is appreciated) is a great way to introduce new team members to the way things work.
It become a mandatory to have a coding guideline that new comer requires to follow.
We use SubMain's as foundation and modify on top.
Documentations like in-code comment, wiki and user guide for non developer are also important.
Peer review comes third as it requires most resource out of 3 and may be frustrating without the first 2 steps.
Various collaborative techniques can be used. Most obviously Code Reviews and Pair Programming.
However for me the major problem is one of knowledge transfer, how does a sufficiently motivated developer find out what "good" is.
This implies a need for well organised, easily consumed information about what to do. Probably with lots of good examples.
Another important technique is to not write code: generate it. There are various pattern-based approaches and tooling techniques which can help teh developer produce confirming code. The basic ida is making the easy path the right path. I have experience of using code-generation techniques in Eclipse to address these kinds of problems.
You need to work out what your coding standards are and write them down. For example, spaces or tabs for indenting, CamelCase or underscore_separated variable names etc. You can then show this to new members of the team.
You can use various code tidying tools to make sure that code standards are adhered to, for example lint. It can be a good idea for a new person to spend some time pairs programming with another developer so they can get a feel of the code.
But mainly, you need code review. All developers code should be reviewed by at least one other developer who is experienced with the style that your organisation uses.
Being force-fed coding standards on a project brings back som dark memories. I think the proper way to do this, is to assign a Mentor (I like 'Jedi Master' better) to every new-comer to a project, who discusses the particular style of the new-comer ('padawan'?) and explain why the coding standard is the preferred way of the team.
Other than that, I tend to find discussions over style somewhat irrelevant when the programmers care about their code. Who cares about their particular (peculiar) style if the code is well organized and easy to read?
Although code style is important, it is not the important part of a review. (There are enough tools.)
More important is that an experienced developer looks at your solution and makes suggestions about problems or improvments in the design. The reviewer may also give some hints about which classes / methods to use, which might already do what was rebuilt by the author or which have a better performance. A second view shows you flaws, that you won't see in code you have written yourself. But because the reviewer is not completely objective, it is the author's choice to choose which improvments he will implement.
As a guideline you should provide a check list for common problems, but you must not restrict the review to them.
And finally you won't need a person that judges and keeps the quality of code, as this is the responsibility of every single programmer.