Was ist der schlimmste Bad Code, den ihr je gesehen habt?
(news.ycombinator.com)„25 Millionen Zeilen Oracle-Database-12.2-Code.“
Eine Antwort eines ehemaligen Oracle-Mitarbeiters auf eine Frage, die auf HN gepostet wurde.
„Es ist ein unvorstellbarer Albtraum. Man kann nicht einmal eine einzige Zeile Code schreiben, ohne 1000 bestehende Tests zu bestehen.
Es gibt mysteriöse Makros, die man nur versteht, wenn man sie von Hand auf einem Notizblock durchgeht, und es dauert ein bis zwei Tage, ihre Funktion wirklich zu begreifen.
Manchmal muss man die Werte und Auswirkungen von 20 verschiedenen Flags verstehen, um vorherzusagen, wie der Code in unterschiedlichen Situationen funktionieren wird.
Manchmal sind es auch über 100. Keine Übertreibung.
Der einzige Grund, warum dieses Produkt noch immer überlebt und funktioniert, sind buchstäblich Millionen von Tests.“
Das Leben eines Oracle-DB-Entwicklers
-
Mit der Arbeit an einem neuen Bug beginnen
-
Zwei Wochen darauf verwenden, 20 verschiedene Flags zu verstehen, die auf mysteriöse Weise miteinander interagieren und diesen Bug auslösen
-
Ein weiteres Flag hinzufügen, um ein neues spezielles Szenario zu behandeln. Noch ein paar Zeilen Code schreiben, um dieses Flag zu prüfen, und noch ein paar Zeilen hinzufügen, um die Problemsituation zu lösen und den Bug zu verhindern
-
Die Codeänderung an eine Test-Farm mit 100 bis 200 Maschinen schicken. Dort wird dann eine neue Oracle DB gebaut und Millionen von Tests verteilt ausgeführt
-
Nach Hause gehen. Am nächsten Tag zurückkommen und mit einer anderen Aufgabe anfangen. Die Tests brauchen 20 bis 30 Stunden bis zum Abschluss
-
Nach Hause gehen. Am nächsten Tag zurückkommen und die Testergebnisse prüfen. An einem guten Tag fallen ungefähr 100 Tests durch. An einem schlechten Tag scheitern eher 1000. Einige dieser Tests auswählen und herausfinden, welche Annahmen falsch waren. Wahrscheinlich gibt es noch etwa 10 weitere Flags, die man berücksichtigen muss, um das eigentliche Wesen des Bugs zu verstehen
-
Noch ein paar Flags hinzufügen, um dieses Issue zu lösen. Die Änderung erneut an die Test-Farm schicken. Wieder 20 bis 30 Stunden warten
-
Zwei Wochen lang wiederholen und nachbessern, bis diese Flag-Kombinationen korrekt funktionieren
-
Endlich kommt „einer dieser guten Tage“, an dem nicht mehr alle Tests fehlschlagen
-
Über hundert Tests für die eigene Änderung hinzufügen, damit der nächste unglückliche Entwickler diesen Fix nicht kaputtmacht
-
Für den finalen Test noch einmal einreichen. Danach zur Review einreichen. Da die Review wieder zwei Wochen bis zwei Monate dauern kann, zur nächsten Bug-Arbeit wechseln und dort anfangen
-
Zwei Wochen bis zwei Monate später ist alles abgeschlossen und der Code wird in den Main-Branch gemergt
So sieht das Leben eines Oracle-Programmierers beim Beheben von Bugs aus. Ohne Übertreibung.
Stellt euch also vor, was für ein Horror die Entwicklung neuer Features sein muss.
Die Entwicklung eines kleinen Features dauert sechs Monate bis ein Jahr, manchmal sogar zwei Jahre. (Zum Beispiel das Hinzufügen einer neuen Authentifizierung wie Active-Directory-Authentifizierung.)
Dass dieses Produkt überhaupt funktioniert, ist ein Wunder.
Ich arbeite jetzt nicht mehr bei Oracle und werde auch nie wieder bei Oracle arbeiten.
8 Kommentare
Der größte Bad Code, den ihr bisher gesehen habt?
Der Testzyklus ist
Code schreiben
Tests schreiben
Code refaktorisieren, zurück zu 1
Da aber 1 und 2 zu viel Zeit kosten, ist das in Summe das Ergebnis davon, dass Schritt 3 ständig ausgelassen wird.
Was ist der größte Bad Code, den ihr bisher gesehen habt?
An dieser Stelle lohnt sich ein erneuter Blick auf Martin Fowlers Vortrag. Offenbar ist die „interne Qualität“ (Internal Quality) der Oracle Database nicht besonders gut.
https://de.news.hada.io/topic?id=2752
Nun, aus Oracles Sicht wirkt das irgendwie selbstverständlich, und es vermittelt eher Vertrauen in dem Sinne: Diese Software ist eben tatsächlich für den Enterprise-Einsatz gedacht ...
Aber wie im Beitrag beschrieben würde ich dort trotzdem nicht arbeiten wollen.
Ich habe eher den Eindruck, dass der Entwicklungsprozess vielleicht gerade wegen einer testzentrierten Entwicklungskultur kaputtgegangen ist.
Es wird dann nach dem Motto entwickelt: Hauptsache, die Tests bestehen ... In so einem Umfeld kann man Refactoring vermutlich nicht einmal träumen.
Wäre nicht eher das architektonische Problem größer als das Testproblem, wenn das Design so aufgebaut ist, dass man für Änderungen/Erweiterungen von Funktionen 20 bis 100 Flags berücksichtigen muss?
Wegen der Komplexität des DBMS scheint das allerdings kaum vermeidbar zu sein.
Tests sind letztlich auch Code, den Entwickler schreiben. Da ich gerade daran denken musste, stelle ich einen Artikel über Tests vor.
https://de.news.hada.io/topic?id=2883
Wenn ein Projekt nicht in so einem Zustand ist, geben Tests einem vielmehr den Mut zum Refactoring, weil sie fortlaufend garantieren können, dass trotz umfassender Änderungen an der Schnittstelle am Ende noch alles so funktioniert wie vorher. Ich habe kürzlich in dem Emulator, an dem ich gerade arbeite, Parameter von BYTE-Werten auf Enum-Werte umgestellt. Der Build war erfolgreich, aber die Tests schlugen fehl, und ich habe mich kurz gefragt, was ich wohl ohne Tests gemacht hätte. Das war schon ein kleiner Schockmoment.
Bei einer Codebasis in dieser Größenordnung überlegt man zwar, ob man refactoren soll, gibt dann aber wegen der schieren Größe wieder auf, und auf den Code wird nur noch mehr draufgepackt ... Ich vermute vorsichtig, dass man so vielleicht in eine Art Endlosschleife geraten ist.
Ich kann nachvollziehen, dass es für die Person hart war,
aber paradoxerweise ist es ein Text, bei dem man denkt: „Genau so wichtig sind Tests also.“ Deshalb habe ich ihn übersetzt.
Auf den ursprünglichen Fragethread zu dieser Antwort gab es insgesamt 578 Antworten.
Ask HN: What's the largest amount of bad code you have ever seen work?
https://news.ycombinator.com/item?id=18442637
Schon die Antworten der ersten Ebene sind unterhaltsam. Da denkt man: Überall, wo Menschen leben, ist es am Ende doch gleich.