I’m a project manager in a small team of developers (consisting 3 team leaders and 10 programmers)
We’re currently trying to enforce clean code for our team , we’re having small frequent seminars discussing uncle bob’s clean code book.
Long story short, we are trying to make sure that clean code are well implemented in our team. to do that we’re asking our team leaders to review their team’s committed code daily and take note whenever a piece of code aren’t clean enough. By using this method, all the team leaders are completely overwhelmed by the amount of code that they have to review everyday and cannot review the codes in detailed manner.
is there any better method to review codes to make sure they are clean? we want to make clean code to become habit as soon as possible.
Thank you
2
You let the team review each others code. Use your team leaders to spot check at random. This means the team is part of the solution, becomes more involved in the whole process, and spreads the task so its achievable.
Invest in a code review tool such as reviewboard or redmine’s plugin to help make reviewing easier and quicker too.
1
Many (but not all) coding style / safety issues can be caught with tools. Also, tools can be configured to signal a certain subset of infringements. You and your team members should agree upon two sets: (1) should never occur (2) might occur under certain conditions. All team members should submit code that does not generate warnings by set 1. Team leaders need only verify that no code has been checked in that does not pass level 1. That is a trivial task that could easily be done by 1 person or be automated. The issues that remain, by definition, are interesting cases that warrant review and discussion.
1
I would recommend not only dev testing the code but also QA testing it with a few scenarios before passing it on for actual QA testing.
Yes, dev testing takes a bit of time to complete properly with useful comments and such. However, you should look at this as a long-term investment. You won’t see results in a week or even a month but over a course of time (a few months let’s say even though it depends per team) you will start noticing that the overall standards of your team and the quality of the product has gone higher. There are a few reasons for this:
1) Code reviewing someone else’s code helps you learn more either by critiquing what could be improved or being inspired by an elegant solution.
2) When you know that another developer is going to be looking at your code you are more likely to put more effort into making your code look prettier. You don’t want to be known as the guy with the messy code. Need for validation is a powerful force.
3) Doing a quick QA testing before passing it on for actual QA testing for BAs/QA Engineers helps you make sure you are passing a more quality product and therefore there is less time spent on communication (when it fails back, they need to write steps how they reproduced it, devs need to switch context, all this takes more time). QA testing by devs just assures that it not only builds but also runs for and works for at least one scenario. Then during actual QA testing more scenarios could be used to test it more thoroughly.
With all these steps you should be able to create a culture where clean code is utilized for designing and developing any projects that come up.
Clean code for my understanding is to adopt standards which allows you to keep correct naming inside the code, correct function and class sizes, on over all a good usage of OO practices. This takes time and it is hard to get it write the first time you write your code. So you must be able to refactor.
The only way I know you can safely Refactor code, is if you followed strictly Test Driven Development. If you refactor the code often and early, after each interaction the code gets cleaner. This means, after each code review the code gets better (in the case of a pair programming session this theoretical can be achieved on the fly.).
The reviews should point improvements to be done by Refactoring.