Warum sollte ein Entwicklungsteam darauf bestehen, dass die Verwendung einer einzigen Lösung für mehrere Projekte in Visual Studio die Komplexität der gegenseitigen Abhängigkeiten erhöht?

26

Ich helfe dabei, ein externes Team zu leiten, das mit der Entwicklung neuer Versionen einiger vorhandener Produkte beginnt. In der Vergangenheit hat dieses Team immer ein Modell eines einzelnen Projekts in einer einzelnen Lösung für ungefähr 30 Module in Visual Studio verwendet, die zusammen einen bereitstellbaren Build erstellen.

Dies wirkt sich nachteilig auf die Zuverlässigkeit und Qualität der Erstellung aus, da sie uns nicht immer den aktuellsten Quellcode senden. Wir versuchen, sie zu drängen, um den gesamten Code, auf den verwiesen wird, in einer einzigen Lösung zu vereinheitlichen, aber wir bekommen Widerstand - insbesondere wird immer wieder davon gesprochen, dass die Interdependenz zwischen Modulen (siehe "Projekte" in Visual Studio) zunimmt, wenn alles in eine einzige Lösung eingefügt wird eine einzelne Lösungsdatei. Keiner der Codes in den separaten Lösungen wird an anderer Stelle verwendet.

Ich bestehe darauf, dass dies Unsinn ist und gute Entwicklungsmuster ein solches Problem vermeiden.

Das fragliche Team führt auch Bugfixes und die Entwicklung neuer Funktionen für ein vorhandenes Produkt durch, dessen Erfahrung gelinde gesagt beschwerlich ist und an dem genau das gleiche Problem der Aufteilung auf mehrere Lösungen leidet. Der Zugriff auf die Quellcodeverwaltung ( TFS ) wurde verweigert. Um die Codebasis zu vereinheitlichen, versuchen wir, die Anzahl der fehlenden Aktualisierungen und mehr als nur gelegentliche Rückschritte zu verringern (ja, behobene Fehler werden behoben) -In das Produkt eingeführt), indem Sie "Senden Sie uns eine ZIP-Datei des gesamten Lösungsordners, damit wir die Datei entpacken, in Visual Studio öffnen und drücken könnenF5 zum Testen ". In Bezug auf die allgemeine Struktur und Qualität ist der Code ziemlich schlecht und schwer zu unterstützen. Aus diesem Grund bin ich bestrebt, die Arbeitsprozesse so früh wie möglich in den Entwicklungszyklus zu integrieren.

Fehlt mir etwas? Gibt es jemals einen guten Grund, den gesamten Code getrennt zu halten? Für mein Geld müsste es ein so zwingender Grund sein, dass es allgemein bekannt wäre, aber ich bin mehr als bereit zuzugeben, dass ich nicht alles weiß.

DrMistry
quelle
5
Wenn das Team extern ist, wird es schwierig sein, irgendetwas zu ändern. Anstatt sich auf das Problem zu konzentrieren, versuchen Sie, Ihre Idee voranzutreiben. Das Problem ist, dass sie uns nicht immer den aktuellsten Code senden, sondern das Problem auf die von ihnen bevorzugte Weise lösen. Können sie Ihnen keinen Zugang zum Versionskontrollsystem gewähren?
RMalke
9
Es klingt nach Unsinn. Die Projekte werden nicht mehr und nicht weniger voneinander abhängig sein, egal ob es sich um eine oder dreißig Lösungen handelt. Der Grund für die Speicherung von Code in separaten Lösungen liegt darin, dass die resultierende Bibliothek von mehreren, separat bereitstellbaren Builds verwendet wird. Das hört sich für Sie nicht so an.
David Arno
3
Es hört sich so an, als ob Sie viele nicht-technische Probleme haben, die am besten durch Änderungen an Ihrem Vertrag und Ihren Arbeitserklärungen gelöst werden können.
Ross Patterson
9
Das Erstellen einer einzelnen Lösung bedeutet nicht zwangsläufig, dass die einzelnen Lösungen aufgegeben werden müssen, da ein Projekt in mehreren Lösungen existieren kann.
Erik Eidt
6
Ich bin mir nicht sicher, warum Sie sich über technische Lösungen für etwas wundern, das im Wesentlichen ein Menschenproblem ist. Entlasse diese Leute und stelle Leute ein, die über einem mittelmäßigen Kompetenzniveau liegen. Das heißt, Sie zahlen mehr, aber es lohnt sich auf jeden Fall in Bezug auf die reduzierten Gesamtbetriebskosten in der IT. Je länger du festhältst, desto mehr wirst du leiden.
Brad Thomas

