Faltam poucos anos para o projeto Código Fonte como um todo completar duas décadas de estrada. A primeiríssima postagem online data de outubro de 2006, ainda falando sobre ASP clássico. A própria linguagem já tinha sido substituída pelo ASP.NET em 2002 e a versão estável mais recente do ASP clássico é de fevereiro de 2000. Apesar dessa versão ainda ser suportada nos servidores e utilizada por alguns desenvolvedores, a grande verdade é que o ASP original está obsoleto.
Se o Código Fonte tivesse se mantido fiel a suas origens e mantido o foco no ASP clássico, hoje em dia o próprio site seria basicamente uma peça de museu e o projeto não teria crescido. O mundo de TI vive de mudanças de paradigmas quase semestrais, de novas abordagens, de novas soluções, de tendências que vem e que vão ou que vem e que ficam. Navegar essa torrente de novidades é o grande desafio de qualquer desenvolvedor. E o grande objetivo que buscamos sempre foi esse: ajudar você a entender para onde o vento está soprando. Por outro lado, o que fazer com a experiência acumulada? Existe mesmo essa obsolescência implacável?
Matt Watson é empresário e engenheiro de software. Ele fundou sua primeira empresa de tecnologia, a VinSolutions, em 2003, aos 22 anos.. Em um artigo publicado na internet, ele explica como lidar com a velocidade do tempo e as mudanças constantes no mercado de tecnologia nas últimas duas décadas.
om sua autorização, traduzimos e reproduzimos o artigo na íntegra:
“Dívida técnica é facilmente a palavra da moda mais usada hoje em dia. As pessoas dizem: ‘estamos avançando rapidamente em nosso MVP enquanto minimizamos a dívida técnica!’. Eles mencionam dívida técnica lá para soar legal ou algo assim.
Eu apenas rio porque tudo é dívida técnica, eventualmente.
Toda a minha carreira agora é dívida técnica ou o código se tornou obsoleto.
Se você não acredita que toda a sua carreira também será uma dívida técnica, você pode acreditar depois de ler este artigo. Vou orientá-lo sobre como as coisas mudaram ao longo dos meus 20 anos de carreira.
Eu era “Básico” no começo…
Minha carreira começou como desenvolvedor do Visual Basic 6. Eu construí vários aplicativos diferentes de 1999 a 2003. Acho que você pode dizer que qualquer coisa no Visual Basic 6 pelo padrão de hoje é uma dívida técnica ou já foi substituída há muito tempo. Vida longa ao “on error resume next!”
Passei muito tempo desenvolvendo páginas clássicas de servidor ativo (ASP). Ao mesmo tempo, eu também era um especialista em fazer sites funcionarem com o Internet Explorer 6 e o Netscape Navigator. Já não significa muito no currículo!
Visual Basic, ASP, IE6 e Netscape são tecnologias há muito esquecidas. Como diria Strong Bad na época, ‘delorted!’.
Linguagens antigas: Perl, Delphi, Fortran, FoxPro, ColdFusion
Existem muitas linguagens de programação que caíram em desuso nos últimos 20 anos, além do Visual Basic 6. As chances são altas de que, se você construiu algo em qualquer uma dessas linguagens, as pessoas estão tentando descobrir como reescrevê-lo porque é difícil encontrar programadores para essas linguagens: Perl, Delphi, Fortran, FoxPro, ColdFusion.
Os aplicativos ainda existem neles? Sim. Você pode contratar pessoas para fazer isso? É duro. Na maioria das circunstâncias, essas empresas devem modernizar e retirar os aplicativos antigos.
No início dos anos 2000, as pessoas achavam que o Adobe ColdFusion era o que estava em alta. Você se lembra de sua pequena ascensão ao estrelato?
Ruby on Rails corre o risco de ser adicionado a esta lista. Ele caiu em desuso e é difícil encontrar desenvolvedores para ele. O que antes o tornava único agora está disponível em outros idiomas.
Linguagens de programação vêm e vão. Os desenvolvedores não querem aprender habilidades que não estão em demanda. É sempre um equilíbrio entre oferta e demanda! Os desenvolvedores abandonam o barco rapidamente e sempre querem novidades em seus currículos.
O que aconteceu com ActiveX, Java Applets, Flash e Silverlight?
Alguns dos primeiros aplicativos que fiz usavam controles ActiveX no Internet Explorer 6. Na época, eles eram obrigatórios para se fazer impressão e outras coisas muito inseguras. Os PDFs não eram tão comuns naquela época, e imprimir a partir do navegador era seu próprio pesadelo divertido.
Applets Java também foram uma grande coisa uma vez. Eles eram lentos e ter a versão correta do Java instalada em seu computador era sempre uma bagunça. Nunca esquecerei o pesadelo de lidar com firewalls de rede que exigiam applets Java. Não sinto falta desses pesadelos e, felizmente, eles desapareceram.
Claro, todos nos lembramos do Macromedia/Adobe Flash! A certa altura, era o filho querido de toda a Internet. Havia jogos em Flash sem fim, e muitos softwares foram construídos em Flash com ActionScript. Um produto chamado CheerpX agora permite a execução de aplicativos Flash antigos com WebAssembly.
A Microsoft lançou um concorrente do Flash chamado Silverlight. Na verdade, era um framework fantástico para desenvolvedores C#. Minha empresa construiu algumas coisas realmente incríveis com o Silverlight.
Como todos sabemos, a Apple acabou com o Flash e o Silverlight abandonando o suporte em seus navegadores.
Aqui está uma captura de tela da calculadora financeira que construímos com o Silverlight na VinSolutions há mais de 10 anos. O Silverlight já se foi há muito tempo e eles o reescreveram todo em JavaScript, mas não é tão legal quanto a versão antiga!
Meu primeiro aplicativo móvel
Criei um aplicativo móvel em 2004. É difícil lembrar, mas o iPhone e o Android ainda não existiam. Escrevi um aplicativo para PDAs Compaq para rastreamento de estoque para concessionárias de automóveis. Foi escrito em C# para o .NET Compact Framework rodar no Windows CE.
Este PDA tinha uma câmera de 1 megapixel. As fotos eram apenas um pouco terríveis, desde que estivesse nublado lá fora para remover o brilho. 😂 Rapaz, a tecnologia mudou! Este aplicativo foi para o cemitério há muito tempo, mas era de ponta em 2005.
É melhor você ser Swift
Swift é outro excelente exemplo de como as ferramentas de desenvolvimento mudam rapidamente. Assim que a Apple lançou o Swift, ficou difícil justificar escrever código em Objective C. Tenho certeza de que existem alguns casos de uso em que ainda é necessário. Mas o Swift é significativamente mais fácil de desenvolver e um grande passo evolucionário.
Eu diria que qualquer aplicativo escrito em Objective C é provavelmente uma dívida técnica agora.
WebForms
Depois de fazer scripts malucos inline para criar aplicativos da Web, fiquei feliz em usar os novos formulários da Web do ASP.NET. Seus controles do lado do servidor tornaram o desenvolvimento significativamente mais fácil. O objetivo deles era tornar a criação de aplicativos da Web o mais fácil possível no Visual Basic 6. Funcionou! Você pode criar componentes de interface do usuário reutilizáveis no lado do servidor para renderizar no navegador. Assim como fazemos hoje 100% com JavaScript.
O WebForms não era perfeito, mas foi uma atualização considerável. Ele teve uma ótima execução até que o Ruby on Rails surgiu e popularizou os frameworks MVC (Model-View-Controller) para o desenvolvimento de aplicativos da web.
O MVC rapidamente descartou todos os aplicativos de formulários da web que já fizemos. Qualquer coisa em formulários da web é definitivamente dívida técnica. (Embora a mesma ideia esteja fazendo um revival com o Blazor)
MVC é rei! (por um tempo)
Antes que você percebesse, todas as linguagens de programação suportavam frameworks MVC. Passamos a fazer tudo novo no ASP.NET MVC. Estava em todos os lugares, incluindo Django, Laravel, Symfony, Spring, etc.
Pulamos para hoje e, desde então, o MVC saiu de moda. Tudo agora é feito em React, Angular, Vue e outros frameworks.
Antes de termos esses, tínhamos outros frameworks Javascript. No Stackify, usamos o Knockout, uma estrutura de front-end razoavelmente popular.
Você se lembra de algum desses frameworks? Knockout, Ember, Aurelia, Meteor, Backbone, Handlebars?
Se você usou algum deles, aposto que todo esse código agora é considerado dívida técnica e caiu em desuso. A primeira geração de frameworks front-end perdeu para React e Angular.
Angular JS
Em 2015, o Angular foi criado pelo Google e entrou em cena. Ele rapidamente se tornou o framework front-end mais popular.
Então, em 2016, o Angular passou por uma grande atualização e não era compatível com versões anteriores.
Adivinha o que isso significa? Qualquer coisa na versão original agora é dívida técnica. Tenho projetos na minha empresa na versão antiga do Angular que são uma grande dívida técnica que devemos atualizar.
O velho e sujo SOAP & WCF
Antes das APIs REST e JSON se tornarem o padrão de fato, outra opção era o SOAP, que significa protocolo simples de acesso a objetos. Ele facilitou a chamada de serviços da Web e a geração automática de código de classes de proxy para chamar os serviços corretamente. Foi usado principalmente pelo Windows Communication Framework (WCF) sobre XML.
Funcionou muito bem… até que não funcionou. Um dos piores projetos da minha carreira envolveu descobrir como usar certificados de segurança entre minha empresa e outro fornecedor em WCF e SOAP. A promessa do SOAP e do WCF era incrível, mas era um pesadelo mantê-la ao longo do tempo.
SOAP e WCF são duas coisas de que não sinto falta. A Microsoft decidiu não oferecer mais suporte ao WCF no .NET Core. Coisas como REST, gRPC e GraphQL agora são preferidas. No entanto, um projeto da comunidade eventualmente criou o CoreWCF para mantê-lo funcionando.
Com o tempo, os tipos de tecnologia que usamos para chamar serviços da web mudaram. As formas mais antigas ainda funcionam, mas a maioria das pessoas provavelmente preferiria aposentá-las.
Versões de idiomas principais
Outro problema comum são as principais alterações na versão da linguagem de programação. Seja Ruby, PHP, .NET ou outros. Eles geralmente exigem várias alterações de código ou até reescritas.
Quando o .NET Core foi lançado, era a versão mais nova, mais leve e mais rápida do .NET projetada para rodar no Linux. O código C# básico é facilmente transferido, mas ninguém usa apenas o código básico para um aplicativo do mundo real.
No entanto, em aplicativos corporativos complexos, há muitos problemas potenciais ao navegar pelo caminho de atualização. Isso se torna uma grande dívida técnica que precisa ser resolvida. Caso contrário, você eventualmente ficará preso em uma versão antiga.
Essas atualizações de versões principais acabam se tornando grandes projetos de dívida técnica.
Preso em uma dependência externa antiga
Um dos maiores desafios que tivemos no Stackify foi ficar preso em uma versão antiga do Elasticsearch.
A certa altura, eles fizeram algumas mudanças significativas em como funcionava que não eram totalmente compatíveis com versões anteriores. Nós o usamos muito, e todo o trabalho para atualizar se tornou uma enorme quantidade de dívida técnica e projeto de atualização.
Continuamos dando murro em ponta de faca repetidamente e, eventualmente, ficamos para trás. Este é outro exemplo de projetos reais de dívida técnica que podem atormentar as empresas.
A alternativa de código aberto aposentou meu código
Na Stackify, construímos nossas próprias bibliotecas de rastreamento/criação de perfil para 6 linguagens de programação. Foi uma quantidade incrível de trabalho para fazer isso.
Bem, agora o OpenTelemetry apareceu e tornou todo esse trabalho inútil.
Por que gerenciar o seu próprio quando você pode usar o padrão da indústria de código aberto? O Stackify está trabalhando lentamente para eliminar o criador de perfil .NET que ajudei a construir.
Todo o código apodrece ou é substituído
Com o tempo, você pode ver como quase tudo que você cria é descartado e substituído por vários motivos ou agora é baseado em tecnologia antiga.
Vários aplicativos que construí no início da minha carreira foram encerrados porque as empresas foram adquiridas e decidiram usar uma tecnologia totalmente diferente.
A maioria dos softwares tem uma vida útil limitada, mais curta do que você pensa. Todo código eventualmente se torna uma dívida técnica que todo mundo quer reescrever de uma maneira mais moderna, ou o negócio precisa mudar drasticamente.
Com certeza, no mundo corporativo, é mais provável que haja aplicativos internos que parecem permanecer para sempre. Algo como uma ferrovia ou um grande banco usa o mesmo software baseado em mainframe há 40 anos.
Eu prevejo que o WebAssembly acabará dominando como o desenvolvimento front-end é hoje, e um mundo totalmente novo evoluirá.
A realidade da dívida técnica
As pessoas estão sempre preocupadas em minimizar a dívida técnica ao fazer novos projetos. Eu entendo. Há um equilíbrio entre fazer as coisas funcionarem e tentar torná-las perfeitas.
No entanto, nada é dívida técnica porque nada é perfeito. Não existe algo perfeito. Com o tempo, o que foi perfeito hoje não será perfeito no futuro. Aprenda a viver com menos do que o perfeito.
O outro lado da dívida técnica é como tudo apodrece lentamente com o tempo. Existem problemas significativos com a atualização para as versões mais recentes ou a tecnologia acaba caindo em desuso devido a novas maneiras de fazer as coisas. Boa sorte ao contratar pessoas para tech stacks antigas.
Tudo eventualmente se torna dívida de tecnologia, ou os projetos são cancelados. Se você tiver sorte, seu código sobreviverá o suficiente para ser uma dívida técnica para outra pessoa.
Com tempo suficiente, todo o seu código será excluído. 🤷♂️”
Publicado originalmente como “My 20 Year Career is Technical Debt or Deprecated“, em 15 de maio de 2023. Traduzido e republicado com autorização do autor.
