it-swarm.com.de

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ängigkeit erhöht"?

Ich helfe bei der Leitung eines externen Teams, das mit der Entwicklung neuer Versionen einiger vorhandener Produkte beginnt. In der Vergangenheit hat dieses Team immer ein Modell eines einzelnen Projekts in einer einzigen Lösung für etwa 30 Module in Visual Studio verwendet, die zusammen einen bereitstellbaren Build erstellen.

Dies wirkt sich nachteilig auf die Zuverlässigkeit und Qualität des Builds aus, da sie uns nicht immer den aktuellsten Quellcode senden. Wir versuchen, sie zu drücken, um den gesamten Code, auf den verwiesen wird, zu einer einzigen Lösung zusammenzufassen, aber wir bekommen einen gewissen Widerstand - insbesondere sprechen sie immer wieder davon, dass die gegenseitige Abhängigkeit zwischen Modulen (lesen Sie "Projekte" in Visual Studio) zunimmt, wenn alles platziert 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 betreffende Team führt auch Bugfix- und neue Funktionsentwicklungen für ein vorhandenes Produkt durch, dessen Erfahrung gelinde gesagt sehr umfangreich war und genau das gleiche Problem hat, mehrere Lösungen aufzuteilen. Uns wurde der Zugriff auf ihre Quellcodeverwaltung verweigert ( TFS ), und der Ansatz zur Vereinheitlichung der Codebasis besteht darin, zu versuchen, die Codebasis zumindest zu reduzieren Anzahl der fehlenden Updates und mehr als gelegentliche Regressionen (ja, behobene Fehler werden immer wieder in das Produkt eingeführt), indem Sie sagen: "Senden Sie uns eine Zip-Datei des gesamten Lösungsordners, damit wir sie entpacken, in Visual Studio öffnen und drücken können." F5 zum Testen ". In Bezug auf die allgemeine Struktur und Qualität ist der Code ziemlich schlecht und schwer zu unterstützen. Aufgrund dieser Erfahrung bin ich bestrebt, die Arbeitsprozesse so früh wie möglich im Entwicklungszyklus richtig zu gestalten.

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

26
DrMistry

Sie müssen ihnen nicht sagen, wie sie ihre Projekte strukturieren sollen. Machen Sie es stattdessen zu einer harten Anforderung, dass Sie das System aus dem Quellcode erstellen können, indem Sie ein einziges Skript ausführen, ohne Fehler zu erhalten. Wenn in diesen Skripten Visual Studio oder Msbuild oder andere Tools ausgeführt werden und diese einmal aufgerufen werden, sollten 50- oder 100-mal keine Rolle spielen.

Auf diese Weise erhalten Sie den gleichen "Vollständigkeitstest" 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 wenn Sie den gesamten Code in einer Lösung haben, wird dies auch nicht überprüft.

Als Antwort auf "Interdependenz zwischen Modulen wird erhöht, wenn alles in einer einzigen Lösungsdatei abgelegt wird" - dies ist beweisbar Unsinn, da das Hinzufügen von Projekten zu einer Lösung keine der Abhängigkeiten zwischen Projekten ändert, sind die Abhängigkeiten das Ergebnis einer Projektdatei, die auf eine andere verweist, was völlig unabhängig davon ist, welche Lösung auf welche Projektdatei verweist. Niemand hält dieses Team davon ab, beides zu haben - eine einzige Lösung, die auf alle Projekte verweist, und auch individuelle 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. So können Sie beispielsweise 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 den Build abzuschließen. Siehe auch F5 ist kein Build-Prozess! und The Joel Test .

55
Doc Brown

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

Im Entwicklungsteam, zu dem ich gehöre, haben wir unabhängige Bibliotheken, die in mehreren Produkten als separate Lösung verwendet werden. In diesem Fall ist es sinnvoll, dass wir sonst Anwendung A kompilieren müssten, um Anwendung B auf dem neuesten Stand zu halten. Dies kann erforderlich sein, um Anwendung 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 Bibliothekslösung erstellen, um den gemeinsam genutzten Code in allen entwickelten Produkten auf dem neuesten Stand zu halten.

3
KeithN

Jedes Softwareunternehmen, für das ich jemals gearbeitet habe, hatte ein Kernentwicklungsteam, das die Hauptniederlassung für die grundlegenden Anwendungsfälle der Produkte des Unternehmens bereitstellte.

Zweigstellenentwickler, die das Kernrepository verwenden, sind dafür verantwortlich, Verbesserungen zu erkennen und Pull-Anforderungen zur Überprüfung an den Hauptzweig zu senden. Auf diese Weise wird man normalerweise zu einem 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 sofort "alle referenzierten Codes zu einer einzigen Lösung zu vereinheitlichen". Wenn sie dies vorschlagen, ohne ihre Budgetbeschränkungen zu verstehen, wird dies (zumindest) wahrscheinlich verhindern, dass jemand zum Kerningenieur wird.

Formulieren Sie also Ihre großartige Vision in ein paar verheerenden Pull-Anfragen bis ins Mark und bereiten Sie sich darauf vor, sich im Rückblick zu verteidigen!

1

Die Behauptung "Die Verwendung einer einzigen Lösung für mehrere Projekte erhöht die Komplexität der gegenseitigen Abhängigkeit" enthält einen Kern der Wahrheit.

Eine einzelne Lösung erleichtert das Referenzieren eines Projekts aus einem anderen Projekt (d. H. Das Wiederverwenden des Codes eines Projekts a.k.a. "Einführung der Interdependenzkomplexität"):

  • anstatt Ihren gesamten Dateisystem-/globalen Assembly-Cache nach der Assembly zu durchsuchen, auf die verwiesen wird, können Sie das Projekt aus einer begrenzten Anzahl relevanter Projekte in der Lösung auswählen. und,
  • beim Lesen von Quellcode ist es viel einfacher, zu einem referenzierten Projekt in der Lösung zu springen als zu einer beliebigen (binären) Assembly.

In den Händen eines undisziplinierten Teams kann die Verwendung mehrerer Projekte in einer einzigen Lösung zu vielen nachlässig eingeführten Abhängigkeiten führen. Ein Team kann jedoch besser versuchen, die erforderliche Disziplin zu erlernen, um die Abhängigkeiten sorgfältig zu verwalten, und dann die einfache Wiederverwendung nutzen, die die Verwendung von Lösungen bietet.

0