No intuito de estudar, venho relendo diversos livros e escrever sobre o que li me ajuda a fixar, então decidi criar um post pra cada parte que eu achar interessante, este será o primeiro do livro Clean Code.

Já não é surpresa pra nenhum desenvolvedor com algum tempo de mercado que projetos tendem a ser mais rápidos no inicio e com o tempo vão ficando cada vez mais lentos e custosos.

Você já se perguntou o por quê?

É disso que Robert C. Martin trata no capitulo The Total Cost of Owning a Mess do livro Clean Code e que vou analisar abaixo.

O Ciclo Vicioso

Todo desenvolvedor experiente já mexeu em código que parece um castelo de cartas, a cada nova adição você corre o risco de derrubar boa parte do castelo e adicionar um campo novo na tela torna-se uma epopeia de duas semanas.

O sistema se torna cada vez mais custoso de se manter e melhorar, o que antes era feito por um time, agora precisa de vários. A gestão faz a unica coisa que pode fazer pra tentar estancar o sangramento: contratar mais pessoal.

Isso pode aumentar a cobrança por produtividade, encurtando prazos e aumentando demandas, fazendo com que mais e mais débitos técnicos sejam adquiridos para que as entregas de valor aconteçam.

Algum tempo depois a base de código está tão problemática que torna-se muito atraente reescreva-la, porém, sem a devida disciplina cultural por parte da empresa e do time técnico, pode tratar-se de uma armadilha!

A armadilha da Reescrita

O autor descreve desenvolvedores cansados de lidar com uma base de código insuportável de se trabalhar demandam a reescrita da aplicação, usando boas práticas desde o inicio.

Selecionam os melhores desenvolvedores da empresa, montando o time dos sonhos, mas com o tempo, se a cultura de desenvolvimento da empresa não mudou, a tendência é que a nova base de código se torne tão problemática como a primeira.

É pior ainda quando, na reescrita, é decidido trocar a linguagem/stack sem um bom motivo.

Os desenvolvedores terão então duas bases de código para manter, o código legado e cheio de problemas e o código novo, ainda muito cru pra ser mantido facilmente e sempre correndo atrás das funcionalidades do legado.

Eventualmente os antigos desenvolvedores do time dos sonhos vão deixando a empresa, um novo time é composto e voltamos ao ponto de querer reescrever toda a aplicação, agora com duas.

E ai está a armadilha, agora teremos duas bases de código problemáticas para manter.

A atitude de um desenvolvedor

"They may defend the schedule and requirements with passion; but that's their job. It's your job to defend the code with equal passion"

Essa frase resume bem o pensamento do autor a respeito da responsabilidade dos desenvolvedores nessa "bagunça".

O papel de cada desenvolvedor e principalmente de suas lideranças é defender a qualidade de suas entregas, acaba se tornando um equilíbrio de poderes, que quando não ocorre, as coisas começam a dar errado.

Por isso é de suma importância que os lideres técnicos tenham essa visão de defender o código e de apontar quando o custo de priorizar os requisitos e o cronograma for alto demais.

Claro, cabe ao leitor avaliar o momento certo de defender o código, não saia daqui com a impressão errada de que temos que defender o código a qualquer custo!

É o seu trabalho apontar isso! Você é quem sabe o impacto dessas decisões e deve ser responsável comunicando-as aos decisores.

Assim como uma equipe saudável deve ter a abertura para questionar as decisões e apresentar contrapontos, que podem ou não ser acatados, mas essa liberdade deve existir.

Conclusão

O capitulo trata com bastante seriedade a responsabilidade do desenvolvedor no processo que leva um código a ficar sujo.

Existem contrapontos importantes a visão do autor sobre débitos técnicos serem sempre ruins, sobre defender o código em absoluto e o excesso de engenharia que o clean code prega.

Mas não vou tratá-los neste post, ficaram para um próximo, mas fique tranquilo que trarei o link aqui!