ti-enxame.com

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?

160
Dan

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: Java foi publicado em 1995, há 21 anos. O XmlHttpRequest foi disponibilizado pela primeira vez como uma extensão proprietária para o Internet Explorer 5, publicado em 1999, há 17 anos. Levou cerca de 5 anos até tornou-se disponível em todos os 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 segmentava 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 é 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.

132
amon

O que é ainda mais importante que o seu código que sobrevive por 20 anos é que seu dados sobrevive 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 o Oracle[1] ou SQL Server.
  • Use os recursos básicos, não tente espremer novos e chamativos.
  • Prefira simples sobre inteligente.
  • Aceite que a manutenção futura possa custar aspectos como desempenho. Por exemplo, você pode se sentir 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 prova 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 uma sobrecarga na 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 manutenibilidade. 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 manterá seu banco de dados em execução por 20 anos? Muito provável.

176
Avner Shahar-Kashtan

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 funcionou em navegadores há 15 anos ainda funcionará 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 consegue 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 JavaScript click , sem saber que o evento tap também é importante.

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

    Mudanças tecnológicas são uma coisa, mas uma 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 seja.

    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 forma que ninguém possa entendê-lo e mantê-lo, a tecnologia não importará: qualquer mudança 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 eu decidi mudar por causa da tecnologia, mais precisamente porque 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!

36
Arseni Mourzenko

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 é agnóstico? 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 permanecerá 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.

31
coteyr

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

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 dentro de 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 navegadores futuros ainda executem HTML e Javascript (pelo menos para compatibilidade), mas isso é realmente uma suposição/suposição e você não pode controlar isso.

12
Jonathan Vanasco

O núcleo da maioria dos aplicativos são os dados. Os dados são eternos. O código é mais dispensá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 a virtualização. Isso não é realmente agradável , 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. Python provou que é muito instável com o Python 3 O JavaScript realmente 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 descolado ("Funky" sendo definido como "eu sei quando vejo isto").

6
usr

As outras respostas fazem sentido. No entanto, sinto que os comentários sobre a tecnologia do cliente acabaram complicando as coisas. Trabalho como desenvolvedor há 16 anos. Na minha experiência, desde que você mantenha seu código de cliente intuitivo, você deve ficar 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 para 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.

0
Jonathan van de Veen