Wie rentabel ist es, eine einzige Webanwendung über mehrere private kleine Repositories zu haben?

8

Wir sind ein Low-Budget-Team, das an einer Web-App arbeitet. Aufgrund einiger Komplikationen müssen wir möglicherweise ab Januar remote arbeiten. Nach einigen Beratungen und Googeln kamen wir zu dem Schluss, dass mehrere kleine Repositories die billigere Option sind. Wir denken in:

  • Backend und Services

  • Middleware

  • Vorderes Ende

Auf diese Weise können wir uns in relevanten Teams trennen, die jeweils remote in ihrem Repository arbeiten. Wie rentabel ist es, unsere App in mehreren privaten kleinen Repositories zu haben?

Welche Überlegungen sollten wir zusätzlich treffen, wenn wir auf diese Weise arbeiten würden?

Hinweis: Ich frage nach einem einzelnen großen Projekt, das auf mehrere kleine Repositorys verteilt ist. Dies unterscheidet sich von den auf dieser Site gestellten Fragen , da mehrere Projekte in einem oder mehreren Repositorys angefordert werden. Darüber hinaus haben wir uns für das Projekt entschieden, vor allem, weil wir nicht bereit sind, ein einziges großes privates Repository zu investieren, es sei denn, wir bleiben dabei.

Silber
quelle
Meinen Sie mit Repository Code-Repository (ala git oder svn)?
Jay Elston
Scant hat insofern Recht, als die Aufteilung des Teams ein viel größeres Problem darstellt als die Aufteilung des Repos. Das Team, in dem ich arbeite, hat ein paar Dutzend Repos, aber wir sind immer noch ein Team.
Ixrec

Antworten:

4

"... wir sind zu dem Schluss gekommen, dass mehrere kleine Repositories die billigere Option sind."

Das ist großartig. Teilen und erobern. Sie teilen die Anstrengung in logische Teile auf, geben jedes Teil einem anderen Hardcore-Team, arbeiten ein paar Monate wie verrückt, bringen alles zusammen und ...

und...

Nun, es wird ein verdammter Albtraum. Es wird definitiv nicht billiger sein. Warum sollte es sein?

Die größten "Kosten" in einem Softwareprojekt sind Kommunikation. Sie sparen kein Geld, indem Sie Code schneller schreiben. Das geben die geheimen Programmierer nicht zu. ( Psst. Sagen Sie es niemandem. Es spielt wirklich keine Rolle, wie schnell Sie Code schreiben. ) Die Zeit, die Sie mit dem Schreiben von Code verbringen, wird durch die Zeit, die Sie mit Planen und Reden und Verhandeln und Kämpfen und Reden und Treffen und Reden verbringen, absolut in den Schatten gestellt Kompromisse eingehen und erkennen, dass Sie keine Kompromisse eingehen und versprechen sollten, es besser zu machen und zu schreien und zu wünschen und zu "lösen" (das ist kein Wort, verdammt) und sich zurückzuschleifen und zu pingen und zu sprechen und nicht schlafen zu können.

Sie teilen Ihre Arbeit also in einzelne Teile auf und geben jeden Teil an ein separates Team weiter. Was hast du gerade getan? Sie haben die Kommunikationslast erhöht. Wenn du Glück hast undIhre Teams sind perfekt, es gibt absolut keinen Kostenunterschied zwischen einem großen Repository und einigen kleinen Repos. Wenn Sie kein Glück haben (nur wenige), kostet das Aufteilen in separate Teams tatsächlich mehr. Es ist schwer genug, synchron zu bleiben, wenn Sie alle in derselben Codebasis sind und sich gegenseitig auf die Zehen treten. Stellen Sie sich nun vor, wie schwierig es sein wird, wenn drei verschiedene Teams der Meinung sind, dass die Anforderungen etwas anderes bedeuten (ohne dass eine schnelle Korrektur möglich ist, weil sie nicht das Zeug der anderen Teams brechen), leicht unterschiedliche Kulturen haben und am Ende sind Sehr motiviert, Schuldzuweisungen zu vermeiden, wenn etwas schief geht, und sie sind mehr als bereit, die anderen Teams unter den Bus zu werfen.

