Com o número cada vez maior de bibliotecas javascript utilizadas nas interfaces web, torna-se rapidamente necessário rastrear os scripts usados, dos seus números de versão e das dependências entre eles no ecossistema de ferramentas internas e de sites externos desenvolvidos, seja nas empresas ou para projetos pessoais.
A abordagem que sugiro para fazer isso consiste num documento de síntese e num processo de monitoramento ativo.
O documento de síntese deve conter todas as informações a seguir:
E isso para cada projeto/ferramenta/site em questão, e portanto, apresentados numa tabela, com para cada um deles um indicador gráfico representando o status da versão utilizada (em dia o não), assim como o número de versão dele.
Idealmente, o documento de síntese deveria também explicitar onde se encontram as chamadas às bibliotecas para cada projeto e/ou permitir uma ligação directa para os arquivos relevantes no sistema de gestão de versão (SVN, Git…).
O processo de monitoramento ativo consiste em verificar regularmente qual é a última versão que se pode utilizar na produção (não há necessidade seguir os Release Candidates), e isto é onde os leitores RSS e outras ferramentas de automação são úteis. Alguns projetos são atualizados com mais frequência do que outros, jQuery por exemplo entrega uma release menor quase todos os meses.
As dependências em cascata entre os scripts são um fenómeno a ter em mente, desde que as atualizações se fazem também em cascata.
Se você estiver usando por exemplo o par jQuery/jQueryUI, a versão mais recente do segundo possa não ser compatível com a versão mais recente do segundo antes de poucas semanas. Não há necessidade de estar sempre na vanguarda em isolamento, é toda a cadeia de dependências que deve ser globalmente em dia.
O problema é agravado quando você desenvolver os seus próprios scripts em sobrecamada de uma biblioteca. Serán ainda compatíveis com a última versão dela?
Em geral, as bibliotecas sigam o princípio da compatibilidade ascendente, o que significa que o código escrito para versões anteriores são ainda funcionais com o novo (o exemplo anterior com jQuery/jQueryUI é, portanto, hipotético), às vezes com uma perda potencial de desempenho. É interessante notar para qual versão do subcamada um script tem sido desenvolvido para saber quando fazer uma revisão do código.
Para estar seguros desta compatibilidade, a utilização de ferramentas de teste automatizado de interface ainda fica a melhor maneira de validação (por exemplo Selenium).
A abordagem que sugiro para fazer isso consiste num documento de síntese e num processo de monitoramento ativo.
O documento de síntese deve conter todas as informações a seguir:
- lista das bibliotecas usadas
- último número de versão e data de publicação
- dependências com outros scripts de terceiros (com os seus números de versão)
- URL do site onde baixar a versão mais recente
- onde encontrar a informação sobre a versão mais recente (página de download, change log, blog, fonte RSS…)
E isso para cada projeto/ferramenta/site em questão, e portanto, apresentados numa tabela, com para cada um deles um indicador gráfico representando o status da versão utilizada (em dia o não), assim como o número de versão dele.
Idealmente, o documento de síntese deveria também explicitar onde se encontram as chamadas às bibliotecas para cada projeto e/ou permitir uma ligação directa para os arquivos relevantes no sistema de gestão de versão (SVN, Git…).
O processo de monitoramento ativo consiste em verificar regularmente qual é a última versão que se pode utilizar na produção (não há necessidade seguir os Release Candidates), e isto é onde os leitores RSS e outras ferramentas de automação são úteis. Alguns projetos são atualizados com mais frequência do que outros, jQuery por exemplo entrega uma release menor quase todos os meses.
As dependências em cascata entre os scripts são um fenómeno a ter em mente, desde que as atualizações se fazem também em cascata.
Se você estiver usando por exemplo o par jQuery/jQueryUI, a versão mais recente do segundo possa não ser compatível com a versão mais recente do segundo antes de poucas semanas. Não há necessidade de estar sempre na vanguarda em isolamento, é toda a cadeia de dependências que deve ser globalmente em dia.
O problema é agravado quando você desenvolver os seus próprios scripts em sobrecamada de uma biblioteca. Serán ainda compatíveis com a última versão dela?
Em geral, as bibliotecas sigam o princípio da compatibilidade ascendente, o que significa que o código escrito para versões anteriores são ainda funcionais com o novo (o exemplo anterior com jQuery/jQueryUI é, portanto, hipotético), às vezes com uma perda potencial de desempenho. É interessante notar para qual versão do subcamada um script tem sido desenvolvido para saber quando fazer uma revisão do código.
Para estar seguros desta compatibilidade, a utilização de ferramentas de teste automatizado de interface ainda fica a melhor maneira de validação (por exemplo Selenium).
Suivi des bibliothèques Javascript (em francês)
Follow-up of javascript libraries (em inglês)
El seguimiento de las bibliotecas javascript (em espanhol)
Sem comentários:
Enviar um comentário