Sollte von Entwicklern erwartet werden, dass sie vor dem eigentlichen Programm eine interne Bibliothek kompilieren?

Kürzlich hat ein leitender Entwickler, mit dem ich zusammenarbeite, dafür plädiert, dass Entwickler die neueste Version erhalten und im Rahmen ihres Projekts eine wichtige interne Bibliothek kompilieren müssen. Dies steht im Gegensatz zu dem Gegenargument, dass Projektteams an einer stabilen Version arbeiten sollten, die sie von einem internen Maven-Repository erhalten, für das der Entwickler argumentierte, dass die Verfügbarkeit des Quellcodes auf den Entwicklercomputern Zeit spart, da sie die Bibliotheksquelle lesen können Code, um festzustellen, ob die erforderliche Funktionalität verfügbar ist.

Hat der leitende Entwickler ein gültiges Argument? Oder müssen Entwickler den Quellcode der Bibliotheken lesen, was der Grundphilosophie der Kapselung zuwiderläuft und die Bibliothek überhaupt erst hat?

Das Argument dieses erfahrenen Entwicklers macht für mich keinen Sinn.

Sie möchten den Aufwand für das ständige Abrufen und Kompilieren einer internen Bibliothek erhöhen, damit Entwickler gelegentlich den Quellcode lesen können? Das wird viel mehr Zeit verschwenden, als wenn Entwickler den Quellcode nur dann ansehen, wenn sie überprüfen müssen, ob eine Funktion verfügbar ist.

Dies ist eine besonders schlechte Idee, wenn die Bibliothek und die Clients von verschiedenen Entwicklungsgruppen entwickelt werden und die Bibliothek aktiv entwickelt wird. Die Client-Entwickler haben keine Isolierung gegen Instabilität in der Bibliothek.

Ich verstehe nicht, warum Quellcode den Entwicklern nicht zur Verfügung gestellt werden kann, ohne sie zu zwingen, ihn als Teil ihres normalen Builds zu verwenden.

Der Vorschlag ist

Wir können Zeit sparen, indem clientseitige Entwickler den Quellcode der Bibliothek lesen, um festzustellen, ob die erforderlichen Funktionen verfügbar sind

Sie könnten einen alternativen Vorschlag machen

Wir können Zeit sparen, indem jemand die Bibliothek dokumentiert, um anzugeben, welche Funktionen verfügbar sind.

Ich würde das Argument nicht kaufen, dass die Möglichkeit, die Quelle lokal zu lesen, ein Vorteil ist, aber wenn sich die Bibliothek in der aktiven Entwicklung befindet (möglicherweise um Unterstützung für die Anforderungen Ihres Projekts hinzuzufügen), halte ich es nicht für unangemessen, Entwickler dazu zu verpflichten Laden Sie Updates regelmäßig herunter (möglicherweise mehrmals am Tag). Ich denke, es ist wirtschaftlich sinnvoller, eine kompilierte (und Unit-getestete) Binärdatei verfügbar zu machen, anstatt von Entwicklern die Kompilierung aus dem Quellcode zu verlangen.

Haben Sie in Ihrem Projekt die Möglichkeit, ein freigegebenes Repository einzurichten, in dem die neueste kompilierte Version verfügbar ist? Idealerweise möchten Sie einen CI-Server, der das Abrufen und Erstellen nach einem Zeitplan durchgeführt hat. Selbst wenn es sich nur um eine Netzwerkressource handelt, die von einem der Teamleiter für die regelmäßige Aktualisierung verantwortlich ist, kann dies hilfreich sein. Natürlich sollte dies auf dem Teller des Bibliotheksteams stehen, aber offensichtlich sind sie nicht interessiert, also müssen Sie ihre Lücke schließen.

Ich habe für eine große Softwarefirma gearbeitet, die ständig ihre eigene Software mit internen Geschäftssystemen "dogfooded" hat.

Sie sahen dies als eine weitere Teststufe an.

Dass ich für ein Unternehmen zustimme, ist eine gute Sache.

Ich denke, Sie zum Herunterladen und Kompilieren der neuesten Version zu zwingen, ist ein Schritt zu weit, es sei denn, der Kompilierungsschritt ist ein wichtiger Bestandteil des Angebots Ihres Unternehmens, eine Bibliothek zu verkaufen oder sogar auszulagern.

Obwohl die Verfügbarkeit des Quellcodes von Vorteil sein kann, ist es für einen CI-Build-Agenten, der das Repository überwacht, sinnvoller, diesen Agenten diese Bibliothek kompilieren und als externe in abhängige Projekte kopieren zu lassen, als dies von den Entwicklern zu verlangen Führen Sie beim Erstellen der Kopie zwei verschiedene Kompilierungsschritte aus.

Ich arbeite derzeit an einem Projekt, das nicht mit einem Build-Agenten verbunden ist. Dazu muss vor dem Erstellen der Hauptanwendung eine Unteranwendung erstellt werden. Es ist ein schwerer Schmerz in meinem Seitenzahn; Um eine Änderung an der Unter-App vorzunehmen, muss ich zuerst das gesamte Projekt erstellen, dann in einen Untererstellungsordner gehen, das kompilierte Produkt daraus holen und es in einen anderen Unterordner kopieren, bevor ich das gesamte Projekt WIEDER erstelle um sicherzustellen, dass die neueste Version der Unter-App im Build der Haupt-App enthalten ist. Dies ist NICHT, wie es gemacht werden sollte; Zumindest sollte es ein MSBuild-Skript geben, das diesen Prozess automatisiert, und ich würde es vorziehen, wenn der Build-Agent die externen Elemente aktualisiert, wenn neuer Code für den Trunk festgeschrieben wird.

Da so viele Leute geantwortet haben, dass es keinen Sinn macht, dass jeder eine interne Bibliothek erstellt, werde ich den entgegengesetzten Standpunkt vertreten, der die Gründe rechtfertigen könnte:

1. Sie nutzen die Bibliothek häufig und es gibt keine Dokumentation. Jeder sollte also die Quelle als Referenz haben. Wenn dies eine Bibliothek ist, die sehr häufig verwendet wird, kann es hilfreich sein, die Referenz zur Hand zu haben

   • Sicher, man würde sagen, dass sie an der Dokumentation arbeiten sollten und höchstwahrscheinlich ist sich Ihr leitender Entwickler dieser Tatsache bewusst. Aber seien wir ehrlich: Oft haben Entwicklungsteams eine Menge undokumentierten Codes. Wenn Sie also wissen müssen, wie es funktioniert, gehen Sie zur Quelle. Sie sollten es nicht tun müssen, aber kurzfristig ist dies die beste Alternative.
   • Normalerweise sind diejenigen, die die Bibliothek am besten kennen, die besten Leute, um Dokumentation zu erstellen. Leider sind dies dieselben Personen, die normalerweise am meisten beschäftigt sind. Daher ist es für sie oft nicht so einfach, alles fallen zu lassen und mit der Dokumentation zu beginnen.

2. Wenn Leute anfangen, ihren eigenen Code zu schreiben, der von der Bibliothek abhängt und etwas in der Bibliothek nicht funktioniert, anstatt ihre Arme in die Luft zu werfen, wird es sehr einfach, direkt in den Bibliothekscode einzusteigen, wenn die Bibliothek lokal erstellt wird

   • Dies kann vorkommen, weil viele Bibliotheken alles andere als perfekt sind und wir alle mit einer "stabilen" Version arbeiten möchten, aber es kann immer noch Probleme geben.
   • Möglicherweise erhalten Sie schlechte Ergebnisse, weil Sie nicht verstehen, wie eine API verwendet werden soll. Selbst mit Dokumentation machen die Leute oft falsche Annahmen
   • Ihr älterer Mann hat wahrscheinlich keine Lust mehr auf neue Leute (und manchmal gibt es viel mehr neue Leute als diejenigen, die das Projekt in- und auswendig kennen), die ihre Arme in die Luft werfen, wenn ein Absturz / ein anderer Fehler von einem Bibliothekscode zu stammen scheint. Anstatt zu Ihrer Maschine und dann zu dem Mann zu kommen, der neben Ihnen sitzt, möchten sie die Möglichkeit haben, mit folgenden Fragen zu antworten: 1) Wo genau ist der Absturz? Welches Modul / Datei / Zeile? 2) Haben Sie es getestet? Was hast DU gefunden?
   • Ihre älteren Mitarbeiter haben lange genug mit dieser Codebasis (Anwendung und Ihrer Hauptbibliothek) gearbeitet, und möglicherweise hat er bemerkt, dass der Code, wenn er bereits auf dem Computer vorhanden ist und zum Debuggen und Durchlaufen bereit ist, sein Leben erleichtert und Menschen anlockt um die Codebasis schneller zu lernen. Aus diesem Grund zwingt er Sie, die Vorabkosten für den Aufbau der Bibliothek auf Ihrem Computer zu übernehmen.

Ich sage nicht, dass seine Entscheidung gerechtfertigt ist, sondern nur darauf hinweisen, dass a) die Frage eine Seite der Geschichte darstellte und b) es plausible Motive geben könnte.

