No dia 26 de setembro de 2018 fui convidado para participar do 7Masters sobre qualidade de código. Foi uma experiência incrível dar uma palestra de 7 minutos sobre um tema tão complexo e ao mesmo tempo tão simples!

Mas, obviamente, em 7 minutos não é possível mostrar toda a extensão de um assunto, justamente porque temos que comprimir o conteúdo para suas partes mais importantes, então surgiu este artigo, um complemento ao conteúdo deste dia sensacional, mostrando algumas ideias a mais e explicando mais a fundo todo o conteúdo.

Por que “qualidade de código”, e não só “qualidade”?

Sempre que pensamos em qualidade de código, nos vem a mente aquele código feito às pressas, cheio de variáveis com nomes nada significativos – em suma, um código ilegível. Provavelmente, uma das primeiras imagens que aparecem na cabeça é a da capa do excelente livro “Clean Code”, de Robert Martin.

Mas, e se eu disser que existe uma forma de você melhorar a sua qualidade de código, suas entregas e todo o fluxo do que chamamos de “desenvolvimento” sem precisar encostar um dedo no código?

O fato é que: qualidade de código é muito mais do que só codificar de forma bonita, dar nomes significativos, manter as linhas entre 80 caracteres e tudo mais. Na verdade, grande parte do que faz um software de qualidade ser, de fato, um software de qualidade, está nas pessoas que o constroem. Afinal, todos estes sistemas são criados por pessoas para pessoas.

Para entendermos um pouco mais sobre qualidade de código, precisamos primeiramente entender o conceito de qualidade.

O que é qualidade?

Pela definição simples de qualquer dicionário, teremos algumas ideias:

“Capacidade de atingir o(s) efeito(s) pretendido(s).”

Também temos:

“Característica ou atributo distintivo, positivo ou negativo, que faz algo sobressair em relação a outros.”

Então, se formos sintetizar o significado, podemos dizer que qualidade é quando fazemos algo que atinge os efeitos que um cliente (que pode ser nós mesmos) quer de forma extraordinária, tão extraordinária, que faz com que este trabalho se sobressaia em relação aos demais do mesmo tipo. Podemos resumir tudo isso no que chamamos de “Trabalho bem feito“, embora até isso seja uma definição bastante simplória do que é qualidade de verdade.

Para o cliente

Quando pensamos em qualidade, automaticamente pensamos em algo caro, muito bem construído, talvez feito a mão, que funcione e que nos deixe contentes em estar usando ou tendo aquele tipo de produto.

Da mesma forma que você pode comprar produtos de qualidade superior, por exemplo, um fone de ouvido com uma definição melhor de som, ou então uma televisão com uma melhor qualidade de imagem, você também pode criar um software que tenha uma melhor qualidade. Mas como medimos essa qualidade? Podemos citar alguns requisitos que nos faz dizer: “Este software foi bem feito” pelo ponto de vista de um cliente:

• Rápido
• Estável
• Fácil de se utilizar

Mas além disso, qualidade é gerar valor. Um sistema de qualidade precisa, acima de tudo, resolver com perfeição o problema o qual se propõe a resolver. Você pode ter um sistema estável, rápido e super simples de se utilizar, mas se ele não resolve o problema para qual foi desenvolvido, nada disso importa. O contrário também é válido, se o sistema resolve o problema, mas não é rápido, estável ou simples, então o usuário não vai utilizar.

Para o desenvolvedor

Além da visão do cliente, também temos a visão do desenvolvedor em tudo isso. Software se constrói em equipes, portanto um sistema precisa ser, ao mesmo tempo, de qualidade para nosso cliente final, que vai usar o sistema e ver valor naquilo, mas também para aqueles que o desenvolvem, já que são eles os responsáveis por manter este sistema de forma contínua.

Não vamos entrar no mérito do que é qualidade tão a fundo para a visão dos desenvolvedores, até porque isso exigiria que escrevêssemos um guia para todas as pessoas envolvidas, programadores, gerentes de projetos, analistas e tudo mais. Então vamos focar nos pontos gerais: um software precisa de algumas qualidades universais para ser considerado “de qualidade” por aqueles que o mantém.

• Escalabilidade
• Eficiência
• Funcionalidade
• Manutenibilidade
• Testabilidade
• Reprodutibilidade

