O bom, o feio e o mal em desenvolvimento – parte 2 – revisores e arquitetos?
E dando seguimento a serie sobre algumas coisas interessantes sobre o desenvolvimento, vamos para mais um novo capítulo. [OFF] São tantas histórias vou acabar escrevendo um romance [/OFF]. Após a repercussão do primeiro artigo de mesmo nome, alguns conhecidos me procuraram para dizer que, existiam outras situações que poderia abordar dentro da série. Uma dessas situações foi sobre estruturas de equipes de desenvolvimento e com isso, acabei me lembrando de uma época, numa dada empresa, em que tínhamos a figura do revisor de códigos. É isso mesmo que você leu, meu amigo …revisor de código.
O revisor de código é o cara que após você ter implementado toda a solução, antes de você colocar as sua alterações no CVS (meu deus, antigo), ele vem e verifica se o seu código está bom, onde bom, significa dentro de um padrão que não está em lugar que não na cabeça dele. Antes que me apedrejem em praça pública, sei que nem todos são assim, e que em muitos tinha ou tem, regras de estilo bem claras e até automatizadas através de plugins em suas IDEs.
Revisar o código não é uma atividade ruim. Ter premissas de estilo e formatação é algo interessante pois padroniza e pode facilitar qualquer pessoa, que esteja acostumado com os padrões da empresa, ler o fonte e entender. Essa preocupação, inclusive, tem sido tema de discussões muito atuais e serve até de argumento para definir o uso ou não de linguagens ( sendo mais específico, são questões como expressividade, legibilidade, etc – suggar sintaxe) . A questão que eu coloco é isso passar o limite do bom senso e do razoável e se tornar uma ditadura sem direito de questionamento.
A própria situação de ter uma única pessoa responsável por zelar pela qualidade do código para mim já é algo péssimo.
Mas então? Qual é o melhor cenário? O que pode ser feito, já que eu disse que qualidade e estilo são bons, se ter alguém revisando é péssimo?
Alguém aí, por acaso, disse … Programação em par!?!?!? Bingo!!! Essa, no meu entender, é um bom caminho. É bom, pois permite a troca, a interação. É bom, pois permite, que a responsabilidade seja de todos e não somente de uma única pessoa. Tira gargalos ( quem nunca ficou parada esperando o revisor ter tempo para ver e validar a implementação). O time como um todo decide o que é melhor.
Nesse cenário as chances das coisas serem menos impostas e mais consenso são grandes. Não existe um ponto único e sim diversidade de visões. O time fica aberto e sempre como abertura para melhorar ou experimentar, desde que todos concordem ou pelo menos seu par, que aquilo traz algum valor.
Observem – bem lembrado por um colega – que nem toquei no fato de revisão de tecnologia, arquitetura. Na velhas e empoeiradas estruturas de fábrica, tem casos em que além do revisor, tem ainda o grande e todo poderoso arquiteto que decide quais tabelas, quantas classes, como as classes são, qual linguagem, api, framework, qual papel higiênico, que todos devem usar. Para mim isso consegue ser pior que o revisor. Pois ele tolhe a inovação, o salto para frente. não quero dizer com isso, que devemos fazer de nossos projetos um laboratório de novas linguagens e etc… estou dizendo que se existe algo que venha a facilitar porque não pelo menos olhar o que é …
Novamente transferir essa “responsabilidade ” para o time é a melhor coisa. Pois se discute. Todos tem voz. A chance de escolher algo interessante é maior… não fica a cargo de um louco que pode ser um tarado por novidades ou um louco que nunca deixará de usar Java 1.3.1 pois sempre funcionou e “não se mexe em time que está ganhando”.
Bem esse era meu recado… aguardo as opiniões de vocês.