Desenvolvimento de aplicações web para longa vida útil (mais de 20 anos)

O planejamento de software para essa vida útil é difícil, porque não sabemos o que o futuro nos reserva. Um pouco de contexto: Java foi publicado em 1995, 21 anos atrás. O XmlHttpRequest foi disponibilizado pela primeira vez como uma extensão proprietária para o Internet Explorer 5, publicado em 1999, há 17 anos. Demorou cerca de 5 anos até ficar disponível em todos os principais navegadores. Os 20 anos em que você está tentando olhar para frente são apenas sobre o tempo em que os aplicativos da Web ricos já existiram.

Algumas coisas certamente permaneceram as mesmas desde então. Houve um strong esforço de padronização e a maioria dos navegadores está em conformidade com os vários padrões envolvidos. Um site que funcionava em navegadores há 15 anos ainda funcionaria da mesma forma, desde que funcionasse porque segmentava o subconjunto comum de todos os navegadores, não porque usasse soluções alternativas para cada navegador.

Outras coisas surgiram e desapareceram - com destaque para o Flash. Flash teve uma variedade de problemas que levaram à sua morte. Mais importante ainda, foi controlado por uma única empresa. Em vez de competir dentro da plataforma Flash, houve competição entre o Flash e o HTML5 - e o HTML5 ganhou.

A partir dessa história, podemos reunir algumas dicas:

• Mantenha a simplicidade: faça o que funciona agora, sem precisar usar nenhuma solução alternativa. Esse comportamento provavelmente ficará disponível por muito tempo no futuro por razões de compatibilidade com versões anteriores.

• Evite confiar em tecnologias proprietárias e prefira padrões abertos.

O mundo do JavaScript hoje é relativamente volátil, com um alto fluxo de bibliotecas e frameworks. No entanto, quase nenhum deles terá importância em 20 anos - o único “framework” que tenho certeza de que ainda será usado até então é o Vanilla JS .

Se você quiser usar uma biblioteca ou ferramenta porque realmente facilita muito o desenvolvimento, primeiro certifique-se de que ela é baseada nos padrões bem suportados de hoje. Você deve então baixar a biblioteca ou ferramenta e incluí-la no seu código-fonte. Seu repositório de código deve incluir todo o necessário para que o sistema seja executado. Qualquer coisa externa é uma dependência que pode quebrar no futuro. Uma maneira interessante de testar isso é copiar seu código para um pen drive, ir para um novo computador com um sistema operacional diferente, desconectá-lo da Internet e ver se você consegue que seu frontend funcione. Contanto que seu projeto seja composto de HTML simples + CSS + JavaScript e talvez algumas bibliotecas, é provável que você passe.

O que é ainda mais importante do que seu código sobreviver por 20 anos é que seus dados sobrevivem por 20 anos. As chances são de que vale a pena preservar. Se os seus dados são fáceis de trabalhar, construir um sistema alternativo com tecnologia mais recente será fácil.

• Portanto, comece com um modelo de dados claro e bem documentado.
• Use um sistema de banco de dados bem suportado e estabelecido, como o Oracle ^[1] ou o SQL Server.
• Use recursos básicos, não tente inserir novos novos chamativos.
• Prefira simples sobre inteligente .
• Aceite que a manutenção futura pode ocorrer às custas de aspectos como desempenho. Por exemplo, você pode ficar tentado a usar procedimentos armazenados, mas eles podem limitar a manutenção futura se impedirem que alguém migre o sistema para uma solução de armazenamento mais simples.

Depois disso, preparar o aplicativo para o futuro é mais simples, porque é um wrapper em torno do modelo de dados e pode ser substituído se, em 10 anos, ninguém usar mais Javascript, por exemplo, e você precisar migrar o aplicativo para WASM ou algo assim. Manter as coisas modulares, menos interdependentes, facilita a manutenção futura.

