2018-04-26 08:23:44 +0000 2018-04-26 08:23:44 +0000
185
185

Wie spricht man mit dem Management über 'genialen' Code?

EDIT:

Danke an alle für die großartigen Ratschläge, Kommentare und Rückmeldungen.

Wie sich herausstellt, war in dieser Situation niemand der “Bösewicht”. Die Ratschläge, die ich hier erhielt, halfen mir, wieder mit dem ehemaligen Leiter des Projekts in Kontakt zu kommen. Wie sich herausstellte, hatte meine Firma ohne erkennbaren Grund eine frühe “in Entwicklung” Version der Codebasis erhalten. Die alte Firma schickte uns eine produktionsreife Version, und als Sahnehäubchen lobte sie mich öffentlich dafür, dass ich ein unvollständiges Produkt so gründlich rückentwickelt hatte, wie ich es hatte.

TL;DR

Ich habe ein Projekt geerbt. Lange Rede, kurzer Sinn, der Code, den ich zu pflegen habe, ist schlecht. So schlecht, dass das Produkt nicht nur unvollständig, sondern auch nicht funktionsfähig ist, und das schon seit Jahren.

_Wie kommuniziere ich dem Management auf eine Art und Weise, die für sie nicht peinlich ist, auf eine Art und Weise, die mich nicht faul oder dumm aussehen lässt, dass ein wertvolles Produkt in einem schlechten Zustand ist? _


Klarstellung: diese Frage vs. technische Verschuldung

_Diese Frage hat damit zu tun, dass ich seit langem bestehende Überzeugungen über ein Produkt in Frage stelle, ohne Karriereselbstmord zu begehen. _ Anstatt sich strikt mit technischer Verschuldung zu befassen, gibt es folgendes: Das Management deutet an, dass der Code vielleicht so komplex ist, dass ich ihn nicht verstehen kann, und postiert, die Fehler seien absichtlich; ** _dass der ursprüngliche Entwickler so meta ist, dass das, was nach Fehlern aussieht, in Wirklichkeit Geniestreiche sind. _

Vielleicht geht es hier auch deshalb nicht um technische Schulden, weil der Unterschied zwischen “genialem” Code und technischer Schuld darin besteht, dass das Management mir mitteilt, dass ich den “genialen” Code nicht verändern darf, und dass “genialer” Code keine technische Schuld ist: Es ist die geheime schwarze Magie. Ich wünschte, das Management würde es als technische Verschuldung betrachten. Stattdessen tun sie es nicht. Das Management kümmert sich nicht direkt um Zeit, Kosten oder Geld – obwohl das eine gewisse Sorge ist.


Details

Die meiste Zeit wäre ich nicht nervös, dies dem Management mitzuteilen. Leider hat eine lange Reihe von Leuten, von denen einige wenig Entwicklungserfahrung hatten und die den Code nur lange genug “angefasst” haben, um hier und da einen Patch hinzuzufügen und dann weiterzumachen, dem Management über die Jahre hinweg das Bild vermittelt, dass das Projekt nur einen Schritt davon entfernt ist, produktionsreif zu werden.

Das ist leider nicht der Fall. Eine kurze Liste von Problemen im genialen Code, auf die ich in der ~1,5-Gb-Code-Basis gestoßen bin, sind…

  • Es gibt in der gesamten Code-Basis die gleiche Funktion, die gleichen Variablennamen mit dem gleichen Umfang (in einer Sprache, die das nicht unterstützt).
  • Funktionen sind definiert, werden aber nie aufgerufen.
  • Verwendung und Initialisierung von Variablen ist nicht in Ordnung.
  • Inkompatible Versionen der verwendeten Bibliotheken.
  • Hartkodierte URIs und IP-Adressen ohne Dokumentation darüber, was sie bewirken.
  • Zufällig angeforderte API-Routen, die nichts oder Kauderwelsch zurückgeben; die dann nicht benutzt werden.
  • Hartcodierte, unverschlüsselte Passwörter und private ssh-Schlüssel.

Ich sollte hinzufügen, dass es sich, als ich anfing, daran zu arbeiten, **_nicht einmal kompiliert hat. Und als ich es zum Kompilieren bekam, schlug es zur Laufzeit fehl.

