Manutenção de software em pesquisa
Edição Python Edição JVM Blog … biblioteca —> Manutenção de software em pesquisa por Konrad Hinsen, publicado em 26 de fev. de 2014 A manutenção de software é uma das dificuldades que os desenvolvedores de software científico enfrentam regularmente. É uma atividade importante, mas pode consumir muito tempo e raramente é recompensada pelos procedimentos de avaliação atuais. E, se você está gerenciando um grande projeto de software, geralmente é difícil obter financiamento para a manutenção.
Dado que a manutenção de software é difícil e não possui interesse científico intrínseco, devemos nos perguntar por que ela é necessária e se podemos fazer algo para reduzir essa necessidade. Antes de tudo, o que é manutenção de software? O Merriam-Webster define o verbo “manter” (maintain) como conservar (algo) em boas condições, fazendo reparos, corrigindo problemas etc. Isso faz sentido para equipamentos técnicos que se deterioram ao longo do tempo devido ao desgaste mecânico, entre outros fatores.
O software não se deteriora; portanto, a manutenção deve significar algo diferente quando aplicada a ele. Não tenho conhecimento de nenhuma definição consensual, então apresento aqui a minha própria: A manutenção de software consiste em modificar o software por uma de duas razões: Corrigir bugs. Manter o software utilizável em ambientes de computação em evolução.
Algumas pessoas adicionariam melhorias funcionais a esta lista, mas estas não são realmente manutenção em nenhum sentido, e sim aprimoramentos. Especialmente no caso do software científico, onde nova funcionalidade frequentemente significa nova ciência. Primeiro, os bugs.
Como em qualquer software, queremos que os bugs no software científico sejam corrigidos para obter melhores resultados no futuro. No entanto, também queremos manter a versão com bugs disponível caso algum estudo científico publicado a tenha utilizado.
Trata-se simplesmente de uma questão de honestidade e preservação do registro científico: se houver a chance de que o resultado de um estudo tenha sido influenciado por um bug no software, as pessoas que analisam o estudo devem poder descobrir isso. Elas devem ter acesso exatamente ao mesmo software que foi usado originalmente, e não apenas ao seu sucessor aprimorado de hoje. Por esse motivo, na verdade, é mais importante preservar o código usado em um estudo do que corrigir bugs. O ActivePapers foi projetado com esse objetivo em mente: qualquer item de dados computado em um ActivePaper está vinculado ao software que o produziu.
Relacionado: — Cursos interativos de Python e ciência de dados que você codifica diretamente no navegador.
Além disso, esse vínculo é estritamente imutável após a publicação, pois os ActivePapers são publicados assim como cópias eletrônicas de artigos e referenciados por meio de DOIs. Você pode trapacear antes da publicação, modificando um ActivePaper com a intenção específica de cometer fraude.
O ActivePapers não oferece suporte a tais ações, mas também não faz nenhum esforço para prevenir fraudes. Tais recursos poderiam ser adicionados protegendo as informações de proveniência com hashes, mas espero que isso não seja necessário. O segundo problema, a evolução dos ambientes de computação, é mais sutil. É um fato da vida que tudo no mundo da computação (computadores, sistemas operacionais, compiladores, definições de linguagem, bibliotecas, …) muda rapidamente, resultando na improvabilidade de que um determinado trecho de código-fonte funcione como está alguns anos depois.
Isso ocorre por duas razões: (1) o progresso técnico permite computadores e softwares cada vez melhores, que é o que as pessoas desejam, e (2) ninguém tem interesse vested na estabilidade das plataformas de computação nem o poder de torná-la realidade. Para fornecedores de hardware e de software comercial, a mudança rápida é a melhor maneira de garantir que os clientes comprem novas máquinas e atualizem suas licenças regularmente. Existe, claro, pelo menos uma comunidade que tem interesse vested na estabilidade das plataformas de computação: a comunidade de ciência computacional.
Favorito do leitor: — Caminhos de ciência de dados baseados em projetos com um terminal guiado e conjuntos de dados reais.
Se pudéssemos executar nosso software 20 anos depois, sem modificação, e obter os mesmos resultados, ficaríamos felizes. Não queremos fazer manutenção de software, e a maioria de nós não consegue razoavelmente manter o software que desenvolve para sua própria pesquisa além de suas necessidades pessoais imediatas. É ainda menos razoável esperar que alguém mantenha o software de outra pessoa, por exemplo, o software deixado pelo estudante de pós-graduação que agora trabalha na indústria. Na prática, apenas o software comunitário amplamente utilizado recebe manutenção por períodos suficientemente longos.
Mas até mesmo projetos de pesquisa que usam pacotes amplamente utilizados e mantidos geralmente também exigem algum software específico do projeto, no mínimo alguns scripts de shell. E essa é uma das razões pelas quais a reprodutibilidade de estudos computacionais é tão ruim.
A comunidade científica poderia fazer algo a respeito? Acredito que sim, mas não sou otimista de que tomará medidas num futuro próximo. É provável que os cientistas continuem a usar hardware convencional para computação científica, o que significa que terão de aceitar a evolução do hardware e do software de sistema associado, que está fora de seu controle. No entanto, eles podem construir uma plataforma estável sobre essas bases em constante evolução, pelo menos para a parte puramente computacional de seu trabalho.
Em um nível fundamental, todas as notações de software Turing-completas são equivalentes e podem ser convertidas umas nas outras. Na prática, considerações de desempenho impõem um limite à conversão de código, mas ainda é possível definir representações de código que possam ser traduzidas eficientemente para todos os tipos de hardware e software de sistema subjacentes e, assim, permanecer estáveis.
Dois exemplos da vida real são o bytecode da JVM e a forma intermediária do LLVM . O bytecode da JVM existe há 20 anos e provou ser extremamente estável. A forma intermediária do LLVM não foi feita para ser estável, mas isso ocorre porque os desenvolvedores do LLVM não querem limitar suas opções futuras ao se comprometerem com uma representação estável. O projeto PNaCl do Google tenta ignorar este aviso e usar o código LLVM de uma forma que só faz sentido se ele permanecer estável.
O tempo dirá como isso funcionará. A comunidade científica poderia definir sua própria representação de código intermediário, baseando-se na experiência com abordagens existentes e otimizando sua plataforma para aplicações científicas. Mas, como disse acima, não sou otimista de que isso aconteça.
Dois requisitos seriam um compromisso de longo prazo de várias grandes organizações de pesquisa e financiamento para manter essa plataforma por muitas décadas. Estou convencido de que isso seria economicamente razoável, pois tenho certeza de que manter uma plataforma é mais barato do que manter muitos pacotes de software científico e reescrever constantemente aqueles que não foram mantidos. Mas exigiria um nível de acordo e compromisso que é raro na ciência; isso só aconteceu para algumas instalações enormes, como o CERN .
A importante vantagem proporcionada por uma plataforma estável é a razão pela qual a primeira edição do ActivePapers foi projetada em torno da JVM. Infelizmente, a JVM não é muito popular na computação científica.
Isso é frequentemente explicado pela falta de desempenho, embora esse argumento já não seja tão válido quanto costumava ser. Há também alguns problemas de design, particularmente concerning operações de ponto flutuante, mas o mesmo pode ser dito sobre linguagens populares como C ou C++, o que não impediu os cientistas de usá-las. A edição Python do ActivePapers, praticamente mais útil, é construída sobre uma plataforma definida pelo ecossistema Scientific Python (em particular Python, NumPy e h5py).
Esta plataforma provou ser moderadamente estável no passado, sendo a transição para o Python 3 o principal evento de instabilidade. A escala de tempo sobre a qual a científica
Leitura adicional
- SciPy — Wikipedia
A estante de referência para cientistas ativos
Uma biblioteca técnica profunda de livros, vídeos e treinamento ao vivo sobre computação científica