Come affrontare la paura di assumere dipendenze

54

Il team in cui mi trovo crea componenti che possono essere utilizzati dai partner dell'azienda per integrarsi con la nostra piattaforma.

In quanto tale, sono d'accordo che dovremmo prestare estrema attenzione quando introduciamo dipendenze (di terze parti). Attualmente non abbiamo dipendenze di terze parti e dobbiamo rimanere al livello API più basso del framework.

Qualche esempio:

Siamo costretti a rimanere al livello API più basso del framework (.NET Standard). Il ragionamento alla base è che un giorno potrebbe arrivare una nuova piattaforma che supporta solo quel livello API molto basso.
Abbiamo implementato i nostri componenti per (de) serializzare JSON e stiamo facendo lo stesso per JWT. Questo è disponibile a un livello superiore dell'API del framework.
Abbiamo implementato un wrapper attorno al framework HTTP della libreria standard, perché non vogliamo dipendere dall'implementazione HTTP della libreria standard.
Tutto il codice per il mapping da / a XML viene scritto "a mano", sempre per lo stesso motivo.

Sento che stiamo andando troppo lontano. Mi chiedo come gestirlo, poiché penso che ciò influisca notevolmente sulla nostra velocità.

— Bertus
fonte

20

C'è una giustificazione per questo (ad esempio, requisito esterno) o viene fatto per ignoranza?

— Blrfl

6

Fai un esperimento con una piccola parte di codebase, crea un livello di isolamento che non cerca di essere una libreria generica, ma definisce un'interfaccia astratta che modella i tuoi bisogni; quindi metti dietro la tua implementazione e una dipendenza di terze parti e confronta come funzionano / eseguono le due versioni. Valuta i pro e i contro, valuta quanto sarebbe facile (o difficile) scambiare le implementazioni, quindi prendere una decisione. In breve, testare le cose in un modo relativamente a basso rischio, vedere cosa succede, quindi decidere.

— Filip Milovanović,

73

"Attualmente non abbiamo dipendenze di terze parti" Questo mi fa sempre ridere quando la gente lo afferma. Certo che lo fai. Non hai scritto il tuo compilatore, IDE, implementazione di nessuna libreria standard. Non hai scritto nessuna delle librerie di oggetti shard che usi indirettamente (o direttamente). Quando ti rendi conto di quanto software e librerie di terze parti da cui dipendi, puoi abbandonare l'idea "le dipendenze sono cattive" e divertirti a non reinventare la ruota. Vorrei solo contrassegnare le dipendenze che hai, e quindi chiedere perché sono accettabili, ma Json non lo è.

— UKMonkey

8

Detto questo, ci sono gli svantaggi alternativi, come non finire mai i progetti. Ma promuove i lavori e l'occupazione del software :)

— Maresciallo artigianale

5

Hai ragione a perdere gli sforzi reinventando il software delle materie prime. Ti sbagli nel fatto che questo non è nemmeno vicino a "evitare tutte le dipendenze". Il team Excel di Microsoft ha scritto una volta il proprio compilatore C per evitare di dipendere dal team C di Microsoft . Stai assumendo enormi dipendenze da sistemi operativi, framework di alto livello e così via.

— Eric Lippert,

94

... Siamo costretti a rimanere al livello API più basso del framework (.NET Standard) ...

Questo per me evidenzia il fatto che, non solo ti stai potenzialmente restringendo troppo, potresti anche andare verso una brutta caduta con il tuo approccio.

.NET Standard non è e non sarà mai " il livello API più basso del framework ". Il set più restrittivo di API per .NET si ottiene creando una libreria di classi portatile destinata a Windows Phone e Silverlight.

A seconda della versione di .NET Standard di destinazione, è possibile ottenere un set molto ricco di API compatibili con .NET Framework, .NET Core , Mono e Xamarin . E ci sono molte librerie di terze parti compatibili con .NET Standard che funzioneranno quindi su tutte queste piattaforme.

Poi c'è .NET Standard 2.1, che sarà probabilmente rilasciato nell'autunno del 2019. Sarà supportato da .NET Core, Mono e Xamarin. Non sarà supportato da nessuna versione di .NET Framework , almeno per il prossimo futuro, e molto probabilmente sempre. Quindi nel prossimo futuro, lungi dall'essere " il livello API più basso del framework ", .NET Standard sostituirà il framework e avrà API che non sono supportate da quest'ultimo.

Quindi stai molto attento con " Il ragionamento dietro questo è che un giorno potrebbe arrivare una nuova piattaforma che supporta solo quel livello API molto basso " poiché è molto probabile che le nuove piattaforme supporteranno effettivamente un'API di livello superiore rispetto al vecchio framework.