Es ist ein Alptraum.

Das Problem ist, dass das Management die Zusicherung erhalten hat, von wem sie es geerbt haben, und von früheren “übereifrigen” Entwicklern, dass es “funktioniert”, also erheblich in es investiert haben… Und jetzt geht die Verantwortung auf mich über. Und sie wollen es in etwa 2 Monaten in Produktion haben.

Wenn ich behaupte, daß frühere Entwickler vielleicht nicht ganz ehrlich waren oder das Produkt nicht ganz verstanden haben, sendet das Management gemischte Signale über “mach es einfach fertig” und “warum ist es noch nicht fertig” … und “wir sind nicht wirklich sicher, ob es jemals funktioniert hat” bis “es funktionierte, als Sie es erhalten haben” und “wir haben es noch nie arbeiten sehen” bis “es ist bereits in Produktion”.

[EDIT: den größten Teil des nächsten Absatzes in den TL;DR-Abschnitt eingefügt. ]

Das Management hat auch angedeutet, dass es vielleicht so komplex ist, dass ich es nicht verstehen kann, und postiert, die Fehler seien absichtlich; ** dass der ursprüngliche Entwickler so meta ist, dass das, was wie Fehler aussieht, in Wirklichkeit Geniestreiche sind. Zugegeben, ich bin kein Genie, und vielleicht ist das der Fall: dem biete ich meine früheren Beobachtungen zu den sehr grundlegenden Fragen an, die ich gefunden habe.

Vielleicht ist über meinem Niveau Politik im Spiel.

Antworten (1)

0
0
0
2018-04-27 17:55:09 +0000

Ihr Plan auf hoher Ebene sollte wie folgt aussehen:

  1. Architekt einen Weg vorwärts. (*)
  2. Schätzen Sie, wie lange es dauern wird, bis Ihr “Weg nach vorn” umgesetzt ist:

  3. Treffen Sie sich mit den Interessenvertretern der Wirtschaft und teilen Sie Folgendes mit:

  4. Dass Sie den aktuellen Code nicht kompilieren/ausführen können (falls das noch zutrifft).

  5. Dass Sie ‘X’ Tage/Wochen brauchen werden, um die Codebasis in einen kompilierbaren/kompilierbaren/ausführbaren Zustand zu versetzen.

  6. Dass es zusätzliche Arbeit gibt, die über die reine Kompilierbarkeit des Codes hinausgeht und die Sie tun müssen, um den Code unterstützbar und erweiterbar zu machen.

  7. Dass Sie ‘X’ Monate brauchen werden, um Ihren Weg vorwärts zu implementieren. Dann erläutern Sie Ihren weiteren Weg (**)

(**) Dies ist am wichtigsten, weil Sie nicht-technische, geschäftliche Interessenvertreter davon überzeugen müssen, dass Ihr Plan solide, durchführbar und lohnenswert ist.

(*) Hier ist meine Empfehlung für einen weiteren Weg, der sofort beginnen kann, nachdem Sie den Code kompilieren, bauen und ausführen können.

  1. Erstellen Sie automatisierte Unit-Tests.
  2. Die Unit-Tests werden zeigen, dass Sie den Code verstehen.
  3. Die Codeabdeckungsstatistik wird Sie kontinuierlich daran erinnern, welche Teile der Codebasis Sie verstehen und welche Teile Sie noch prüfen müssen.
  4. Lassen Sie niemanden ohne eine Pull-Anforderung, die von mindestens zwei Personen genehmigt wurde, mit dem Master-Zweig fusionieren.
  5. Die Pull-Anfragen werden das sich entwickelnde Verständnis Ihres Teams für die Codebasis fördern.
  6. Fördern Sie, besonders in dieser schwierigen Zeit, eine unterstützende Kultur unter Ihren Entwicklern.
  7. Versuchen Sie, nicht die Fassung zu verlieren. Andere Entwickler werden Ihre Frustration spüren und vielleicht selbst frustriert werden.
  8. Wenn ein Entwickler Schwierigkeiten mit einem kniffligen, veralteten Code hat, ermutigen Sie andere Entwickler, mit anzupacken und den schwierigen Code gemeinsam anzugehen, vielleicht mit Paar-Programmierung.