it-swarm-eu.dev

Wie man mit der Angst um Abhängigkeiten umgeht

Das Team, in dem ich bin, erstellt Komponenten, die von den Partnern des Unternehmens zur Integration in unsere Plattform verwendet werden können.

Daher stimme ich zu, dass wir bei der Einführung von Abhängigkeiten (von Drittanbietern) äußerste Vorsicht walten lassen sollten. Derzeit haben wir keine Abhängigkeiten von Drittanbietern und müssen auf der niedrigsten API-Ebene des Frameworks bleiben.

Einige Beispiele:

  • Wir sind gezwungen, auf der niedrigsten API-Ebene des Frameworks (.NET Standard) zu bleiben. Der Grund dafür ist, dass eines Tages eine neue Plattform eintreffen könnte, die nur diese sehr niedrige API-Ebene unterstützt.
  • Wir haben unsere eigenen Komponenten für die (De-) Serialisierung von JSON implementiert und sind dabei, dies auch für JWT zu tun. Dies ist auf einer höheren Ebene der Framework-API verfügbar.
  • Wir haben einen Wrapper um das HTTP-Framework der Standardbibliothek implementiert, da wir keine Abhängigkeit von der HTTP-Implementierung der Standardbibliothek übernehmen möchten.
  • Der gesamte Code für die Zuordnung zu/von XML wird aus demselben Grund "von Hand" geschrieben.

Ich denke, wir gehen zu weit. Ich frage mich, wie ich damit umgehen soll, da dies meiner Meinung nach unsere Geschwindigkeit stark beeinflusst.

54
robinwit

... Wir sind gezwungen, auf der niedrigsten API-Ebene des Frameworks (.NET Standard) zu bleiben ...

Dies unterstreicht für mich die Tatsache, dass Sie sich möglicherweise nicht nur zu sehr einschränken, sondern mit Ihrem Ansatz auch auf einen bösen Sturz zusteuern.

.NET Standard ist nicht und wird niemals " die niedrigste API-Ebene des Frameworks " sein. Der restriktivste Satz von APIs für .NET wird durch die Erstellung einer portablen Klassenbibliothek erreicht, die auf Windows Phone und Silverlight abzielt.

Je nachdem, auf welche Version von .NET Standard Sie abzielen, erhalten Sie möglicherweise eine Vielzahl von APIs, die mit .NET Framework kompatibel sind: . NET Core , Mono und Xamarin . Und es gibt viele Bibliotheken von Drittanbietern, die mit .NET Standard kompatibel sind und daher auf all diesen Plattformen funktionieren.

Dann gibt es .NET Standard 2.1, der voraussichtlich im Herbst 2019 veröffentlicht wird. Er wird von .NET Core, Mono und Xamarin unterstützt. Es wird von keiner Version von .NET Framework unterstützt , zumindest auf absehbare Zeit und höchstwahrscheinlich immer. In naher Zukunft wird .NET Standard also weit davon entfernt sein, " die niedrigste API-Ebene des Frameworks " zu sein, das Framework ersetzen und über APIs verfügen, die es nicht gibt. t von letzterem unterstützt.

Seien Sie also sehr vorsichtig mit ". Der Grund dafür ist, dass eines Tages eine neue Plattform eintreffen könnte, die nur diese sehr niedrige API-Ebene unterstützt", da dies sehr wahrscheinlich ist dass neue Plattformen tatsächlich eine API auf höherer Ebene unterstützen als das alte Framework.

Dann gibt es das Problem der Bibliotheken von Drittanbietern. JSON.NET ist beispielsweise mit .NET Standard kompatibel. Jede mit .NET Standard kompatible Bibliothek funktioniert garantiert API-weise mit allen .NET-Implementierungen, die mit dieser Version von .NET Standard kompatibel sind. Sie erzielen also keine zusätzliche Kompatibilität, wenn Sie sie nicht verwenden und Ihre JSON-Bibliothek erstellen. Sie schaffen einfach mehr Arbeit für sich selbst und verursachen unnötige Kosten für Ihr Unternehmen.

Also ja, Sie gehen meiner Meinung nach definitiv zu weit.

94
David Arno

Wir sind gezwungen, auf der niedrigsten API-Ebene des Frameworks (.net-Standard) zu bleiben. Der Grund dafür ist, dass eines Tages eine neue Plattform eintreffen könnte, die nur diese sehr niedrige API-Ebene unterstützt.

Die Argumentation hier ist eher rückwärts. Ältere, niedrigere API-Ebenen werden mit größerer Wahrscheinlichkeit veraltet und nicht mehr unterstützt als neuere. Ich stimme zwar zu, dass es sinnvoll ist, einen bequemen Weg hinter der "Schneide" zu halten, um ein angemessenes Maß an Kompatibilität in dem von Ihnen erwähnten Szenario zu gewährleisten, aber niemals vorwärts zu gehen, ist extrem.

