Agile Praktiken zur Vermeidung von veraltetem Code?

Question

Ich konvertiere gerade eine Open-Source-Java-Bibliothek nach C#, die eine Reihe von Methoden und Klassen enthält, die als veraltet gekennzeichnet sind. Dieses Projekt ist eine Gelegenheit, mit einer weißen Weste zu beginnen, so dass ich plane, sie vollständig zu entfernen. Da ich jedoch zum ersten Mal an größeren Projekten arbeite, bin ich nervös, dass die Situation wieder auftauchen wird. Da sich ein Großteil der agilen Entwicklung darum dreht, etwas jetzt zum Laufen zu bringen und später bei Bedarf zu überarbeiten, scheint die Veralterung von APIs ein häufiges Problem zu sein. Gibt es vorbeugende Maßnahmen, die ich ergreifen kann, um die Veralterung von APIs zu vermeiden/zu minimieren, selbst wenn ich mir über die zukünftige Richtung eines Projekts nicht ganz sicher bin?

Answer 1

Ich denke, dass die Veralterung von Code ein unvermeidliches Nebenprodukt von agilen Prozessen wie kontinuierlichem Refactoring und inkrementeller Entwicklung ist. Wenn Sie also bei der Arbeit an Ihrem Projekt auf veralteten Code stoßen, ist das nicht unbedingt etwas Schlechtes - es ist einfach eine Tatsache. Natürlich werden Sie wahrscheinlich feststellen, dass Sie eine Menge Code beibehalten, ihn aber in andere Methoden, Klassen usw. umwandeln, anstatt ihn zu verwerfen.

Also, unterm Strich: Ich würde mir keine Sorgen machen, dass Code während der agilen Entwicklung veraltet ist. Wenn er eine Zeit lang seinen Zweck erfüllt hat, tun Sie das Richtige.

Answer 2

Als Faustregel für die Gestaltung von APIs gilt, dass man sich darauf konzentrieren sollte, was sie tun, und nicht, wie sie es tun. Sobald Sie das Endziel kennen, sollten Sie das absolute Minimum an Input herausfinden, das Sie benötigen, und dieses verwenden. Vermeiden Sie die Übergabe Ihrer eigenen Objekte als Parameter, übergeben Sie nur Daten.

Trennen Sie die Konfiguration von der Ausführung. Zum Beispiel, vielleicht haben Sie ein Bild Encoder/Decoder.

Anstatt einen Anruf zu tätigen wie:

Encoder.Encode( bytes, width, height,  compression_type, compression_ratio, palette, etc etc);

Machen Sie es

Encoder.setCompressionType(compression_type);
Encoder.setCompressionType(compression_ratio);
etc,etc
Encoder.Encode(bytes, width, height);

Auf diese Weise ist es viel unwahrscheinlicher, dass das Hinzufügen oder Entfernen von Einstellungen bestehende Implementierungen beschädigt.

Answer 3

Es gibt grundsätzlich 3 Arten von APIs: interne, externe und öffentliche.

Intern ist, wenn nur Ihr Team an dem Code arbeitet. Die Abschaffung dieser APIs ist keine große Sache. Ihr Team ist das einzige, das sie verwendet, also gibt es sie noch nicht lange, es gibt Druck, sie zu ändern, die Leute haben keine Angst, sie zu ändern, und die Leute wissen, wie man sie ändert.

Extern ist, wenn es sich um dieselbe Codebasis handelt, die aber von verschiedenen Teams verwendet wird. Dies könnten einige gemeinsame Bibliotheken in einem großen Unternehmen oder eine beliebte Open-Source-Bibliothek sein. Der Punkt ist, dass die Leute wählen können, mit welcher Version des Codes sie kompilieren. Wie einfach es ist, eine API abzuschaffen, hängt von der Größe des Unternehmens ab und davon, wie gut es kommuniziert. IMO, ist es die missbilligend Aufgabe, alten Code zu aktualisieren, anstatt ihn als veraltet zu kennzeichnen und Warnungen in der gesamten Codebasis zu verbreiten. Warum der "deprecator" und nicht der "deprecatee"? Weil der Deprecator sich auskennt; er weiß, was sich geändert hat und warum.

Diese beiden Fälle sind ziemlich einfach. Solange die Abwärtskompatibilität gegeben ist, können Sie im Allgemeinen tun, was Sie möchten, die Clients selbst aktualisieren oder die Betreuer davon überzeugen, dies zu tun.

Dann gibt es noch öffentliche APIs. Dies sind im Grunde externe APIs, über die die Kunden keine Kontrolle haben, wie z. B. eine Web-API. Diese sind unglaublich schwer zu aktualisieren oder zu verwerfen. Die meisten werden nicht bemerken, dass sie kaputt sind, werden niemanden haben, der sie repariert, werden keine Benachrichtigungen erhalten, dass sie sich ändern, und werden sólo reparieren, wenn er kaputt ist (nachdem sie ihn angeschrien haben Sie für das Brechen, natürlich).

Ich habe das schon ein paar Mal machen müssen, und es ist so mühsam. Ich denke, das Beste, was man tun kann, ist, es absichtlich zu unterbrechen früh , warten Sie ein wenig und stellen Sie sie dann wieder her. Natürlich verschicken Sie zuerst die üblichen Warnungen und Mahnungen, aber - glauben Sie mir - es wird nichts passieren, bis etwas kaputt geht.

Eine Idee, die ich noch nicht ausprobiert habe, ist die Möglichkeit, einfache Anwendungen zu registrieren, die kleine Tests durchführen. Wenn Sie eine API-Aktualisierung vornehmen wollen, führen Sie die externen Tests durch und kontaktieren die betroffenen Personen.

Answer 4

Ein anderer beliebter Ansatz ist die Abhängigkeit der Kunden von (Web-)Diensten. Es gibt Konstrukte, die es Ihnen ermöglichen, Ihre Dienste zu versionieren und den Kunden die Möglichkeit zu geben, Nachforschungen anzustellen. Dies erhöht die Anzahl der beweglichen Teile und die Komplexität der Gleichung, kann aber hilfreich sein, wenn Sie viele Versionen umdrehen und mehrere Versionen in der Produktion unterstützen müssen.

Dieser Artikel erklärt das Problem und den Ansatz sehr gut.