Assessoria na criação de aplicativos da Web com mais de 40 anos de vida

Cenário

Atualmente, faço parte de um projeto de assistência médica cujo principal requisito é capturar dados com atributos desconhecidos usando formulários gerados pelo usuário por prestadores de assistência médica. O segundo requisito é que a integridade dos dados seja essencial e que o aplicativo seja usado por mais de 40 anos. No momento, estamos migrando os dados do cliente dos últimos 40 anos de várias fontes (papel, Excel, Access, etc ...) para o banco de dados. Os requisitos futuros são:

• Gerenciamento de fluxo de trabalho de formulários
• Agendar gerenciamento de formulários
• Gerenciamento baseado em segurança / função
• Mecanismo de relatórios
• Suporte para celular / tablet

Situação

Apenas 6 meses depois, o atual arquiteto (contratado) / programador sênior adotou a abordagem "rápida" e projetou um sistema ruim. O banco de dados não é normalizado, o código é acoplado, as camadas não têm finalidade específica e os dados começam a desaparecer, pois ele projetou alguns beans para executar "exclusões" no banco de dados. A base de código é extremamente inchada e existem trabalhos apenas para sincronizar dados, pois o banco de dados não é normalizado. Sua abordagem tem sido confiar em tarefas de backup para restaurar os dados ausentes e parece não acreditar em refatorar.

Depois de apresentar minhas descobertas ao PM, o arquiteto será removido quando o contrato terminar. Foi-me dada a tarefa de re-arquitetar esse aplicativo. Minha equipe é composta por mim e um programador júnior. Não temos outros recursos. Nos foi concedido um congelamento de requisitos de 6 meses, no qual podemos nos concentrar na reconstrução deste sistema.

Sugeri o uso de um sistema CMS como o Drupal, mas por motivos de política na organização do cliente, o sistema deve ser construído do zero.

Esta é a primeira vez que projetarei um sistema com mais de 40 anos de vida útil. Eu só trabalhei em projetos com expectativa de vida de 3 a 5 anos, então essa situação é muito nova, mas emocionante.

Questões

• Que considerações de design tornarão o sistema mais "à prova de futuro"?
• Que perguntas devem ser feitas ao cliente / PM para tornar o sistema mais "à prova de futuro"?

Data is King

Eu acho que é um pouco irracional esperar que um aplicativo da web por volta de 2013 ainda esteja pronto para ser executado em 2053. As tecnologias vão mudar. Plataformas vão e vêm. O HTML pode ser uma memória singular até então. Mas seus dados ainda estarão por aí.

Portanto, os dados são seu foco principal. Enquanto seus dados ainda estiverem lá, as pessoas poderão se adaptar a quaisquer novas tecnologias. Certifique-se de que seus esquemas de dados sejam bem pensados ​​e adequados para expansão. Tome seu tempo especificando-os.

Em relação às aplicações reais, sua empresa provavelmente está correta aqui em ter uma diretiva 'build from scratch'. Eu mantenho alguns aplicativos da Web com mais de 10 anos de idade e estou muito feliz por eles não estarem presos aos sistemas CMS predominantes de 2003. Eles usam estruturas domésticas e muito simples. Penso que, para algo assim, você está melhor com uma estrutura muito básica que você cria especificamente para as necessidades do projeto.

Mas a realidade é que, em mais de 40 anos, a empresa (esperançosamente) estará realizando alguns serviços de front-end e back-end para se adaptar às plataformas em evolução. Portanto, eu visaria uma vida útil de 5 a 10 anos para aplicativos individuais voltados para o usuário.

Produzimos software usado por clientes pagantes há mais de 20 anos. A base de código superou várias gerações de ferramentas de controle de origem. Nosso software atinge todos os seus pontos de bala, exceto o tablet.

Algumas das preocupações incluem ESIGN e UETA . Nossos advogados acreditam que precisamos manter os registros eletrônicos legíveis por um período mínimo de 10 anos. Para documentos que são mantidos todo, você deve olhar para PDF / A .