Wir haben unsere eigenen Komponenten für die (De-) Serialisierung von JSON implementiert und sind dabei, dies auch für JWT zu tun. Dies ist auf einer höheren Ebene der Framework-API verfügbar. Wir haben einen Wrapper um das HTTP-Framework der Standardbibliothek implementiert, da wir keine Abhängigkeit von der HTTP-Impelemntation der Standardbibliothek haben möchten. Der gesamte Code für die Zuordnung zu/von XML wird aus demselben Grund "von Hand" geschrieben.

Das ist Wahnsinn. Auch wenn Sie aus irgendeinem Grund keine Standardbibliotheksfunktionen verwenden möchten, gibt es Open Source-Bibliotheken mit kommerziell kompatiblen Lizenzen, die alle oben genannten Funktionen erfüllen. Sie wurden bereits geschrieben, unter dem Gesichtspunkt der Funktionalität, Sicherheit und des API-Designs ausgiebig getestet und in vielen anderen Projekten ausgiebig verwendet.

Wenn das Schlimmste passiert und das Projekt nicht mehr funktioniert oder nicht mehr gewartet wird, haben Sie den Code, um die Bibliothek trotzdem zu erstellen, und Sie weisen jemanden zu, der sie verwaltet. Und Sie sind wahrscheinlich immer noch in einer viel besseren Position als wenn Sie Ihren eigenen gewürfelt hätten, da Sie in Wirklichkeit mehr getesteten, saubereren und wartbareren Code haben, um den Sie sich kümmern müssen.

In dem viel wahrscheinlicheren Szenario, dass das Projekt beibehalten wird und Fehler oder Exploits in diesen Bibliotheken gefunden werden, kennen Sie diese, können also etwas dagegen tun - beispielsweise ein kostenloses Upgrade auf eine neuere Version oder das Patchen Ihrer Version mit dem Fix, wenn Sie eine Kopie genommen haben.

51
berry120

Im Großen und Ganzen sind diese Dinge gut für Ihre Kunden. Selbst eine beliebte Open-Source-Bibliothek kann aus irgendeinem Grund nicht verwendet werden.

Beispielsweise haben sie möglicherweise einen Vertrag mit ihren Kunden unterzeichnet, in dem sie versprechen, keine Open Source-Produkte zu verwenden.

Wie Sie jedoch betonen, sind diese Funktionen nicht kostenlos.

  • Zeit zum Markt
  • Größe der Packung
  • Performance

Ich würde diese Nachteile ansprechen und mit Kunden sprechen, um herauszufinden, ob sie wirklich die von Ihnen angebotene überragende Kompatibilität benötigen.

Wenn beispielsweise alle Kunden Json.NET bereits verwenden, wird es durch die Verwendung in Ihrem Produkt anstelle Ihres eigenen Deserialisierungscodes verkleinert und verbessert.

Wenn Sie eine zweite Version Ihres Produkts einführen, die Bibliotheken von Drittanbietern sowie eine kompatible Version verwendet, können Sie die Akzeptanz beider Produkte beurteilen. Werden Kunden die Drittanbieter nutzen, um die neuesten Funktionen etwas früher zu erhalten, oder sich an die "kompatible" Version halten?

11
Ewan

Die kurze Antwort lautet, dass Sie Abhängigkeiten von Drittanbietern einführen sollten. Sagen Sie allen bei Ihrem nächsten Stand-up-Meeting, dass die nächste Arbeitswoche der größte Spaß seit Jahren sein wird - sie werden die JSON- und XML-Komponenten durch Open-Source-Standardbibliothekslösungen ersetzen. Sagen Sie allen, dass sie drei Tage Zeit haben, um die JSON-Komponente zu ersetzen. Feiern Sie, nachdem es fertig ist. Eine Party feiern. Das ist es wert, gefeiert zu werden.

Grundsätzlich kommt es auf Aufwand und Risiko an.

Indem Sie eine zusätzliche Abhängigkeit hinzufügen oder Ihr Framework aktualisieren oder eine API auf höherer Ebene verwenden, verringern Sie Ihren Aufwand, gehen jedoch ein Risiko ein. Daher würde ich vorschlagen, eine SWOT-Analyse durchzuführen.

  • Stärken: Weniger Aufwand, da Sie ihn nicht selbst codieren müssen.
  • Schwächen: Es ist nicht so maßgeschneidert für Ihre speziellen Bedürfnisse wie eine handgefertigte Lösung.
  • Chancen: Die Markteinführungszeit ist kürzer. Sie könnten von externen Entwicklungen profitieren.
  • Bedrohungen: Sie können Kunden mit zusätzlichen Abhängigkeiten verärgern.

Wie Sie sehen, ist der zusätzliche Aufwand für die Entwicklung einer handgefertigten Lösung eine Investition in die Verringerung Ihrer Bedrohungen. Jetzt können Sie eine strategische Entscheidung treffen.

0
Dominic Hofer