Diese Woche haben die Benutzer von Hacker News
beschlossen, die Frage zu diskutieren: "Was ist die maximale Menge an schlechtem - aber immer noch funktionierendem - Code, den Sie gesehen haben?" (Später kamen
Reddit-Benutzer dazu ). In den Kommentaren wurden viele „lustige“ Geschichten über Dinge erzählt, die uns von Zeit zu Zeit begegnen. Die Geschichte über den Code „Advanced DBMS, der von den meisten Fortune 100-Unternehmen verwendet wird“ erregte jedoch die größte Aufmerksamkeit.
Der Gewinner der Lovecraft Horror-Nominierung war zu Recht die
Geschichte eines ehemaligen Oracle-Entwicklers, der während der Entwicklung von Version 12.2 an Oracle Database gearbeitet hat. Die Codebasis des DBMS betrug zu dieser Zeit 25 Millionen Zeilen in C - und sobald Sie nur eine dieser Zeilen geändert haben, brachen
Tausende von Tests, die zuvor geschrieben wurden.
Im Laufe der Jahre haben mehrere Generationen von Programmierern an dem Code gearbeitet, die regelmäßig von harten Fristen verfolgt wurden - und dank dessen könnte der Code zu einem echten Albtraum werden. Heute besteht es aus komplexen "Codeteilen", die für Logik, Speicherverwaltung, Kontextumschaltung und vieles mehr verantwortlich sind. Sie sind über
Tausende verschiedener Flags miteinander verbunden. Der gesamte Code ist durch ein mysteriöses Makro miteinander verbunden, das nicht entschlüsselt werden kann, ohne auf ein Notizbuch zurückzugreifen, in das Sie aufschreiben müssen, was die relevanten Teile des Makros tun. Infolgedessen kann ein Entwickler ein oder zwei Tage brauchen, um herauszufinden, was das Makro tatsächlich tut.
Um das Verhalten des Codes in dem einen oder anderen Fall vorherzusagen, müssen Sie verstehen und sich daran erinnern, welche Werte und Konsequenzen 20 (oder sogar hundert) Flags haben können. Die Situation wird durch die Tatsache verschärft, dass verschiedene Entwickler ihre eigenen Typen verwendeten, die im Wesentlichen dasselbe waren (zum Beispiel int32) - und kaum jemand würde riskieren, ein solches Erbe zu berühren (wir können mit Sicherheit sagen, dass dies der Fall war) Oracle 8i-Codebasis).
Es stellt sich die Frage: Wie kann Oracle Database bei alledem noch auf den Beinen bleiben? Das Geheimnis liegt in Millionen von Tests. Ihre vollständige Implementierung kann 20 bis 30 Stunden dauern (gleichzeitig werden sie verteilt auf einem Testcluster von 100 bis 200 Servern ausgeführt).
Das Team, das Ende der 90er Jahre an dem Produkt arbeitete und sich an die Ideen von TDD (testgetriebene Entwicklung) hielt, war der folgenden Meinung: „Automatisierte Tests bedeuten, dass Sie keinen verständlichen Code schreiben müssen - stattdessen sollten Sie dies tun Denk Tests. " Zukünftig mussten sich die Entwickler an die von ihnen festgelegten Grundsätze halten, und jetzt sehen wir in der Praxis, wie sich diese Idee auf lange Sicht entwickelt hat - mit all ihren Vor- und Nachteilen.
Heute dauert das Beheben eines neuen Fehlers in der Oracle-Datenbank mehrere Wochen bis mehrere Monate. Zunächst muss der Entwickler mehrere Tage damit verbringen, die von ihm benötigten Flags herauszufinden (deren mysteriöse Interaktion einen Fehler verursacht). Danach muss er häufig ein eigenes Flag hinzufügen, das für die Verarbeitung eines bestimmten Skripts verantwortlich ist, das den Fehler verursacht hat.
Dann sendet er den Code zum Testen und wechselt am nächsten Tag ruhig zu einer anderen Aufgabe. Er wartet darauf, dass der Testcluster eine neue Oracle DB-Assembly zusammenstellt und alle Tests darauf ausführt. Wenn der Entwickler Glück hat, werden ungefähr 100 Tests "rot"; Wenn nicht (und diese Option kommt häufiger vor) - ungefähr 1000, muss er überprüfen, welche seiner Annahmen über die Funktionsweise des vorhandenen Codes sich als falsch herausgestellt hat. Es ist durchaus möglich, dass er feststellen wird, dass er ein Dutzend verschiedener Flaggen studieren muss, die auf nicht offensichtliche Weise an der Arbeit des von ihm geänderten Codes beteiligt waren.
Er muss diesen Vorgang einige Wochen lang wiederholen, bevor ihn das Glück endlich anlächelt und alle Tests endlich bestanden sind. Danach muss er mehrere Dutzend Tests schreiben - um sicherzustellen, dass der Entwickler, der seinen Code in Zukunft stören wird, seinen „Fix“ nicht bricht. Anschließend werden die Verbesserungen an eine Überprüfung gesendet, die mehrere Wochen bis einige Monate dauern kann. Danach wird der Fehler endgültig in den Hauptarbeitsbereich integriert.
Aufgrund der Tatsache, dass das Erstellen des DBMS und das Ausführen der Tests mindestens einen Tag dauert, wird erwartet, dass jeder Entwickler gleichzeitig an 2-3 Fehlern arbeitet und zwischen diesen wechselt, während er auf die Testergebnisse wartet.
Wenn Sie der Meinung sind, dass das Leben von Entwicklern, die dem DBMS neue Funktionen hinzufügen, einfacher ist, sind Sie vergebens. Das Hinzufügen einer kleinen neuen Funktion wie eines neuen Authentifizierungsmodus kann in besonders fortgeschrittenen Fällen 6 Monate bis zu einem Jahr dauern - bis zu zwei Jahre.
In dem beschriebenen Fall erlaubt TDD, den "Spaghetti" -Code, in dem es bereits äußerst schwierig ist, etwas zu verstehen, nicht zu zerbröckeln und ein funktionierendes Produkt am Ausgang zu haben. Gleichzeitig steigen die Kosten weiter und die Qualität des neuen Codes lässt oft zu wünschen übrig. Nicht nur ein Team von Entwicklern aus den USA, sondern auch ein Team aus Indien arbeitet am DBMS. Einige Oracle-Entwickler geben ihnen nach der etablierten Tradition die Schuld an der Qualität des Codes. Andere sind mit ihnen nicht einverstanden, und basierend auf dem Änderungsprotokoll sagen sie, dass die Qualität des Codes nicht von der Geografie des Teams abhängt und dass schlechter Code regelmäßig von beiden Teams „fliegt“. Ein wirklich ernstes Problem für das Produkt sind Entwickler, die das Projekt als „Einstieg in die Branche“ wahrnehmen und nicht länger als 1-2 Jahre am DBMS arbeiten. In dieser Zeit ist es unmöglich, die Feinheiten des Projekts wesentlich zu verstehen.
Nach Aussage eines anderen Entwicklers, der die Oracle 8i-Codebasis Ende der 90er Jahre auf eine der Unix-Versionen portierte, war der Code bereits zu diesem Zeitpunkt eine Kugel aus „Spaghetti“, die überhaupt nicht vollständig zu verstehen war. Ein anderer Entwickler, der Ende der 80er Jahre mit DBMS-Code gearbeitet hat, behauptet, dass die Codebasis eine große Menge von C-Quellen und eine Reihe von Makefiles für die Assemblierung war - von denen viele viel komplizierter waren als der Kernel-Code selbst. Natürlich lohnt es sich, realistisch zu sein - kaum ist die Situation bei ähnlichen Produkten besser, Branchenführern, deren Entwicklung seit mehreren Jahrzehnten durchgeführt wird.