Ich weiß, ich weiß ... deine Teams sind besser als das. Aber sind sie es wirklich? Sind Sie zuversichtlich genug, Geld darauf zu setzen?

Schauen Sie, in beiden Ansätzen (großes Repo / viele kleine Repos) müssen Sie am Anfang eine Menge Mist verspotten. Du fängst an blind zu arbeiten. Sobald sie verfügbar sind, sollten Sie konkrete Implementierungen aus den anderen Ebenen verwenden. Dadurch werden Probleme und Missverständnisse frühzeitig erkannt. Sicher, es wird ein wenig holprig sein, aber es ist verdammt viel weniger holprig, als sich unabhängig mit einer wackeligen Spezifikation und einem Handschlag zu entwickeln und die Dinge dann spät zusammenzufalten.

Mein Punkt ist, große Repo / kleine Repos sind nicht das Problem. Entscheidend ist, wie Sie Ihre Teams strukturieren. Im Idealfall haben Ihre Teams kleine unabhängige Identitäten innerhalb einer größeren zusammenhängenden Identität. Ein bisschen wie Organe in einem Organismus oder vielleicht eine Schleimpilz . Unabhängig davon, wie Sie den Code strukturieren, geben Sie jedem die Möglichkeit, sich zu begegnen. Machen Sie die Kommunikation einfach. Machen Sie gemeinsam Fehler und beheben Sie sie früh und häufig.

Scant Roger
quelle
Ich bin mit den meisten dieser Antworten nicht einverstanden. Kommunikation ist natürlich wichtig, aber; Nur weil Sie die Codebasis in mehrere Repositorys aufteilen, gibt es: 1. Zusammenarbeit - Mitarbeiter können die Codebasis anzeigen (und bei Bedarf ändern), 2. Dokumentation . Wenn Sie eine REST-API separat vom Frontend erstellen, kann die API sehr gut dokumentiert werden und es entstehen keine Probleme (es sei denn, Sie haben wirklich unerfahrene Front-End-Entwickler oder Mistdokumentation). Wie soll ich wissen? Ich schreibe / pflege eine REST-API, die von Drittentwicklern verwendet wird, und erhalte möglicherweise eine E-Mail pro Woche über die Verwendung.
Chris Cirefice
@ ChrisCirefice Das ist ein ganz anderer Ansatz. Es ist eine andere Art von Tier, ein System gemeinsam zu entwickeln, als einen Teil davon zu entwickeln. In Ihrem Fall passen sich Front-End-Entwickler Ihren Entscheidungen an, aber im Fall von op werden die Back-End-Entscheidungen parallel zu den Anforderungen und Wünschen des Front-End getroffen
Machinarius
@Machinarius Das ist mehr oder weniger wahr. Mein Chef verspottet das Frontend und trifft alle Entscheidungen darüber, wie die App aussehen / funktionieren soll. Die Frontend-Entwickler beginnen mit der Arbeit am Skelett, ich entwickle die erforderlichen API-Endpunkte im Backend, und die Frontend-Leute schließen dann API-Aufrufe an, um die Daten parallel abzurufen. Dies geschieht von Woche zu Woche, daher sehe ich in meinem Fall keinen großen Unterschied, und es funktioniert immer noch einwandfrei. Separate Entwickler arbeiten gemeinsam an verschiedenen Aspekten, obwohl dies in meinem vorherigen Kommentar offensichtlich nicht erwähnt wurde.
Chris Cirefice
Unser Team hat einen Backender, einen Mann für das Schreiben und die Wartung der Dienste, zwei Front-Ender, zwei Leute, die an der mobilen Version arbeiten, und den Teamleiter, auch unseren Chef, der dafür verantwortlich ist, dass die Dinge funktionieren. Wir berühren kaum einen Code außerhalb ihres Bereichs. Die Kommunikationsprobleme sind wie bei jedem Team real, aber die Aufteilung des Teams ist kein Problem, da wir bereits unabhängig arbeiten. Vielen Dank für Ihre Antwort, da ich dem Teamleiter einige Einblicke geben konnte.
Silber
1

