Dovremmo cercare di essere indipendenti dalla tecnologia il più possibile?

2

È vero che non possiamo essere indipendenti dalla tecnologia al 100% quando utilizziamo un framework o uno strumento, saremo sempre almeno il 20% dipendenti dallo strumento o dal framework.

Il fatto è che mi sento meglio se posso essere il più agnostico possibile della tecnologia scelta. I miei due principali motivi sono: è facile migrare verso uno strumento migliore che verrà creato in futuro e ogni nuovo sviluppatore che verrà nel team capirà immediatamente il codice, se non è dipendente dal "framework".

Qualcun altro può venire con buone ragioni per essere o non essere tanto più indipendenti dagli strumenti che possiamo?

Grazie

    
posta Miguel Domingos 29.05.2016 - 01:37
fonte

2 risposte

1

Questa è una domanda molto generale, quindi la risposta può essere inevitabilmente "dipende".

Ad esempio, JPA (Hibernate) e Entity Framework sono tentativi di creare astrazione su database (per lo più relazionali), in modo che la tua app sia indipendente dal motore di database SQL in uso.

È fantastico, ma non è gratuito. Ciò che ottieni è maggiore flessibilità (puoi teoricamente cambiare il motore DB sottostante) e una migliore astrazione, ma perdi la possibilità di utilizzare funzionalità più avanzate del DB per es. prestazioni migliori. Inoltre, queste astrazioni sono spesso abbastanza "leaky". Sostituito DB (e app) probabilmente si comporterà in modo leggermente diverso da quello vecchio. È ancora necessario essere consapevoli di ciò che fa SQL, basi del modello relazionale. Quindi può essere effettivamente più difficile per i nuovi arrivati: devono conoscere sia l'SQL che il framework di tua scelta.

Ma questo non è ancora totalmente agnostico. JPA / EF sono di nuovo solo un pezzo di tecnologia di cui vuoi essere indipendente. Quindi crei il tuo livello su JPA / EF che nasconde tutti i dettagli dell'implementazione (gestori di entità, dbcontexts ecc.)

Le persone utilizzano tipicamente modelli esistenti (dao, repository) per questo scopo. Il nuovo dipendente ha ancora bisogno di conoscere SQL, JPA / EF e ora il tuo nuovo livello brillante.

La situazione descritta sopra è in realtà abbastanza comune, ma è lungi dall'essere "il più agnostico possibile". Si potrebbe anche smettere di assumere che si utilizzi db con modello relazionale (NoSQL), che il proprio db supporti le transazioni e ACID, quindi si finisca per avere un modello di programmazione di storage a valori-chiave essenzialmente persistente. Devi pensare a ciò che perdi e ciò che guadagni.

    
risposta data 29.05.2016 - 02:50
fonte
0

La giuria è ancora fuori su questa domanda.

Ci sono dei costi (conseguenze) indipendentemente dalla tua scelta.

Ci sono molti modi per classificare e confrontare le conseguenze, ma quelle di base sono:

  • Effetto sui costi di sviluppo / produttività
  • Effetto sulla qualità del prodotto giudicato dai clienti (ad esempio, mancanza di difetti e limitazioni funzionali)
  • Effetto sulla manutenzione
  • Capacità del team - se sono / saranno all'altezza del compito. Ricorda che la "squadra" è un concetto fluido: le persone si uniscono e lasciano le squadre su base regolare. Non ci possono essere membri originali rimasti nella squadra da cinque a dieci anni lungo la strada.
  • Rischi
    • Competitivo - dipende da ciò che fanno i tuoi concorrenti.
    • Interruzioni - se un fornitore di strutture può sparire improvvisamente o essere colpito da cause legali, o se la licenza di contratto / codice può essere interrotta in qualsiasi momento

Questo elenco, ovviamente, non è esaustivo.

Quando si analizzano i costi e i benefici, si deve prendere il tempo in sconto. Questo è noto come "time discount" / "time preference" in economia .

In altre parole, devi prendere in maggiore considerazione i compromessi a breve ea breve termine, perché il lungo termine tende ad essere imprevedibile.

    
risposta data 29.05.2016 - 02:27
fonte

Leggi altre domande sui tag