Wie gehe ich mit der Angst um, Abhängigkeiten einzugehen?

54

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

Daher stimme ich zu, dass wir beim Einführen von Abhängigkeiten (von Drittanbietern) äußerste Vorsicht walten lassen sollten. Derzeit bestehen keine Abhängigkeiten von Drittanbietern und wir 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 auf den Markt kommen könnte, die nur dieses sehr niedrige API-Level 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 eingehen möchten.
Der gesamte Code für die Zuordnung zu / von XML wurde aus demselben Grund "von Hand" geschrieben.

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

— Bertus
quelle

20

Gibt es eine Rechtfertigung dafür (z. B. externe Anforderung) oder geschieht dies aus Unwissenheit?

— Blrfl

6

Machen Sie ein Experiment mit einem kleinen Teil der Codebasis, erstellen Sie eine Isolationsebene, die nicht versucht, eine generische Bibliothek zu sein, sondern eine abstrakte Schnittstelle definiert, die Ihre Anforderungen modelliert. Stellen Sie dann sowohl Ihre eigene Implementierung als auch eine Abhängigkeit von Drittanbietern dahinter und vergleichen Sie, wie die beiden Versionen funktionieren. Wägen Sie die Vor- und Nachteile ab, bewerten Sie, wie einfach (oder wie schwierig) es ist, Implementierungen auszutauschen, und treffen Sie dann eine Entscheidung. Kurz gesagt, testen Sie die Dinge auf relativ risikoarme Weise, sehen Sie, was passiert, und entscheiden Sie dann.

— Filip Milovanović

73

"Derzeit haben wir keine Abhängigkeiten von Drittanbietern." Das bringt mich immer zum Lachen, wenn Leute dies behaupten. Natürlich tust du. Sie haben keinen eigenen Compiler, keine eigene IDE und keine Implementierung von Standardbibliotheken geschrieben. Sie haben keine der Shard-Objekt-Bibliotheken geschrieben, die Sie indirekt (oder direkt) verwenden. Wenn Sie feststellen, auf wie viel Software und Bibliotheken von Drittanbietern Sie angewiesen sind, können Sie die Idee "Abhängigkeiten sind schlecht" fallen lassen und es einfach genießen, das Rad nicht neu zu erfinden. Ich würde nur die Abhängigkeiten kennzeichnen, die Sie haben, und dann fragen, warum sie akzeptabel sind, aber JSON-Analyse ist es nicht.

— UKMonkey

8

Das heißt, es gibt die alternativen Nachteile, wie nie Projekte zu beenden. Aber es fördert Software-Jobs und Beschäftigung :)

— Marschall Handwerk

5

Sie haben Recht, dass Sie Mühe verschwenden, wenn Sie die Warensoftware neu erfinden. Sie irren sich, dass dies nicht einmal annähernd "das Vermeiden aller Abhängigkeiten" ist. Das Excel-Team von Microsoft hat einmal einen eigenen C-Compiler geschrieben, um eine Abhängigkeit vom C-Team von Microsoft zu vermeiden . Sie gehen enorme Abhängigkeiten von Betriebssystemen, übergeordneten Frameworks usw. ein.

— Eric Lippert

94

... 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 auch mit Ihrem Ansatz auf einen bösen Sturz zusteuern.

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

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

Dann gibt es .NET Standard 2.1, der voraussichtlich im Herbst 2019 veröffentlicht wird. Es wird von .NET Core, Mono und Xamarin unterstützt. Zumindest für die absehbare Zukunft wird es von keiner Version von .NET Framework unterstützt, und dies ist mit hoher Wahrscheinlichkeit immer der Fall . In naher Zukunft wird .NET Standard also nicht die " niedrigste API-Ebene des Frameworks " sein, sondern das Framework ablösen und APIs haben, die von diesem nicht unterstützt werden.

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

Dann gibt es das Problem der Bibliotheken von Drittanbietern. JSON.NET ist zum Beispiel mit .NET Standard kompatibel. Es ist garantiert, dass jede mit .NET Standard kompatible Bibliothek in Bezug auf die API mit allen .NET-Implementierungen funktioniert, die mit dieser Version von .NET Standard kompatibel sind. Sie erreichen also keine zusätzliche Kompatibilität, indem Sie es nicht verwenden und Ihre JSON-Bibliothek erstellen. Sie schaffen sich einfach mehr Arbeit und verursachen Ihrem Unternehmen unnötige Kosten.

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

