Wie man Kollegen dazu bringt, gemeinsame Lösungen anzuwenden

Aus Ihrer Beschreibung geht nicht hervor, dass die API-Versionierung in diesem speziellen Szenario erforderlich oder sinnvoll ist. Ich vermute, die Notwendigkeit ist auch den anderen Ingenieuren, von denen Sie sprechen, nicht klar. Und Ausdrücke wie „allgemein bekannt“ und „Industriestandard“ sind eine Art Code für „andere Leute tun es, also sollten wir es auch tun“, was ein Argument der Autorität ist, das allein selten überzeugend ist, wenn Sie andere Menschen davon überzeugen müssen, etwas zu tun Sie wollen, dass sie es tun.

Was Sie tun müssen, wenn Sie dies wirklich tun möchten, ist, zunächst ein bestimmtes Problem zu identifizieren, das Sie gerade haben, und dann die Argumente für die API-Versionierung darauf aufzubauen. Ein Beispiel:

Wir haben letzten Monat ## Stunden damit verbracht, App A neu zu schreiben, weil API-Änderungen alles kaputt gemacht haben. Da wir dafür ## ausgegeben haben, konnten wir Feature Z für Kunde Y nicht hinzufügen und haben X $ Umsatz verpasst. Anstatt unsere API zu beschädigen, hätten wir bei Versionierung 5 Minuten für die API-Änderung aufgewendet, Z abgeschlossen und X + W $ verdient, weil wir uns einen Vorsprung bei Feature V verschaffen konnten.

Beachten Sie, dass diese Begründung überhaupt nicht abstrakt ist; es hängt ganz von Dingen ab, die messbar sind. Alle messbaren Dinge sind Dinge, die ein nicht technischer Manager verstehen kann: Geld, Zeit (was Geld ist), abrechenbare Funktionen (die je nach Geschäftsmodell in Geld umgewandelt werden könnten).

Als "Senior Engineer" möchte ich niemals mehrere API-Versionen pflegen, weil das eine Menge Arbeit ist, mit der ich mich nicht beschäftigen möchte. Als "Typ, der tut, was mein Chef mir sagt", werde ich mich total verbiegen, wenn mein Chef mir sagt, dass wir mehrere Versionen pflegen müssen, um eine nicht unerhebliche Menge Geld zu sparen.

Anhand der von Ihnen gemachten Angaben kann ich schwer sagen, ob Sie Recht oder Unrecht haben. Aber ich versuche mal deine Frage zu beantworten:

Was ist der beste Weg, um im Rahmen meiner Möglichkeiten zu pushen, ohne den Anschein zu erwecken, als würde ich versuchen, die Arbeit des anderen Teams zu erledigen?

Sehr wenig, wie es aussieht, denn die Entscheidung über die Versionierung (oder deren Fehlen) scheint mir ein Teil der Teamarbeit zu sein. Aber wenn Sie trotzdem versuchen wollen, sie zu überzeugen, hier ein paar Vorschläge:

• Beziehe dich nicht auf „Allgemeinwissen“, wenn es Allgemeinwissen wäre, würden dir bereits alle zustimmen

• Sei bereit, falsch zu liegen. Es gibt ein Team von Senioren, die sich hauptberuflich mit dem Thema beschäftigen und alle eine andere Meinung haben als Sie, Sie liegen höchstwahrscheinlich falsch.

• Versuchen Sie zu verstehen, warum die Wahl getroffen wurde und welche Probleme die Senioren erwarten

• Beschreiben Sie Ihren Problemfall (den Grund, warum Sie eine Versionierung benötigen) so gut wie möglich und Ihre Hausaufgaben, um herauszufinden, ob es andere Lösungen für Ihr Problem gibt.

• Finden Sie heraus, dass andere Teams von der Implementierung der Versionsverwaltung profitieren würden

Dann führen Sie alle Ihre Recherchen in einem Fall zusammen, wie die Versionierung dem Unternehmen nützen könnte (seien Sie bereit, Zahlen vorzulegen), wie die größten Bedenken gegen die Versionierung angegangen werden könnten und mit welchem ​​Aufwand sie implementiert und gewartet werden kann.

