Von Projekt zu Projekt stellen wir fest, dass unser Code dieselben Funktionen ausführt und fast gleich aussieht. Das wundert uns - machen wir nicht die zusätzliche Arbeit, indem wir dasselbe umschreiben? Wir beginnen, Klassen aus früheren Projekten zu kopieren und verstehen immer noch, dass wir etwas falsch machen und richtig sind. Wenn wir nur Klassen aus einem Projekt in ein Projekt kopieren, können wir leicht etwas verlieren / ersetzen / löschen, und wenn unser Team ein paar mehr führt Projekte gleichzeitig, dann erfordert die Fehlererkennung in ausgeliehenen Klassen manuelle Änderungen in allen Projekten. Wir sind es leid, auf diesen Rechen zu treten, und entscheiden, dass wir einen gemeinsamen Code benötigen, der für alle unsere Projekte freigegeben wird und dessen Änderungen leicht abgerufen werden können. Ja, wir erstellen unsere Bibliothek mit wiederverwendbaren Komponenten! Sie lernen verschiedene Arten der Organisation Ihrer Bibliothek kennen, alle Vor- und Nachteile von Ansätzen unter cat :)

Es gibt verschiedene Möglichkeiten, unsere gemeinsame Codebasis zu organisieren:

1. Android-Bibliothek (aar / jar)
2. Git-Submodul
3. Git-Teilbaum

Android-Bibliothek (aar / jar)

Jede Bibliothek für unsere Anwendung besteht nur aus vielen Klassen, die auf eine bestimmte Weise organisiert sind. Jedes Mal, wenn wir Retrofit oder Dagger in build.gradle verbinden , laden wir die Bibliothek als aar / jar-Archiv von einer der Bibliotheksveröffentlichungsplattformen. Die beliebtesten Veröffentlichungsplattformen für Bibliotheken sind JCenter und MavenCentral. Die Entwickler der Bibliothek arbeiten in ihrem Repository an der neuen Version. Wenn die Version bereit ist, in die Welt hinauszugehen, veröffentlichen sie sie auf einer der Plattformen und sagen: "Hey, wir haben eine neue Version unserer Top-Bibliothek veröffentlicht!". Für Entwickler, die diese Bibliothek in ihren Projekten verwenden, bleibt nur noch die Version in build.gradle zu ändern und neue Funktionen zu nutzen. Ist es bequem? Falsches Wort!

Aber wie bequem ist dieser Ansatz, wenn unsere Bibliothek jeden Tag von verschiedenen Entwicklern aus verschiedenen Projekten unseres Teams entwickelt und mit neuen Funktionen aktualisiert wird? Mal sehen, wie es in der Praxis aussieht.

Wir erstellen ein Repository unserer Bibliothek, tragen dort einige Funktionen bei, debuggen es und sind bereit, es mit unserem Team zu teilen. Dann lernen wir Wörter wie JCenter, MavenCentral, Bintray, Jitpack.io kennen. All dies sind Plattformen für die Veröffentlichung von Bibliotheken. Jetzt ist JCenter die Hauptplattform für Android-Projekte. Wenn Sie ein Projekt erstellen, sehen Sie, dass in der Datei build.gradle (Projektebene) in den Repositorys JCenter angegeben ist

repositories { google() jcenter() } 

Das heißt, wenn der Entwickler Ihre Bibliothek verbinden möchte, reicht es aus, sie mit der Modulebene build.gradle zu verbinden.

Der einfachste Weg, die Bibliothek für mich zu veröffentlichen, scheint Jitpack.io zu sein, ein paar Schritte und Ihre Bibliothek ist einsatzbereit.

So organisieren Sie die Teamarbeit in der Bibliothek

Wenn wir eine Bibliothek erstellt und in das Repository hochgeladen haben, hat der Rest unseres Teams nur das empfangene jar / aar-Archiv. Damit das gesamte Team an jedem arbeiten kann, muss jeder Entwickler das Bibliotheksrepository entleeren und Änderungen daran vornehmen.

Versionierung

Bei der Entwicklung und Verwendung von Bibliotheken muss man sich mit einem Konzept wie der Versionierung befassen. Das heißt, die Änderungen in der Bibliothek, die wir veröffentlichen möchten, müssen durch die Version festgelegt werden. Dies hilft beim Aktualisieren der Bibliothek auf eine neue Version, um zu verstehen, wie schwerwiegende / brechende Änderungen dank des übernommenen Versionsschemas vorgenommen wurden.

Überprüfen der Bibliothek im Projekt

Um zu überprüfen, ob die vorgenommenen Änderungen dem entsprechen, was wir beabsichtigt haben, muss das Verhalten des geschriebenen Codes im Projekt überprüft werden. Wir erhöhen die Version der Bibliothek und ... hier ist einer der Engpässe dieses Ansatzes. Unsere Bibliothek und das Projekt befinden sich in verschiedenen Repositorys, was bedeutet, dass wir nicht nur Bibliotheksklassen im Projekt erhalten können. Wir haben zwei Möglichkeiten, um den neuen Bibliothekscode zu überprüfen:

