Código científico ruim supera código que segue “melhores práticas” (2014)
A pesquisa científica muitas vezes depende de scripts rápidos e de uso único escritos por especialistas de domínio, enquanto desenvolvedores profissionais tendem a levar “melhores práticas” e abstrações mais pesadas até mesmo para bases de código pequenas e experimentais. Os comentaristas debatem o que é pior: código científico frágil e sem documentação, que prejudica a reprodutibilidade, ou sistemas superengenheirados, difíceis de entender, modificar e adaptar a questões de pesquisa em evolução. Muitos concluem que o problema real são os incentivos e o contexto, defendendo um equilíbrio entre simplicidade e disciplina de engenharia, além de engenheiros de software de pesquisa dedicados para fazer a ponte entre os dois mundos.
Reação geral ao artigo
- Muitos veem o post como um desabafo ou um espantalho: ele contrapõe “código de cientistas ruim” vs. “código de programadores ruim” usando exemplos extremos.
- Outros dizem que ele ressoa fortemente, especialmente a crítica ao excesso de engenharia e às “melhores práticas” em estilo cargo cult.
- Vários argumentam que o alvo real deveria ser “programadores ruins” (muitas vezes juniores ou seguidores cegos de padrões), e não a engenharia de software como um todo.
Cientistas vs. engenheiros de software
- Visão comum: cientistas frequentemente fazem pouca engenharia (código desorganizado, ad hoc, scripts de uso único); engenheiros de software frequentemente fazem engenharia demais (camadas de abstração, herança, padrões “enterprise”).
- Alguns argumentam que cientistas costumam ser mais inteligentes em seu domínio e podem ser mais eficazes para ferramentas pontuais; outros respondem que inteligência no domínio não substitui habilidade em software.
- Vários comentaristas observam que, na prática, uma enorme quantidade de código científico é cheio de bugs, não é reproduzível e muitas vezes nem sequer executa um ano depois.
Excesso de engenharia, “melhores práticas” e complexidade
- Crítica forte a:
- Abstração excessiva (herança profunda, sistemas de plugins, muitos arquivos pequenos, camadas de indireção).
- Design guiado por padrões (“Clean Code” levado ao pé da letra, microfunções, grafos de módulos espalhados).
- Java empresarial / OOP pesada como fontes históricas de complexidade desnecessária.
- Visão contrária: esses são abusos de melhores práticas, não as práticas em si; boa engenharia busca o design mais simples que suporte mudanças de longo prazo.
Patologias em código científico
- Problemas recorrentes: sem testes, sem controle de versão, caminhos e dados codificados, passos de build não documentados, uso inadequado de hardware (por exemplo, carregar todos os dados na RAM).
- A reprodutibilidade é amplamente vista como ruim; alguns dizem que isso está por trás da crise de replicação.
- Outros observam que as expectativas são diferentes: historicamente, a academia aceitava esforços “manuais” de reprodutibilidade, e não reexecuções com um clique.
Exemplo do modelo de COVID do Imperial College
- Vários posts usam isso como um conto de advertência: código científico grande e de longa duração com bugs graves (não determinismo, problemas de memória, design frágil) teria produzido resultados enganosos relevantes para políticas públicas.
- Isso é citado como evidência de que pesquisa “rápida e suja” pode ser perigosa quando reaproveitada para decisões do mundo real.
Colaboração e funções
- Muitos defendem “engenheiros de software de pesquisa” dedicados, fazendo a ponte entre expertise de domínio e disciplina de engenharia.
- Emparelhar especialistas de domínio com desenvolvedores focados em manutenibilidade é visto como ideal, mas subfinanciado; os incentivos na academia priorizam artigos em vez de software robusto.