O que falam de legado
Sempre achei no mínimo estranho tantas pessoas (e empresas) de nossa área falando tanto de legado. Na minha cabeça toda esta discussão simplesmente não faz sentido pois sempre tive uma definição muito clara:
Legado é sistema pré-existente
Henrique Lobo Weissman
É código que você pegou para dar manutenção/usar que não foi escrito por você. Ou talvez código que tenha sido escrito por você, mas que está sendo revisitado em algum momento.
E as pessoas até fazem palestras sobre o assunto (incluindo eu), lives, posts com diversas definições. Será que elas realmente sabem sobre o que estão falando? Pois se algo tem tantas definições, na prática não tem nenhuma.
Pra começar este post vou expor algumas das piores descrições que conheço sobre o assunto.
Bobagens sobre legado
“Green” field e “brown” field
Em teoria é o seguinte: se você está criando um projeto do zero, então você está no green field: penso naquele papel de parede clássico do Windows. Se está pegando projetos que não foram criados por você então temos aí um terreno pantanoso (estou sendo educado aqui).
Só por curiosidade, vá ao Google e busque por “green field” e “brown field”. Vai lá, to te esperando… aqui estão as imagens (educadas) que encontrei:
Se lidar com código que não foi escrito por você é algo que fará parte do seu dia a dia durante toda a sua carreira, pra quê esta conotação negativa? Como é que você trata quem se junta ao seu time?
Muito bom ter você aqui: este código que já existe é o brown field com que você lidará!É assim que você recebe seus novos coleguinhas?
É um tiro no pé: afinal de contas, a mesma pessoa que chama de brown field código já existente é aquela que irá gerar código que será “brown field” para seus colegas.
Na minha opinião apenas alimenta uma postura negativa em relação ao objeto de trabalho do programador que é o código pré-existente.
“Sistema legado é aquele difícil de manter”
Um sentimento profundo de vergonha alheia se apodera de mim ao ouvir isto vindo de profissionais que atuam com desenvolvimento de software (especialmente aqueles que se vendem como “experientes”): não, uma plataforma difícil de manter e evoluir não é legado, é uma plataforma mal projetada. Não, código difícil de manter não é legado, é apenas ruim.
É outro non-sense: se você enquanto consultor(ia) diz isto está assumindo publicamente sua incapacidade em evoluir código ou arquiteturas (sim, arquiteturas podem ser refatoradas e evoluídas, por piores que sejam). E ainda pior: um sistema então “nasceria legado”? Qual o sentido disto?
Aqui há claramente uma confusão entre déficit técnico e desculpa para não evoluir o trabalho alheio na minha opinião.
“É mais barato reescrever do zero que evoluir o que existe”
Se ouvir isto, por favor, obrigue quem disse a lhe mostrar os fatos reais que justifiquem a frase. Temos uma longa experiência na itexto na evolução de legados. Muitos projetos mesmo: de todos estes sabe qual foi o único caso em que uma reescrita valeu à pena? Um sistema que era apenas um amontoado de formulários de cadastro gerados por uma plataforma que não existia mais, cujo código fonte havia sido perdido e que era apenas um reflexo de tabelas no banco de dados sem qualquer inteligência.
Tirando isto, em todos os casos era mais barato evoluir do que reescrever. Há conhecimento ali na forma de código, há um investimento ali que precisa ser respeitado, há um cliente que não deve ser enganado.
Uma reescrita total só faz sentido quando os argumentos são irrefutáveis por outra equipe técnica que não seja a sua.
E outra: quem diz isto sem mostrar uma justificativa válida tá assumindo que simplesmente não sabe ler código alheio.
O problema do “legado”
Código e plataformas pré-existentes não são um problema. Na realidade, se você usa um framework ou qualquer outra biblioteca que não tenha sido escrita pro você, temos aqui o uso de legados. Se você trabalha com desenvolvimento, legado é sua vida e ponto, para de show.
O problema está na conotação negativa.
Se você apresenta algo (especialmente que não seja negativo) como um problema, imediatamente está desmotivando todos os envolvidos. Mas o problema vai além.
Imagine um médico reclamando de pacientes que foram atendidos por outros médicos. Faz sentido? Não: se há um erro médico é seu papel salvar o paciente. Então por que vendem como fazendo sentido quando o assunto é software?
A parte profunda do problema está nas razões: curiosamente vi muito poucas pessoas falando a respeito. Então vamos a algumas justificativas reais para adotar uma conotação negativa ao pensarmos na evolução de código pré-existente?
Sua equipe não conhece a tecnologia adotada no sistema
Resposta honesta: não conhecemos esta tecnologia mas podemos fazer um esforço interno para que esta seja dominada e, posteriormente, lhe atender.
Resposta desonesta: é um sistema de difícil evolução e que deve ser substituído. (isto quando não detonam o trabalho da equipe anterior sem mostrar nenhum fato concreto que possa ser conferido por outros profissionais, né?).
Pior: e este exemplo senti na pele. A consultoria diz que a tecnologia é morta e não sofrerá evoluções. De qual tecnologia estou falando, Grails? Não, Java.
Baixa qualificação técnica da equipe
Resposta honesta: minha equipe não é qualificada o suficiente para lidar com código de complexidade média ou complexa.
O que vejo: detonam o sistema anterior sem qualquer preocupação em evoluir o que já existia e substituem a solução por outra desenvolvida por uma equipe de baixa qualificação.
Baixa formação arquitetural
Arquitetura não se limita a criar novas plataformas: mais que isto, diz também respeito à evolução do que já existe. Não raro a equipe técnica por não conseguir planejar uma evolução de algo existente simplesmente adota uma conotação negativa pra vender um “green field”.
Há outras justificativas, algumas até desonestas mesmo, como simplesmente tentar obter o projeto que é mantido por outra empresa detonando o trabalho alheio, mas acredito que estas três que acima mencionei são as mais comuns.
Ego
Puro ego: a solução ou tecnologia adotada não é a favorita de quem está avaliando. Há dificuldade em entender que há diferentes soluções para o mesmo problema.
Conselho a quem paga pelo código
Agora não vou falar para quem programa, mas sim com quem paga. Boa parte do meu negócio é evoluir legados: gosto muito disto, então leia o que vou dizer de forma cética.
Se aparecer qualquer consultoria ou profissional lhe vendendo uma reescrita e usando conotações negativas em relação ao que você já tem, desconfie. Peça que lhe envie por escrito justificativas para tal. Analisar sistemas pré-existentes é trabalhoso, sugiro que você inclusive pague por isto. Pague por um bom parecer técnico que justifique a reescrita. E que justifique economicamente também (com CapEx e Opex).
Lembre que você precisará fornecer o código fonte e acesso ou informações sobre sua infraestrutura. Estas informações são sigilosas, colocam seu negócio em perigo caso sejam mal usadas. Então tenha um contrato de confidencialidade em mãos antes de fornecer estas informações.
Com o parecer técnico em mãos, procure sua equipe (caso a tenha) ou outra para avaliar aquele conteúdo e só aí pense na reescrita.
Concluindo esta catarse
Este post foi uma catarse pra mim: se ofendi alguém foi de propósito, enquanto o escrevia me imaginava dizendo estas coisas a alguns.
Mas é que esta conotação negativa do legado é danosa. Penso na infinidade de coisas que aprendi e aprendo quando sistemas legados chegam a mim: outras formas de pensar problemas, tecnologias que não conheço com profundidade até aquele momento, portas que se abrem mas, mais que isto.
Podem me chamar de ingênuo, mas mesmo quando me vejo como um “médico na UTI”, todo o processo de evolução da plataforma é algo que sempre me excita, sempre é fenomenal quando o cliente se lembra dos problemas que tinha antes e não tem mais.
E levando em consideração que somos pagos para lidar com código e também evoluí-lo, devo confessar que esta conotação negativa sempre me soa desonesta (pronto, falei). Se você odeia lidar com código alheio, por que tá nesta área? Se odeia plataformas que não criou sem nem pensar em como evoluí-las, o que tá fazendo aqui? (pronto, falei de novo).
E outra: temos de respeitar o trabalho alheio. Poucas coisas me irritam mais que a “crítica preconceituosa”. Todo código é o trabalho de alguém que ralou (talvez HORRORES) pra ter aquele resultado (por pior que seja). Se nós não nos respeitarmos, quem vai? Se todo código pré-existente for ruim, todo código é ruim e portanto todos seremos incompetentes?
E mais: existem diferentes maneiras de se resolver um problema, se a encontrada é diferente da que você tomaria, isto não quer dizer que seja ruim se não for apresentada uma justificativa coerente.
Esta conotação negativa do legado mostra um lado negativo de nós enquanto desenvolvedores: nosso egoísmo, vaidade e arrogância (isto quando somos honestos).
Temos de repensar esta conotação negativa. Foi por isto que escolhi a imagem abaixo pra representar este post: legados deveriam representar a base sobre a qual progredimos.
PS
Soa contraditório, mas este não é um tema novo deste blog. Segue meus textos antigos sobre o tema:
