Software de sangue frio
- Em 2004, o autor, formado em ciência da computação, assistia a uma aula de história natural quando o professor mostrou um filhote de tartaruga-pintada congelado.
- Essa tartaruga é uma das poucas espécies que conseguem sobreviver mesmo congeladas, um animal de sangue frio capaz de regular seu metabolismo em baixas temperaturas.
- Ao observar durante a aula a tartaruga se mover lentamente e recuperar a vida, ele aprofundou sua compreensão sobre animais de sangue frio.
A dicotomia dos projetos de software
- Projetos de software também podem ser divididos em projetos de sangue quente e de sangue frio.
- Projetos de sangue quente exigem atividade contínua, e quando essa atividade para, surgem problemas.
- Projetos de sangue frio podem passar por longos períodos de inatividade e, quando retomados, continuar imediatamente de onde pararam.
O software de sangue frio do blog
- O software que roda o blog do autor é um software de sangue frio.
- Iniciado há 12 anos, esse projeto é simples, não depende de serviços externos e inclui todas as dependências no repositório do projeto.
- Tirando algumas pequenas melhorias, ele funciona bem sem modificações e a expectativa é que continue funcionando pelos próximos 12 anos.
Opinião do GN⁺
- O conceito de software de sangue frio tem impacto importante na sustentabilidade e na manutenibilidade dos projetos.
- Este texto oferece insights sobre como a escolha da stack tecnológica afeta a longevidade de um projeto.
- A experiência do autor traz lições para desenvolvedores de software sobre como construir sistemas estáveis no longo prazo.
1 comentários
Discussão no Hacker News
No ecossistema de Node e JavaScript existe o framework web Express. O branch principal atual, 4.x.x, tem mais de 10 anos e é baixado mais de 17 milhões de vezes por semana. Faltam alguns recursos e o desempenho não é o melhor, mas muitos desenvolvedores o preferem porque permite desenvolvimento rápido e estável, além de possibilitar planejamento de longo prazo sem preocupação com mudanças de API ou falta de patches de segurança. A linguagem Go oferece uma estabilidade ainda melhor graças à sua ampla biblioteca padrão e à promessa de compatibilidade, permitindo executar programas com mais de 10 anos.
Quando um software funciona bem sem atualizações, normalmente é porque foi bem feito desde o início. Softwares de uso pessoal são relativamente mais fáceis, porque as preferências não mudam tanto. Porém, ao escrever software para outras pessoas usarem, os requisitos podem ser diferentes e problemas inesperados podem surgir. Por exemplo, ele pode travar ao processar arquivos grandes, e corrigir isso pode exigir reescrever metade do software. Esse é o maior contra-argumento à ideia de que software que não muda com frequência é necessariamente melhor.
Python é um exemplo ruim por causa das mudanças contínuas que quebram compatibilidade. Em contraste, Go e Java conseguem fazer código de 10 anos atrás funcionar bem com ferramentas modernas. Perl é um exemplo ainda melhor: até código de 30 anos continua funcionando bem.
Trabalho com mainframes IBM (z/OS). A IBM é a melhor em manter compatibilidade retroativa. A Microsoft (Windows) vem em segundo, e a ABI do Linux (kernel) em terceiro. Na maioria dos outros sistemas, esse problema é comum em OSS que não quer gastar tempo mantendo compatibilidade.
Dependências podem deixar um app de "sangue quente", mas Docker ou conteinerização podem resolver isso em certa medida. Ao escolher bibliotecas para um projeto, faço bastante pesquisa para verificar se são bibliotecas de "sangue frio".
Muitos engenheiros, ao procurar bibliotecas no GitHub, verificam a data do último commit. Acham que quanto mais recente o commit, melhor o suporte. Porém, encontrar um projeto arquivado que se manteve estável por muito tempo e sem bugs é como achar uma joia escondida num brechó.
Faço manutenção do meu próprio projeto paralelo. Comecei há 12–13 anos e o reescrevi com PHP, Laravel e Symfony. Foi muito valioso para aprender a manter um projeto no longo prazo. Por exemplo, procuro oportunidades para simplificar, como migrar de Vagrant para Docker e de Vue + Axios + Webpack para Htmx. Recentemente, fiz upgrade para PHP 8.2 e Symfony 7 e integrei recursos baseados em ChatGPT.
Estou cansado de como os apps móveis dos últimos anos exigem algumas horas de trabalho com patches. O autor descreve seu gerador de site estático como de "sangue frio"; ele roda em Python 2, mas está ficando cada vez mais difícil instalar Python 2.
Um SDK que escrevi em 1994–95 continuou sendo usado até eu sair da empresa em 2017. Foi escrito em ANSI C, e algo que escrevi em PHP (5) também funciona bem no PHP 8.2. Mas essas coisas são entediantes e têm pouco apelo midiático.
Além do que foi mencionado no artigo, também é importante ter um modelo de ameaças intrinsecamente seguro. Por exemplo, um site completo precisa lidar continuamente com atacantes, bots de spam etc., então é intrinsecamente de "sangue quente". Já páginas estáticas como Tiddlywiki são muito melhores, porque não precisam ser colocadas na web e o navegador é uma plataforma muito estável.