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?

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ß.

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 .

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.

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!

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.