Quel est le plus gros morceau de bad code que vous ayez jamais vu ?

"Les 25 millions de lignes de code d’Oracle Database 12.2."

Réponse laissée par un ancien employé d’Oracle à une question publiée sur HN.

"C’est une horreur inimaginable. Impossible d’écrire la moindre ligne de code sans faire passer 1 000 tests existants.

Il y a des macros mystérieuses qu’on ne peut comprendre qu’en les décortiquant à la main sur un carnet, et il faut un à deux jours pour réellement comprendre ce qu’une macro fait.

Parfois, il faut comprendre la valeur et l’effet de 20 flags différents pour prévoir comment le code va se comporter selon les situations.

Et parfois, il y en a plus de 100. Sans exagération.

La seule raison pour laquelle ce produit existe encore et fonctionne toujours, c’est littéralement grâce à des millions de tests."

La vie d’un développeur Oracle DB

1. Commencer à travailler sur un nouveau bug

2. Passer 2 semaines à comprendre 20 flags différents qui interagissent entre eux d’une manière mystérieuse et provoquent ce bug

3. Ajouter un flag de plus pour gérer un nouveau scénario particulier. Écrire quelques lignes de code pour vérifier ce flag, puis quelques lignes supplémentaires pour résoudre le cas problématique et éviter le bug

4. Soumettre la modification de code à une ferme de test composée de 100 à 200 machines. Cela lance un build du nouvel Oracle DB et l’exécution distribuée de millions de tests

5. Rentrer chez soi. Revenir le lendemain et commencer à travailler sur autre chose. Les tests mettent 20 à 30 heures à se terminer

6. Rentrer chez soi. Revenir le lendemain et vérifier les résultats des tests. Un bon jour, il y a environ 100 tests en échec. Un mauvais jour, environ 1 000. En examiner quelques-uns pour comprendre quelles hypothèses étaient fausses. Il y aura probablement encore une dizaine de flags à prendre en compte pour comprendre la vraie nature du bug

7. Ajouter encore quelques flags pour résoudre ce problème. Soumettre à nouveau les modifications à la ferme de test. Attendre encore 20 à 30 heures

8. Répéter et corriger pendant 2 semaines jusqu’à ce que ces combinaisons de flags fonctionnent correctement

9. Enfin, "un beau jour", plus aucun test n’échoue

10. Ajouter plus d’une centaine de tests pour la modification que j’ai faite, afin que le prochain développeur malchanceux ne puisse pas casser ce correctif

11. Soumettre à nouveau pour les tests finaux, puis pour la review. Comme la review peut encore prendre de 2 semaines à 2 mois, passer à un autre bug et commencer à travailler dessus

12. Au bout de 2 semaines à 2 mois, quand tout est enfin terminé, le code est merge dans la branche principale

Voilà la vie d’un programmeur Oracle qui corrige des bugs. Sans exagération.

Imaginez maintenant à quoi peut ressembler l’horreur quand il faut développer une nouvelle fonctionnalité.

Développer une petite fonctionnalité prend entre 6 mois et 1 an, et parfois jusqu’à 2 ans. (Par exemple, ajouter une nouvelle méthode d’authentification comme l’authentification Active Directory.)

Le simple fait que ce produit fonctionne tient du miracle.

Je ne travaille plus chez Oracle, et je n’y retravaillerai jamais

[neocoin]

Quel est le pire bad code que vous ayez vu jusqu’à présent ?

Le cycle de test, c’est :

1. Write Code

2. Write Test

3. Refactor Code, revenir à 1

Mais comme les étapes 1 et 2 prennent trop de temps, le résultat cumulé est que l’étape 3 continue d’être omise.

[kunggom]

La conférence de Martin Fowler qu’il vaut la peine de revoir à ce stade. Il semblerait qu’Oracle Database n’ait pas une très bonne « qualité interne » (Internal Quality).

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

[kbumsik]

Bon, du point de vue d’Oracle, ça semble presque naturel, et ça donne même confiance en se disant que ce logiciel est décidément bien conçu pour l’entreprise...

Mais comme dans ce billet, je n’aurais pas envie d’y travailler.

[exitmusic]

Je me demande au contraire si la culture du développement centrée sur les tests n’a pas fini par casser le processus de développement.

Le développement se fait dans l’idée que peu importe la manière, du moment que les tests passent… Dans un tel environnement, il serait sans doute même impensable de faire du refactoring.

[sduck4]

Plutôt qu’un problème de tests, le vrai problème n’est-il pas davantage une conception qui vous oblige à prendre en compte 20 à 100 flags pour modifier ou ajouter une fonctionnalité ?

J’imagine qu’on ne peut pas vraiment faire autrement à cause de la complexité du SGBD, cela dit.

[kunggom]

Puisque même les tests restent au final du code écrit par des développeurs. Ça m’y a fait penser, alors j’ai partagé un article sur les tests.

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

[ffdd270]

À moins que le projet ne soit pas à ce point-là, les tests peuvent au contraire donner le courage de refactorer, puisqu’ils peuvent garantir en continu que même si on remanie complètement l’interface, le comportement reste le même qu’avant. J’ai récemment modifié, dans l’émulateur que je développe en ce moment, des paramètres en remplaçant des valeurs BYTE par des valeurs d’énumération. La compilation a réussi, mais les tests ont échoué, et je me suis dit : sans tests, qu’est-ce que j’aurais fait ? Ça m’a franchement fait peur sur le moment.

Avec une base de code de cette taille, même si on envisage un refactoring, c’est tellement énorme qu’on finit par abandonner, puis on empile encore plus de code… Je suppose prudemment que c’est peut-être ce genre de boucle sans fin dans laquelle ils sont tombés.

[xguru]

Je comprends aussi que cette personne ait eu du mal,

mais paradoxalement, c’est un texte qui fait se dire à quel point « les tests sont importants », donc je l’ai traduit.

La question d’origine à laquelle cette réponse est rattachée a reçu au total 578 réponses.

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

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

Rien qu’en lisant les réponses de premier niveau, c’est déjà amusant. On se dit que, partout, les gens se ressemblent au fond...