Nesta semana, os usuários do Hacker News
decidiram discutir a questão "Qual é a quantidade máxima de códigos ruins - mas ainda funcionando - que você já viu?" (
usuários posteriores do
Reddit se juntaram a eles). Nos comentários, muitas histórias "engraçadas" foram contadas sobre coisas que encontramos de tempos em tempos; mas a história sobre o código "DBMS avançado usado pela maioria das empresas da Fortune 100" atraiu mais atenção.
O vencedor da indicação Lovecraft Horror foi merecidamente a
história de um ex-desenvolvedor Oracle que trabalhou no Oracle Database durante o desenvolvimento da versão 12.2. A base de código do DBMS na época era de 25 milhões de linhas em C - e assim que você alterou apenas uma dessas linhas,
milhares de testes escritos anteriormente foram interrompidos.
Ao longo dos anos, várias gerações de programadores trabalharam no código, que eram regularmente perseguidos por prazos difíceis - e, graças a isso, o código pode se transformar em um verdadeiro pesadelo. Hoje, ele consiste em "partes" complexas de código responsáveis pela lógica, gerenciamento de memória, alternância de contexto e muito mais; eles estão conectados entre si usando
milhares de sinalizadores diferentes. Todo o código é interconectado por uma macro misteriosa que não pode ser descriptografada sem o recurso a um bloco de anotações, no qual é necessário anotar o que as partes relevantes da macro fazem. Como resultado, um desenvolvedor pode levar um dia ou dois apenas para descobrir o que a macro realmente faz.
Para prever o comportamento do código em um ou outro caso, você precisa entender e lembrar quais valores e consequências 20 (ou até cem) sinalizadores podem ter. A situação é agravada pelo fato de vários desenvolvedores usarem seus próprios tipos, que eram essencialmente a mesma coisa (por exemplo, int32) - e quase ninguém ousaria tocar em um legado (podemos dizer com certeza que esse foi o caso em Base de código do Oracle 8i).
Surge a pergunta: como, com tudo isso, o Oracle Database ainda é capaz de se manter de pé? O segredo está em milhões de testes. Sua implementação completa pode levar de 20 a 30 horas (ao mesmo tempo em que são executadas distribuídas em um cluster de teste de 100 a 200 servidores).
A equipe que trabalhou no produto no final dos anos 90 e aderiu às idéias do TDD (desenvolvimento orientado a testes), tinha a seguinte opinião: “testes automatizados significam que você não precisa escrever um código que possa ser entendido; em vez disso, você deve pense em testes ". No futuro, os desenvolvedores foram forçados a aderir aos princípios estabelecidos por eles, e agora estamos testemunhando na prática o que essa ideia se transformou a longo prazo - com todas as suas vantagens e desvantagens.
Hoje, o processo de correção de um novo bug no Oracle Database leva de várias semanas a vários meses. No início, o desenvolvedor precisa passar vários dias apenas classificando os sinalizadores de que precisa (cuja interação misteriosa causa um bug), após o qual muitas vezes precisa adicionar seu próprio sinalizador, que será responsável por processar o script específico que causou o bug.
Em seguida, ele envia o código para teste e, no dia seguinte, ele alterna calmamente para outra tarefa, aguardando o cluster de teste montar um novo assembly do Oracle DB e executar todos os testes nele. Se o desenvolvedor tiver sorte, cerca de 100 testes irão "corar"; se não (e essa opção acontece com mais frequência) - cerca de 1000, e ele terá que verificar quais de suas suposições sobre a operação do código existente se mostraram incorretas; é bem possível que ele descubra que precisa estudar uma dúzia de sinalizadores diferentes, que de maneira não óbvia participaram do trabalho do código que ele alterou.
Ele terá que repetir esse processo por algumas semanas antes que a sorte finalmente sorria para ele e todos os testes sejam aprovados. Depois disso, ele terá que escrever várias dezenas de testes - para garantir que o desenvolvedor, que irá perturbar seu código no futuro, não interrompa sua “correção”. Em seguida, as melhorias serão enviadas para uma revisão, que pode levar de várias semanas a alguns meses, após o que o bug será finalmente mesclado no ramo de trabalho principal.
Devido ao fato de levar pelo menos um dia para criar o DBMS e executar os testes, espera-se que cada desenvolvedor trabalhe simultaneamente em 2 a 3 erros e alterne entre eles enquanto aguarda os resultados do teste.
Se você pensou que a vida dos desenvolvedores que adicionam novas funcionalidades ao DBMS é mais fácil, você é em vão. Adicionar até um novo recurso pequeno como um novo modo de autenticação pode levar de 6 meses a um ano, em casos especialmente avançados - até dois anos.
No caso descrito, o TDD permite não esfarelar o código "spaghetti", no qual já é extremamente difícil entender alguma coisa, e ter um produto em funcionamento na saída. Ao mesmo tempo, os custos continuam a crescer e a qualidade do novo código geralmente deixa muito a desejar. Não apenas uma equipe de desenvolvedores dos EUA, mas também uma equipe da Índia está trabalhando no DBMS; portanto, alguns desenvolvedores da Oracle, de acordo com a tradição estabelecida, culpam a qualidade do código. Outros discordam deles e, com base no changelog, dizem que a qualidade do código não depende da geografia da equipe, e que o código incorreto "voa" periodicamente das duas equipes. Um problema realmente sério para o produto são os desenvolvedores que percebem o projeto como "entrando no setor" e trabalham no DBMS há mais de um ou dois anos; durante esse período, é impossível entender significativamente os meandros do projeto.
De acordo com o testemunho de outro desenvolvedor que estava portando a base de código do Oracle 8i para uma das versões do Unix no final dos anos 90, o código já naquela época era uma bola de espaguete que era completamente impossível de entender completamente. Outro desenvolvedor que trabalhou com o código DBMS no final dos anos 80 afirma que a base de código era um monte de fontes C e um conjunto de makefiles para montagem - muitos dos quais eram muito mais complicados do que o próprio código do kernel. Certamente, vale a pena ser realista - dificilmente a situação é melhor em produtos similares, líderes do setor, cujo desenvolvimento é realizado há várias décadas.