O custo total de manter uma bagunça

No intuito de estudar, venho relendo o Clean Code e escrever me ajuda a fixar, então decidi criar um post pra cada parte do livro que eu achar interessante, este será o primeiro da série do 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 e a gestão faz a unica coisa que pode fazer contratar mais pessoal pra fazer o que antes era executado por um time muito menor elevando o custo da operação.

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 que os 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.

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, mas quando esse poder está desequilibrado as coisas começam a dar errado.

Por isso é de suma importância que os lideres 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.

É 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.