Antworten:

54

Sie müssen ihnen nicht sagen, wie sie ihre Projekte strukturieren sollen. Stellen Sie stattdessen eine harte Anforderung, dass Sie das System aus dem Quellcode erstellen können, indem Sie ein einziges Skript ausführen, ohne dass Fehler auftreten. Wenn dieses Skript Visual Studio oder Msbuild oder andere Tools ausführt und diese einmal aufgerufen werden, sollte es keine Rolle spielen, ob sie 50 oder 100 Mal ausgeführt werden.

Auf diese Weise erhalten Sie den gleichen "Test auf Vollständigkeit" des Codes, den Sie erhalten würden, wenn Sie alles in einer einzigen Lösung zusammenfassen würden. Natürlich sagt Ihnen dieses Skript nicht, ob das Team wirklich die neueste Version aus der Quellcodeverwaltung ausgecheckt hat, aber der gesamte Code in einer Lösung würde dies auch nicht überprüfen.

Als Antwort auf „gegenseitige Abhängigkeit zwischen den Modulen erhöht werden , wenn alles in einer einzigen Lösung Datei abgelegt wird“ - das ist proveable Unsinn, da Projekte zu einer Lösung Zugabe nicht eine der Abhängigkeiten zwischen den Projekten ändern, sind die Abhängigkeiten ein Ergebnis von einem Projekt Datei referenziert eine andere, die völlig unabhängig davon ist, welche Lösung auf welche Projektdatei verweist. Keiner hält dieses Team davon ab, beides zu haben - eine einzige Lösung, die auf alle Projekte verweist, und auch einzelne Lösungen, die jeweils nur auf ein Projekt verweisen.

Trotzdem würde ich vorschlagen, ein Build-Skript hinzuzufügen. Dies hat auch dann Vorteile, wenn nur eine Lösungsdatei vorhanden ist. Beispielsweise können Sie einen VS-Build mit einer bevorzugten Konfiguration ausführen, die endgültigen Dateien für die Bereitstellung (und nichts weiter) in einen "Bereitstellungs" -Ordner kopieren und möglicherweise einige andere Tools und Schritte ausführen, um die Erstellung abzuschließen. Siehe auch F5 ist kein Build-Prozess! und der Joel-Test .

Doc Brown
quelle
Ja, ich bin damit einverstanden, dass F5 kein Build-Prozess ist, aber wir möchten den Code innerhalb des Entwicklerteams testen, bevor wir ihn aufgrund von Rückschritten und Aktualisierungsfehlern für End-to-End-Tests an unseren QA-Prozess übergeben. Wie gesagt, wir haben keinen Zugriff auf ihr TFS, daher müssen wir ihre Änderungen in unsere eigene Codebasis importieren und sie dann in TFS einchecken. Im Moment ist dieser Prozess so schlecht, dass das Ausführen von AutoBuild beim Einchecken eine reine Zeitverschwendung ist! Wir haben Autobuild für den Rest unseres Produkts und es funktioniert wirklich sehr gut für uns.
DrMistry
Ich wollte nur hinzufügen, dass "The Joel Test" Zeug ausgezeichnet ist und ich würde empfehlen, einen guten Blick zu haben. Vielen Dank!
DrMistry
3