^[1] A maioria dos comentários a essa resposta tem uma strong postura contra o uso do Oracle para um banco de dados, citando muitas razões perfeitamente legítimas pelas quais o Oracle é trabalhoso, tem uma curva de aprendizado íngreme e sobrecarga de instalação. Essas são preocupações inteiramente válidas ao escolher o Oracle como um banco de dados, mas, no nosso caso, não estamos procurando um banco de dados de uso geral, mas um em que a principal preocupação seja a manutenção . A Oracle existe desde o final dos anos 70 e provavelmente terá suporte por muitos anos, e há um enorme ecossistema de consultores e opções de suporte que podem ajudá-lo a mantê-lo em funcionamento. Isso é uma bagunça superfaturada para muitas empresas? Certo. Mas manterá seu banco de dados funcionando por 20 anos ? Muito provável.

A resposta anterior de amon é ótima, mas há dois pontos adicionais que não foram mencionados:

• Não se trata apenas de navegadores; dispositivos também são importantes.

  Ele menciona o fato de que um "site que funcionava em navegadores há 15 anos ainda funcionaria da mesma forma" , o que é verdade. No entanto, olhe para os sites criados não quinze anos, mas dez anos atrás, que, quando criados, funcionavam na maioria dos navegadores para a maioria dos usuários. Hoje, uma grande parte dos usuários não poderá usar esses sites, não porque os navegadores mudaram, mas porque os dispositivos o fizeram. Esses sites pareceriam terríveis em telas pequenas de dispositivos móveis e, eventualmente, não funcionariam se os desenvolvedores decidissem confiar no evento click do JavaScript, sem saber que tap event também é importante.

• Você está se concentrando em um assunto errado.

  Mudanças tecnológicas são uma coisa, mas uma mais importante é a mudança de requisitos . O produto pode precisar ser dimensionado, ou pode precisar de recursos adicionais ou pode precisar que seus recursos atuais sejam alterados.

  Não importa o que acontecerá aos navegadores ou dispositivos, ou W3C, ou ... o que for.

  Se você escreve seu código de uma forma que possa ser refatorada , o produto evoluirá com a tecnologia.

  Se você escrever seu código de uma maneira que ninguém possa entendê-lo e mantê-lo, a tecnologia não importa: qualquer alteração ambiental trará seu aplicativo de qualquer maneira, como a migração para um sistema operacional diferente ou até mesmo uma coisa simples crescimento natural de dados.

  Como exemplo, trabalho no desenvolvimento de software por dez anos. Entre as dezenas e dezenas de projetos, havia apenas dois que decidi mudar por causa da tecnologia , mais precisamente porque o PHP evoluiu muito nos últimos dez anos. Não foi nem mesmo a decisão do cliente: ele não se importaria se o site usasse os namespaces ou fechamentos do PHP. No entanto, mudanças relacionadas a novos requisitos e escalabilidade, foram muitas!

Você não pretende durar 20 anos. Claro e simples. Em vez disso, você muda seus objetivos para compartimentalização.

O seu banco de dados de aplicativos é agnóstico? Se você tivesse que mudar bases de dados agora, você poderia. Sua linguagem lógica é agnóstica? Se você tivesse que reescrever o aplicativo em um idioma totalmente novo agora, você poderia? Você está seguindo boas diretrizes de design, como SRP e DRY?

Eu tenho projetos ao vivo por mais de 20 anos, e posso dizer que as coisas mudam. Como pop-ups. 20 anos atrás você poderia confiar em um pop-up, hoje você não pode. XSS não era uma coisa há 20 anos, agora você tem que dar conta do CORS.

Portanto, o que você faz é garantir que sua lógica esteja bem separada e que você evite usar QUALQUER tecnologia que o prenda a um fornecedor específico.

Isso pode ser muito complicado às vezes. O .NET, por exemplo, é ótimo em expor a lógica e o método para seu adaptador de banco de dados MSSQL que não possui equivalentes em outros adaptadores. MSSQL pode parecer um bom plano hoje, mas será assim por 20 anos? Quem sabe. Um exemplo de como contornar isso para ter uma camada de dados totalmente separada das outras partes do aplicativo. Então, na pior das hipóteses, você só precisa reescrever toda a camada de dados, o restante do seu aplicativo permanece inalterado.

