Na esmagadora maioria das vezes que escuto alguém reclamando do fato de estar lidando com código legado me vêm um dos dois pensamentos a seguir : “chorão detected” ou “tá reclamando da coisa errada”. Também não é raro ver software ser jogado fora para ser reescrito do zero e sentir aquela certeza de que irá dar errado e dá. A postura diante do legado é errada. Amo legado e vou te contar as razões.
Minha evolução com o legado
Quando comecei a programar sequer pensava na possibilidade de lidar com código alheio. Aliás, eu só via código que fosse um exemplo ou outro que usava para aprender por simples cópia. Até que o legado caiu sobre mim e, junto com ele, hoje percebo, uma forte dose de arrogância.
“Arrogância é a confiança excessiva nas próprias habilidades.” – Norberto Bobbio
Olhava para o código escrito por outros colegas, a maior parte pessoas que não atuavam mais na empresa (e jamais conheci) e os tinha como algo tosco. Me perguntava como a pessoa não sentia vergonha de deixar aquele “legado”. Pegava aquele “trem” e reescrevia do zero. Sentia o triunfo e me orgulhava do feito: expunha aos demais como um troféu que erguia alto para que todos vissem.
(e hoje vejo diversas daquelas mesmas pessoas como heróis)
“Curiosamente” tempos depois eu precisava alterar novamente aquele código que havia reescrito por que “um ponto ou outro não haviam sido levados em consideração”. O tempo passou e hoje fica claro que era um sintoma.
O tempo voa e trabalhei em projetos iniciados e finalizados por mim, apenas iniciados por mim e tantos outros que não foram iniciados por mim. E nesta história bem mais de 50% da minha carreira foi gasto manipulando código que não fui o pai, mas no máximo um padrinho ou tio generoso.
Aos poucos passei a gostar do legado que foi se tornando meu maior professor. Aprendo, cresço e enriqueço hoje graças a ele. Enquanto foi meu adversário eu era símio: hoje que o tenho como parceiro sou “sapiens” (ou penso ser (arrogância?)).
Como o legado se tornou meu parceiro
Percebi o valor do legado quando minha arrogância me socou a cara. Lembra no início deste post quando falei de um “certo sintoma” que ocorria quando eu reescrevia algo do zero? Yeap: eu estava jogando fora conhecimento importante sem me dar conta. Não estava melhorando a criatura, mas piorando-a. E sabem o que é legal? Só caiu a ficha quando o Joel Spolsky “me contou”. Bendito tapa!
Foi quando percebi que eu só olhava para o código e não o lia. Por coincidência na época fazia uma matéria no curso de Filosofia sobre hermenêutica e este acabou me indicando o caminho: não era apenas ler, mas sim interpretar e absorver. Eu devia “absorver como Kico” e “interpretar como quem o escreveu”.
(Quando você acorda para o fato de que mais de 85% da vida do software ocorre depois que é entregue fica nítido que a sua visão de mercado “talvez” fosse bem limitada. :) )
Legado como arqueologia e compaixão
Minha dificuldade ao interpretar o legado estava em meu ego. Por que com tantos SGBDs disponíveis o sujeito tinha de usar JUSTO O MALDITO MICROSOFT ACCESS para aquela aplicação Delphi/VB? Por que tantas classes anônimas naquela aplicação desktop Java? Por que aqueles padrões de projeto tão fora da nossa realidade naquele projeto Java EE? Te respondo: por que quem escreveu o sistema muito provavelmente (quase 100% de certeza) aprendeu a fazer daquele jeito. Duvida? Leia algum livro antigo sobre Delphi, Java ou Java EE. Como sei isto? Nas fotos abaixo está uma mínima parcela das “evidências” que acumulo no escritório (e que se um dia Nanna jogar fora teremos uma briga séria).
Quando um cliente me procura com um sistema antigo uma das primeiras coisas que me diz é: “acho ele velho, gostaria que fosse reescrito do zero”. Meu primeiro passo é discordar e iniciar o trabalho arqueológico: compro livros publicados na mesma época das tecnologias usadas naquele software, corro atrás de revistas relacionadas, navego por antigos fóruns, artigos, blogs, enfim: inicio um processo de pesquisa profundo, como se fosse um livro.
O objetivo é ter compaixão. O que é compaixão? É o posicionar-se no lugar do outro e com isto entender seu modo de agir. Se conseguir acesso direto ao programador, melhor ainda! Posso saber mais a respeito do seu ambiente de trabalho na época, talvez suas frustrações e como isto influenciou o seu código. Isto me permite inclusive, quando meu ego está fora de alcance, saber se aquela pessoa de fato sabia o que estava fazendo (tem noção da quantidade de pessoas (me incluo) que aprendeu a programar usando arquivos de ajuda?).
Muitas vezes tento construir um ambiente de desenvolvimento próximo ao da época. Consigo isto tendo em casa alguns computadores mais antigos, de preferência com o software daquele tempo. Isto me permite eliminar o risco de estar lidando com incompatibilidades com versões atuais das bibliotecas, sistema operacional (máquinas virtuais valem ouro), etc.
(acredite, quando você se depara com uma máquina cujo HD tem 80 Mb e seu PC 16 Mb de RAM você passa a entender imediatamente o porquê da forma daquele código)
Agora que tenho o modo de pensar e o ferramental da época posso trabalhar com segurança e ver como o software funcionava naquela época.
Como evoluo legado
Com base nestas informações, aí sim altero o código fonte. Se fica nítido que o programador não conhecia a tecnologia, o trabalho fica fácil: consigo melhorar a qualidade apenas aplicando as boas práticas da época. Repare: não vou fazer uma transposição direta para o presente ainda. Chamo esta fase de “restauro” pois não estou evoluindo arquiteturalmente a criatura, mas sim “colando alguns cacos soltos com testes e muita paciência”.
Feitas estas melhorias implemento uma ou outra nova funcionalidade que o cliente queira. Normalmente a produtividade está alta neste ponto pois já conheço a criatura. O processo de upgrade é gradual e nunca direto. Por exemplo: se o sistema é feito em Delphi 3, não vou migrá-lo direto para o Delphi XE. Primeiro passo pelo Delphi 4, depois 5 e por aí vai. (faço muito isto com versões antigas do Grails). Muitas vezes há recursos da época que não foram usados na aplicação: em alguns casos é quase um upgrade.
(e este processo de upgrade de plataforma muitas vezes é desnecessário. Será que seu sistema em Grails 1.3 precisa realmente do Grails 2.4?)
Se a plataforma tecnológica não é mais suportada (FoxPro, Visual Basic, Clipper, algum framework que “não existe mais”), sei exatamente em qual ponto parar. Daí pra frente precisamos decidir se há de fato algo que possa ser reaproveitado naquele sistema, se é possível encapsulá-lo de alguma forma ou mesmo se a partir daquele momento podemos iniciar um trabalho de reescrita (sempre o último caso) tendo como base a geração de alguma forma de documentação.
Se algo funciona torço para que meu ego não a quebre.
Minha visão de TI graças ao legado
O principal ganho que o legado me trouxe foi uma visão muito mais rica sobre as tecnologias que vejo serem lançadas. É incrível como diversas das coisas que as pessoas hoje bradam como novidade são apenas a reencarnação de algo que funcionou muito bem (ou não) no passado. Virtualização como algo moderno? Na década de 60 o OS/360 já tinha. Execução dinâmica de código? CODASYL previa na década de 50. Manifesto reativo? Olha para os mainframes. E por aí vai…
Você adquire mais pontos para fazer conexões entre as coisas: fica mais fácil assimilar a “novidade” que, na maior parte das vezes é uma nova roupagem ou ponto de vista sobre algo que já foi resolvido no passado e agora estão redescobrindo ou aperfeiçoando.
Não é raro que eu leia sobre tecnologias do passado que provavelmente nunca vou tocar (mainframes, COBOL, Clipper). Não tanto por que eu “adquira mais pontos”, mas sim por que passo a ter um respeito muito maior por aqueles profissionais do passado que com tão “pouco” criaram as bases deste mundo incrível que temos hoje.
(tenho uma imensa lista de heróis entre estes profissionais)
Concluindo?
Espero neste post ter exposto o aspecto positivo do legado que, a meu ver, supera em muito o “negativo”. As reclamações que fazemos ou ouvimos costumam gerar esta imagem terrível de algo que, convenhamos, além de ser um mercado imenso e muito maior que o “green field” também nos fornece uma visão de TI muito mais profunda.
Acredito que este “mal estar” diante do legado se deva em grande parte à nossa formação. Nas faculdades e cursos técnicos é muito raro termos exercícios que exijam dos alunos interpretar e entender código: na maior parte das vezes você apenas escreve. Talvez se houvesse uma matéria de “arqueologia” ou mesmo hermenêutica a coisa fosse muito diferente.
Também acredito que seja importante saber do que estamos reclamando. Será que é do código legado ou da empresa que não nos permite lidar direito com ele devido a uma má gestão? Será que a reescrita é realmente o melhor caminho sempre? Será que os problemas que temos não é a simples falta de compaixão e nossa pressa exagerada para resolver logo o problema e com isto nos impede de pensar (e aprender)?
Esta é minha visão sobre o legado. Torço para que tenha mudado a opinião de alguém aqui.
PS:
e só pra lembrar: o legado também serve para separar as crianças dos adultos. :)
Lembrando que qualquer coisa que eu escreva com Rails ou Grails, programação funcional e assíncrona, orientação a aspectos daqui a 5 anos (no mínimo) virará legado. Legado é sempre o código dos outros.
Concordo com o seu post, já vi muito desenvolvedor que gastou menos de um dia olhando um projeto legado e enganando o gestor conseguiu convencer de jogar fora o projeto e fazer um novo…
Talvez em um caso que um júnior fez algo muito ruim talvez justifique, mas normalmente vale a pena ver o que foi feito… afinal se aquilo está em produção há algum tempo, no mínimo a parte de negócio está ok.
Trabalhei numa empresa em que se falava: “ah, isso é problema de código legado”.. quando era código que praticamente a mesma equipe tinha feito =)
Fernando, a título de curiosidade, reparou que você está na capa da Mundo Java cuja foto expus no artigo? :)
Nem tinha reparado… nossa, zoaram tanto comigo com essa foto aí, falavam que era de velório, kkk.
Fernando, esta é uma das revistas que guardo com maior cuidado: até hoje é uma baita fonte de inspiração para mim.
Não sei se alguém já te disse isto (com certeza já), mas valeu pelo trabalho que você desenvolveu (ainda desenvolve?) no Mentawai. :)
Oi , o Mentawai não contribui muito, tirando a parte de tradução e de JPA nele, não fiz muito mais não. Faz um bom tempo que não contribuo mais com ele … mas tem uma galera que de vez em quando commita alguma coisa.
Talvez a minha maior contribuição foi a divulgação dele =)
E já que é pra agradecer, eu agradeço a você pode escrever no seu blog, continue assim, sempre escrevendo coisa boa \o/
Opa, valeu! :)
Olha eu desenterrando post antigo :D
Faço minhas as palavras do Boaglio. Seus textos são excelentes! Esse por exemplo mostra o quanto muitas vezes nos deixamos levar pela nossa arrogância e acabamos por destruir o que é mais importante para o cliente no sistema: as regras de negócio. Dane-se a tecnologia! Ele quer o software funcionando, e bem! Cabe a nós apenas decidir o quê, tecnologicamente falando, irá ajudá-lo melhor.
Mais uma vez obrigado!
Excelente artigo, Henrique. O que vejo nesse seu comportamento é o que falta em muitos fodões da nossa área: Maturidade e Respeito.
Deixo-lhe uma recomendação, a você caso ainda não conheça, e a seus leitores:
Incrível como links nos comentários nunca funcionam no WordPress rs.
A recomendação é o livro Working Effectively with Legacy Code, do Michael Feathers.
https://www.goodreads.com/book/show/44919.Working_Effectively_with_Legacy_Code
WordPress sempre apronta das dele!
Opa, valeu Rafael!
Eu vi este livro a um tempo atrás, tá na fila, valeu pela indicação!
São pontos excelentes, Kico! Eu confesso que já tive um certo receio de legado no início da carreira. Mas acabou que, por eu ser meio maluco pra resolver problemas, acabei sempre ficando na manutenção de legados e a limitação que um sistema legado te trás foi justamente o que colocou minha criatividade em cena. Muitos dos truques que aprendi foram mantendo legado e muitos profissionais excelentes com quem já trabalhei mantinham legado.
O interessante é que eu sempre ouvia desculpas do tipo “Esse sistema é um lixo porque é legado!” e acho uma verdadeira burrada. O “lixo” pode significar uma limitação tecnológica ou burrada do desenvolvedor e o grande problema é que as pessoas tendem a comparar o código antigo com um código que poderia ser escrito hoje com todo o ferramental e teoria atuais, acabando por afirmar que aquilo é ruim.
Claro que existem situações onde um código legado é terrível, mas isso é “mérito” de quem programou e não da época em que foi feito.
Parabéns pelo post! Acho que todo desenvolvedor que sonha em trabalhar somente com frameworks atuais deveria lê-lo duas vezes antes de cada reclamação.
Oi Ataxexe, valeu!
Algo que observo demais é a “consultoria” chamar de legado algo apenas como desculpa irresponsável para reescrever algo e ganhar mais com isto. Rola muito.
Acho que deve-se pensar em reescrever um sistema legado quando não se tem mais mão-de-obra suficiente no mercado para dar manutenção no sistema. Eu trabalho como analista de um sistema escrito em Delphi, e as manutenções estão na mão de apenas um desenvolvedor, para uma instituição pública de 4500 pessoas e que afetam toda a população da minha cidade que venha a “utilizar” esta instituição. E mais, é um sistema que trata de dinheiro.
Meu medo é se esse cara ficar doente ou ter que fazer uma cirurgia, ou decidir simplesmente ir embora da cidade, e nós ficaremos sem o conhecimento dele e da sua mão-de-obra. Nesses casos acho que reescrever o sistema (enquanto ele está conosco) em plataforma moderna para se ter acesso a mão-de-obra suficiente, vale ouro.
Sei la, apenas dando um outro ponto de vista tb.
Legal o post, pouco se fala sobre isso, mt menos em faculdades.
Oi Leandro, obrigado.
Neste seu caso o problema tende mais para a gestão do conhecimento, não? Vou te dar uma dica: documentar este conhecimento pode ser difícil, mas não impossível. Uma forma de começar é com um wiki simples no qual vai se incluindo pequenas “dicas de manutenção”. Com o tempo o conteúdo cresce e este seu risco vai sendo mitigado.
Otimo Texto parabens!
Obrigado Thiago!
Excelente reflexão sobre um tema deixado de lado nesse mundo onde a inovação é sempre o tema preferido.
Gostaria de comentar um ponto que, em minha opinião, deve ser considerado. Quando falamos de software corporativo é importante considerar um ponto essencial à sua manutenção: suporte do fornecedor e de profissionais capacitados.
Uma empresa que depende de TI (qual empresa não depende de TI hoje?) para o sucesso de seu negócio não pode ficar refém de uma tecnologia “ultrapassada”, onde não há suporte de um fornecedor e nem de profissionais no mercado com conhecimento técnico para manter.
Tomamos por exemplo Mainframe/COBOL. É “legado”, mas existem grandes players (acho desnecessário citar um nome :-|) de mercado suportando e fomentando sua permanência no mercado.
Se uma tecnologia não é mais suportada nem pelo fornecedor e nem pelo mercado penso ser justificável sua atualização.
Bom ponto Rafael, obrigado!
Excepcional. Sem dúvidas, um dos melhores textos que li em anos. Diversas vezes me senti dentro do texto. Nunca tinha parado para pensar no ambiente de desenvolvimento da época, e faz todo sentido do mundo. Hoje mesmo vou atrás do meu K6 II e desenterrar o meu CP-500. Muito obrigado.
Pode ter certeza que passarei esse texto para frente.
Até mais.
Oi Arlei, obrigado!
Nesta sexta-feira, 28/8/2015, falei na QCon Rio exatamente sobre este assunto. Você pode ver os detalhes da apresentação neste link: http://www.qconrio.com/speaker/henrique-lobo-weissmann
Excelente Henrique.
Estou cursando uma especialização em arquitetura de software e meu trabalho de conclusão de curso se trata justamente de sistemas legados. Fiquei bastante interessado nesse tema arqueologia de software.
Artigo bastante inspirador e motivador.
Obrigado
Oi Zoran, que bom que gostou. Obrigado!