In meinen Augen hängt die Aufteilung des Repositorys stark von Ihren Zielen und den von Ihnen verwendeten Tools ab.

Wenn Sie beispielsweise eine Ruby on Rails-Webanwendung ohne öffentliche (oder private) API schreiben, die Ihr Frontend verwenden wird (z. B. von AJAX), sehe ich eigentlich nicht, ohne wie Sie das Repository aufteilen könnten verursacht massive Kopfschmerzen für Ihr Team. Das Rails-Framework funktioniert in diesem Fall am besten mit einer monolithischen Architektur.

Wenn Sie jedoch vorhaben, eine API in Rails oder Node.js zu schreiben, Ihr Frontend jedoch in Ember.js oder etwas anderem geschrieben werden soll, ist es sinnvoll, das Repository aufzuteilen. Gleiches gilt, wenn Ihre Web-App-Daten zukünftig von anderen Clients geteilt werden (z. B. über eine Android / iOS-App). Wenn Sie vorhaben, eine API zu schreiben, die von mehreren Clients verwendet werden soll, teilen Sie Ihr Repo auf. Einige würden argumentieren, dass es eine schlechte Idee ist, die API sogar vollständig in eine andere Anwendung aufzuteilen, was ich von ganzem Herzen ablehne (und das scheint aus gutem Grund so zu sein !

Das Aufteilen des Repositorys, wenn Sie bereits vorhatten, die Web-App wie beschrieben zu trennen, ist die einzig logische Option. Beachten Sie jedoch, dass Sie, da es für die Benutzer schwieriger ist, den Code des anderen zu durchsuchen, sicherstellen müssen, dass Sie über eine hervorragende Kommunikation , aber vor allem über eine Dokumentation verfügen . Ohne die API zu dokumentieren, werden Ihre beiden anderen Teams zum Beispiel sehr schnell sauer sein, weil das API-Team die Architektur nicht dokumentiert hat, und Ihr API-Team wird sauer sein, weil alle ihnen immer wieder Fragen stellen. Dies gilt umso mehr für entfernte Teams .

Es hängt also alles davon ab, wie Sie die App überhaupt strukturieren wollten. Wenn Sie eine monolithische Web-App erstellen (und Sie wissen oder sicher sind, dass es sich nur um eine Web-App handelt ), verfügen Sie über ein Repository. Wenn Sie beispielsweise Microservices oder eine REST-API erstellen möchten, die von mehreren Clients verwendet wird (oder dies für die Zukunft planen ), teilen Sie das Repo auf.

Chris Cirefice
quelle
Ein einzelnes Repo muss kein Monolith sein. Physische und logische Ebenen können in separaten Repos gespeichert werden, müssen es aber nicht. Ein einzelnes Repo kann eine Backend-API sowie andere Ebenen enthalten. Die Kommunikationslast (Dokumentation ist Teil der Kommunikation) ist bei einem großen Repo oder mehreren kleinen Repos nicht mehr oder weniger groß. Das ist mein Punkt - die Repos spielen keine Rolle. Was zählt, ist, wie Ihr Team / Ihre Teams über Probleme denken und zusammenarbeiten, um sie zu lösen.
Scant Roger
Wir haben die App bereits in verschiedene Einheiten unterteilt. Das Backend und die Services sind auf einer Seite. Das Frontend verwendet die Dienste nur über den Client. Unsere Front-Ender wissen nur, wie die Services funktionieren. Unser Team hat einen Backender, einen Mann für das Schreiben der Dienste, zwei Front-Ender und zwei Leute, die an der mobilen Version arbeiten, und sie berühren kaum Code außerhalb ihres Bereichs.
Silber