Algum tempo atras estava conversando com um amigo que estava comentando sobre os problemas que a empresa/projeto em qual ele estava trabalhando estava enfrentando em relação a quantidade de check-ins com código extremamente pobre ou fora do padrão em que estavam tentando adotar e o pior de tudo: com um alto número de bugs. Esse amigo meu perguntou quais estratégias usamos aqui na Microsoft para minimizar esses tipos de problemas e garantir que exista um padrão mínimo de codificação para aumentar a qualidade do código que esta sendo submetido e tambem melhorar a manutenção futura do codigo.
Comecei a explicar que existem varios mecanismos, desde ferramentas e metodológias que a Micrososft usa, mas foi quando comecei a falar sobre um exercício que fazemos aqui chamado Code Review que ele ficou realmente interessado. Existem inúmeros benefícios de fazer e receber code review antes que o código seja submetido (check in), dentre eles: validar se a funcionalidade esta sendo alcançada, validar se o código esta seguindo os padrões estipulados pelo time, validar se o códgio é entendivel por outros desenvolvedores, obter uma opinião externa sobre o código escrito, entender melhor partes do sistema/código que você não esta diretamente trabalhando, encontrar possíveis bugs que o desenvolvedor pode estar introduzindo no sistema, aprender com os outros, etc, etc, etc...., como falei existe muitas vantagens e seria muito difícil listarmos todas.
Aqui no meu time antes de fazermos check-in, temos a orientação de receber pelo menos 2 code reviews, ou seja 2 desenvolvedores vão analisar o código e fornecer comentarios (caso exista algum). O code review é algo que todos podem se beneficiar, portanto tente estar sempre aberto as sugestões de quem esta fazendo o code review. Muitas vezes ficamos um pouco defensivos sobre o que estam falando do nosso código e entendemos o code review como duras criticas ou sugestões não necessarias. Uma dica é tentar sempre ver quem esta revisando seu código como seu aliado, ele pode estar te ajudando a evitar bugs. Inumeras vezes eu recebi code review eu pensei que tal sugestão seria desnecessária, aprendi que se nao tivesse aceitado a sugestão teria problemas futuros com meu código, ou seja a melhor estratégia durante code reviews é deixar seu ego de lado e tirar o maximo de proveito da situação.
Além de todos esses benefícios, o code review também fornece uma maior confiança ao desenvolvedor no momento do check-in. A introdução de um bug no sistema nunca é recebida com bons olhos, mas existe sempre a desculpa de que o código foi revisado e ninguém foi capaz de encontrar o bug durante o code review. :-)
Uma outra dica que pode ajudar a evitar muitos bugs e forcar uma padronização de escrita de código é a utilização de ferramentas de análise de código. Existem diversas ferramentas no mercado sobre isso, por exemplo: aqui no meu time antes de enviarmos nosso código para code review, usamos 2 ferramentas que ajudam na validação se o código esta seguindo um padrão mínimo de qualidade.
Ambas ferramentas são totalmente gratuitas e possuem uma utilização muito facil, em minutos você pode evitar serios bugs. Outro exemplo de ferramenta muito popular para esse tipo de exercicio é o Code Auditor, essa ferramenta é bem mais completa do que o StyleCop por exemplo e suporta outras linguagem alem do C#, o lado ruim é que não é uma ferramenta gratuita. :-(
É isso ai pessoal, fica aqui a minha dica sobre o exercício de fazermos code review antes de efetuarmos qualquer check-in, caso você/seu time também esta passando por um problema parecido e gostaria de compartilhar sua experiência comigo, aguardo seu email.
Abraços.