1

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

marked as duplicate by gnat, Doc Brown, durron597, user40980, GlenH7 Mar 31 '15 at 14:38

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • see also: How should code reviews be Carried Out? and questions linked to it – gnat Mar 31 '15 at 9:00
  • i've known only one other manager to have the same scruples or values expressed here (are you sure you're a real manager or just one of us posing as a manager). normally managers just don't get it. if it "works", it's "done" and no additional company time is to be spent on cleaning it up. – robert bristow-johnson Mar 31 '15 at 20:47
4

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.

  • We will try to do that!, thank you for your answer :) P.S: It's my first time asking here, and I must say, it's a wonderful community, awesome and prompt answer – technofreak939 Apr 2 '15 at 7:37
0

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.

  • I am pretty sure you cannot validate SOLID principles by tools. – Doc Brown Mar 31 '15 at 13:14
0

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.

0

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.