Suche Materialien zum Thema Schnittstellen
-
Das Problem: Ich habe eine etwas emotionale Kollegin welche ein Funkformat ändern möchte, wobei das Funkprotokoll gleich bleiben soll. Wo also früher ein Messwert steht, soll in Zukunft z.B. ein Offset stehen.
Und das ist aus meiner Sicht eine Katastrophe mit Ansage, da das Ganze seit Jahren im Feld ist. Auf die Frage was denn die Kunden im Feld tun, bleibt sie mir eine Antwort schuldig. Ebenso auf die Frage, warum denn eine Protokoll-Erweiterung nicht funktionieren soll.
Ich bin mir daher nicht sicher ob die Kollegin das Problem von Formaten bzw. Schnittstellen versteht.
Das Format-Problem habe ich mal meinem Azubi folgendermaßen erklärt. Ich habe für mein Programm ein Datenformat auf Basis von XML definiert. Nach ein paar Jahren stellte ich einen Rechtschreibfehler bei einem Attribut im Format fest. Darf ich diesen korrigieren?
Offenbar ist dies keine gute Idee, denn würde der Fehler korrigiert werden würde, so würden neuere Versionen das Attribut richtig schreiben. Wenn nun aber diese Datei von einer älteren Programmversion eingelesen wird, so überliest diese das Attribut, s.d. auf einmal ein unterschiedliches Ergebnis herauskommt...
Könnt ihr mir hierzu Materialen empfehlen?
BTW: Leider habe ich das Buch von Don Box "Essential COM" nicht mehr. Das würde auch schon helfen.
-
Ich weiß nicht, was dir da Zusatzmaterial helfen soll, du siehst das schon alles ganz richtig, allein durch deine gesunden Menschenverstand. Was du vielleicht noch nicht siehst, ist, dass genau solche Fälle der Grund sind, wieso so viele Protokolle damit beginnen, dass man sich zuallererst auf eine gemeinsame Version des Protokolls einigt. Manchmal noch nicht einmal in Form einer gemeinsamen Absprache, sondern durch eine einseitige Angabe. Das hast du wirklich überall. Denk mal darüber nach, wie viele Datenformate mit der Angabe des Formats, inklusive Versionsnummer beginnen, oder wie fast jedes Kommunikationsprotokoll damit beginnt, dass man sagt, was man überhaupt spricht/sprechen will. Wenn du also jemals selber in die Verlegenheit kommst, so etwas zu entwerfen, gehört das spätestens in die zweite Version des Protokolls (und die erste kann man dann an der fehlenden Angabe erkennen).
Wenn deine Kollegin das Problem selbst mit logischer Erklärung nicht versteht, dann hilft doch auch kein Appell an die Autorität eines Buches.
-
Kann man leicht herausfinden, wo überall in der Codebase relevante Protokollfunktionen verwendet werden? Wenn einem eine solche Suche 20.000 Dateien ausspuckt, wäre das vermutlich eine Hilfe, um die Kollegin und andere Entscheider von der potentiellen Tragweite einer Protokolländerung zu überzeugen. Auch wenn man konkret noch keinen Codeteil benennen kann, wo das tatsächlich zum Problem wird. Eigentlich müsste man sich diese ganzen Codestellen auch zumindest mal ansehen und schauen, wie die auf das neue Format reagieren würden. Vielleicht überzeugt ja auch die Anzahl der rekursiv notwendigen Anpassungen, wenn man mal ein paar auflistet. Eine große Anzahl Tests, die Reihenweise vor die Wand laufen (so sie denn existieren) hätten sicher auch einiges an Überzeugungskraft.
Gerade bei zentralen Änderungen sollte es eigentlich Aufgabe derjenigen sein, welche die Änderungen vornehmen wollen, solche Risiken zu untersuchen und zu argumentieren, warum die gewonnenen Vorteile überwiegen. Es ist schon klar, dass ein echter "Negativbeweis", dass es nirgendwo zu Problemen kommt, nicht praktikabel ist, aber ein bisschen mehr als gar nichts sollte da schon kommen.
Wer entscheidet bei euch eigentlich letztendlich darüber? Der Chef? Das Team mit Mehrheitsbeschluss oder kann das jeder Entwickler selbst entscheiden? Vielleicht ist es auch hilfreich andere Entscheider zu überzeugen, wenn man bei der Kollegin auf derart auf Granit beißt.
Achja, und nochwas nicht-technisches: Diplomatisches Fingerspitzengefühl ist auch nicht verkehrt. Ich würde Probleme mit Vorschlägen von Kollegen immer so ansprechen, dass diese den Vorschlag gesichtswahrend zurückziehen können. Also statt "was für eine saudumme Idee!" lieber sowas wie "was für eine pfiffige Idee, aber ich befürchte, dass unsere Codebase noch nicht reif dafür ist"
... wenn Kollegen wie ein Idiot dastehen, wenn sie nachgeben, läuft man Gefahr, dass an schlechten Ideen ausschließlich deshalb festgehalten wird, damit eben das nicht passiert.
-
Ich habe gerade einen Punkt gefunden, wo ihre Änderungen für Kunden gefährliche Konsequenzen haben können. Genauer gesagt führt ihr Vorschlag dazu dass nicht alle Zustände Fail-Safe sind.
Damit fällt ihr Vorschlag.
Meine Kollegin hat sich seit Corona stark zum negativen verändert. Sie ist egozentrisch, herablassend und streitsüchtig geworden und ist leider mit einem Vorgesetzten liiert. Das hat unsere Freundschaft gekostet und ich weiß nicht ob sie dies begreift. Sie hat auch eine ziemliche "Mit dem Kopf durch die Wand" Mentalität und ich habe schon öfter fürs sie die Kohlen aus dem Feuer geholt.
Sie kann sehr gut arbeiten, doch manchmal hat sie eine emotionale Phase wo ich sie am liebsten auf den Mond schießen würde. Und nun arbeiten wir wieder zusammen, sie spart nicht an Kritik und ich kassiere gerade etwas zu oft ihre Vorschläge ein.
Die Entscheidungen trifft der Chef.
