Cette semaine, les utilisateurs de Hacker News ont
décidé de discuter de la question "Quelle est la quantité maximale de mauvais code - mais qui fonctionne toujours - que vous avez vue?" (plus tard,
les utilisateurs de Reddit les ont rejoints ). Dans les commentaires, beaucoup d'histoires «drôles» ont été racontées sur des choses que nous rencontrons de temps en temps; mais l'histoire du code «SGBD avancé utilisé par la plupart des sociétés du Fortune 100» a retenu le plus l'attention.
Le gagnant de la nomination Lovecraft Horror était à juste titre l'
histoire d'un ancien développeur Oracle qui a travaillé sur Oracle Database pendant le développement de la version 12.2. La base de code du SGBD à cette époque était de 25 millions de lignes en C - et dès que vous n'avez modifié qu'une seule de ces lignes, des
milliers de tests écrits plus tôt se sont rompus.
Au fil des ans, plusieurs générations de programmeurs ont travaillé sur le code, qui ont été régulièrement pourchassés par des délais stricts - et grâce à cela, le code pourrait se transformer en un véritable cauchemar. Aujourd'hui, il se compose de «morceaux» de code complexes qui sont responsables de la logique, de la gestion de la mémoire, du changement de contexte et bien plus encore; ils sont connectés les uns aux autres à l'aide de
milliers de drapeaux différents. Tout le code est interconnecté par une mystérieuse macro qui ne peut pas être déchiffrée sans recourir à un ordinateur portable, dans lequel vous devez écrire ce que font les parties pertinentes de la macro. En conséquence, un développeur peut prendre un jour ou deux juste pour comprendre ce que fait réellement la macro.
Afin de prédire le comportement du code dans l'un ou l'autre cas, vous devez comprendre et vous rappeler quelles valeurs et conséquences 20 (voire une centaine) drapeaux peuvent avoir. La situation est aggravée par le fait que divers développeurs ont utilisé leurs propres types, qui étaient essentiellement la même chose (par exemple, int32) - et presque personne ne risquerait de toucher à un tel héritage (on peut dire avec certitude que c'était le cas dans Base de code Oracle 8i).
La question se pose: comment, avec tout cela, Oracle Database est-il toujours capable de rester debout? Le secret réside dans des millions de tests. Leur implémentation complète peut prendre de 20 à 30 heures (en même temps, elles sont effectuées réparties sur un cluster de test de 100 à 200 serveurs).
L'équipe qui a travaillé sur le produit à la fin des années 90 et a adhéré aux idées du TDD (développement piloté par les tests), avait l'opinion suivante: «les tests automatisés signifient que vous n'êtes pas obligé d'écrire du code qui peut être compris - à la place, vous devriez pensez aux tests. " À l'avenir, les développeurs ont été contraints d'adhérer aux principes qu'ils ont posés, et maintenant nous assistons dans la pratique à ce que cette idée s'est transformée à long terme - avec tous ses avantages et inconvénients.
Aujourd'hui, le processus de correction d'un nouveau bogue dans Oracle Database prend de plusieurs semaines à plusieurs mois. Dans un premier temps, le développeur ne doit passer plusieurs jours que pour déterminer les indicateurs dont il a besoin (dont la mystérieuse interaction provoque un bug), après quoi il doit souvent ajouter son propre indicateur, qui sera responsable du traitement d'un script spécifique à l'origine du bug.
Ensuite, il envoie le code pour les tests, et le lendemain, il passe calmement à une autre tâche, en attendant que le cluster de tests assemble un nouvel assemblage Oracle DB et exécute tous les tests sur celui-ci. Si le développeur a de la chance, environ 100 tests «rougiront»; sinon (et cette option se produit plus souvent) - environ 1000, et il devra vérifier laquelle de ses hypothèses sur le fonctionnement du code existant s'est avérée incorrecte; il est tout à fait possible qu'il se rende compte qu'il a besoin d'étudier une douzaine de drapeaux différents, qui ont participé de façon non évidente aux travaux du code qu'il a changé.
Il devra répéter ce processus pendant quelques semaines avant que la chance ne lui sourie enfin et que tous les tests passent enfin. Après quoi, il devra écrire plusieurs dizaines de tests - afin de s'assurer que le développeur, qui va déranger son code à l'avenir, ne cassera pas sa «correction». Ensuite, les améliorations seront envoyées à un examen, qui peut prendre de plusieurs semaines à quelques mois, après quoi le bogue sera finalement fusionné dans la branche de travail principale.
En raison du fait qu'il faut au moins une journée pour construire le SGBD et exécuter les tests, il est prévu que chaque développeur travaille simultanément sur 2-3 bugs et bascule entre eux en attendant les résultats du test.
Si vous pensiez que la vie des développeurs ajoutant de nouvelles fonctionnalités au SGBD est plus facile, alors vous êtes en vain. L'ajout d'une nouvelle fonctionnalité, comme un nouveau mode d'authentification, peut prendre de 6 mois à un an, dans des cas particulièrement avancés - jusqu'à deux ans.
Dans le cas décrit, TDD permet de ne pas émietter le code "spaghetti", dans lequel il est déjà extrêmement difficile de comprendre quelque chose, et d'avoir un produit fonctionnel en sortie. Dans le même temps, les coûts continuent de croître et la qualité du nouveau code laisse souvent à désirer. Non seulement une équipe de développeurs des États-Unis, mais aussi une équipe de l'Inde travaille sur le SGBD, donc certains développeurs Oracle, selon la tradition établie, leur reprochent la qualité du code. D'autres ne sont pas d'accord avec eux et, d'après le changelog, ils disent que la qualité du code ne dépend pas de la géographie de l'équipe et qu'un mauvais code «vole» périodiquement des deux équipes. Un problème très sérieux pour le produit est que les développeurs perçoivent le projet comme «entrant dans l'industrie» et travaillent sur le SGBD depuis moins de 1 à 2 ans; pendant ce temps, il est impossible de comprendre de manière significative les subtilités du projet.
Selon un autre développeur qui portait la base de code Oracle 8i vers l'une des versions Unix à la fin des années 90, le code était déjà à cette époque une boule de «spaghetti» qui était complètement impossible à comprendre complètement. Un autre développeur qui a travaillé avec le code SGBD à la fin des années 80 affirme que la base de code était un énorme tas de sources C et un ensemble de makefiles pour l'assemblage - dont beaucoup étaient beaucoup plus compliqués que le code du noyau lui-même. Bien sûr, cela vaut la peine d’être réaliste - à peine la situation est-elle meilleure dans des produits similaires, leaders de l’industrie, dont le développement s’effectue depuis plusieurs décennies.