E-Rápido

Vivemos em um ambiente instável, hora está tudo calmo, um ar sereno paira sobre nossas cabeças, todos os projetos estão dentro do prazo, bugs controlados, cliente feliz, hora está complicado, projetos atrasados, clientes insatisfeitos, quantidade de bugs crescente e equipe desesperada. Não é incomum passarmos pelos dois cenários, sabemos como é, e nossas atitudes podem variar bastante entre estes dois cenários, tanto para pior, como para melhor.

Levando em consideração o segundo cenário, onde tudo parece complicado, tudo parece atrasado e clientes infelizes, naturalmente colocamos em ação o modo e-rápido. Quando estamos programados nestes modo, tentamos fazer tudo da maneira mais rápida possível, mesmo que não seja a maneira correta (daí o nome e-rápido, e = errado, ou seja, o modo errado e rápido).

Sempre que fazemos tudo na base do atropelo, de forma rápida, comprometemos o “outro lado”. Mas, que lado é este? O lado da qualidade, do raciocínio, da sensatez! É muito fácil fazer isto, visto que, parece que neste cenário, temos a sensação de que não há tempo para qualidade, ou para raciocinar muito, mas há!

Divida Técnica

Estamos acostumados a lidar com dívidas técnicas, talvez você não tenha percebido, mas quando se dá manutenção num código ruim, você está liquidando uma divida técnica. Sabe aquele código mal feito? Ou então aquele código sem testes que você terá que por as mãos agora? Então, isto é pagar uma dívida técnica. Você inevitavelmente terá que refatorar alguns pedaços, criar alguns testes ou testar manualmente após sua alteração, em resumo, fazer o que já deveria estar feito (e com um custo muito, muito maior).

Sempre que fazemos ou construímos algo da forma e-rápida, pode ter certeza de que
estamos assumindo uma dívida técnica, e esta é uma péssima ideia! Assumir dividas técnicas é dizer a si mesmo ou à equipe na qual você faz parte, que alguém sofrerá no futuro ao tentar dar qualquer manutenção no que foi feito. Seja pela falta de testes unitários, seja pela forma como o código ou a solução foi construída, seja pela falta de documentação, alguém pagará esta dívida em algum momento, e com juros!

As dívidas técnicas crescem por si só, conforme o tempo passa, cada uma das dívidas assumidas vão crescendo, tomando formas desproporcionais, e no final, fica bem complicado de paga-las.

Desligando o modo e-rápido

Esta não é uma tarefa muito fácil! Desligar o modo e-rápido requer responsabilidade, imposição e sensatez. Entretanto, é recompensador, principalmente a longo prazo.
Sempre que estiver em uma situação complicada, com prazos apertados, resista à tentação de fazer tudo nas pressas, faça com calma, teste tudo o que fizer, e se possível, construa testes unitários em todo os códigos que desenvolver, isto o ajudará muito no futuro, e com certeza ajudará a equipe da qual você faz parte.

Sabemos como é complicado dar manutenção em código ruim, obscuro, sem testes, e sabemos também o custo disto! O tempo que levamos para dar manutenção em um código limpo e testado é muito inferior ao tempo necessário para dar manutenção em um código ruim e sem testes, não é mesmo? Pense nisto sempre que estiver em apuros e tentado a usar o modo e-rápido, reflita e busque não utiliza-lo.

Exceção à regra

Sim, apesar de eu defender piamente que nada seja feito no modo e-rápido, sei que existem exceções! Em situações emergenciais, onde devemos agir de forma rápida, é possível utilizarmos o modo e-rápido para resolver uma determinada situação, não é errado fazer isto, desde que, passada a situação emergencial, você retorne ao ponto inicial e faça tudo com a devida qualidade e responsabilidade, eliminando prontamente a divida técnica criada recentemente.

Apesar de existir uma exceção, onde podemos utilizar o modo e-rápido, não podemos converter esta exceção em regra! Sempre que utilizarmos o modo e-rápido em situações assim, devemos ter a preocupação de quitar a divida técnica o quanto antes para que no futuro não tenhamos que quitar com um valor consideravelmente mais alto.

Responsabilidade

Seja responsável! Se você é um desenvolvedor, não faça nada do modo e-rápido, você está prejudicando a si mesmo e a todos que no futuro terão que mexer no que você construiu!

Se você é um gerente ou líder de equipe, garanta que os desenvolvedores que fazem parte de sua equipe não façam nada no modo e-rápido, pois se fizerem de forma desenfreada, no futuro terá que contratar mais e mais desenvolvedores, visto que, conforme aumentam as dívidas técnicas, aumentam os custos com manutenção (tempo para dar manutenção em algo), e com custos elevados, é necessário mais “mão de obra”.

Conclusão

Apesar do modo e-rápido parecer adequado em diversas situações, até mesmo parecer o jeito correto de resolver vários tipos de situações, não é! Os malefícios causados pelo modo e-rápido são muito maiores que os benefícios, em outras palavras, os benefícios são momentâneos, vão satisfazer às necessidades atuais, porém, os malefícios permanentes e perceptíveis num futuro próximo, e provavelmente se tornará uma bola de neve, que cresce constantemente.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.