Diese Art von Tests sollte in der Tat besser durchgeführt werden. Die Sache ist jedoch, dass sie von Testern und nicht von Entwicklern durchgeführt werden sollte . In diesem Sinne ist es weder Ihre noch die Aufgabe eines Bibliotheksentwicklers.

_{Nach dem, was Sie beschreiben, klingt es so, als ob es keine Tester im Projekt gibt - wenn dies der Fall ist, ist dies ein Managementproblem und ein ziemlich ernstes.}

... spart Zeit, da sie den Quellcode der Bibliothek lesen können, um festzustellen, ob die erforderliche Funktionalität verfügbar ist

Ziemlich lahmes Denken. Wenn die neueste Versionsbibliothek nicht mit dem neuesten Versionsprojekt kompiliert werden kann, kann dies verschiedene Gründe haben - nur das Bohren in den lib-Quellcode kann Zeitverschwendung sein.

• Was ist, wenn die Bibliothek in Ordnung ist und ein Buildfehler durch den Fehler im Projektcode verursacht wurde? Oder was ist, wenn ein Buildfehler durch vorübergehende inkompatible Änderungen verursacht wurde, die ein oder zwei Tage später korrigiert werden sollen? Was ist, wenn ein Build-Fehler auf ein kompliziertes Integrationsproblem hinweist, dessen Behebung eine Woche oder einen Monat dauern wird? Würde die Verwendung einer früheren Versionsbibliothek bei einem Integrationsproblem eine Problemumgehung darstellen oder nicht?
   
  Was auch immer der Grund sein mag, eine vorläufige Analyse des Fehlers würde bedeuten, dass die Zeit des Entwicklers für eine Arbeit verschwendet wird, die von Testern ausgeführt werden soll.

Eine andere Sache, die über das Fehlen von Überlegungen hinausgeht, sind unvermeidliche (und meiner Erfahrung nach ziemlich schmerzhafte) Produktivitätsverluste, die entstehen, wenn man den Fluss durch Umschalten zwischen Entwicklungs- und QS-Aktivitäten unterbrechen muss.

Wenn es Tester im Team gibt, sind solche Dinge wirklich einfach und können viel einfacher gehandhabt werden. Was Ihr "Senior" -Entwickler an Sie gegossen hat, ist im Grunde ein Testentwurf.

Stellen Sie bei jeder Änderung am Projekt oder an der Bibliothek sicher, dass die Erstellung erfolgreich ist.

Schritte, um von dort fortzufahren, sind typische QS-Aktivitäten: Klären Sie Anforderungsdetails, entwerfen Sie ein formalisiertes Testszenario, verhandeln Sie über den Umgang mit Testfehlern.

• Aus Sicht von SQA ist dies eine ziemlich routinemäßige Aufgabe beim Entwerfen, Einrichten und Verwalten eines ziemlich einfachen Regressionstestverfahrens , das hochautomatisiert sein könnte - wahrscheinlich bis zu dem Punkt, an dem nur manuelle Aktivitäten das Erstellen und Verwalten von Tickets im Issue Tracker und die Überprüfung von wären behebt.

Was der Sr. Dev vorschlägt, macht für mich bestenfalls wenig Sinn. Es ist schön, Quellen durchsuchen zu können, aber es gibt bessere Möglichkeiten, dies zu tun.

Welches Artefakt-Repository verwenden Sie? Sie sollten in der Lage sein, für jede Version ein Quell-JAR bereitzustellen, das neben der kompilierten Bibliothek angezeigt wird. Bei den meisten IDEs können Sie diese dann zum Durchsuchen der Quelle an die kompilierte Bibliothek anhängen. Eclipse mit dem Maven Plugin erledigt dies automatisch.

Wenn Sie den neuesten Code benötigen, können Sie einfach Versions-Snapshots bereitstellen.

Dies sollte einfach in Ihrem Build-Skript geschehen:

1. Überprüfen Sie, ob eine neue Version verfügbar ist. sonst 2 überspringen.
2. Laden Sie es herunter, kompilieren Sie es und führen Sie alle Tools aus, die Sie benötigen, um lokal eine API-Referenz aus dem Quellcode zu generieren. Änderungsprotokoll anzeigen.
3. Erstellen Sie Ihre App

Ich verstehe nicht, warum oder wie das ein Problem ist. Auch wenn etwas in der Referenz fehlt, können Sie es zu den Quellen hinzufügen und die Änderungen übernehmen. Natürlich mag es ein wenig beängstigend erscheinen, dass sich die Bibliothek direkt unter Ihren Füßen ändern kann, aber wenn die Bibliotheksverwalter ihre Arbeit ordnungsgemäß erledigen, ist dies eine gute Sache.