5 razões porque você NÃO deve reescrever seu sistema

Publicado em Janeiro 21, 2018

Depois de muitos anos trabalhando em seu sistema, construindo, consertando, melhorando, quebrando e remontando, você decide que o que realmente precisa é de uma reescrita completa. Afinal, o que poderia dar errado?

Se você já esteve envolvido em um projeto de reescrita completa, você sabe a resposta. Absolutamente tudo pode dar errado.

Porque você acha que quer

Existem muitos motivos para se defender uma reescrita completa de sistema, mas o mais comum é a complexidade do software e o custo de manutenção. Isso se traduz em “o sistema é tão complexo/mal escrito que é impossível corrigi-lo efetivamente sem reescrever tudo”.

Na verdade, faz muito sentido, tanto que já escrevi uma postagem no blog garantindo que seu software será reescrito. Hoje ainda acho que esse é o caso, mas, em vez de focar em reescritas completas, devemos nos esforçar para mais refatoração.

Importante: como regra geral, você nunca deve exigir uma reescrita completa do sistema.

Porque você não deveria fazer

1. As estimativas estarão erradas, muito erradas

Eu já disse como é difícil dar boas estimativas? Em reescritas de software, elas tendem a ser ainda piores do que em circunstâncias normais. A principal razão para isso é simples: geralmente nos concentramos nas áreas que sabemos que precisam ser trabalhadas, mas raramente temos um entendimento completo de detalhes importantes dentro do software (para qualquer sistema do mundo real, é quase impossível saber tudo o que está acontecendo sob o capô).

O problema da estimativa é ainda pior neste cenário porque, dada a aprovação para uma reescrita completa, as partes interessadas serão extremamente exigentes sobre a evolução do projeto. Normalmente, os programadores precisam fazer grandes promessas sobre datas e resultados, o que inevitavelmente leva à decepção e expectativas mal administradas.

2. Conhecimento tácito e correção de bugs serão jogados fora

Existem duas razões principais para um “software mal escrito”: a primeira é um design ruim. A segunda é correção de bugs. Embora às vezes seja difícil diferenciar uma da outra, é uma distinção importante ao pesar os prós e os contras de uma reescrita completa. É difícil argumentar positivamente em favor de um projeto com design pobre, mas mesmo se for esse o caso, você tem certeza de que todo o sistema está fundamentalmente quebrado ou existem ilhas isoladas de decisões terríveis? Porque o segundo não parece um bom motivo para uma reescrita completa.

Correções de bugs, por outro lado, podem tornar o trabalho de manutenção mais difícil porque geralmente trazem algum rastro de sujeira no código, como métodos maiores do que deveriam ou condições booleanas extras, tornando mais difícil a leitura simples. Geralmente é chamado de “código complexo”, mas é necessário lembrar que isso também é a base de conhecimento do seu software.

Ler software é muito mais difícil do que escrever, é por isso que às vezes você não vê razão em algum pedaço de código, mas simplesmente jogá-lo fora é desperdiçar tempo do mundo real na correção de bugs. Além disso, código em produção é código testado em batalha. Há uma grande chance de que, com o tempo, você precise adicionar as mesmas verificações ao seu novo software porque alguma coisa quebrou na produção.

3. Tempo gasto em reescrita poderia ser focado em melhorar o software existente

Então, depois de defender o seu ponto ao máximo, você recebeu carta branca para uma reescrita completa. Quanto tempo vai demorar? Quatro meses? Legal. Só uma coisa:

Quanto você pode melhorar o software existente em quatro meses, em vez de uma reescrita completa?

Se sua resposta for “Em nada!”, significa que você ainda não sabe nada sobre o projeto.

A primeira reação a uma base de código antiga é a necessidade urgente de reescrevê-la. Isso geralmente acontece porque não sabemos o que é o quê naquele projeto, e reescrevê-lo nos levará ao controle novamente. Mas é um pensamento racional? A decisão ideal, geralmente, é dar tempo para amadurecer o código em sua cabeça e tentar entender o que trouxe as coisas ao estado real. Depois disso, é possível, pelo menos, melhorar um pouco as coisas. E se der certo, melhore mais um pouco. E então, um pouco mais.

É assim que softwares bons são criados.

4. Você não trará nada de novo para clientes e demais áreas interessadas, mesmo se for um sucesso

A parte mais difícil de uma reescrita é a ideia de que você trabalhará muito para entregar exatamente o mesmo que seus clientes e stakeholders já receberam. Claro, haverá algumas melhorias de desempenho ou melhor UI, mas os principais recursos e funcionalidades irão (ou deverão) permanecer semelhantes. Afinal, é uma reescrita.

Outra coisa para ter em mente é que, em alguns projetos, durante o tempo em que você reescreve seu software, você é um alvo fácil para sua concorrência. Enquanto reescreve e reescreve, seus concorrentes continuam melhorando e adicionando novos recursos. O que mantém seus clientes em seu sistema: o novo código bonito ou software construído e testado?

5. É um ciclo infinito

Mesmo que você tenha feito uma reescrita completa e tudo corra bem e todos estejam felizes. O que impede o próximo desenvolvedor deste projeto de defender uma nova reescrita completa do software? Como terminar esse ciclo?

Você pode melhorar as coisas se estiver apenas reescrevendo recursos existentes? Quanto trabalho será necessário para manter o legado funcionando enquanto você constrói a próxima grande coisa? Quais são as coisas novas a serem adicionadas? Elas ficarão congeladas até que você termine o novo?

Bonus: Nunca reescrever?

Existem, é claro, momentos em que uma reescrita completa é obrigatória. Às vezes, o software está muito quebrado ou muito complexo para manter que você deve consertar o avião enquanto ele está no ar. As principais dicas para isso são manter todos na mesma página, mostrando porque é uma boa decisão e, obviamente, como sempre, administrar as expectativas. Faça ajustes em suas estimativas e mantenha uma lista de pendências atualizada do que falta fazer. Mostre como você está melhorando as coisas no novo software usando problemas do mundo real que você está resolvendo (de preferência, problemas que assombravam o antigo). Contanto que todos estejam a bordo do trem de reescrita, você pode ter certeza de que foi a decisão certa.

Se é possível deletar e criar seu projeto em um mês (essa é a sua estimativa? Levará seis. Acredite), e houver apoio da alta administração e de áreas fora da TI, você deve ir em frente.

Mas não diga que eu não avisei.