Hinzufügen von Dateien zur DPR-Datei im Vergleich zu Projektpfaden in Delphi 2010

Wenn all Ihre Einheiten explizit im dpr enthalten sind, werden die Kompilierungszeit, Code-Vervollständigung, Fehlereinsicht und die allgemeine Navigation erheblich verbessert.
Es hindert Sie nicht daran, Ihre Dateien in Ordnern und Unterordnern zu organisieren, aber verlassen Sie sich nicht auf die verschiedenen Pfade, um sie zu finden.
Bei einem großen Projekt mit Millionen LOC macht es einen großen Unterschied.

Ich bin dafür, "Bibliothekseinheiten" von "Projekteinheiten" zu trennen und alle "Bibliothekseinheiten" im Suchpfad zu halten, mit allen "Projekteinheiten" in der Projektdatei. Hier ist warum:

• Unsere Branchenprojekte sind große, fast Millionen-LOC-Projekte, aber neben diesen gibt es buchstäblich Hunderte von kleineren Projekten für alle möglichen kleinen Dinge. Wenn die "Bibliothekseinheiten" im Suchpfad verfügbar sind, ist es sehr einfach, diese Einheiten einfach zu verwenden, ohne sie dem Projekt hinzuzufügen: Ein Schritt weniger, der summiert!
• Die Verwendung des Suchpfads erleichtert das Verschieben von PAS-Dateien. Das ist mir wichtig, da ich gerade dabei bin, unsere gesamte "Build-Umgebung" neu zu organisieren, um Versionskontrollsysteme besser zu nutzen.
• Wenn Sie eine der gemeinsam genutzten Einheiten ändern und sie abhängig von einer anderen gemeinsam genutzten Einheit wird, müssen Sie nicht viele Projekte aktualisieren, sie funktionieren einfach.
• Ich würde niemals in Erwägung ziehen, Drittanbieterkomponenten (oder VCL-Komponenten) zu meinem Projekt hinzuzufügen. Warum also meine "Bibliothekseinheiten" zu dem Projekt hinzufügen? Wir müssen irgendwo die Grenze ziehen, denn wenn wir dem Projekt absolut alle Dateien hinzufügen würden, in der Hoffnung auf schnellere Kompilierzeiten, würden wir unhandlich große Projekte haben!
• Delphi ändert automatisch den Namen der Dateien in der DPR-Datei in relative Dateinamen. Aus diesem Grund können Sie Ihr Projekt nicht wirklich von seiner aktuellen Position aus verschieben. Versuchen Sie nun, "verzweigen" und zwei Kopien des Projekts gleichzeitig auf demselben Rechner (ein "Release" und ein "Work-in-Progress") am Leben zu erhalten. (Das ist meine Aufgabe, meine Build-Umgebung für GIT vorzubereiten, mit dem einzigen Ziel, BRANCH zu machen).

Als Referenz sind meine "Bibliothekseinheiten" jene Einheiten, die in nicht verwandten Projekten verwendet werden (denke an Komponenten und Dienstprogramme).

Ich würde dafür plädieren, alle Dateien einzuschließen, die das Projekt im Projekt selbst verwendet. Dies verbessert die Leistung der "Einblicke", indem sichergestellt wird, dass gebrauchte Einheiten Teil des Projekts sind. Darüber hinaus können Sie damit Ihren Code im Projektmanager einfacher verwalten. Große, komplizierte Pfade zu haben ist fragil und kann schwer zu verwalten sein.

Die Kommentare über die Beschleunigung von Einsichten haben mich fasziniert und ich werde es versuchen, aber bis jetzt habe ich niemals gemeinsame Einheiten in die Projekte aufgenommen, die sie benutzt haben. Stattdessen habe ich Pakete für jede Bibliothek erstellt und sie der Projektgruppe hinzugefügt (meistens nur für organisatorische Zwecke, d. H. Ich kompiliere sie nie als Laufzeitpakete). Ich fand das einfacher zu verwalten (besonders mit all den letzten Verbesserungen im Projektmanager), als alle Dateien in einem Projekt zu haben, da die Ordnerhierarchien innerhalb der einzelnen (Paket-) Projekte nicht so tief sind und besonders keine ".. "-Ebene auf diese Weise.

Gründe, nicht alle Dateien in das Projekt aufzunehmen:

• weniger Zeit zum Öffnen / Schließen eines Projekts (Formulare und Datamodule benötigen zusätzliche Zeit)
• schnellere Refactoring-Funktionen (Umbenennen / Verschieben von Dateien und Verzeichnissen erfordert nicht das Bearbeiten aller Projekte)
• einfacher zu finden die Einheiten, die die Kernanforderungen sind und die Einsprungstelle für die Anwendungslogik ( uses MyInterfaces, MyTypes, MymMainUnit; )

Und dieser QC-Eintrag:

  

Bericht Nr: 77687 (RAID: 273031)
  Status: Öffnen Bearbeiten im .dpr   Quelle wird langsamer mit mehr Einheiten in   das Projekt    Ссылка

Update: Jetzt weiß ich, dass es viele Möglichkeiten gibt, die Projektdatei zu öffnen :) - Aber mein Punkt ist, dass es in einem dpr mit 500 Einheitenreferenzen schwierig ist, die "wichtigen" (oder "Haupt") Einheiten zu finden Dies ist der Ausgangspunkt für einen Drilldown in die Quelle - und es ist einfacher, Code zu untersuchen, wenn es sich um eine "leichte" Projektdatei handelt, die nur die erforderlichen Einheitenreferenzen enthält.