Como alcançar a qualidade?

Um sistema é muitas vezes comparado a uma criança, que nasce, vai crescendo e aprendendo dos pais todas as coisas boas, mas chega o momento onde temos que interagir com o mundo real e ai viramos adolescentes rebeldes; esta comparação é extremamente válida.

Todo o começo de um projeto se inicia com uma preocupação muito grande em processos, escrita, estilo, documentação e muitas outras práticas importante, que vão se perdendo com o tempo, conforme o projeto vai crescendo e sendo desenvolvido por mais pessoas.

Podemos dizer que não, mas, inevitavelmente, todos os programadores querem deixar sua marca no código, querem escrever uma linha e poder dizer: “Eu que fiz isto”, o que não está errado de forma alguma, mas começa a se tornar um problema quando padrões definidos pelo time são abandonados em prol de uma alteração de escopo, adição de alguma funcionalidade com data de lançamento marcada ou então simplesmente porque o desenvolvedor não gostou de um padrão criado e aplicado por outro desenvolvedor. Por esse motivo, o “bom código” parece, muitas vezes, uma utopia.

Como você já deve ter percebido, alcançar a qualidade de código está muito conectado ao time, a integração dos membros e à capacidade de cada um de ceder e entrar em um acordo. A palavra chave para a qualidade é: time.

Todos por um

Para começarmos a falar sobre a importância do time, primeiramente temos que entender que manter a qualwidade em qualquer tipo de atividade que é realizada por um time é um trabalho árduo, que demanda bastante tempo e esforço de todas as partes envolvidas. E, uma vez que essa qualidade é alcançada, começa a segunda parte de todo esse esforço, que é manter o que já foi feito no mesmo nível do que o que ainda está por fazer.

 

Como a ilustração anterior demonstra com maestria, o código de qualidade é bonito, rápido, escalável, mas é extremamente frágil; não porque sua estrutura é complicada, ou porque ele é ilegível, mas sim porque manter um código com qualidade continuamente é extremamente complicado, pois depende de pessoas trabalhando juntas e, como todos sabemos, humanos não tem um bom histórico de trabalhar juntos para resolver problemas – então como podemos contornar isso?

Sinergia

O primeiro passo de um time deve ser criar sinergia, aprender que cada componente deste tem uma área de especialidade, gostos e desgostos, preferências pessoais e ideias próprias. A maioria dos gestores de times acredita que impor uma visão – geralmente a sua própria – sobre o time é a solução, pois com isto esperam agrupar todas as expectativas, preferências e estilos debaixo de um só guarda-chuva.

E são estes tipos de gestores que, na maioria dos casos, são considerados os piores gestores pelo seu próprio time, pois falham em perceber que um time não deve ser uma versão distribuída de si mesmo, como uma pessoa dividida em várias, mas sim o oposto: o time deve ser várias pessoas trabalhando como uma só.

Como podemos alcançar essa sinergia? Aqui, nossa conversa se torna cada vez menos técnica e cada vez mais humana. O time deve interagir entre si, não só no ambiente de trabalho, mas também como velhos amigos. Um time que se dá bem dentro e fora do trabalho é, automaticamente, um time que não vai ter medo de se comunicar. Mais importante do que isto, será um time que se sentirá à vontade para anunciar seus próprios erros sem medo de julgamentos, sabendo que outras pessoas irão se prontificar não só para ajudar a corrigir tais erros, mas também para aprender como não cometer estes mesmos erros novamente.

A perda do medo de se expressar é essencial para que um time possa expor suas ideias, dar opiniões, concordar e, mais importante, discordar sobre vários assuntos.

Vários gestores também acreditam que, por um time discordar muito, eles estão perdendo o companheirismo e deixando de ser um time. Muito pelo contrário, a discordância gera discussões que, se debatidas de forma saudável, podem gerar dois produtos fundamentais para o bom funcionamento de um time: a capacidade de entender que você pode estar errado e outra pessoa pode estar certa (e não há nada de errado nisso!), e também a capacidade de argumentar contra ou a favor de um tópico, ideia ou sugestão.