Para o seu banco de dados, não se preocupe muito com a normalização. Em vez disso, você deve se preocupar em registrar tudo e ter tabelas de auditoria que rastreiam alterações / exclusões nos dados. Ao atualizar versões, planeje testar novas versões em paralelo por tempo suficiente para garantir que os dados sejam migrados. Esse teste de novas versões também inclui novos sistemas operacionais - tivemos algumas surpresas desagradáveis ​​ao longo dos anos. Preserve a mídia de instalação e as chaves de licença no caso de uma reversão precisar ser realizada. Testes de backup. Se você deseja serializar objetos para armazenar no banco de dados, faça-o como XML em vez da serialização fornecida por sua estrutura de desenvolvimento.

Para sua equipe, as bases de códigos de longo prazo precisam de memória de longo prazo. Idealmente, você gostaria de ter pessoas por perto que existem há muito tempo. Se isso for institucionalmente impossível, você precisará documentar tudo em algo como um wiki. E meu conselho é um wiki que possa se conectar ao seu sistema de rastreamento de bugs.

Para sua base de código, verifique se você tem comentários no seu código. A migração de um sistema de controle de versão para outro quase sempre perde seus comentários de check-in. Sou fã de nomear testes de unidade após números de especificações e erros. Dessa forma, se o teste de unidade for Test_Bug_1235 interrompido, você saberá o que e onde rastrear o que deveria estar testando. Não é tão "sexy" quanto nomear seus testes, Check_File_Save_Networked_Drivesmas é difícil retroceder esse tipo de teste às especificações, requisitos ou bugs Test_requirement_54321_case_2.

Em vez de tentar descobrir como esse aplicativo ainda estará em operação daqui a 20 anos, acho que você deve passar seus seis meses corrigindo os problemas que encontrou pelo arquiteto original, criando uma arquitetura robusta e sensível e seguir em frente a partir daí.

A desnormalização parcial de um banco de dados não é necessariamente totalmente inesperada em um ambiente médico. Algumas partes dos bancos de dados médicos têm características que os tornam um bom ajuste para o modelo EAV (Entidade / Atributo / Valor) .

Resposta de uma perspectiva de front-end:

Não ouça todo mundo dizendo que isso não pode ser feito, porque um serviço da Web experimental da Universidade do Estado de São Francisco que eu co-escrevi em 1996 finalmente foi para o paraíso na Internet há alguns anos e nunca precisou de uma única correção de compatibilidade de navegador naquele tempo ; isso é quase metade da sua meta de 40 anos. E esse front-end baseado em JavaScript que eu fiz em 1998 para um projeto do Stanford Research Institute foi substituído por algo mais chamativo alguns anos depois, mas não há razão para que a interface do usuário original ainda não estivesse funcionando hoje com pequenas correções de compatibilidade.

O truque é garantir que seu aplicativo use apenas os padrões W3C / ECMA amplamente suportados e tenha um design limpo sob seu controle. Embora muitos aplicativos da Web gravados na moderna tecnologia da era dos anos 90 não funcionem bem ou hoje, os aplicativos da era dos anos 90 gravados nos principais padrões ainda funcionam. Eles podem parecer ultrapassados, mas eles funcionam.

O objetivo aqui não é escrever um aplicativo Web que suba no servidor e permaneça lá por 40 anos sem que ninguém o toque novamente. É construir uma base que ainda possa ser usada décadas depois, que pode crescer para suportar novos recursos sem precisar ser reconstruída do zero.

Primeiro de tudo, você precisa codificar para padrões oficiais e somente para padrões oficiais. Nenhum recurso JavaScript que não faça parte de um padrão ECMAScript ratificado; ES5.1 é a versão atual e geralmente é suportada, de modo que é seguro segmentar. Da mesma forma, as versões atuais de HTML5, CSS e Unicode são boas. Não há recursos experimentais de JavaScript, CSS3 ou HTML (aqueles com prefixos de fornecedores ou sem acordo de 100% entre os navegadores). E não há hacks de compatibilidade específicos do navegador. Você pode começar a usar um novo recurso quando ele estiver no padrão e todos o suportarem sem prefixos.

