Como ter um mindset diferente

Neste artigo irei abordar alguns tópicos que podemos aplicar no nosso dia a dia para melhorar e facilitar a qualidade no desenvolvimento de software.

Qualidade

A qualidade no software tem que ser um dos principais pilares no momento do desenvolvimento, pois atualmente encontramos software em todos os lugares:

Imagine você realizar uma cirurgia, usando um software que foi construído por um(a) desenvolvedor(a) que trabalhava mais de 10 horas por dia e que finalizou o projeto sem testes, entregando um dia antes do prazo de entrega. Você ficaria tranquilo em realizar a cirurgia? Ou pensando no WhatsApp, um app que está presente no dia a dia de muitos, caso a funcionalidade de visto por último não funcionasse perfeitamente, o quanto de briga entre casais isso não ocasionaria?

A mesma situação ocorre no software que nós desenvolvemos. Se não estivermos focados em desenvolver com qualidade, entregaremos um produto com muitos bugs, que causam muitos problemas para nosso usuário.

Como criar ou melhorar a qualidade no desenvolvimento de software? Na Bionexo utilizamos alguns mecanismos, como: code review, pair programming, testes unitários, testes automatizados, entre outros. Mas é importante pensar na outra ponta do fluxo, na entrega para o usuário final, implementando deploy automatizado e monitoração.

Resultado

Será que já paramos para pensar o quanto nós entregamos de resultado para a nossa empresa? Muitas vezes falamos que a empresa não nos valoriza, ou não nos dá o que realmente merecemos, mas será que o contrário é verdadeiro? Já paramos para pensar o quanto custamos e o quanto damos de retorno para a empresa em que trabalhamos? O quanto custa um erro nosso? O quanto custa um código mal escrito? Uma deploy sem todos os cuidados necessários?

Como podemos melhorar?

Se você está criando um código que gera muita complexidade, onde muitas adaptações (POGs) foram necessárias para que aquela funcionalidade funcione, não prossiga com isso. Pare, levante a mão e diga, MEU CÓDIGO ESTÁ RUIM, PRECISO REFAZER. Corrigindo bugs e não gerando outros. Se o processo de desenvolvimento está improdutivo porque precisa de automação ou se o código está causando improdutividade e precisa ser refatorado é papel do desenvolvedor reconhecer isso e sugerir melhorias.

Comunicação

Esteja sempre pronto para dar uma estimativa quando te perguntarem quanto tempo você irá ficar em uma atividade e não responda algo como: “xiii, do jeito que esta…”, responda: “Acredito que em x dias estaremos disponibilizando para teste ou o pacote para produção”.

Não fale coisas como: “se já funciona assim para que eu vou mexer?” busque a melhoria contínua, ou coisas do tipo “Se não tivéssemos problemas, não estaríamos aqui”. Nós não podemos sempre estar focados em apenas resolver os problemas, mas sim, buscar aprimorar o nosso software para mitigar esses erros.

Decisões

É esperado que um profissional seja capaz de identificar os prós e contras de uma decisão. Principalmente da parte técnica.

Lembre-se: andar com pressa não significa que irá chegar mais rápido no destino. Sempre existirá a forma “rápida” e a forma “demorada” de implementar, a forma rápida não se preocupa com a sujeira que irá se criar, pois o foco é a entrega, e a forma demorada se preocupa com as dependências que aquela alteração irá refletir, deixará o código mais fácil para se alterar no futuro.

Se muitas decisões rápidas estão sendo tomadas, é papel do profissional levantar a mão e sinalizar que as entregas “rápidas” poderão diminuir a velocidade do futuro e dependendo da situação, dizer não para aquilo que está se pedindo, pois é inviável tecnicamente, e sugerir uma outra forma para solucionar o problema.

Dívidas técnicas muitas vezes são uma solução, mesmo que a empresa opte por fazer da forma fácil e rápida, mas temos que ter em mente que eles podem ser como juros do cartão de crédito, quanto mais tarde demorarmos para pagarmos mais juros vão ser acrescentados.

Surpreenda-se quando QA encontrar um bug, da mesma forma, que criamos um pull request e não esperamos que ele tenha muitas solicitações de mudanças, assim deve ser quando QA for testar sua atividade, pode até acontecer mas tem que ser cenários raros. E se acontecer, você deve se perguntar:
“Como isso aconteceu? Por que eu não consegui identificar esses cenários nos meus testes?”. Pense em uma forma de evitar que isso aconteça no futuro, seja por falta de conhecimento no negócio ou da linguagem que está se trabalhando, procure sempre identificar os pontos de melhoria e atue neles.

“Deixe o código melhor do que quando você encontrou”.

É normal que quando você escrever na primeira vez, a sua nova classe, método ou variável não fique da melhor maneira possível, mas sempre existe espaço para melhorar.

Evolução constante

Nós devemos sempre estar estudando, não precisamos conhecer TUDO mas é preciso saber o que está rolando de novidades. E por que isso é importante? Pois pode ser que uma tecnologia que foi criada há 6 meses ajude a equipe a solucionar um problema de uma forma mais eficiente.

Há várias formas de estudar, cada um tem que encontrar a sua melhor maneira, pode ser assistindo vídeos no Youtube, lendo livros, artigos no medium ou ouvindo podcasts. Precisamos criar o nosso tempo e rotina de estudos, precisamos colocar o estudo como um hábito. Identifique os seus pontos de melhorias e comece estudando por eles.

Não adianta saber de todas as linguagens, frameworks e bibliotecas para nos tornarmos programadores profissionais, precisamos conhecer o nosso usuário, produto, time e empresa.

Ao finalizar este artigo, gostaria de reforçar que criamos software em conjunto com pessoas e para pessoas. Temos que desenvolver habilidades pessoais. Saber ouvir, saber se comunicar, ter empatia pela equipe e pelo cliente. Tudo isso é muito importante.