Recentemente tive a oportunidade de assitir uma palestra do Mark Shuttleworth na Linux Tag 2010. Naturalmente, foram abordados os assuntos de open-source de uma forma mais abrangente e do próprio Ubuntu. Não consegui acompanhar todos os detalhes pois não sou tão envolvido assim com Linux. Mas achei bem interessante quando ele abordou a questão de qualidade de código.
Em particular, gostei bastante do que foi dito com relação à revisão de código. É relativamente comum quando programadores externos a um projeto ou simplesmente menos experientes têm seus códigos revisados por alguém do núcleo principal. O que pode não ser tão perceptível imediatamente é que essa prática também é extremamente útil no sentido inverso. Dessa forma, o aprendizado se torna bem mais motivante já que o novo programador é diretamente exposto ao que é considerado um modelo de código de boa qualidade dentro de determinado contexto.
Com certeza essa é uma prática já utilizada em vários projetos e empresas. Mas talvez não tanto quanto poderia ser. Portanto, se sua equipe ainda não a utiliza vale à pena considerar esse item para as próximas discussões sobre melhorias no processo de desenvolvimento.
Continuando o assunto, também comecei a refletir sobre a existência de uma definição amplamente aceita e, principalmente, adotada na prática do que é um código de boa qualidade. Creio que na grande maioria dos ambientes profissionais esse ponto é teoricamente tido como importante. Mas será que na prática é assim mesmo? Além disso, será que a meritocracia empregada no dia-a-dia dos envolvidos considera de forma justa esse fator?
Arriscaria dizer que boa parte dos engenheiros de software já passaram por uma situação na qual foram cobrados por terem atrasado no desenvolvimento de determinado software. Realmente estimativas não são fáceis de serem feitas. E uma das razões que podem deixá-las falhas é quando são baseadas em uma visão simplista e puramente comparativa com base em algum componente ou biblioteca escrita por determinado programador dentro de um determinado tempo. Sendo que em certos casos esse tal programador acaba sendo considerado como um exemplo pois executa suas tarefas com rapidez e “eficiência”.
O problem nesse tipo de situação é que o simples fato de que alguém conseguiu escrever determinado software em determinado tempo significa algo próximo de nada se pontos relacionados à qualidade do código não forem avaliados. Além dos fatores óbvios que são o software atender aos requisitos desejados e conter poucos (quem sabe zero) bugs, a lista abaixo resume minhas principais expectativas com relação a um bom código-fonte.
- Em primeiro lugar, o código deve ser altamente inteligível e limpo. Entender um programa é fácil para qualquer computador, mas nem sempre para um ser humano.
- Deve haver boa reutilização de código. Trechos relativamente parecidos, funções compridas, abusos de herança, classes sobrecarregadas, entre outros, não são bons indicadores.
- Mudanças de comportamento não muito complexas mas também não triviais devem ser suportadas por uma base flexível.
- Pontos de extensão devem ser fornecidos. Idealmente da forma mais genérica possível.
- Os recursos da linguagem de programação em questão devem ser usados da forma apropriada. Tanto o conhecimento da definição e estrutura da linguagem, assim como da API, devem ser visíveis.
- Teste de unidade para os principais componentes. Dependendo do caso testes mais abrangentes também.
- O código deve possuir uma única “cara”, desde técnicas/estilos de códificação até padrões arquiteturais. Isso promove a integridade conceitual do código.
Pode ser que os itens acima não sejam novidade para ninguém. No entanto, chutaria dizer que na maioria dos projetos eles não são levados em consideração de forma profunda. Isso devido à falta de visão (da importância do assunto) ou até mesmo devido à falta de competência e conhecimento técnico para realizar uma avaliação detalhista e precisa.
Além disso, há ainda um fator complicador: o tempo. Nem sempre é possível chegar a uma conclusão definitiva com relação à qualidade de um código se não houver momentos em que seja necessário lidar diretamente com extensões ou qualquer tipo de manutenção sobre ele (incluindo, naturalmente, correção de bugs). Nesses casos as facilidades ou dificuldades encontradas durante tarefas reais podem contribuir significativamente para um veredito final. E para que isso aconteça é necessário que o software tenha passado por etapas relevantes de seu ciclo de vida. Não há substituto para o tempo.
Já vi muitas iniciativas com intuito de melhorar a qualidade de um produto tendo foco em gestão ou modelos processuais. Apesar de ajudarem (se muito ou pouco, depende do caso eu acho), elas nem sempre atuam diretamente na essência do problema (na verdade, da solução) que é a qualidade do código. Para investir em qualidade de produto é obrigatório investir, entre outras coisas, na qualidade do código-fonte. Portanto, tenha revisores de código que realmente entendam bem de fundamentos da computação (como algoritmos e estruturas de dados), que conheçam bem as linguagens de programação, as tecnologias envolvidas, boas práticas de programação e arquitetura, e que gostem de estudar.
Leandro Melo
