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 Weissmann
É 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:
Faltou uma definição do livro “Trabalho Eficaz com código legado” do Michael C. Feathers:
“código legado é todo código que não possui testes”
“Código sem testes é código ruim. Não importa o quão bem escrito, nem se ele é bonito, orientado a objetos ou se foi bem encapsulado. Com testes podemos alterar o comportamento de nosso código de maneira rápida e verificável. Sem eles, não temos como saber se o nosso código está melhorando ou puorando”.
Minha experiência. Certa vez entrei numa equipe que cuidava de um software com 10 anos de produção (eram quase 2 milhões de linhas de código), isso em 2014, projeto com Java o único”framework” utilizado (estava mais pra uma biblioteca) era o JDBC. JSP era o que tinha de atual nesse projeto. Quando eu entrei eu consegui colocar o Spring (obrigado kiko pelo livro “vire o jogo com Spring framework”) hibernate e infelizmente o angular (que logo veio a ser descontinuado, era uma época em que eu estava vivendo um momento hype, e que graças a um artigo daqui também eu pude ver a mer** que estava fazendo). Eu ignorei mesmo, ignorei o que tinha de melhor neste sistema, que era sua arquitetura (padrão command, facades, mvc bem escrito e poderia ter tido uma evolução muito tranquila com a ajuda do Spring) Esse sistema continuou até meados de 2018 (na verdade o desenvolvimento dele, por que até hoje ele roda em produção ). Quando surgiu a ideia de criar um novo sistema eu mesmo fui contra. Já tinha lido vários artigos sobres falhas catastróficas de se criar novos sistemas no lugar do anterior. Mas meu voto estava entre os da minoria e lá fomos nós criar um novo sistema que revolucionaria a galáxia. Hoje o novo sistema tem um pouco mais de 2 anos, problemas muito maiores do que o do sistema antigo ( e não chegamos nem a migrar o core inteiro ainda), está quase do tamanho do sistema antigo.
Hoje estou muito mais cético ao criar sistemas e abandonar conhecimento de pessoas que com certeza foram mais sábias do que eu. Estou tentando diminuir meu ritmo sempre criando sistemas com testes (até hoje os dois sistemas não possuem testes e eu vejo o quanto isso dificulta qualquer mudanças neles). Estava novamente sendo um pouco mais Hyper (aprendendo node e js), mas cai na real quando o js estava indo em direção ao Java com o typescript e parei pra refleti e estou tentando desenvolver meus sistemas pessoais com groovy (que na minha opinião é muito melhor que Java e tão legal de se trabalhar como o Javascript, pois não é obrigatório tipar todas as variáveis, fora a questão com clojures muito melhores que as do Java) , fazendo testes com spock, tentando utilizar o netty ou o micronaut como servidor e o melhor de tudo, nao preciso ignorar vários anos de sabedoria e amadurecimento que já existe na tecnologia. Hoje vejo o Javascript através dos seus milhares de bibliotecas trilhando caminhos que já foram trilhados e estão amadurecidos a anos Luz dessas bibliotecas (sequelize estou falando com você :/)
Parabéns kiko pelo artigo e obrigado pelos livros, artigos e recomendações de livros (vou comprar o de spock da casa do código por causa da sua recomendação), acho que já li todos os seus artigos e até me sinto um “amigo oculto” pois apesar de nunca ter comentado nada nos seus posts sempre acompanho as coisas que você posta pena que não dê continuidade a tudo (como a série de grails +vue no youtube) mas tudo bem acho que a culpa é de caras como eu que acaba não mostrando a cara e agradecendo as suas contribuições.
Obrigado mesmo.
Obrigado Javan,
eu é que agradeço por ter compartilhado aqui a sua experiência, obrigado!
Esse texto me bateu na minha cabeça umas dúvidas. (Ai no caso o que vou escrever aqui tem alguns raciocínios que fiz ao ler o texto, não fui buscar material sobre o assunto, talvez você possa trazer algo relacionado a isso se você achar relevante e se dispor a isso.)
Imagine que os ganhos de um software possam ser quantificáveis em valor monetários( dindin)
Os ganhos seriam dado subtraindo os custos dos valores gerado pelo software.
E aqui fica bem indefinido.
Quais são os custos e quais são os valores gerados?
O que deve ser embutido e o que deve ser subtraído?
Como quantificar eles?
Alguns exemplo:
A tecnologia utilizada ser atraente e relevante no mercado para atrair e reter desenvolvedores talentosos é algo que se deve quantificar? e se sim, como?
A documentação e comunidade da linguagem deve ser levada em conta como custo? ( a maioria da empresas acabam só tendo acesso a profissionais medianos/medíocres, e esses profissionais são bastante dependentes de stackoverflow, documentação da linguagem, vídeos no youtube ( digo porque sou um deles))
Como é possível quantificar em valor financeiro a manutenção de um sistema “não refatorado”? (É fácil verificar o tempo gasto para implementação de uma nova funcionalidade antes e depois dessa evolução e por ai calcular a diferença, mas e antes disso? e como saber esse custo de manutenção de um sistema “green field” que nem foi desenvolvido? )
e etc…
Mas vamos supor que depois de bater a cabeça foram definidos todos esses pontos (talvez já estejam em alguns livros que eu nem faça ideia que existam), e sabemos definir de maneira razoável tantos os custos como possíveis retorno no investimento.
Uma definição mais exata para definir um software como legado não poderia seria algo como:
os ganhos do software atual são menores do que os ganhos de um software novo?
Eu gostei dessa definição porque ela seria bastante prática.
E também seria algo curiosa.
por exemplo, um software poderia vir a ser legado, e deixar de ser legado, de acordo com a evolução dos valores que definiriam isso.
gostei muito desses texto e do blog.
parabéns pelo conteúdo.
Oi Felipe, interessante sua argumentação , mas o problema desta sua definição é que ela liga o termo legado a algo negativo, não?
Ainda relacionado ao comentário acima,
por essa visão um software nunca seria ou não legado por si só, mas sempre em relação a outros softwares.
O software não seria legado numa comparação com linguagem x, framework y, mas seria numa comparação com linguagem z e framework w.
isso também seria uma característica engraçada em relação ao que comentei.
Com certeza.
Na verdade essa definição, não tem nada haver com legado no sentido da palavra em sim, apenas aborda ela num sentido “popular” que percebi no meu pouquíssimo tempo na área, algo que entendi como “código ruim que ainda entrega valor”.
No sentido que se o software não entrega valor (não faz o que tem que fazer, faz errado e quebrado) ele é consertado e se não dá para consertar então ele não é legado, mas sim é obsoleto ou inútil e vai para o lixo E se o código é antigo, mas é constantemente evoluído, refatorado, utilizado, compreendido, e ainda por cima entrega valor, então ele não é legado, é só o software da empresa mesmo.
Esse legado “código ruim que ainda entrega valor” do meu curto ciclo de profissionais da área seria o que entrega valor, mas é um software com que os desenvolvedores não querem colocar a mão. Meio naquele sentindo “Sistema legado é aquele cujo controle foi perdido por seus principais stakeholders.”, onde no caso os stakeholders principais seriam os desenvolvedores, e o controle poderia ser algo como a compreensão ou adequação as habilidades e técnicas destes.
Esse definição que eu dei foi bem cretina, no sentido de tentar raptar a palavra para usar numa outra definição que ignora a parte mais subjetiva desta ideia (evita definir o que é ruim, antiquado, difícil, confuso, ou qualquer valores ligado a legado enquanto adjetivo ) e simplesmente foca na parte do valor enquanto algo monetário que ofereceria uma abordagem de decidir se podemos aumentar o retorno substituindo o código ou não.
E nessa definição ataquei o legado como uma palavra amorfa o suficiente para uso. hahahaha
Lendo suas outras postagens, vi sua palestra na devCamp e por isso veio meio essa ideia. Não tentar achar uma definição para legado, mas tentar grudar uma nele.
Tive a impressão, legado é uma palavra meio mágica que serve para falar mal de um software, uma ofensa. Assim como as vezes podem chamar alguém de “filho da puta” sem estarem com a ideia de que aquela pessoa tem como mãe uma profissional no sexo. Legado parece ser só uma palavra que meio que se auto define em um conjunto de qualidades negativas meio genéricas. Características que podem ser uma, algumas, todas, ou mesmo nenhuma das seguintes: Falta teste, tem bug, usa padrões antiquados, usa tecnologias antiquadas, difícil de evoluir, difícil de fazer manutenção, difícil de compreender.
E partir desse meu entendimento, ao invés de tentar combater esse aspecto da palavra enquanto algo negativo, simplesmente tentar limitar sua abrangência. No sentido que para alguém ser filho da puta, a mãe da pessoa deve ser uma profissional do sexo. Definir uma maneira objetiva de determinar legado, tornaria limitado o alcance da palavra.
Se a continha não bate o software não é legado. Se a continha de legado não fecha, então é só software, software bom, software que entrega, que pode e deve ser evoluído.
Nesse sentido acho que é mais uma contra proposta a essa ideia de “legado é software preexistente”, pois não retira da palavra o sentido de algo ruim. A definição não favorece esse sentido negativo, mas também não o combate, já que preexistente não é uma qualidade em si positiva.
Novamente, talvez tudo o que o que falei podem ser divagação idiotas, mas creio que só o fato de eu realizado a leitura de seus texto sobre legado e refletido sobre isso me foi bastante positivo. Obrigado novamente.
e nessa postagem aqui https://devkico.itexto.com.br/?p=2106, especificamente nesta frase (a ultima na postagem) “E também vejo que o termo legado sequer deveria ser usado. Explico as razões neste post.” o link tá quebrado.