O suporte ao ES5 significaria abandonar o IE8 ou anterior, o que eu sugiro de qualquer maneira, pois requer hacks específicos do navegador que serão inúteis em alguns anos. Eu sugiro o Modo Estrito do ES5 para a melhor chance de longevidade, o que realmente define a compatibilidade do navegador de linha de base no IE10 e nas versões recentes de todos os outros . Esses navegadores também têm suporte nativo para muitos dos recursos de validação de formulário e espaço reservado do HTML5, que serão úteis por muito tempo.

Novas edições do ECMAScript mantêm a compatibilidade com versões mais antigas, por isso será muito mais fácil adotar os próximos recursos se o seu código for escrito de acordo com os padrões atuais. Por exemplo, as classes definidas usando a classsintaxe futura serão totalmente intercambiáveis ​​com as classes definidas com a constructor.prototypesintaxe atual . Assim, em cinco anos, um desenvolvedor pode reescrever classes no formato ES6, arquivo por arquivo, sem quebrar nada - supondo, é claro, que você também tenha bons testes de unidade.

Segundo, evite estruturas modernas de aplicativos JavaScript, especialmente se elas mudarem a maneira como você codifica seu aplicativo. A espinha dorsal era toda a raiva, então SproutCore e Ember, e agora o Angular é a estrutura que todo mundo gosta de promover. Eles podem ser úteis, mas também têm algo em comum: geralmente quebram aplicativos e exigem alterações de código quando novas versões são lançadas e sua longevidade é questionável. Atualizei recentemente um aplicativo Angular 1.1 para 1.2 e um pouco teve que ser reescrito. Da mesma forma, passar do Backbone 2 para 3 requer muitas alterações de HTML. Os padrões são lentos por um motivo, mas essas estruturas se movem rapidamente e as coisas quebram periodicamente são o custo.

Além disso, novos padrões oficiais geralmente deixam obsoletas estruturas antigas e, quando isso acontece, essas estruturas sofrem mutações (com alterações recentes) ou são deixadas para trás. Você sabe o que vai acontecer com todas as bibliotecas de promessas concorrentes do mundo depois que o ECMAScript 6 for ratificado e todos os navegadores suportarem sua classe Promise padronizada? Eles ficarão obsoletos e seus desenvolvedores deixarão de atualizá-los. Se você escolheu a estrutura correta, seu código pode se adaptar bem o suficiente e, se você adivinhou mal, verá uma grande refatoração.

Portanto, se você está pensando em adotar uma biblioteca ou estrutura de terceiros, pergunte-se o quão difícil será remover no futuro. Se é uma estrutura como Angular que nunca pode ser removida sem reconstruir seu aplicativo do zero, é um bom sinal de que não pode ser usado em uma arquitetura de 40 anos. Se for um widget de calendário de terceiros que você abstraiu com um middleware personalizado, a substituição levaria algumas horas.

Terceiro, ofereça uma estrutura de aplicativo boa e limpa. Mesmo se você não estiver usando uma estrutura de aplicativo, ainda poderá aproveitar as ferramentas do desenvolvedor, criar scripts e um bom design limpo. Pessoalmente, sou fã do gerenciamento de dependências do Closure Toolkit porque é leve e sua sobrecarga é completamente removida na criação do aplicativo. LessCSS e SCSS também são ótimas ferramentas para organizar suas folhas de estilo e criar folhas de estilo CSS baseadas em padrões para lançamento.

Você também pode organizar seu próprio código em classes de uso único com uma estrutura MVC. Isso tornará muito mais fácil voltar vários anos no futuro e saber o que você estava pensando quando escreveu algo, e substituir apenas as partes que precisam.

Você também deve seguir os conselhos do W3C e manter as informações de apresentação completamente fora do seu HTML. (Isso inclui truques, como fornecer aos elementos nomes de classe de apresentação, como "texto verde grande" e "largura de duas colunas".) Se o seu HTML for semântico e o CSS for de apresentação, será muito mais fácil mantê-lo e adaptá-lo para novas plataformas no futuro. Também será mais fácil adicionar suporte a navegadores especializados para pessoas cegas ou deficientes.

