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 bin mir nicht sicher, ob Sie viel tun können. Anforderungen ändern sich, und wenn Sie unbedingt sicherstellen müssen, dass Clients der API nicht durch neuere API-Versionen beeinträchtigt werden, müssen Sie sich darauf verlassen, dass Sie den Code einfach verwerfen, bis Sie glauben, dass niemand den veralteten Code verwendet.

Das Setzen von [Obsolete]-Attributen im Code bewirkt, dass der Compiler Warnungen erzeugt, wenn es Verweise auf die veralteten Methoden gibt. Auf diese Weise können die Kunden der API, wenn sie ihre Compiler-Warnungen sorgfältig beheben, schrittweise zu den neuen Methoden übergehen, ohne dass mit der neuen Version alles kaputt geht.

Es ist nützlich, wenn Sie das ObsoleteAttribute's override verwenden, das eine Zeichenkette nimmt:

[Obsolete("Foo is deprecated. Use Bar instead for munging widgets.")]

<frivol>

Vielleicht könnten Sie ein TimeBombAttribute erstellen:

[TimeBomb(new DateTime(2010,1,1), "Foo will blow up! Better use Bar, or else."]

Suchen Sie in Ihrem Code nach Methoden mit dem Attribut timebomb und werfen Sie eine KaboomException, wenn sie nach dem angegebenen Datum aufgerufen werden. Damit stellen Sie sicher, dass nach dem 1. Januar 2010 niemand mehr die veralteten Methoden verwendet, und Sie können Ihre API schön aufräumen :)

</frivol>

Answer 2

Wie Matt sagt, ist die Obsolete Attribut ist Ihr Freund... aber wenn Sie es anwenden, geben Sie Details an, wie Sie den Aufrufcode ändern können. Auf diese Weise haben Sie eine viel größere Chance, dass die Leute tatsächlich etwas ändern. Vielleicht sollten Sie auch angeben, in welcher Version Sie die Methode voraussichtlich entfernen werden (wahrscheinlich in der nächsten Hauptversion).

Natürlich sollten Sie sorgfältig darauf achten, dass Sie rufen Sie den veralteten Code nicht auf - insbesondere in Beispielcode.

Answer 3

Da sich ein Großteil der agilen Entwicklung darum dreht, etwas jetzt zum Laufen zu bringen und später bei Bedarf zu überarbeiten

Das ist nicht agil. Es ist Cowboy-Coding, getarnt unter dem Etikett "agil".

Das Ideal ist, dass alles, was Sie fertigstellen, auch vollständig nach der Definition von "erledigt", die Sie haben. In der Regel besagt die DoD etwas in der Art von "Feature implementiert, getestet und zugehöriger Code refaktorisiert". Wenn Sie an einem Wegwerf-Prototypen arbeiten, können Sie natürlich eine entspanntere DoD haben.

API-Änderungen sind ein schwieriges Unterfangen. Wenn es sich nur um projektinterne APIs handelt, die Sie ändern, ist es am besten, wenn Sie frühzeitig refaktorisieren. Wenn Sie die interne API ändern müssen, machen Sie einfach weiter und ändern Sie alle API-Clients zur gleichen Zeit. Auf diese Weise werden die Refactoring-Schulden nicht sehr groß und Sie müssen keine Verwerfung vornehmen.

Für veröffentlichte APIs müssen Sie wahrscheinlich einige Garantien für die Kompatibilität von Quellcode und Binärdateien aufrechterhalten, zumindest bis zur nächsten größeren Version oder so. Wenn Sie die alten APIs als veraltet kennzeichnen, können Sie die Kompatibilität aufrechterhalten. Wie bei internen APIs sollten Sie Ihren internen Code so schnell wie möglich korrigieren, um die veralteten APIs nicht zu verwenden.

Answer 4

Die Antwort von Matt ist ein guter Rat. Ich wollte nur erwähnen, dass Sie anfangs wahrscheinlich etwas in der Art von verwenden möchten:

[Obsolete("Please use ... instead ", false)]

Sobald Sie den Code portiert haben, ändern Sie false in true und der Compiler wird dann alle Aufrufe der Methode als Fehler behandeln.

Answer 5

Sehen Sie Josh Blochs " Wie man eine gute API entwirft und warum sie wichtig ist "

Das Wichtigste in Bezug auf die Verwerfung ist die Erkenntnis, dass man es im Zweifelsfall weglassen sollte. Sehen Sie sich das Video zur Erläuterung an, aber es hat damit zu tun, dass Sie das, was Sie anbieten, für immer unterstützen müssen. Wenn Sie realistischerweise davon ausgehen, dass diese API wiederverwendet wird, sind Ihre Entscheidungen praktisch in Stein gemeißelt.

Ich denke, dass die Entwicklung von APIs auf agile Weise viel schwieriger zu bewerkstelligen ist, weil man davon ausgeht, dass sie wahrscheinlich auf viele verschiedene Arten wiederverwendet werden. Man muss sich Gedanken darüber machen, ob man andere, die von einem abhängig sind, kaputt macht, und so ist es zwar möglich, aber schwierig, das richtige Design zu entwickeln, ohne eine schnelle Antwort von anderen Teams zu erhalten. Natürlich wird die Abschaffung von Funktionen hier helfen, aber ich denke YAGNI ist eine viel bessere Design-Heuristik, wenn es um APIs geht.