Desenvolvimento de aplicativos da Web para longa vida útil (mais de 20 anos)

Atualmente, estou desenvolvendo um aplicativo da web para o planejamento de terras do governo. O aplicativo é executado principalmente no navegador, usando o ajax para carregar e salvar dados.

Vou fazer o desenvolvimento inicial e depois me formar (é um trabalho de estudante). Depois disso, o restante da equipe adicionará o recurso ocasional, conforme necessário. Eles sabem como codificar, mas na maioria são especialistas em planejamento de terras.

Considerando o ritmo em que as tecnologias Javascript mudam, como posso escrever um código que ainda funcionará daqui a 20 anos? Especificamente, quais bibliotecas, tecnologias e idéias de design devo usar (ou evitar) para tornar meu código à prova de futuro?

Planejar software para uma vida útil tão difícil é difícil, porque não sabemos o que o futuro reserva. Um pouco de contexto: o Java foi publicado em 1995, há 21 anos. O XmlHttpRequest ficou disponível como uma extensão proprietária do Internet Explorer 5, publicada em 1999, há 17 anos. Demorou cerca de 5 anos até se tornar disponível nos principais navegadores. Os 20 anos que você está tentando olhar para o futuro são praticamente o tempo em que aplicativos da Web ricos existiram.

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

Outras coisas vieram e foram - principalmente o Flash. O Flash teve vários problemas que levaram ao seu desaparecimento. Mais importante ainda, era controlado por uma única empresa. Em vez de competição dentro da plataforma Flash, havia competição entre Flash e HTML5 - e o HTML5 venceu.

A partir desta história, podemos reunir algumas pistas:

• Mantenha as coisas simples: 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 motivos de compatibilidade com versões anteriores.

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

O mundo JavaScript hoje é relativamente volátil, com um alto fluxo de bibliotecas e estruturas. No entanto, quase nenhum deles importará em 20 anos - a única “estrutura” que tenho certeza de que ainda será usada até então é o Vanilla JS .

Se você deseja usar uma biblioteca ou ferramenta porque realmente facilita muito o desenvolvimento, primeiro verifique se ele foi desenvolvido com base nos padrões bem suportados de hoje. Você deve fazer o download da biblioteca ou ferramenta e incluí-la no seu código-fonte. Seu repositório de código deve incluir tudo o que é necessário para executar o sistema. Qualquer coisa externa é uma dependência que pode se romper no futuro. Uma maneira interessante de testar isso é copiar seu código em um pen drive, acessar um novo computador com um sistema operacional diferente, desconectá-lo da Internet e verificar se você pode fazer com que seu front-end funcione. Contanto que seu projeto consista em HTML + CSS + JavaScript simples e talvez em algumas bibliotecas, você provavelmente será aprovado.

O que é ainda mais importante que o seu código que sobrevive por 20 anos é que seus dados sobrevivem por 20 anos. Provavelmente, é isso que vale a pena preservar. Se for fácil trabalhar com seus dados, será fácil criar um sistema alternativo com as novas tecnologias.

• Portanto, comece com um modelo de dados claro e bem documentado.
• Use um sistema de banco de dados estabelecido e bem suportado, como Oracle ^[1] ou SQL Server.
• Use os recursos básicos, não tente espremer novos e chamativos.
• Prefira simples ao invés de inteligente .
• Aceite que a manutenção futura possa custar 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, a aplicação do futuro é mais simples, porque é um invólucro do modelo de dados e pode ser substituída se, em 10 anos, ninguém mais usar 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 forte posição contra o uso do Oracle para um banco de dados, citando muitas razões perfeitamente legítimas pelas quais o Oracle é uma dor de trabalhar, possui uma curva de aprendizado acentuada e sobrecarga de instalação. Essas são preocupações totalmente 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 onde a principal preocupação seja a manutenção . A Oracle existe desde o final dos anos 70 e provavelmente será suportada por muitos anos, e há um enorme ecossistema de consultores e opções de suporte que podem ajudá-lo a mantê-lo funcionando. Esta é uma bagunça muito cara para muitas empresas? Certo. Mas ele manterá seu banco de dados em funcionamento 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 importam.

  amon menciona o fato de que um “site que funcionava em navegadores há 15 anos ainda funcionaria da mesma forma” , o que é verdade. No entanto, observe os sites criados não há quinze, mas dez anos atrás, que, quando criados, funcionavam na maioria dos navegadores para a maioria dos usuários. Hoje, 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 clickevento JavaScript , sem saber que o tapevento também é importante.

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

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

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

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

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

  Como exemplo, trabalho no desenvolvimento de software há 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 a decisão do cliente: ele não se importaria se o site usasse namespaces ou fechamentos de PHP. No entanto, mudanças relacionadas a novos requisitos e escalabilidade, havia muitas!

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

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