— David Arno
quelle

16

"Sie schaffen sich einfach mehr Arbeit und verursachen Ihrem Unternehmen unnötige Kosten." - und Sicherheiten. Stürzt Ihr JSON-Encoder mit einem Stapelüberlauf ab, wenn Sie ihm ein rekursives Objekt zuweisen? Verarbeitet Ihr Parser maskierte Zeichen korrekt? Lehnt es unescaped Charaktere ab, die es sollte? Wie wäre es mit ungepaarten Ersatzfiguren? Überläuft es, wenn JSON eine Zahl größer als 2 ^ 64 codiert? Oder ist es nur eine winzige evalHülle mit einigen Hygienekontrollen, die leicht umgangen werden können?

— John Dvorak

4

"Der restriktivste Satz von APIs für .NET wird durch die Erstellung einer portablen Klassenbibliothek erreicht, die auf Windows Phone und Silverlight abzielt." Ich werde auf die Probe stellen und behaupten, dass es mindestens einige APIs in dieser Untergruppe gibt, die nicht von allen möglichen Implementierungen unterstützt werden, die jemals existierten (und niemand kümmert sich mehr um WinPhone oder Silvernight, nicht einmal mehr um Microsoft). Die Verwendung von .NetStandard 2.0 als Ziel für ein modernes Framework erscheint sehr umsichtig und nicht besonders einschränkend. Ein Update auf 2.1 ist eine andere Geschichte, aber es gibt keinen Hinweis darauf, dass sie dies tun würden.

— Voo

Abgesehen von zukünftigen Plattformen, die wahrscheinlich mehr als weniger unterstützen, ist die Entwicklung für alle möglichen Dinge unglaublich teuer (und Sie werden wahrscheinlich sowieso etwas verpassen). Stattdessen ohne Entwicklung das Rad neu erfinden wird mehr Zeit sparen als zu einige neue Situation anzupassen , wenn diese benötigt wird , kosten wird.

— Jasper

51

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 auf den Markt kommen könnte, die nur dieses sehr niedrige API-Level unterstützt.

Die Argumentation hier ist eher rückständig. Ältere, niedrigere API-Level werden mit größerer Wahrscheinlichkeit veraltet und werden nicht mehr unterstützt als neuere. Ich stimme zu, dass es sinnvoll ist, einen komfortablen Weg hinter der "Schneide" zu finden, um ein angemessenes Maß an Kompatibilität in dem von Ihnen genannten Szenario zu gewährleisten.

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-Aktivierung der Standardbibliothek haben möchten. Der gesamte Code für die Zuordnung zu / von XML wurde 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 ausführen. Sie wurden bereits geschrieben, ausführlich im Hinblick auf Funktionalität, Sicherheit und API-Design getestet und in vielen anderen Projekten ausführlich verwendet.

Wenn das Schlimmste passiert und das Projekt verschwindet oder nicht mehr gewartet wird, haben Sie den Code, um die Bibliothek trotzdem zu erstellen, und Sie weisen jemanden an, der sie wartet. Und Sie sind wahrscheinlich immer noch in einer viel besseren Position als Sie selbst, da Sie in Wirklichkeit mehr getesteten, saubereren und besser wartbaren Code haben, um den Sie sich kümmern müssen.

In dem viel wahrscheinlicherem Szenario, dass das Projekt beibehalten wird und Fehler oder Exploits in diesen Bibliotheken gefunden werden, wissen Sie Bescheid, damit Sie etwas dagegen tun können - z. B. ein kostenloses Upgrade auf eine neuere Version oder das Patchen Ihrer Version mit dem Update, wenn Sie eine Kopie genommen haben.

— berry120
quelle

3

Und selbst wenn Sie dies nicht können, ist der Wechsel zu einer anderen Bibliothek immer noch einfacher und besser als das Rollen Ihrer eigenen.

— Leichtigkeit Rennen mit Monica

5

Hervorragender Punkt, dass Sachen mit niedrigerem Level schneller sterben. Das ist der springende Punkt, um Abstraktionen zu etablieren.

— Leichtigkeit Rennen mit Monica