Em outras palavras, pense nisso como um carro. Seu carro não vai chegar a 20 anos. Mas, com pneus novos, novo motor, nova transmissão, novas janelas, novos eletrônicos, etc. Esse mesmo carro pode ficar na estrada por muito tempo.

As respostas de @amon e algumas outras são ótimas, mas eu queria sugerir que você olhasse isso de outra perspectiva.

Trabalhei com grandes fabricantes e agências governamentais que dependiam de programas ou bases de código que eram usados há mais de 20 anos e todos eles tinham uma coisa em comum: a empresa controlava o hardware. Ter algo em execução e extensível por mais de 20 anos não é difícil quando você controla o que é executado. Os funcionários desses grupos desenvolveram código em máquinas modernas que eram centenas de vezes mais rápidas que as máquinas de implementação ... mas as máquinas de implementação estavam congeladas no tempo.

Sua situação é complicada, porque um site significa que você precisa planejar dois ambientes - o servidor e o navegador.

Quando se trata do servidor, você tem duas opções gerais:

• Confie no sistema operacional para várias funções de suporte, que podem ser muito mais rápidas, mas significa que o sistema operacional pode precisar ser "congelado no tempo". Se for esse o caso, você vai querer preparar alguns backups da instalação do sistema operacional para o servidor. Se algo falhar em 10 anos, você não vai querer deixar alguém louco tentando reinstalar o sistema operacional ou reescrever o código para funcionar em um ambiente diferente.

• Use bibliotecas com versão em um determinado idioma / estrutura, que são mais lentas, mas podem ser empacotadas em um ambiente virtual e, provavelmente, executadas em diferentes sistemas operacionais ou arquiteturas.

Quando se trata do navegador, você precisará hospedar tudo no servidor (ou seja, você não pode usar um CDN global para hospedar arquivos). Podemos supor que os futuros navegadores ainda executam HTML e Javascript (pelo menos para compatibilidade), mas isso é realmente um palpite / suposição e você não pode controlar isso.

O núcleo da maioria das aplicações são os dados. Os dados são para sempre. O código é mais descartável , modificável, maleável. Os dados devem ser preservados, no entanto. Portanto, concentre-se em criar um modelo de dados realmente sólido. Mantenha o esquema e os dados limpos. Antecipar que uma nova aplicação pode ser construída sobre o mesmo banco de dados.

Escolha um banco de dados que seja capaz de impor restrições de integridade. Restrições não forçadas tendem a ser violadas com o passar do tempo. Ninguém percebe. Faça o máximo uso de recursos como chaves estrangeiras, restrições exclusivas, restrições de verificação e possivelmente gatilhos para validação. Existem alguns truques para usar o modo de exibição indexado para impor restrições de exclusividade entre tabelas.

Então, talvez você precise aceitar que o aplicativo será reescrito em algum momento. Se o banco de dados estiver limpo, haverá pouco trabalho de migração. As migrações são extremamente caras em termos de trabalho e defeitos causados.

Do ponto de vista da tecnologia, pode ser uma boa ideia colocar a maior parte do aplicativo no servidor e não em um formulário JavaScript no cliente. Você provavelmente será capaz de executar o mesmo aplicativo na mesma instância do sistema operacional por um período extremamente longo, graças à virtualização . Isso não é muito legal , mas é uma garantia de que o aplicativo funcionará daqui a 20 anos sem nenhum custo caro de manutenção e hardware. Ao fazer isso, você tem pelo menos o retorno seguro e barato de continuar executando o código antigo em funcionamento.