Poi c'è il problema delle librerie di terze parti. JSON.NET ad esempio è compatibile con .NET Standard. Qualsiasi libreria compatibile con .NET Standard è garantita, per quanto riguarda le API, per funzionare con tutte le implementazioni .NET compatibili con quella versione di .NET Standard. Quindi non ottieni alcuna compatibilità aggiuntiva non utilizzandola e creando la tua libreria JSON. Crea semplicemente più lavoro per te stesso e incorri in costi inutili per la tua azienda.

Quindi sì, sicuramente lo stai portando troppo lontano dal mio punto di vista.

— David Arno
fonte

16

"Devi semplicemente creare più lavoro per te stesso e sostenere costi inutili per la tua azienda." - e le passività di sicurezza. Il tuo codificatore JSON si arresta in modo anomalo con uno stack overflow se gli dai un oggetto ricorsivo? Il tuo parser gestisce correttamente i caratteri di escape? Rifiuta i caratteri senza escape che dovrebbe? Che ne dici di personaggi surrogati spaiati? Trabocca quando JSON codifica un numero maggiore di 2 ^ 64? O è solo un piccolo evalinvolucro con alcuni controlli di integrità che possono essere facilmente aggirati?

— John Dvorak,

4

"Il set più restrittivo di API per .NET si ottiene creando una libreria di classi portatile destinata a Windows Phone e Silverlight." Esco da un arto e pretendo che ci siano almeno alcune API in quel sottoinsieme che non sono supportate da tutte le possibili implementazioni che siano mai esistite (e nessuno si preoccupa più di WinPhone o Silvernight, nemmeno di Microsoft). L'uso di .NetStandard 2.0 come target per un framework moderno sembra molto prudente e non particolarmente limitante. L'aggiornamento a 2.1 è una storia diversa, ma non vi è alcuna indicazione che lo farebbero.

— Voo

A parte le piattaforme future che probabilmente supportano più che meno, lo sviluppo di tutte le cose che potrebbero accadere è incredibilmente costoso (e probabilmente ti mancherà qualcosa). Invece, lo sviluppo senza reinventare la ruota farà risparmiare più tempo rispetto all'adattarsi a qualche nuova situazione quando ciò sarà necessario.

— Jasper,

51

Siamo costretti a rimanere al livello API più basso del framework (standard .net). Il ragionamento alla base è che un giorno potrebbe arrivare una nuova piattaforma che supporta solo quel livello API molto basso.

Il ragionamento qui è piuttosto arretrato. I livelli API più vecchi e più bassi hanno maggiori probabilità di diventare obsoleti e non supportati rispetto a quelli più recenti. Anche se concordo sul fatto che rimanere a proprio agio dietro "l'avanguardia" sia ragionevole per garantire un ragionevole livello di compatibilità nello scenario che si menziona, non andare mai oltre è estremo.

Abbiamo implementato i nostri componenti per (de) serializzare JSON e stiamo facendo lo stesso per JWT. Questo è disponibile a un livello superiore dell'API del framework. Abbiamo implementato un wrapper attorno al framework HTTP della libreria standard perché non vogliamo prendere una dipendenza dall'impelemntation HTTP della libreria standard. Tutto il codice per il mapping da / a XML viene scritto "a mano", sempre per lo stesso motivo.

Questa è follia . Anche se non si desidera utilizzare le funzioni di libreria standard per nessun motivo, esistono librerie open source con licenze commercialmente compatibili che fanno tutto quanto sopra. Sono già stati scritti, ampiamente testati dal punto di vista della funzionalità, della sicurezza e della progettazione API e ampiamente utilizzati in molti altri progetti.

Se succede il peggio e quel progetto scompare o smette di essere mantenuto, allora hai il codice per costruire la libreria e assegni a qualcuno di mantenerlo. E probabilmente sei ancora in una posizione molto migliore rispetto a se avessi creato il tuo, poiché in realtà avrai un codice più testato, più pulito e più gestibile da gestire.

Nello scenario molto più probabile che il progetto venga mantenuto e che si trovino bug o exploit in quelle librerie, ne saprai di più, quindi puoi fare qualcosa al riguardo, come l'aggiornamento gratuito a una versione più recente o l'applicazione di patch alla tua versione con la correzione se hai preso una copia.

— berry120
fonte

3

E anche se non ci riesci, passare a un'altra libreria è ancora più facile e meglio che crearne uno tuo.

— Lightness Races con Monica il

5

Ottimo punto che le cose di livello inferiore muoiono più velocemente. Questo è il punto centrale di stabilire le astrazioni.

— Corse di leggerezza con Monica il

