Para os que se interessaram pelo tema, pois tem algum colega com dificuldades sérias de higienização: sinto muito. Não é minha intenção fazer devaneios sobre o número máximo de dias que um desenvolvedor pode utilizar a mesma camiseta. A expressão ‘maus cheiros’ (em inglês ‘bad smells’) é utilizada em software como indicativo para alguma coisa que pode não estar bem.
Martin Fowler e Kent Beck introduziram o conceito de ‘mau cheiro’ no código fonte: código duplicado, métodos longos, muitos parâmetros e outros. Gerard Meszaros fez o mesmo para testes: testes obscuros, lógica de testes em produção, para citar alguns. O mau cheiro não indica que, efetivamente, existe algum problema, mas serve como um indicativo que certamente vale a pena examinar.
Me aventuro, a seguir, na tentativa de identificar quais seriam os maus cheiros (MCs) no comportamento de um desenvolvedor de software. Insisto que não necessariamente um mau cheiro esconde um problema, mas, na minha experiência, pode sim estar afetando negativamente o time, o projeto ou o negócio.
MC#1: Postura defensiva.
Apontar as falhas dos outros. Sempre descobrir um terceiro que pode ser culpado pelo problema de hoje. Envolver-se em trocas intermináveis de emails (ou simplesmente não envolver-se para se proteger). Tomar todo e qualquer feedback como um possível ataque pessoal. Vemos essas atitudes diariamente em diversas organizações e negócios, atitudes estas que prejudicam muito a capacidade de colaboração de um time.
Desenvolver software que seja competitivo demanda esforço. Muito esforço. Dificilmente uma pessoa sozinha consegue ser competitiva nessa empreitada. Precisamos de times. E somente times capazes de colaborar conseguem entregar produtos realmente inovadores.
Se alguém optou por ser desenvolvedor de software por acreditar que obteria fama e fortuna sem a necessidade de interagir com outras pessoas que não o seu computador, nunca é tarde para buscar outra profissão.
MC#2: Não codificar testes (na frente).
A abordagem utilizada no desenvolvimento de software tem evoluído bastante. Uma das técnicas que mais tem contribuído para a melhora de qualidade do software sendo produzido é o desenvolvimento guiado por testes. Através dessa abordagem, o desenvolvedor inicia pela codificação da especificação de um comportamento, para depois escrever o código que implementa o comportamento esperado.
Quando bem aplicado, esse processo resulta em um código bem documentado, que já oferece uma bateria de testes de regressão. Para trabalhar dessa forma, o desenvolvedor se vê obrigado a escrever código testável, melhorando a qualidade interna do código. O custo de localização e correção de erros é reduzido, entre outras vantagens importantes.
Uma das principais barreiras para a adoção dessa abordagem é a resistência dos próprios desenvolvedores. Infelizmente, nós, desenvolvedores, também somos humanos e, portanto, nos acomodamos com os nossos próprios processos. Este seria um bom momento para todos os usuários que ouviram as nossas ironias em relação à dificuldade de usar nossos novos sistemas nos darem o troco!
MC#3: Ausência de curiosidade tecnológica.
Um tipo de desperdício muito importante no desenvolvimento de software é a defasagem tecnológica. A defasagem tecnológica é um tipo de desperdício pois nos obriga dispender maior quantidade de esforço do que a necessária para resolver um determinado problema.
Novos frameworks de desenvolvimento, como Ruby on Rails, ou novas formas de entrega de serviços, como Cloud Computing, entre outras, têm possibilitado um incremento de produtividade bastante significativo. Para tanto, o desenvolvedor precisa assumir uma postura ativa em relação ao próprio aprendizado. Para que possamos ser competitivos precisamos buscar atualização constante.
A falta de iniciativa em relação a esse aprendizado, ou uma postura defensiva em relação a novas tecnologias, ferramentas ou métodos, levam negócios, projetos e sistemas a uma importante defasagem competitiva.
MC#4: Agenda própria.
Quantas vezes participamos de projetos onde cada um faz a sua parte mas o resultado final não atende as expectativas? Muitos desenvolvedores fixam-se em realizar cada uma das tarefas inicialmente planejadas da melhor forma possível, perdendo de vista o todo. Dadas as incertezas de um projeto de software, ter viva a visão do todo, os objetivos do esforço e repensar as tarefas de forma a atingir os objetivos são elementos necessários para a competitividade no desenvolvimento de software. De que adianta um sistema com capacidade de atender um milhão de usuários que ainda não consegue atender nenhuma demanda real de negócio?
MC#5: Aceitar apenas atribuições dentro da sua especialidade.
Desenvolver software é uma atividade que cada vez demanda maior especialização: arquitetura, infraestrutura, análise, testes, mobilidade, segurança, desempenho, e por aí vai. Dispor dessas especialidades é fundamental. Além disso, para aproveitar melhor as competências das quais dispomos, a última coisa que queremos é um especialista em banco de dados codificando o software enquanto um programador otimiza o banco.
Entretanto, velocidade de entrega é fundamental, e o esforço necessário para cada tarefa a ser executada no desenvolvimento de um software sofre variações estratosféricas. Estudos apontam para um fator de produtividade de mais de 20 vezes entre programadores . Um mesmo programador tem variações enormes de produtividade dependendo do dia. Para que um time consiga entregar de forma rápida, além de dispor das competências necessárias, precisa de membros versáteis, capazes de avançar outras atividades para viabilizar os objetivos de negócio.
Recusar-se a executar uma atividade, pois talvez seja necessário algum aprendizado para entregá-la, ou adiantar tarefas menos importantes, pois as pendentes não são dignas do nosso esforço, são comportamentos para os quais temos que estar atentos.
MC#6: Desenvolvedores fazendo o check in de grande volume de código.
O consumo excessivo de tempo na integração de grandes mudanças de código sinaliza que o desenvolvedor talvez esteja espaçando muito as entregas ou assumindo tarefas demasiadamente grandes. Os desenvolvedores de hoje têm que, cada vez mais, serem capazes de quebrar o trabalho a ser realizado em pequenos entregáveis, utilizando as estratégias adequadas para colocar a disposição do restante do time o que vai sendo finalizado.
Além de competência, essa abordagem demanda disciplina. E sim, ela é viável e fundamental para reduzir o retrabalho e melhorar a previsibilidade das entregas.
Outros maus cheiros por aí? Compartilhe comigo!
Artigo de Alejandro Olchik, originalmente publicado em baguete.com.br