Além disso, descubro que algumas pilhas de tecnologia são mais estáveis do que outras . Eu diria que o .NET tem a melhor história possível de compatibilidade com versões anteriores. A Microsoft está falando sério sobre isso. Java e C / C ++ são realmente estáveis também. O Python provou que é muito instável com as alterações de quebra do Python 3. JavaScript na verdade parece bastante estável para mim, porque quebrar a web não é uma opção para qualquer fornecedor de navegador. Você provavelmente não deve confiar em nada experimental ou funky, no entanto. ("Funky" sendo definido como "Eu sei quando o vejo").

As outras respostas fazem sentido. No entanto, sinto que os comentários sobre a tecnologia do cliente estão complicando demais as coisas. Eu tenho trabalhado como desenvolvedor nos últimos 16 anos. Na minha experiência, desde que você mantenha seu código de cliente intuitivo, você deve estar bem. Portanto, não há "hacks" com frames / iframes, etc. Use apenas funções bem definidas nos navegadores.

Você sempre pode usar os modos de compatibilidade nos navegadores para mantê-los funcionando.

Para provar meu ponto de vista, apenas alguns meses atrás eu consertei um bug do milênio no código javascript para um cliente, que está rodando seu aplicativo web há 17 anos. Ainda funciona em máquinas recentes, banco de dados recente, sistema operacional recente.

Conclusão: mantenha-a simples e limpa e você deve estar bem.

Alguns axiomas:

• A verdade sobrevive. Neste contexto, seriam algoritmos e modelos de dados - o que representa verdadeiramente o "o quê" e o "como" do espaço do seu problema. Embora, sempre haja o potencial para refinamento e melhoria, ou uma evolução do problema em si.
• As línguas evoluem. Isso é tão verdadeiro para linguagens de computador quanto para linguagens naturais.
• Toda tecnologia é vulnerável à obsolescência. Pode demorar mais para algumas tecnologias do que outras

As tecnologias e padrões mais estáveis (os menos vulneráveis à obsolescência) tendem a ser aqueles que não são proprietários e foram amplamente adotados. Quanto maior a adoção, maior a inércia contra quase qualquer forma de mudança. Os "padrões" proprietários são sempre vulneráveis às fortunas e aos caprichos de seus proprietários e forças competitivas.

Vinte anos é muito tempo na indústria de computadores. Cinco anos é um alvo mais realista. Em cinco anos, todo o problema que sua aplicação pretende resolver poderia ser completamente redefinido.

Alguns exemplos para ilustrar:

C e C ++ existem há muito tempo. Eles têm implementações em praticamente todas as plataformas. O C ++ continua a evoluir, mas os recursos "universais" (aqueles disponíveis em todas as plataformas) estão praticamente garantidos para nunca serem preteridos.

O Flash quase se tornou um padrão universal, mas é proprietário. As decisões corporativas de não suportá-lo em plataformas móveis populares basicamente o condenaram em todos os lugares - se você for autor da Web, deseja que seu conteúdo esteja disponível em todas as plataformas; você não quer perder o grande mercado móvel tornou-se.

WinTel (Windows / x86) apesar de ser proprietário da Microsoft e da Intel, tendo começado em uma plataforma que não é a ideal (interno de 16 bits / externo de 8 bits 8088 versus Macintosh 32 bits interno interno / 16 bit externo 68000) e a erosão da Apple no mercado de consumo continua sendo uma escolha de fato para as plataformas de negócios. Em todo esse tempo (25 anos), o compromisso com a retrocompatibilidade atrapalhou o desenvolvimento futuro e inspirou considerável confiança de que o que funcionava na caixa antiga ainda funcionaria no novo.

Considerações finais

O JavaScript pode não ser a melhor opção para implementar a lógica de negócios. Por motivos de integridade e segurança de dados, a lógica de negócios deve ser executada no servidor, portanto, o JavaScript do lado do cliente deve ser limitado ao comportamento da interface do usuário. Mesmo no servidor, o JavaScript pode não ser a melhor escolha. Embora mais fácil de trabalhar do que outras pilhas (Java ou C #) para projetos pequenos, ela não tem a formalidade que pode ajudá-lo a escrever soluções melhores e mais organizadas quando as coisas ficam mais complexas.