"I livelli API più vecchi e più bassi hanno maggiori probabilità di diventare obsoleti e non supportati rispetto a quelli più recenti". Eh? Per quanto ne so, gli standard NetST sono costruiti uno sopra l'altro (il che significa che 2.0 è 1.3 + X). Anche gli standard sono semplicemente ... standard, non implementazioni. Non ha senso parlare di uno standard che non è supportato, nella maggior parte dei casi le implementazioni specifiche di quello standard potrebbero essere in futuro (ma vedere il punto precedente perché anche questo non è un problema). Se la tua libreria non ha bisogno di nulla al di fuori di NetStandard 1.3, non c'è assolutamente alcun motivo per cambiarla in 2.0

— Voo

11

Nel complesso queste cose sono buone per i tuoi clienti. Anche una popolare libreria open source potrebbe essere impossibile da usare per qualche motivo.

Ad esempio, potrebbero aver firmato un contratto con i loro clienti promettendo di non utilizzare prodotti open source.

Tuttavia, come sottolineato, queste funzionalità non sono esenti da costi.

Time to market
Dimensione del pacchetto
Prestazione

Vorrei sollevare questi aspetti negativi e parlare con i clienti per scoprire se hanno davvero bisogno dei superbi livelli di compatibilità che stai offrendo.

Se, ad esempio, tutti i clienti utilizzano già Json.NET, utilizzandolo nel proprio prodotto anziché nel proprio codice di deserializzazione, ne riduce le dimensioni e lo migliora.

Se si introduce una seconda versione del prodotto, una che utilizza librerie di terze parti e una compatibile, è possibile giudicare l'assorbimento su entrambi. I clienti useranno le terze parti per ottenere le ultime funzionalità un po 'prima o attenersi alla versione "compatibile"?

— Ewan
fonte

11

Sì, sono ovviamente d'accordo e aggiungerei "sicurezza" al tuo elenco. C'è un potenziale che potresti introdurre una vulnerabilità nel tuo codice, specialmente con cose come JSON / JWT, rispetto ai framework ben testati e sicuramente alla libreria standard.

— Bertus

Sì, è difficile fare la lista perché ovviamente cose come sicurezza e prestazioni potrebbero andare in entrambe le direzioni. Ma c'è un evidente conflitto di interessi tra le funzionalità di finitura e l'assicurazione che i componenti interni siano pienamente descritti / compresi

— Ewan

12

"potrebbero aver firmato un contratto con i loro clienti promettendo di non utilizzare prodotti open source" - stanno usando .NET Standard, che è open source. È una cattiva idea firmare quel contratto quando si basa l'intero prodotto su un framework open source.

— Stephen,

E ancora la gente lo fa

— Ewan,

7

La risposta breve è che dovresti iniziare a introdurre dipendenze di terze parti. Durante la tua prossima riunione stand-up, di 'a tutti che la prossima settimana di lavoro sarà la più divertente che abbiano avuto negli anni: sostituiranno i componenti JSON e XML con soluzioni di librerie standard open source. Di 'a tutti che hanno tre giorni per sostituire il componente JSON. Festeggia dopo aver finito. Fare una festa. Vale la pena celebrarlo.

— Double Vision Stout Fat Heavy
fonte

2

Questo può essere ironico ma non è irrealistico. Sono entrato in una società in cui un dev "senior" (senior solo per l'istruzione) aveva incaricato un dev junior di scrivere una biblioteca di macchine statali. Aveva cinque mesi di sviluppo ed era ancora pieno di bug, quindi l'ho strappato e sostituito con una soluzione chiavi in mano nel giro di un paio di giorni.

— No U

0

Fondamentalmente tutto si riduce allo sforzo rispetto al rischio.

Aggiungendo una dipendenza aggiuntiva o aggiornando il framework o utilizzando un'API di livello superiore, si riducono gli sforzi ma si assumono rischi. Quindi suggerirei di fare un'analisi SWOT .

Punti di forza: meno sforzo, perché non è necessario codificarlo da soli.
Punti deboli: non è progettato su misura per le tue esigenze speciali come una soluzione artigianale.
Opportunità: il time to market è inferiore. Potresti trarre profitto da sviluppi esterni.
Minacce: potresti turbare i clienti con dipendenze aggiuntive.

Come puoi vedere, lo sforzo aggiuntivo per sviluppare una soluzione artigianale è un investimento per ridurre le tue minacce. Ora puoi prendere una decisione strategica.

— Dominic Hofer
fonte

-2

Dividi le librerie dei componenti in un set "Core", che non ha dipendenze (essenzialmente quello che stai facendo ora) e in un set "Common", che ha dipendenze dalle librerie "Core" e di terze parti.

In questo modo se qualcuno vuole solo funzionalità "Core", può averlo.

Se qualcuno vuole funzionalità "comune", può averlo.

E puoi gestire ciò che è "Core" contro "Common". Puoi aggiungere funzionalità più rapidamente a "Comune" e spostarlo nella tua implementazione "Core" se / quando ha senso fornire la tua implementazione.

— Turtle1363
fonte