Quarto, automatize seus testes e verifique se você tem uma cobertura quase total. Escreva testes de unidade para todas as classes, seja do lado do servidor ou em JavaScript. No front-end, verifique se cada classe tem desempenho de acordo com suas especificações em todos os navegadores suportados. Automatize esses testes do seu bot de compilação para cada confirmação. Isso é importante tanto para a longevidade quanto para a confiabilidade, pois é possível detectar erros mais cedo, mesmo quando os navegadores atuais os ocultam. As estruturas de teste baseadas em JSUnit do Jasmine e do JS Closit do Google são boas.

Você também deseja executar testes funcionais completos da interface do usuário, nos quais o Selenium / WebDriver é bom. Basicamente, você escreve um programa que percorre sua interface do usuário e o usa como se uma pessoa estivesse testando. Conecte-os também ao bot de compilação.

Por fim, como outros já mencionaram, seus dados são importantes. Pense em seu modelo de armazenamento de dados e verifique se ele foi desenvolvido para durar. Certifique-se de que seu esquema de dados seja sólido e que também seja testado completamente em todas as confirmações. E verifique se a arquitetura do servidor é escalável. Isso é ainda mais importante do que qualquer coisa que você faça no front end.

Deixando de lado os problemas das expectativas irracionais do seu cliente e focando nos problemas de design, eu não chegaria a 40 anos, mas o problema que você parece ter, de capacidade de evoluir a longo prazo, é exatamente o que o REST foi criado para . Por isso, eu realmente quero dizer REST como um estilo de arquitetura, não o desenvolvimento orientado por chavão que é tão comumente associado ao termo atualmente.

Até certo ponto, as pessoas entendem errado o REST porque eu não incluí detalhes suficientes no design do tipo de mídia na minha dissertação. Isso porque o tempo acabou, não porque pensei que fosse menos importante que os outros aspectos do REST. Da mesma forma, suspeito que muitas pessoas entendem errado, porque leem apenas a entrada da Wikipedia sobre o assunto, que não é baseada em fontes autorizadas.

No entanto, acho que a maioria das pessoas comete o erro de que deve ser simples projetar coisas simples. Na realidade, o esforço necessário para projetar algo é inversamente proporcional à simplicidade do resultado. Conforme os estilos arquitetônicos, o REST é muito simples.

O REST é um projeto de software na escala de décadas : todos os detalhes visam promover a longevidade do software e a evolução independente.

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

Você mencionou que pretende usar uma interface RESTful. Esse comentário sugere que você deve fazer uma pesquisa séria sobre isso e tentar entender o que realmente é o REST. Você provavelmente o associa apenas ao mapeamento de métodos HTTP para operações CRUD que a maioria das pessoas pensa que o REST é, mas não tem nada a ver com isso.

Pense no REST como uma formalização da arquitetura da própria web. De uma maneira ou de outra, existem muitas partes da Web escritas há uma década ou mais que ainda estão disponíveis e podem ser usadas com um cliente feito hoje, por isso, conseguimos algo nesse departamento. Garanto que vai dar muito trabalho, porque fazer o REST corretamente é difícil, mas os benefícios a longo prazo valem a pena.

Depois de ler a pergunta e as outras respostas (muito bem pensadas), pensei em deixar meus dois centavos também. Nota: Não preciso manter nenhum aplicativo / software realmente antigo. O que eu uso como referência é meu próprio aplicativo da web de hobby em andamento que pega alguns dados abertos do governo, analisa e os exibe em diferentes formatos. O aplicativo começou como um projeto em que eu não estava sozinho e onde o governo acabou de anunciar que oferecerá esses dados de alguma forma. Portanto, ficou claro que muitas coisas mudarão com o tempo. E eles fizeram. O que eu aprendi com isso:

