Qual é o maior Bad Code que você já viu até agora?

 (news.ycombinator.com)
21 pontos por xguru 2020-09-21 | 8 comentários | Compartilhar no WhatsApp

"O código de 25 milhões de linhas do Oracle Database 12.2"

Resposta deixada por um ex-funcionário da Oracle em uma pergunta que apareceu no HN

"É um horror inimaginável. É impossível escrever sequer uma linha de código sem passar por 1.000 testes existentes.

Existem macros misteriosas que você não consegue entender sem anotar tudo à mão em um caderno, e leva de um a dois dias para realmente compreender como essas macros funcionam.

Às vezes, é preciso entender os valores e os efeitos de 20 flags para prever como o código vai se comportar em situações diferentes.

Às vezes passam de 100. Sem exagero.

A única razão de esse produto ainda sobreviver e funcionar é, literalmente, por causa de milhões de testes."

A vida de um desenvolvedor de Oracle DB

  1. Começar a trabalhar em um novo bug

  2. Gastar 2 semanas para entender 20 flags diferentes que interagem entre si de formas misteriosas e causam esse bug

  3. Adicionar mais uma flag para lidar com um novo cenário especial. Escrever mais algumas linhas para verificar essa flag e mais algumas linhas para resolver a situação problemática e evitar o bug

  4. Submeter a alteração de código para uma fazenda de testes com 100 a 200 máquinas. Então ela compila um novo Oracle DB e executa milhões de testes de forma distribuída

  5. Ir para casa. Voltar no dia seguinte e começar outro trabalho. Os testes levam de 20 a 30 horas para terminar

  6. Ir para casa. Voltar no dia seguinte e verificar os resultados dos testes. Em um dia bom, uns 100 testes falham. Em um dia ruim, falham uns 1.000. Escolher alguns desses testes e investigar quais suposições estavam erradas. Provavelmente ainda existem umas 10 flags a mais que precisam ser consideradas para entender a natureza do bug

  7. Adicionar mais algumas flags para resolver esse problema. Submeter de novo para a fazenda de testes. Esperar mais 20 a 30 horas de novo

  8. Passar 2 semanas ajustando e repetindo até que essas combinações de flags funcionem direito

  9. Finalmente, em "algum belo dia", todos os testes deixam de falhar

  10. Adicionar mais de 100 testes sobre a alteração que eu fiz, para que o próximo desenvolvedor azarado não quebre essa correção

  11. Submeter de novo para o teste final. E então submeter para revisão. A revisão pode levar de 2 semanas a 2 meses, então é hora de mudar para outro bug e começar a trabalhar nele

  12. De 2 semanas a 2 meses depois, quando tudo termina, o código é mergeado na branch principal

Essa é a vida de um programador da Oracle corrigindo bugs. Sem exagero.

Agora imagine que tipo de horror deve ser desenvolver uma funcionalidade nova.

Desenvolver uma funcionalidade pequena leva de 6 meses a 1 ano, e às vezes até 2 anos. (Como adicionar um novo método de autenticação, como autenticação via Active Directory)

É um milagre que esse produto funcione.

Eu não trabalho mais na Oracle e nunca mais vou trabalhar na Oracle

Leituras relacionadas

8 comentários

 
neocoin 2020-09-28

O maior "Bad Code" que vocês já viram até agora é qual?

O ciclo de testes é

  1. Write Code

  2. Write Test

  3. Refactor Code, go to 1

Mas, como 1 e 2 acabam levando tempo demais, o resultado acumulado é que o passo 3 continua sendo constantemente omitido.
 
kunggom 2020-09-21

Qual foi o maior exemplo de bad code que vocês já viram até hoje?

Vale a pena rever a palestra do Martin Fowler neste ponto. Parece que o Oracle Database não tem uma boa "qualidade interna" (Internal Quality).

https://pt.news.hada.io/topic?id=2752
 
kbumsik 2020-09-21

Bem, do ponto de vista da Oracle, isso parece algo natural e, na verdade, chega a passar confiança a ponto de fazer pensar: realmente, esse software é mesmo para uso enterprise...

Mas, como no texto, eu não gostaria de trabalhar lá.
 
exitmusic 2020-09-21

Eu, na verdade, chego a pensar se não foi a própria cultura de desenvolvimento centrada em testes que acabou arruinando o processo de desenvolvimento.

O desenvolvimento acaba sendo feito na base do "não importa como, desde que passe nos testes"... provavelmente, num ambiente desses, nem dá para sonhar com refatoração.
 
sduck4 2020-09-22

Em vez de o problema ser os testes, a questão maior não seria um problema de arquitetura que faz com que seja preciso considerar de 20 a 100 flags para modificar/adicionar funcionalidades?

Acho que, por causa da complexidade do DBMS, talvez seja inevitável.
 
kunggom 2020-09-21

No fim, testes também são código escrito por desenvolvedores. Aproveitando que pensei nisso, apresentei um texto sobre testes.

https://pt.news.hada.io/topic?id=2883
 
ffdd270 2020-09-21

Se o projeto não estiver nesse nível, os testes conseguem garantir continuamente que, mesmo mexendo na interface, tudo continue como antes, então acho que isso até dá mais coragem para refatorar. Recentemente, no emulador que estou fazendo, tive que mudar os parâmetros de valores BYTE para valores de Enum. O build passou, mas os testes falharam, e pensei: o que eu teria feito sem testes? Foi um daqueles momentos de puro susto.

Com uma base de código desse tamanho, mesmo que se pense em refatorar... ela é tão gigantesca que acaba dando vontade de desistir, e mais código vai sendo empilhado por cima... Suspeito, com certa cautela, que talvez tenham caído nesse tipo de loop infinito.
 
xguru 2020-09-21

Entendo que aquela pessoa tenha passado por dificuldades,

mas, ironicamente, é um texto que faz pensar: "os testes são realmente importantes nesse nível", então resolvi traduzi-lo.

A postagem original desta resposta recebeu, ao todo, 578 respostas.

Ask HN: What's the largest amount of bad code you have ever seen work?

https://news.ycombinator.com/item?id=18442637

Só de ver as respostas de primeiro nível já é divertido. Dá a sensação de que, no fim, a vida de todo mundo é parecida...