Dies hängt davon ab, wie oft die kompilierten Assemblys wiederverwendet werden. Wenn es keine Wiederverwendung von Baugruppen gibt, gibt es keinen wirklichen Grund, die "Module" getrennt zu halten. Meiner Erfahrung nach ist dies eher ein Hindernis.

Im Entwicklungsteam, zu dem ich gehöre, verfügen wir über unabhängige Bibliotheken, die in mehreren Produkten als separate Lösung verwendet werden. In diesem Fall ist es sinnvoll, dass wir Anwendung A kompilieren müssen, um Anwendung B auf dem neuesten Stand zu halten. Dies kann erforderlich sein, um Application C auf dem neuesten Stand zu halten.

Jedes Produkt wird in einer eigenen Lösung aufbewahrt, auch wenn das Produkt aus mehreren Projekten besteht. Auf diese Weise müssen wir nur die Library-Lösung erstellen, um den gemeinsam genutzten Code in allen entwickelten Produkten auf dem neuesten Stand zu halten.

KeithN
quelle
Keines der Split-Out-Projekte wird irgendwo anders eingesetzt, das ist frustrierend. Sie werden alle in diesem einen Produkt verwendet und nirgendwo anders!
DrMistry
1

Jedes Software-Unternehmen, für das ich jemals gearbeitet habe, hatte ein Kern-Entwicklungsteam, das die Hauptabteilung mit den grundlegenden Anwendungsfällen der Produkte des Unternehmens versorgte.

Filialentwickler, die das Core-Repository verwenden, sind dafür verantwortlich, Verbesserungen festzustellen und Pull-Anforderungen zur Überprüfung an die Hauptfiliale zu senden. So wird man in der Regel zum Kernentwickler, indem man zeigt, dass man bessere Beiträge leisten kann, als nur die Flammen eines Architekturkonflikts zu entfachen.

Es ist wahrscheinlich, dass Ihr Unternehmen einfach nicht über die Ressourcen verfügt, um "den gesamten Code, auf den verwiesen wird, sofort zu einer einzigen Lösung zu vereinheitlichen". Wenn man ihnen vorschlägt, dies zu tun, ohne ihre Budgetbeschränkungen zu kennen, kann man (zumindest) verhindern, dass man ein Hauptingenieur wird.

Formulieren Sie also Ihre große Vision in ein paar verheerende Pull-Requests, und bereiten Sie sich darauf vor, sich in einem Review zu verteidigen!

Dominic Cerisano
quelle
0

Es gibt einen Kern der Wahrheit in der Behauptung "Die Verwendung einer einzigen Lösung für mehrere Projekte erhöht die Komplexität der gegenseitigen Abhängigkeiten".

Eine einzige Lösung erleichtert das Referenzieren eines Projekts aus einem anderen Projekt (dh das Wiederverwenden des Codes eines Projekts, auch bekannt als "Einführung der Komplexität von Abhängigkeiten"):

  • Anstatt das gesamte Dateisystem / den globalen Assemblycache nach der Assembly zu durchsuchen, auf die verwiesen wird, können Sie das Projekt aus einer begrenzten Anzahl relevanter Projekte in der Projektmappe auswählen. und,
  • Beim Lesen von Quellcode ist es viel einfacher, zu einem Projekt in der Projektmappe zu springen, auf das verwiesen wird, als zu einer beliebigen (binären) Assembly.

In den Händen eines undisziplinierten Teams, das mehrere Projekte in einer einzigen Lösung einsetzt, kann es daher zu vielen unachtsam eingeführten Abhängigkeiten kommen. Ein Team kann jedoch besser versuchen, die erforderliche Disziplin zu erlernen, um die Abhängigkeiten sorgfältig zu verwalten, und dann die Einfachheit der Wiederverwendung nutzen, die die Verwendung von Lösungen bietet.

Kasper van den Berg
quelle