"Ältere, niedrigere API-Level werden mit größerer Wahrscheinlichkeit veraltet und werden nicht mehr unterstützt als neuere". Huh? Soweit ich weiß, sind die NetSTandards aufeinander aufgebaut (was bedeutet, dass 2.0 1.3 + X ist). Auch die Standards sind einfach das .. Standards, keine Implementierungen. Es macht keinen Sinn, davon zu sprechen, dass ein Standard nicht mehr unterstützt wird, da die meisten spezifischen Implementierungen dieses Standards in der Zukunft liegen könnten (siehe aber den vorherigen Punkt, warum dies auch kein Problem darstellt). Wenn Ihre Bibliothek nichts außerhalb von NetStandard 1.3 benötigt, gibt es absolut keinen Grund, sie auf 2.0 zu ändern

— Voo,

11

Im Großen und Ganzen sind diese Dinge gut für Ihre Kunden. Sogar eine populäre Open-Source-Bibliothek könnte aus irgendeinem Grund für sie unmöglich sein.

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

Sie weisen jedoch darauf hin, dass diese Funktionen nicht kostenlos sind.

Zeit zum Markt
Größe des Pakets
Performance

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

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

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

— Ewan
quelle

11

Ja, dem stimme ich natürlich zu und ich würde Ihrer Liste "Sicherheit" hinzufügen. Im Vergleich zu gut getesteten Frameworks und definitiv der Standardbibliothek besteht ein gewisses Potenzial, dass Sie eine Sicherheitslücke in Ihren Code einbauen, insbesondere bei Dingen wie JSON / JWT.

— Bertus

Ja, es ist schwierig, die Liste zu erstellen, da Dinge wie Sicherheit und Leistung offensichtlich in beide Richtungen gehen können. Es besteht jedoch ein offensichtlicher Interessenkonflikt zwischen der Endbearbeitung und der Gewährleistung, dass die internen Komponenten voll funktionsfähig sind

— Ewan,

12

"Sie haben möglicherweise einen Vertrag mit ihren Kunden geschlossen, in dem sie versprechen, keine Open Source-Produkte zu verwenden" - sie verwenden .NET Standard, das Open Source ist. Es ist eine schlechte Idee, diesen Vertrag zu unterzeichnen, wenn Sie Ihr gesamtes Produkt auf einem Open-Source-Framework basieren.

— Stephen

Und immer noch machen es die Leute

— Ewan

7

Die kurze Antwort lautet, dass Sie damit beginnen sollten, Abhängigkeiten von Drittanbietern einzuführen. Erklären Sie bei Ihrem nächsten Stand-up-Meeting allen, dass die nächste Arbeitswoche der größte Spaß sein wird, den sie seit Jahren hatten. 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, nachdem es fertig ist. Eine Party feiern. Das ist es wert, gefeiert zu werden.

— Double Vision Stout Fat Heavy
quelle

2

Das mag ein Augenzwinkern sein, ist aber nicht unrealistisch. Ich trat einer Firma bei, in der ein "Senior" -Entwickler (nur von der Schule) einen Junior-Entwickler mit dem Schreiben einer State-Machine-Bibliothek beauftragt hatte. Es hatte fünf Entwicklermonate und es war immer noch fehlerhaft, also habe ich es herausgerissen und innerhalb weniger Tage durch eine schlüsselfertige Lösung ersetzt.

— Nein U

0

Im Grunde kommt es auf Aufwand und Risiko an.

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

Stärken: Weniger Aufwand, da Sie es nicht selbst codieren müssen.
Schwächen: Es ist nicht so speziell auf Ihre speziellen Bedürfnisse zugeschnitten wie eine handgefertigte Lösung.
Chancen: Time-to-Market ist kürzer. Sie könnten von externen Entwicklungen profitieren.
Bedrohungen: Sie könnten 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 Reduzierung Ihrer Bedrohungen. Jetzt können Sie eine strategische Entscheidung treffen.

— Dominic Hofer
quelle

-2

Teilen Sie Ihre Komponentenbibliotheken in einen "Core" -Satz auf, der keine Abhängigkeiten aufweist (im Wesentlichen das, was Sie gerade tun), und einen "Common" -Satz, der Abhängigkeiten von Ihren "Core" -Bibliotheken und Bibliotheken von Drittanbietern aufweist.

Auf diese Weise kann jemand, der nur "Core" -Funktionalität haben möchte, diese haben.

Wenn jemand "Common" -Funktionalität will, kann er sie haben.

Und Sie können verwalten, was "Core" im Vergleich zu "Common" ist. Sie können "Common" schneller um Funktionen erweitern und in Ihre eigene "Core" -Implementierung verschieben, wenn es sinnvoll ist, Ihre eigene Implementierung bereitzustellen.

— Turtle1363
quelle