• Divida as coisas em miniaplicativos. Cada um totalmente capaz de cumprir sua tarefa por conta própria. Isso torna a troca de uma peça única muito rápida, muito segura e muito fácil. E quando você precisa voltar, não é realmente difícil entender por que as coisas acontecem e como elas acontecem. Se você ou outra pessoa precisar alterar alguma coisa posteriormente, é mais fácil substituir uma única peça do que um conjunto inteiro de coisas.
• Obtenha um middleware / camada constante e sólido que é usado para comunicação entre as diferentes partes. Nesse caso, usei JSON, mas padrões XML, ini ou similares também seriam bons. É fácil de repetir e pode ser transformado em quase tudo. Todos são padrões comprovados que sobreviverão por algum tempo. Mesmo que os dados subjacentes e / ou o modelo de armazenamento sejam alterados. Cada um dos aplicativos pode usar seu próprio armazenamento de dados para sua tarefa específica. Isso diminui a quantidade de dados digitalizados para uma tarefa, portanto, é mais fácil de manusear e manter e é mais fácil de trocar.
• Não se preocupe com as decisões da linguagem de programação. Aqueles mudarão com o tempo. Apenas certifique-se de usar o idioma com o qual se sinta confortável ou que melhor se adapte a uma tarefa.
• Verifique se o armazenamento de dados é "horizontalmente escalável" e se é fácil conectar módulos de armazenamento adicionais.
• Obtenha um ponto comum (no meu caso, são URIs) em que os miniaplicativos são chamados e / ou trocam dados.

Resumindo: O que mais me importa é a separação de preocupações e a capacidade de troca de peças designadas para tarefas. Você simplesmente sabe que em 40 anos (mesmo em 5 ou 10) o hardware, as interfaces, o armazenamento etc. mudarão muito. E os desenvolvedores posteriores terão que reagir a essas alterações e trocar partes de seu aplicativo, seja o contêiner de dados ou partes da Interface do Usuário.

Para tornar as coisas o mais "possível para o futuro", planeje a mudança. Ou seja, tente o máximo possível para não otimizar nada além da capacidade de mudar facilmente. Portanto, não há normalização, validação estrita e abundância de acoplamentos soltos.

• Use as principais tecnologias de código aberto. Para os dados, os sistemas de código fechado são uma importante fonte de risco, pois não se pode planejar em que empresas as empresas vão adotar ou alterar estratégias, levando consigo todo o acesso aos dados. Além disso, projetos menores de código aberto sem uma comunidade vibrante também tendem a perder apoio.

• Use um banco de dados NoSQL sem esquema. Os tipos de dados não estruturados que estão sendo usados ​​são quase diretos para livros de documentos como o MongoDB. Os bancos de dados relacionais tradicionais e sua normalização são bons quando você sabe como seus dados serão estruturados, mas isso é realmente uma ficção, especialmente aqui. Os custos da alteração do esquema em um RDBS ficam cada vez maiores à medida que o sistema se expande. Saiba que qualquer estrutura escolhida agora vai acabar mudando.

• Desacoplar o sistema fortemente usando padrões amplamente aceitos. A divisão de todo acesso e mutação de dados em serviços da Web é um passo para isso. Combinar isso com filas de mensagens para enviar alterações e isso ajudará partes individuais do sistema a mudarem idiomas ou tecnologias ao longo do tempo.

OK, então eu vou dizer algumas coisas aqui que provavelmente serão muito impopulares, mas fique comigo aqui.

Como este é o seu primeiro projeto em que os dados e / ou o aplicativo devem durar mais de 20 anos e você é o líder do projeto, é necessário dar um passo atrás e pensar sobre quais são as chances desse projeto ser bem-sucedido. . Porque eles são basicamente próximos de zero.

Você precisa gastar uma quantidade enorme de tempo concentrando-se no design do banco de dados e acertando. Para que este projeto seja bem-sucedido, você precisa trazer um arquiteto de dados para o projeto, e antes disso. Sem alguém com experiência em design de banco de dados e com boa prática na expectativa de como os dados podem ser usados ​​no futuro, as chances de os dados continuarem sendo úteis após 5 anos e muito menos 40 anos são praticamente nulas.

Esperar que duas pessoas (uma delas com o título de jr. Dev) construa algo do zero, que deve durar 40 anos, provavelmente não será bem-sucedido. Deve haver uma equipe de pessoas com experiência no trabalho de grandes projetos como este que trabalham no design de dados, no design da API e no design do aplicativo. Algo assim não é um projeto para 2 pessoas.

