So pflegen Sie dieselben Codefragmente in mehreren Projekten [geschlossen]

Ich bin ein Indie-Entwickler, der an mehreren Android-Projekten arbeitet. Ich habe Probleme mit der Aufrechterhaltung der gleichen Funktionalität in verschiedenen Projekten. Zum Beispiel verwenden drei meiner Apps dieselben zwei Klassen. Da es sich um verschiedene Projekte handelt, muss ich drei Änderungen vornehmen, wenn ich diese Klassen ändern muss. Gibt es eine einfache Lösung für diese Art von häufigem Problem?

Trennen Sie den gemeinsam genutzten Code in eine Bibliothek und fügen Sie die Bibliothek in die Projekte ein.

Als Android-Entwickler verwenden Sie vermutlich Java. Erwägen Sie die Verwendung eines Abhängigkeitsverwaltungstools wie Maven oder Ivy .

Ein Nebeneffekt ist, dass dies dazu beiträgt, die Trennung von Bedenken aufrechtzuerhalten , indem die Modularität durchgesetzt wird. Die Kosten sind, dass die Trennung einige Arbeit erfordern kann. Der Vorteil ist eine bessere zukünftige Wartbarkeit. Wenn Sie sich jemals dazu entschließen, können Sie die Bibliothek auch separat (entweder kommerziell oder als Open Source) von Ihren Anwendungen freigeben.

Versionskontrolle. Git. Git-Submodule.

Stellen Sie Ihre Projekte unter Versionskontrolle, indem Sie DVDs wie Git oder Mercurial usw. verwenden. Fügen Sie den freigegebenen Code in ein Submodul in Git ein. Verwenden Sie das Submodul in den Projekten, die es benötigen. Wenn Sie das Submodul aktualisieren, können Sie die Änderungen mit einem einzigen Befehl auf andere Projekte übertragen.

Noch hat niemand das zweischneidige Schwert erwähnt, also werde ich meine 2 Cent hinzufügen. Wenn Sie mehrere Projekte haben und alle einen wiederverwendbaren Code gemeinsam haben, sollten Sie den Code gemäß den guten Programmierpraktiken / -prinzipien (z. B. DRY) an einem globalen Ort platzieren und so strukturieren, dass er von allen gemeinsam genutzt werden kann Ihre Projekte ohne Änderungen. Mit anderen Worten, definieren Sie Schnittstellen so, dass sie allgemein und allgemein genug sind, um jedem gerecht zu werden.

Hierfür gibt es nur wenige Optionen: 1) Erstellen Sie ein Basisprojekt, von dem andere abhängig sind. Dieses Projekt kann eine binäre Verteilung erstellen, die andere Projekte verwenden. 2) Ziehen Sie ein Open-Source-Modell in Ihre Organisation. Lassen Sie gemeinsamen Code einen eigenen Codezweig sein und lassen Sie andere Projekte Code auf dieselbe Weise abrufen, wie Sie Quellcode von jedem OSS online übernehmen würden.

Hier kommt das Schwert ins Spiel ...

Das Platzieren von Code an einem gemeinsamen Ort, von dem andere Projekte / Personen abhängen, kann ziemlich teuer werden. Angenommen, Sie haben einen Code und 4 andere Projekte hängen davon ab. Einer Ihrer Kunden, der Projekt A verwendet, findet einen Fehler und Sie müssen eine Korrektur vornehmen. Sie beeilen sich und der Kunde ist zufrieden. Sie haben jedoch gerade Code geändert, von dem 3 andere Projekte abhängen. Haben Sie alle erneut getestet, um sicherzustellen, dass keine Randbedingungen eingeführt wurden?

Allgemeiner Code muss auch viel sorgfältiger erstellt werden, und die Modulschnittstellen müssen viel besser gestaltet sein, da dieser Code nicht nur einen, sondern vier Clients aufnehmen darf und jeder von ihnen diesen Code möglicherweise nur mit einem ganz geringen Unterschied verwendet.

Wenn sich Ihre Projekte in unterschiedlichen Release-Zyklen befinden, müssen Sie beim Verwalten des gemeinsamen Codes noch vorsichtiger sein. Sie können nicht einfach Änderungen am allgemeinen Code vornehmen, da Projekt B neue Funktionen benötigt, wenn Sie 3 Tage vor dem Ausschneiden des endgültigen Bilds für Projekt C sind.

Ich sage nicht, dass eine gemeinsame Bibliothek nicht die richtige Lösung ist. Ich bin ein starker Befürworter von DRY und habe zuvor gemeinsamen Code erstellt und unterstützt und tue dies auch weiterhin. Ich wollte nur sagen, dass das einfache Erstellen von Code seine eigenen Kosten hat.

