Dívida técnica: minha biblioteca Rust agora virou um CDO

Dívida técnica: minha biblioteca Rust agora virou um CDO

• Como uma piada sobre dívida técnica, existe a brincadeira de que, se há dívida técnica, então também deveria haver derivativos para lidar com essa dívida.
• O ecossistema Rust acabou criando uma solução que parece securitizar a dívida técnica.
• Por exemplo, uma biblioteca stuff depende de outra biblioteca learned-rust-this-way, mas o autor de learned-rust-this-way perdeu o interesse e os problemas começaram a se acumular.

A realidade da dívida técnica

• learned-rust-this-way é considerada dívida técnica, o que não causa um problema direto, mas ainda assim continua sendo uma dívida.
• Em algum momento, alguém percebe que learned-rust-this-way é uma dívida, não consegue entrar em contato com o autor original, e ela é adicionada ao banco de dados RUSTSEC.
• O RUSTSEC, como agência de classificação, avalia essa dívida como lixo, e por causa disso o CI (integração contínua) de muita gente começa a falhar.

Como resolver a dívida

• Como mantenedor de stuff, o estresse aumenta quando os usuários começam a reclamar do uso de learned-rust-this-way, e passam a exigir alguma ação para lidar com a dívida.
• Migrar para uma alternativa é uma opção, mas, neste caso, todas as alternativas são pouco atraentes.
• Fazer um fork de learned-rust-this-way leva ao mesmo tipo de exigência, sendo apenas uma solução temporária, sem realmente resolver o problema.

A solução que realmente funciona

• Se você incorporar esse código à sua própria biblioteca, aquele lixo de dívida técnica de repente passa a ser avaliado como “AAA”.
• Você não mexe mais no código, esconde o fato de que ele foi incorporado, e continua mantendo a biblioteca como antes, enquanto o mundo segue girando.
• Ao vendorizar e incorporar yaml-rust em insta, ele passou a ser uma fusão do código de insta com yaml-rust, e assim a dívida técnica foi promovida à classificação AAA.

A opinião do GN⁺

• Este artigo compara a dívida técnica a derivativos financeiros para explicar, de forma espirituosa, problemas que surgem no desenvolvimento de software.
• Dívida técnica é um problema comum no desenvolvimento de software, e o artigo apresenta aos desenvolvedores uma forma criativa de lidar com ela.
• Sistemas de avaliação como o RUSTSEC no ecossistema Rust podem ajudar desenvolvedores a avaliar a estabilidade de bibliotecas, mas ao mesmo tempo também podem gerar estresse desnecessário.
• Incorporar código como forma de resolver dívida técnica pode ser uma solução temporária; no longo prazo, é necessária uma estratégia de manutenção sustentável.
• Em situações assim, vale considerar várias alternativas, como manutenção guiada pela comunidade, co-manutenção de projetos open source, ou buscar versões alternativas da biblioteca.

[GN⁺]

Comentários do Hacker News

• O autor do parser YAML mais popular abandonou repentinamente o projeto, marcando-o como obsoleto (deprecated) e sem manutenção (unmaintained). Isso foi feito sem aviso ou indicação de outro mantenedor; o pacote ainda funciona, mas é usado por mais de 4.000 outros crates, então ferramentas de auditoria e atualização automática passarão a alertar sobre o uso de crates sem manutenção.
• Para quem ficou confuso com a sigla CDO, a suposição é que significa collateralized debt obligation, já que a palavra collateralized foi usada várias vezes.
• Se um caminho vulnerável do código não pode ser executado nem acessado por bibliotecas externas, então ele se torna um caminho de código seguro. Fazer vendoring de uma biblioteca fornece as ferramentas para atacar o código e, se você tiver cobertura de testes suficiente para sua própria biblioteca, poderá executar ferramentas de cobertura de código também na biblioteca incorporada. Modificar a biblioteca incorporada pode ser desafiador, mas remover as partes de que você não precisa pode ser relativamente fácil. Claro, isso depende da estrutura da biblioteca incorporada.
• Um ex-analista quantitativo e atual economista elogia o autor por usar corretamente o termo Collateralized Debt Obligation. Ele gostaria de escrever um artigo sobre “dívida técnica”, porque acha que a metáfora de “dívida” não se encaixa bem nesse conceito. “Código de alta viscosidade” talvez seja uma expressão melhor. Parece ter alta indutância, já que o código não pode ser facilmente alterado para se adaptar a novos recursos.
• Sobre a ideia de que uma junk tech debt de repente recebe nota AAA, o autor parece querer dizer que o mesmo código não pode ter uma classificação melhor de dívida antes e depois do vendoring. Mas isso olha apenas para o valor do código em si e perde a parte mais importante da proposta de valor geral. O mantenedor que faz vendoring do código agora passa a possuí-lo, e um mantenedor ativo que incorpora código de um projeto morto aumenta o valor desse código porque existe um humano que pode responder a issues, revisar pull requests e corrigir bugs.
• O mesmo padrão já foi visto no ecossistema JS npm. O npm audit em geral faz alertas exagerados sobre problemas de segurança e, desde que a licença permita, o vendoring é uma das formas mais confiáveis de se livrar dos problemas absurdos que vêm dos usuários.
• Foi uma sorte alguém ter feito um fork do yaml-rust e reescrito em Rust puro para criar o yaml-rust2. Esse fork passa completamente pela suíte de testes do YAML e também apresenta melhor desempenho nos benchmarks. A migração também parece simples. No fim, o problema continua o mesmo: ainda dependemos de outras pessoas que hoje trabalham de graça, sem qualquer garantia de que continuarão fazendo isso para sempre.
• Se um gerenciador de pacotes baseado em código-fonte não impuser que o registro tenha o direito legal de assumir à força a manutenção de pacotes publicados, ele enfrentará problemas assustadores: abandono, mudanças maliciosas, remoção maliciosa, falsificação de identidade etc. Para pacotes considerados importantes o suficiente pela comunidade, é preciso haver uma forma de tirar a entrada do registro das mãos do proprietário original e substituí-la por um fork.
• Se o código funciona e funciona há anos, por que importaria o fato de não ter manutenção? Se ele não precisa ser corrigido e você conhece seus limites e capacidades, então não há problema. O código não piora sozinho. Durante décadas não houve problema algum em pegar emprestado ou integrar código várias vezes.
• Fazer vendoring das dependências é a solução. Isso foi feito ao longo de 20 anos para quase todas as dependências “concluídas” cujo desenvolvimento e manutenção desaceleraram.