¿Cuál es el código malo más grande que han visto hasta ahora?

"El código de Oracle Database 12.2 con 25 millones de líneas"

Una respuesta que dejó un ex empleado de Oracle en una pregunta que apareció en HN

"Es un horror inimaginable. Es imposible escribir aunque sea una sola línea de código sin pasar 1000 pruebas existentes.

Hay macros misteriosas que no se pueden entender si no las vas resolviendo a mano en una libreta, y realmente toma entre uno y dos días entender cómo funcionan.

A veces, para predecir cómo va a comportarse el código en distintas situaciones, tienes que entender el valor y el efecto de 20 banderas diferentes.

A veces incluso son más de 100.

No es exageración.

La única razón por la que este producto sigue vivo y funcionando es, literalmente, por los millones de pruebas que tiene."

La vida de un desarrollador de Oracle DB

1. Empezar a trabajar en un bug nuevo

2. Pasar dos semanas entendiendo 20 banderas distintas que interactúan de forma misteriosa y que provocan este bug

3. Agregar una bandera más para manejar un nuevo escenario especial. Escribir unas cuantas líneas más para revisar esa bandera, y otras cuantas para resolver la situación problemática y evitar el bug

4. Enviar el cambio de código a una granja de pruebas compuesta por 100 a 200 máquinas. Entonces se construye una nueva Oracle DB y se ejecutan de forma distribuida millones de pruebas

5. Irse a casa. Volver al día siguiente y empezar otra tarea. Las pruebas tardan entre 20 y 30 horas en completarse

6. Irse a casa. Volver al día siguiente y revisar los resultados. En un buen día, fallan como 100 pruebas. En un mal día, fallan como 1000. Elegir algunas de esas pruebas para averiguar qué estaba mal en mis suposiciones. Probablemente haya unas 10 banderas más que también hay que considerar para entender la verdadera naturaleza del bug

7. Agregar algunas banderas más para resolver este problema. Volver a enviar los cambios a la granja de pruebas. Esperar de nuevo entre 20 y 30 horas

8. Repetir este proceso durante dos semanas hasta lograr que esas combinaciones de banderas funcionen bien

9. Finalmente, en "algún buen día", todas las pruebas dejan de fallar

10. Agregar más de cien pruebas sobre el cambio que hice, para que el siguiente desarrollador con mala suerte no rompa esta corrección

11. Enviar otra vez para la prueba final. Y luego enviar para revisión. La revisión puede tardar de nuevo entre dos semanas y dos meses, así que pasar a trabajar en otro bug

12. Después de entre dos semanas y dos meses, cuando todo termina, el código se fusiona en la rama principal

Así es la vida de un programador de Oracle que corrige bugs. Sin exagerar.

Ahora imaginen qué clase de horror debe ser desarrollar una función nueva.

Desarrollar una sola función pequeña toma entre 6 meses y 1 año, y a veces hasta 2 años. (Como agregar una nueva autenticación, por ejemplo autenticación con Active Directory)

Que este producto funcione es un milagro.

Ya no trabajo en Oracle, y no volveré a trabajar en Oracle nunca más

[neocoin]

Lo más grande entre el mal código que han visto hasta ahora

El ciclo de pruebas es

1. Write Code

2. Write Test

3. Refactor Code, go to 1

Pero como 1 y 2 toman demasiado tiempo, al final el resultado es que el paso 3 se sigue omitiendo.

[kunggom]

Volviendo a ver en este momento la charla de Martin Fowler. Parece que Oracle Database no tiene una buena “calidad interna” (Internal Quality).

https://es.news.hada.io/topic?id=2752

[kbumsik]

Bueno, desde la perspectiva de Oracle, de algún modo parece algo natural, e incluso da la impresión de que ese software realmente es para uso empresarial... hasta inspira confianza.

Pero, como dice ese texto, yo no querría trabajar ahí.

[exitmusic]

Más bien, me da la impresión de que la cultura de desarrollo centrada en las pruebas quizá terminó arruinando el proceso de desarrollo.

Se desarrolla con la idea de que, no importa cómo se haga, mientras pasen las pruebas está bien... probablemente en un entorno así ni soñar con hacer refactoring.

[sduck4]

Más que un problema de pruebas, ¿no será un problema de diseño haberlo hecho de forma que, para modificar o agregar funciones, haya que considerar entre 20 y 100 flags?

Aunque supongo que, por la complejidad del DBMS, probablemente no se podía evitar.

[kunggom]

Al final, las pruebas también son código que escriben los desarrolladores. Ya que salió el tema, compartí un artículo sobre testing que me vino a la mente.

https://es.news.hada.io/topic?id=2883

[ffdd270]

Si el proyecto no fuera de ese nivel, las pruebas podrían seguir garantizando de forma continua que, aunque se rehaga por completo la interfaz, todo siga funcionando como antes, y eso más bien daría confianza para refactorizar. Hace poco, en un emulador que estoy creando, tuve que cambiar parámetros de valores BYTE a valores de enum. El build pasaba, pero las pruebas fallaban, así que pensé: ¿qué habría hecho si no hubiera tenido pruebas? La verdad, me pegué un buen susto.

Con una base de código de ese tamaño, aunque uno se plantee refactorizar, termina rindiéndose porque es demasiado enorme, y se le sigue montando más código encima... Supongo con cautela que quizá cayeron en ese tipo de bucle infinito.

[xguru]

Entiendo que esa persona la haya pasado mal,

pero, paradójicamente, es un texto que te hace pensar: "así de importantes son las pruebas", así que lo traduje.

La publicación original de esta respuesta recibió un total de 578 respuestas.

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

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

Incluso leyendo solo las respuestas de primer nivel ya es entretenido. Me hace pensar que, al final, la gente vive lo mismo en todas partes...