Wenn Sie der einzige sind, der diesen Code wiederverwendet, ist dies nicht so schlimm. Wenn Sie ein Team von Ingenieuren haben, die den gemeinsamen Code verwenden, steigen die Kosten noch weiter an. Wenn andere beteiligt sind, sollten Sie damit rechnen, dass das Platzieren von Code in einer gemeinsamen Bibliothek dreimal so lange dauert, bis ein Punkt erreicht ist, an dem Sie glauben, dass er "vollständig" ist. Sie müssen a) die Bibliothek robuster machen, um sie vor allen Arten von Randbedingungen und ungültiger Nutzung zu schützen, b) Dokumentation bereitstellen, damit andere die Bibliothek verwenden können, und c) anderen Personen beim Debuggen helfen, wenn sie die Bibliothek auf eine von Ihnen verwendete Weise verwenden nicht erwartet und Ihre Dokumentation deckte nicht ihren spezifischen Anwendungsfall ab.

Einige Vorschläge, die ich anbieten kann:

1. Gemeinsamer Code, der durch automatisierte Komponententests abgedeckt wird, kann viel bewirken und Ihnen die Gewissheit geben, dass Sie bei einer Änderung nicht nur ein anderes Projekt abgebrochen haben.
2. Ich würde nur sehr stabile Funktionen in gemeinsamen Code einfügen. Wenn Sie letztes Jahr eine Klasse für Timer-Management geschrieben haben und diese seit 9 Monaten nicht mehr geändert haben und jetzt 3 andere Projekte haben, die Timer benötigen, dann ist das sicher ein guter Kandidat. Aber wenn Sie letzte Woche etwas geschrieben haben, haben Sie nicht so viele Optionen (und ich hasse es, Code zu kopieren / einzufügen, wahrscheinlich mehr als der nächste), aber ich würde zweimal darüber nachdenken, es allgemein zu machen.
3. Wenn ein Teil des Codes trivial ist, Sie ihn jedoch an mehreren Stellen verwendet haben, ist es möglicherweise besser, in die Kugel zu beißen, DRY in Ruhe zu lassen und mehrere Kopien am Leben zu lassen.
4. Manchmal lohnt es sich, nicht einfach gemeinsamen Code an einem gemeinsamen Ort abzulegen und alle darauf verweisen zu lassen. Behandeln Sie den allgemeinen Code jedoch lieber als seinen eigenen, der mit Versionen, Veröffentlichungsdaten und allem freigebbar ist. Auf diese Weise kann Projekt C sagen: "Ich verwende die allgemeine Bibliothek v1.3". Wenn Projekt D neue Funktionen benötigt, lassen Sie v1.3 in Ruhe, Release v1.4 und Projekt C wird nicht beeinträchtigt. Denken Sie daran, es ist VIEL, VIEL teurer, gemeinsamen Code als eigenes Produkt zu behandeln, als ihn einfach an einem gemeinsamen Ort einchecken zu lassen.

Dies ist eine idealisierte Lösung und kann einige Anstrengungen erfordern, um an die Arbeit zu gehen.

Das DRY-Prinzip besagt, dass es eine einzige maßgebliche Quelle der Wahrheit geben sollte. Dies schreibt die Verwendung eines einzigen Quell- Repositorys für die gesamte Programmlogik ohne Duplizierung vor. Dateien, die so organisiert sind, dass sie das Teilen und Wiederverwenden von Dokumenten fördern.

Die pragmatischen Anforderungen der Kommunikation in einer verteilten Umgebung mit mehreren Teams legen nahe, dass mehrere unabhängige Repositorys vorhanden sein sollten, eines für jedes Projekt oder jede Zusammenarbeit.

Ich würde mich diesem Problem nähern, indem ich mich dem Unvermeidlichen unterwerfe: Sie müssen beide Ansätze gleichzeitig verfolgen, und wir werden Scripting und Automatisierung verwenden, um die Tatsache zu glätten, dass die Ansätze widersprüchlich sind.

:-)

Das eine einheitliche Repository ist Ihre einzige maßgebliche Quelle. Der Erstellungsprozess für jedes Projekt kopiert alle von diesem Projekt verwendeten Dateien (und nur diese Dateien) an einen Zwischenspeicherort und erstellt dann von diesem Zwischenspeicherort aus. (Unison oder ein ähnliches Tool kann verwendet werden, um Deltas anstelle ganzer Dateien zu verschieben.)

Diese Zwischenspeicherorte können als lokale Arbeitskopien für den Satz von sekundären, abgeleiteten oder nachgeschalteten Repositorys verwendet werden. Post-Commit-Hook-Skripte im autorisierenden Repository aktualisieren alle Zwischenspeicherorte und überprüfen nacheinander, ob sie geändert wurden, und führen dasselbe Commit für das entsprechende sekundäre Repository durch, wenn eine Änderung festgestellt wird.

Auf diese Weise werden die mehreren sekundären Repositorys mit dem einzelnen autorisierenden Quellrepository synchronisiert, und der Erstellungsprozess stellt sicher, dass die sekundären Repositorys alle (möglicherweise freigegebenen) Dokumente und anderen Dateien enthalten, die für den erfolgreichen Build erforderlich sind. Schließlich und vor allem stellt der Entwicklungs- und Erstellungsprozess sicher, dass Dateien an einem Ort und nur an einem Ort bearbeitet werden und dass alle Kopien konsistent und aktuell bleiben.