1. Erstellen Sie im Beispielbibliotheksprojekt ein Modul, in das Code geschrieben wird, der die Funktionalität der Bibliothek überprüft. Die Option ist einfach, aber es gibt 2 Minuspunkte: 1. Wir schreiben zusätzlichen Code; 2. Die Umgebung des Testmoduls unterscheidet sich von dem tatsächlichen Projekt, in dem wir die Bibliothek verwenden. Wenn wir Fehler machen, wird sie angezeigt, wenn wir eine neue Version des Projekts erhalten.
2. Veröffentlichen Sie Änderungen im lokalen mavenLocal- Repository. Dank dieses Ansatzes können Sie einen neuen Code im Projekt erhalten, der jedoch nicht für das gesamte Team veröffentlicht wird (Sie müssen jedoch ein wenig am Setup basteln).

Git-Submodul

Beim vorherigen Ansatz hatten wir die Schwierigkeit, in der Entwicklungs- / Debugging-Phase des Projekts neuen Code zu erhalten, da sich die Bibliothek und der Projektcode in verschiedenen Repositorys und Studio-Projekten befinden. Der Git-Submodul-Ansatz beinhaltet auch die Verwendung separater Repositorys, ermöglicht es dem Hauptprojekt jedoch, die Bibliothek mithilfe von Git als Modul abzurufen. Dies bedeutet, dass der Bibliothekscode im Projekt verfügbar ist und alle Änderungen sofort im Projekt verfügbar sind!

Wie funktioniert es?

Mit Submodulen können Sie ein Git-Repository als Unterverzeichnis eines anderen Git-Repositorys enthalten. Auf diese Weise können Sie ein anderes Repository innerhalb des Projekts klonen und die Commits für dieses Repository separat speichern.

Einfach ausgedrückt, wir haben 2 Repositories: ein Projekt und eine Bibliothek. Das Projekt-Repository speichert den Bibliothekscode und einen Link zum Status des Bibliotheks-Repositorys. Git versteht also, welchen Status (welche Version) der Bibliothek das Projekt benötigt.

Lesen Sie hier mehr darüber, wie Git Submodule funktioniert .

So organisieren Sie Teamwork

Beim Git-Submodul-Ansatz ist die Teamarbeit an der Bibliothek wie folgt organisiert:

1. Beim Erstellen eines neuen Projekts oder beim Verbinden einer Bibliothek mit einem vorhandenen Projekt wird ein neuer Git-Zweig vom Master mit dem Namen des Projekts erstellt.
2. Wenn es an der Zeit ist, die Bibliothek mit einigen Funktionen aufzufüllen, wird ein Zweig für die Aufgabe (aus dem Projektzweig) erstellt und dort werden Änderungen vorgenommen.
3. Eine Überprüfung wird durchgeführt, Pools werden in die Projektniederlassung gegossen. Wenn genügend Änderungen eingegeben wurden, um die Version freizugeben, wird beim Zusammenführen des Projektzweigs im Hauptzweig der Bibliothek ein Pool erstellt.
4. Nachdem der Pool die Überprüfung durch das für die Bibliothek zuständige Team bestanden und in den Hauptzweig eingegossen hat, werden die verbleibenden Projektteams über das angezeigte Bibliotheksupdate informiert und entscheiden über das Update.

Versionierung

Wenn der Pool in den Master gegossen wurde und die Teams über das Bibliotheksupdate informiert werden, wissen sie nicht, wie global die Änderungen in der neuen Version sind. Schließlich erfordert der Ansatz mit Git Submodule kein Versionsschema. Dieses Problem lässt sich jedoch leicht durch die Einführung eines Versionsschemas lösen. Sie müssen lediglich eine Version und eine Beschreibung der Änderungen schreiben und zur Beschreibung der Poolanforderung im Hauptzweig hinzufügen. Dann werden die Entwickler verstehen, wie viel sie jetzt wirklich auf die neue Version der Bibliothek aktualisieren können. Es klingt großartig, aber die Frage ist:

Ja, das Studio weiß nicht, wie es sich separat auf die durch das Submodul verbundene Bibliothek festlegen soll. Ich benutze SourceTree, um dieses Problem zu lösen. Diese Anwendung ist für Windows und Mac und für Linux gibt es GitKraken.

Git-Teilbaum

Git Subtree ist eine erweiterte Version von Git Submodule. In Git Subtree haben sie versucht, die Probleme zu lösen, auf die Entwickler bei der Arbeit mit Git Submodule gestoßen sind. Es gibt einen guten Artikel auf dem Hub, der die Unterschiede zwischen den Tools beschreibt. Obwohl sie unterschiedlich arbeiten, lösen sie ein Problem.

Fazit

Git Submodule / Subtree-Tools eignen sich hervorragend zur Lösung des Problems der Erstellung einer gemeinsamen Codebasis für ein Team, das an mehreren Projekten beteiligt ist. Einer der wichtigen Vorteile ist die sofortige Überprüfung des neuen Codes im Projekt nach Änderungen an der Bibliothek. In dieser Hinsicht ist der Standardansatz zum Veröffentlichen einer Bibliothek in JCenter oder MavenCentral minderwertig. Wenn Sie das Git-Submodul / den Teilbaum zu Ihrem Team bringen möchten, denken Sie im Voraus über das Versionsschema nach und erstellen Sie Regeln / Plugins, um die Versionsverwaltung zu steuern.

Tolle Wiederverwendung für alle!