De todas as más práticas que existem sobre gestão de times – que estão, felizmente, desaparecendo do nosso meio de trabalho – a pior delas, na minha opinião, é a chamada “canetada”, ou seja, quando grande parte do time discorda sobre algum assunto proposto por um gestor ou então um gerente – que pode ou não estar ligado diretamente ao time – mas o mesmo diz a famosa frase: “Será assim porque eu quero que seja dessa forma”.

Neste momento este gestor acabou de perder completamente a confiança de seus geridos, porque o time não irá mais confiar que suas decisões e opiniões estão sendo levadas em conta, já que elas podem ser sobrescritas a qualquer momento pela opinião do gestor. E isto nos leva a outro problema muito recorrente: Líderes.

Elegendo um líder

Pessoas em geral não gostam de ser comandadas por outras pessoas, receber ordens e instruções do que deve ser feito. Desenvolvedores são ainda mais avessos a este tipo de comportamento, uma vez que, por termos um trabalho altamente criativo, quase sempre criamos um vínculo muito forte com nossas ideias e desenvolvimentos – com certeza você já teve algum programa de estimação que protegia com unhas e dentes das alterações alheias não é mesmo? – da forma que preferimos trabalhar, muitas vezes, em uma estrutura totalmente horizontal.

O trabalho em um time (ou empresa) totalmente horizontal, ou seja, sem nenhum cargo de liderança que esteja “verticalmente” acima dos demais é, geralmente, o que faz com que desenvolvedores mais rendam em serviço, pois dão liberdade para que possamos criar ideias, escrever código e resolver problemas, que é o que fazemos de melhor.

Mas o problema é que esta estrutura é inviável a longo prazo; a medida que o número de colaboradores de uma empresa vai crescendo, torna-se necessária a figura do líder de equipe, que será a pessoa que, ao contrário do que muitos pensam, não vai ser o “chefe” dos componentes do time, mas sim simplesmente o representante das ideias daquele time perante à empresa, não há nada de errado ter este cargo, desde que um líder de time seja naturalmente escolhido, de preferência, pelo seu próprio time.

A pior atitude que um gerente/diretor pode tomar é “canetar” um líder, ou seja, escolher uma pessoa do time pelos seus próprios critérios e transformá-la, do dia para a noite, no líder daquele time. Isso cria uma sensação de impotência enorme nos membros e também, muitas vezes, os desmotivam a continuar, pois começam a acreditar que não eram bons o suficiente para possuir aquele cargo, gerando uma síndrome do impostor crescente, sem falar do medo, também crescente, em se comunicar com este líder por achar que, agora, ele ou ela está em uma posição privilegiada e que poderá demitir ou remover pessoas de seus cargos.

Mas, se não podemos escolher quem vai ser o líder, como teremos um líder para começo de conversa? Esta pergunta só pode ser respondida pelo time. Serão somente os membros deste time que poderão apontar quem será seu líder, da mesma forma que votamos nas eleições em candidatos que acreditamos que possam melhor nos representar.

Um líder que é eleito pelo time inspira confiança, pois se o time possuir essa sinergia, saberá que esta pessoa será uma boa ouvinte, que irá debater os fatos com argumentos plausíveis, que aceitará que suas ideias sejam contrariadas (e, muitas vezes, completamente descartadas) em prol de uma melhor solução vinda dos membros e, o mais importante, o time não terá medo de se comunicar com este líder, porque, afinal, o líder é também parte do time.

Será neste ponto, quando o time, ao mesmo tempo, enxerga um líder como um guia e também não o enxerga como um superior, mas sim um colega inspirador de mesmo nível, que o time ficará completo.

Conclusão

Notadamente este artigo não é técnico – não estamos falando de frameworks, códigos e outras ferramentas, mas sim de algo que é de igual importância para que todos nós, desenvolvedores ou não, possamos crescer e evoluir em nosso trabalho de resolver problemas cada vez mais complexos. Comunidades de desenvolvimento são criadas e mantidas com base nessas ideologias, e só conseguem progredir e evoluir cada vez mais porque seus membros acreditam que são parte dela como um todo.

Nenhum deles é mais importante ou menos importante do que outro. Este é o objetivo que precisamos alcançar nos nossos times para criar um código de qualidade.

Nos próximos artigos abordaremos temas mais técnicos, mas ainda relacionados ao time, sobre como podemos melhorar a comunicação e a padronização de código entre diversas pessoas com ideias conflitantes. Então fique ligado para as próximas partes!

Até mais!