Wenn Sie nicht nur offen dafür sind, dass jemand anders Ihre Meinung ändert, sondern aktiv darauf hinarbeiten und niemand Ihre Meinung geändert hat, während Sie all die Forschungsergebnisse gesammelt haben, haben Sie sehr wahrscheinlich Recht und andere werden nicht widersprechen können :)

Dies ist eines dieser Szenarien, in denen Sie jetzt Zeit verbringen, um Zeit für spätere Szenarien zu sparen. Die Leute, die Kosten kalkulieren, berücksichtigen selten zukünftige Einsparungen, weil sie erwarten, dass sie nicht eintreten werden. Sie wollen in der Regel immer nur kurzfristig sparen. Infolgedessen sind Sie gezwungen, schnell schlechten Code zu schreiben und ihn in jeder nachfolgenden Version zu verbinden.

Dies wird zu ziemlich lustigen, aber frustrierenden Szenarien führen, in denen Sie Code wie diesen sehen werden

var oldDate = api.convertDateTime(input);
//.....some code
var newDate = api.convertDateTime1(input, format);
//.....some code
var finalDate = api.convertDateTime2([oldDate, newDate], format);

Und der Grund ist einfach, niemand möchte zurückblicken und sehen, wo api.convertDateTime verwendet wurde, und alle Verwendungen beheben, also erstellen sie eine neue Version. Aber es gibt keinen Unterschied in dem, was es tut, also bekommst du eine Nummer. Später passiert es dann wieder, jemand möchte ein Format hinzufügen, und es ist erforderlich, aber er möchte nicht zurückgehen und alle alten Verwendungen korrigieren, also erstellen sie eine weitere neue Version. Und schließlich möchte jemand mehrere Daten in einer Zeile konvertieren, also eine weitere neue Version erstellen und nicht jede alte Verwendung einem Regressionstest unterziehen, also noch eine neue Version.

Und so wird eine schlechte Version der API-Versionierung geboren.

Also, wie kann man das vermeiden? Sie müssen die Leute davon überzeugen, dass Zeitverschwendung jetzt das Chaos vermeidet, das ich gerade beschrieben habe. Das ist nicht einfach und wirkt sich stark auf die Unternehmenskultur aus. Es spielt auch eine große Rolle, ob Ihre Abteilung ein Cost Center oder ein Profit Center ist. Ein Profitcenter darf oft vorausplanen. Eine Kostenstelle ist in der Regel erforderlich, um die Kosten jedes Jahr so ​​niedrig wie möglich zu halten, egal wie viele technische Schulden Sie anhäufen.

Ihre Argumentation ist also einfach:

Sie müssen einige Beispiele dafür zeigen, dass die Versionierung schief gelaufen ist.

Zeigen Sie einige Beispiele für eine bessere Versionierung.

Und, was am wichtigsten ist, stellen Sie die Zeitkosten zwischen den Methoden grafisch dar, damit Ihre auf lange Sicht billiger aussieht. Wenn Sie mit Nummern bewaffnet kommen, werden Sie nicht ignoriert.

Meiner Erfahrung nach wird normalerweise ein Kompromiss gemacht, bei dem eine erste Version der API erstellt wird und anschließend ein Versionierungssystem eingebaut wird, unter der Annahme, dass es anfangs zu viele Versionen geben wird, um den Überblick zu behalten, also warten Sie auf die API zu stabilisieren und zu reifen, bevor Sie sich Gedanken über Versionen machen. Dann wird Zeit darauf verwendet, alle alten API-Verwendungen zu aktualisieren, um eine Version bereitzustellen, sobald eine vorhanden ist, oder alle Verwendungen ohne angegebene Version werden als Version 1 angenommen.

Anstatt sich Gedanken über eine bestimmte Lösung für Ihr Problem (z. B. Versionierung) zu machen, konzentrieren Sie sich darauf, welche Uptime-/Change-Management-Prinzipien Sie von der API erfüllen müssen. Es ist fair zu sagen, dass API-Änderungen niemals eine Clientanwendung unerwartet beschädigen sollten, dass die API sehr wenig Ausfallzeit haben sollte und dass alle wichtigen Änderungen an der API so früh wie möglich angekündigt werden.

Wenn Sie sich auf diese Prinzipien einigen können, lassen Sie die API-Entwickler (oder die Gruppe) entscheiden, wie Sie diese Ziele erreichen.