É bom deixar claro uma coisa. O ponto central destes dois (agora três) artigos é tentar combater a cultura enraizada do "está funcionando, não mexe".
Ouvi, ouço e acredito que ainda vou ouvir isso de muitos analistas, inclusive experientes.
A questão do cliente precisa ser mais detalhada.
Em primeiro lugar, quero deixar claro que me refiro a todos os clientes com que trabalhei. Alguns lidam melhor com essa situação, outros não. Inclusive nesse aspecto, creio que a responsabilidade de provar que a melhoria constante no código é um benefício, seja do analista.
Estamos falando de um nível muito baixo no desenvolvimento, o código. O cliente não tem a obrigação de ter visibilidade, o gerente da equipe normalmente não tem e a questão repousa no colo dos líderes técnicos e analistas. Mais especificamente dos analistas, pois estes estão em contato permanente com o código.
Acredito que a nossa área ainda encontra-se em fase de maturação, e vai demorar para que tenhamos uma equalização do conhecimento da importância da qualidade, por todos os níveis envolvidos no processo.
Se o cliente não bancar uma melhoria, o gerente fica sem ação (fica só tomando pancada nas reuniões), o líder menos ainda e o analista, quando psicopata, vai arcar com a melhoria do código. Por outro lado, um analista sem voz, não consegue convencer o líder, este não vai convencer o gerente e este não vai convencer o cliente. Ovo e a galinha?
É claro que estou pintando o pior cenário, quando nem o líder técnico crê nos benefícios da qualidade.
Neste cenário, só vejo uma forma de quebrar esse circulo vicioso. O analista mostrar, praticamente, que estas melhorias vão gerar valor para o cliente e poderá aumentar a sua margem de lucro, com a redução dos custos de manutenção.
Agora vamos a outra questão que está sempre batendo à minha porta. Por que foi codificado sem preocupação com a qualidade?
Em primeiro lugar, prazos e metas agressivos demais. Nada é mais frustrante do que trabalhar com prazo estourado ou sabendo que o prazo vai estourar de qualquer forma.
Agora vamos analisar a estrutura mais comum de uma equipe.
Temos um sênior, dois plenos e três estagiários.
O sênior faz as especificações, os plenos cuidam da codificação complexa e os estagiários funcionam como code-monkeys. Na minha visão, é correto o papel de code-monkey dos estagiários, já que nossas faculdades não formam bons júniores. Quando muito, dá muito conhecimento teórico e nada sobre boas práticas, desenvolvimento corporativo, etc. Com a repetição, o estagiário aprende "na marra".
Claro que falta a figura do arquiteto e dos juniores, mas para a explicação, creio que esta estrutura seja suficiente.
Voltando. O sênior especifica como a coisa deve ser feita e cuida dos códigos complexos. Os plenos cuidam dos códigos complexos. Os estagiários cuidam do serviço repetitivo, como a criação dos DAOs. Notar que não estou entrando no mérito se DAO é bom ou ruim, é apenas exemplificação.
Um dos meus contratos com a equipe, como especificador, são as interfaces. Se não monto uma interface com qualidade para os DAOs, como os estagiários farão um trabalho decente? Difícil. Se monto uma interface com o metodo "add" lançando uma Exception (sic!), como o estagiário saberá que isso é uma péssima prática? Ele vai lançar Exception até se a mãe dele vier a pedir alguma coisa.
Se estou criando uma arquitetura baseada em VO e BO, como explicar para ele que trata-se de um modelo anêmico? Neste outro excelente artigo, Fowler fala sobre o modelo anêmico e a má utilização da Service Layer.
Quase sempre a culpa cai nos ombros dos pobres estagiários, mas vejo isso muito mais como um problema de quem está acima. O estagiário está ali para aprender.
Então, contrário do que muitos podem estar pensando, não creio que a implantação da qualidade, como pedra fundamental da área de desenvolvimento de softwares, seja algo simples.
É necessário mudar muita coisa em muitos lugares. Mas temos que começar de alguma forma.
Nenhum comentário:
Postar um comentário