Eu tenho projetos em execução há 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. O XSS não era uma coisa há 20 anos, agora você precisa prestar contas do CORS.

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

Isso pode ser muito complicado às vezes. O .NET, por exemplo, é excelente para expor lógica e método para o adaptador de banco de dados MSSQL que não possui equivalentes em outros adaptadores. O MSSQL pode parecer um bom plano hoje, mas continuará 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. Na pior das hipóteses, você precisará reescrever toda a camada de dados, o restante do seu aplicativo não será afetado.

Em outras palavras, pense nisso como um carro. Seu carro não fará 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 gostaria de sugerir que você olhe para isso de outra perspectiva.

Eu trabalhei com grandes fabricantes e agências governamentais que dependiam de programas ou bases de código 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 centenas de vezes mais rápidas que as máquinas de implantação ... mas as máquinas de implantação foram 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, convém preparar alguns backups da instalação do SO para o servidor. Se algo travar em 10 anos, você não quer enlouquecer alguém 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ê precisa hospedar tudo no servidor (ou seja, não é possível usar uma CDN global para hospedar arquivos). Podemos supor que futuros navegadores ainda executem HTML e Javascript (pelo menos para compatibilidade), mas isso é realmente uma suposição / suposição e você não pode controlar isso.

O núcleo da maioria dos aplicativos são os dados. Os dados são para sempre. O código é mais descartável , mutável, maleável. Os dados devem ser preservados, no entanto. Portanto, foque na criação de um modelo de dados realmente sólido. Mantenha o esquema e os dados limpos. Preveja que um novo aplicativo possa ser construído sobre o mesmo banco de dados.

Escolha um banco de dados capaz de impor restrições de integridade. Restrições não impostas tendem a ser violadas com o passar do tempo. Ninguém nota. Faça o máximo uso de recursos, como chaves estrangeiras, restrições exclusivas, restrições de verificação e possivelmente disparadores para validação. Existem alguns truques para abusar de visualizações indexadas para impor restrições de exclusividade entre tabelas.

Talvez você precise aceitar que o aplicativo seja 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 mão-de-obra 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 poderá 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 bom, mas é uma garantia de que o aplicativo funcionará daqui a 20 anos sem custos de manutenção e hardware caros. Ao fazer isso, você tem pelo menos o fallback seguro e barato de continuar executando o código antigo e funcional.

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

As outras respostas fazem sentido. No entanto, acho que os comentários sobre a tecnologia do cliente acabaram complicando as coisas. Trabalho como desenvolvedor há 16 anos. Na minha experiência, contanto que você mantenha seu código de cliente intuitivo, tudo bem. Portanto, nenhum "hacks" com frames / iframes, etc. Use apenas funções bem definidas nos navegadores.

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

Para provar meu argumento, há apenas alguns meses, corrigi um bug do milênio no código javascript de um cliente que está executando seu aplicativo da web há 17 anos. Ainda funciona em máquinas recentes, banco de dados recente, sistema operacional recente.

Conclusão: mantenha-o simples e limpo e você ficará bem.

Alguns axiomas:

• A verdade sobrevive. Nesse contexto, seriam algoritmos e modelos de dados - o que representa verdadeiramente o "o quê" e o "como" do seu espaço problemático. Embora haja sempre o potencial de aprimoramento e aprimoramento, ou uma evolução do problema em si.
• Idiomas evoluem. Isso é verdade tanto para linguagens de computador quanto para linguagens naturais.
• Toda tecnologia é vulnerável à obsolescência. Pode levar mais tempo para algumas tecnologias do que para 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 às forças competitivas.

Vinte anos é muito tempo na indústria de computadores. Cinco anos é um objetivo mais realista. Dentro de cinco anos, todo o problema que seu aplicativo deve resolver pode ser completamente redefinido.

Alguns exemplos para ilustrar:

C e C ++ já existem há muito tempo. Eles têm implementações em praticamente todas as plataformas. O C ++ continua a evoluir, mas os recursos "universais" (disponíveis em todas as plataformas) têm praticamente a garantia de 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ê é autor da Web, deseja que seu conteúdo esteja disponível em todas as plataformas; você não quer perder o principal mercado móvel que se tornou.

WinTel (Windows / x86), apesar de ser proprietário da Microsoft e da Intel, tendo começado em uma plataforma abaixo do ideal (16 bits interno / 8 bits externo 8088 versus o contemporâneo Apple Macintosh 32 bits interno / 16 bits externo 68000) e erosão para a Apple no mercado consumidor continua sendo uma opção de fato para plataformas de negócios. Durante todo esse tempo (25 anos), o compromisso com a compatibilidade com versões anteriores impediu o desenvolvimento futuro e inspirou considerável confiança de que o que funcionou na caixa antiga ainda funcionará na nova.

Pensamentos finais

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