Vamos começar esse post fazendo um acordo: as considerações e opiniões abaixo são para contextos específicos. Não escreva código nojento para coisas importantes e/ou que precisam ser duradouras. Acordo feito, vamos para uma definição:

manutenível
passível de ser manutenido ou mantido.

Quando escrevemos código (serviços, aplicações, etc.) precisamos nos preocupar em como a implementação se comportará no futuro e, para isso, procuramos adotar boas práticas e padrões afim de que sua manutenção seja facilitada e alterações necessárias sejam de simples compreensão. Mas será mesmo que isso é sempre uma verdade absoluta?

Evidentemente há aqui, a depender do contexto, uma linha tênue sobre qualidade. Ao assumir débitos técnicos (especialmente por gambiarras), você está afirmando que sofrerá penalizações em seu ciclo de desenvolvimento futuro, seja como retrabalho ou aparição de novos erros.

Quando

Mas então, como podemos determinar quando não precisamos nos preocupar com o ciclo de vida de um código? Ou então, o que é um código mal escrito? De fato, perguntas difíceis, mas vamos tentar começando pelo "quando" você muito provavelmente não deve se preocupar tanto com o que está construindo:

Scripts simples de formatação de arquivos;
Scripts de chamadas em massa para cadastro de usuários de teste ou outra massa de dados quaisquer;
Páginas de teste/temporárias;
Validações simples de usabilidade/conversão de usuários;
Scripts de rotina de uso pessoal (notificadores, webhooks, etc.);
Qualquer implementação para fins acadêmicos e que não vai precisar apresentar a ninguém; Etc.

Qualidade

Já sobre código mal escrito, entramos em mais um vórtex de ambiguidades. O código que compreendo e interpreto pode sim, ter percepções em relação à qualidade, diferentes da que você ou qualquer outra pessoa analise/construa. Mas há norteadores mais bem aceitos e testados (ou seja, que funcionaram em diversos outros cenários e contextos) que podemos nos espelhar. Calma, não vou te receitar doses cavalares de "Uncle Bob" (ao menos não dessa vez).

Vamos abstrair um pouco mais essa questão para retirar parte das ambiguidades e direções que possam aqui existir: um código bem escrito é bem escrito porque é fácil de entender e manter. Logo, precisa ser fácil de entender para alguém ou alguma coisa ou, se você estiver precisando pagar seus boletos, para várias pessoas (se você trabalhar com/para uma IA, talvez seja para alguma coisa - mas isso é assunto para outro post). Isso quer dizer que, você e seu time, determinarão boas práticas a seguirem e o que é um "bom código" mesclando experiências e aprendizados que obtiveram no passado e/ou no percurso.

Questione

Distinções e exemplificações feitas, afinal, por que não se preocupar com a qualidade de implementações desse contexto? Inicialmente, por um motivo simples: porque é mais rápido. Nosso cérebro implora por feedbacks de coisas que construímos/aplicamos e, quando isso é quase que instantâneo, a chance de você não desanimar no meio do caminho, é maior.

Ademais, nós sabemos: a vida real é a selva. Nem sempre teremos todo o tempo que gostaríamos para tratar tudo como nossos mais preciosos anéis. Produto, mercado e dinheiro são coisas extremamente difíceis de lidar. Gaste seu precioso tempo e sanidade mental enquanto pessoa desenvolvedora de software priorizando coisas que serão/precisarão ser minimamente duradouras e importantes.

Até a próxima! 🖖

# Débito técnico

Seu código não precisa ser sempre manutenível