Desejar vincular o projeto a algo como o Drupal mostra por que o projeto precisa de pessoas acostumadas a trabalhar nesse tipo de projeto. Você não deseja vincular o aplicativo a nada que possa ficar fora de moda dentro de alguns anos. Se você conseguiu, encontrar alguém para trabalhar no sistema em 5 a 10 anos pode ficar muito difícil muito rapidamente.

Eu aceitaria esse conselho para a gerência e explicaria a eles que você precisa atrair mais pessoas seniores para o projeto. Caso contrário, o projeto está fadado ao fracasso, e você provavelmente acabará sendo o culpado por isso.

O aplicativo não precisa sobreviver 40 anos sem nenhuma evolução. Mas, como seria ou deveria ser construído do zero, ainda poderia estar 'funcionando'.

O que é mais importante é a 'arquitetura de dados' que permite certa estabilidade e governança, além de extensível.

Projetamos arquitetura e taxonomia de dados que quase poderiam sobreviver ao fim da humanidade, mas ainda assim extensíveis. Você encontrou uma pessoa verdadeira com TAXONOMIA DE DADOS / ARQUITETURA DE DADOS para fazer isso por você.

A chave aqui é focar no banco de dados (como vários já disseram). Isso precisa ser coerente e descrever completamente a operação. Ele precisa crescer com a operação à medida que muda. Se não é fácil mudar, ficará desatualizado e esse é o beijo da morte. O resto é relativamente menos importante.

Não concordo com aqueles acima que sugerem que a normalização não é importante, embora sempre haja casos em que os sistemas atuais não estão à altura do trabalho. Nesses casos, desnormalize, mas garanta que o banco de dados lide com as gravações / alterações extras como parte de uma transação atômica. Dessa forma, você pode efetivamente ignorar o problema até consertá-lo.

A empresa em que trabalhei antes da aposentadoria está executando um sistema que foi escrito do zero e cresceu quase continuamente por 25 anos, e abrange praticamente todos os aspectos de um varejista médio. Aspectos deste sistema que considero importantes são:

• A integração é vital.
• O banco de dados precisa ser o mais correto e compreensível para a equipe de TI e para outros funcionários; portanto, é necessária uma ênfase quase paranóica na nomeação. Temos tabelas de mnemônicos definidos que são então combinados para formar nomes de tabelas e campos e todos os “códigos” também foram nomeados como constantes e armazenados em uma estrutura de tabela EAV.
• Encapsulamos a lógica de negócios em gatilhos de banco de dados. Isso é doloroso no início e requer trabalho adicional para transmitir mensagens de erro aos clientes e permitir que os gatilhos sejam alterados de maneira flexível sem bloquear a tabela inteira em alguns sistemas, mas isso rapidamente se torna uma economia de tempo enorme e força o banco de dados a ser muito mais correto do que o contrário.
• Suponha que você mantenha pelo menos tabelas de referência (idealmente todas, exceto as transações mais rápidas e menos importantes) durante toda a vida útil do sistema, mesmo quando "excluído" para que suas referências estejam corretas.
• Por causa do exposto, verifique se todos os identificadores e números de transação exclusivos são dimensionados para o longo prazo. (Originalmente, sugeri brincando, eles precisavam durar até eu me aposentar).

Eu sugeriria o uso de fonte de eventos e comando e consulta de segregação de responsabilidades . Isso ocorre principalmente porque a única coisa que você pode ter certeza é dos eventos que já apareceram. Novos tipos de eventos podem vir. Portanto, mesmo se você pensar muito em um modelo, é certo que isso ficará desatualizado. A migração de todos os dados a cada release pode não ser viável. Portanto, o melhor é ter um modelo que atenda às suas necessidades atuais e que seja calculado a partir de eventos já gravados toda vez que você precisar, e depois distribuir eventos que são calculados a partir do estado atual desse modelo.

Também tenha em mente os testes. Se o aplicativo estiver em uso daqui a dez anos, os testadores precisam se certificar de que ainda estão fazendo o que deveriam fazer. Torne o teste de integração seu aplicativo o mais fácil possível.