Vendita di LINQ alla gestione

Articoli

Se vuoi convincere il management hai bisogno di fonti esterne. Prova a trovare alcuni articoli che mostrano come LINQ migliori la produttività. Ciò aiuterà il tuo caso e aiuterà il management a sentirsi più sicuro nella decisione di andare avanti con LINQ.

Non accetteranno una nuova tecnologia semplicemente perché una delle "nuove assunzioni" l'ha suggerita. Tuttavia, se ci sono risorse solide e affidabili che parlano di come questa nuova tecnologia migliorerà la produttività, allora sarà molto più probabile che la considerino.

Ecco un paio di articoli che ho trovato (per un paio di cattivi esempi):

• un brutto esempio
• altro cattivo esempio
• un esempio decente

Codice campione

Un'altra idea sarebbe quella di scrivere un codice semplice con LINQ in modo che possano vedere come sarebbe usato rispetto alla loro attuale tecnologia. In pratica fai una "conversione di esempio" da esaminare.

Per vendere alla gestione è necessario concentrarsi sui risparmi sui costi. LINQ to SQL (presumo che tu intendessi questo) è molto più veloce da scrivere, quindi puoi ridurre i costi del progetto.

Se vuoi convincere qualcuno a usare LINQ potresti usare i seguenti motivi:

1. LINQ è solo una funzione di framework, non richiede alcuna modifica del tuo runtime. Ciò significa che non esiste alcun pericolo per l'applicazione .Net esistente purché siano scritti contro. NET 2.0 CLR.
2. LINQ viene implementato tramite i metodi di estensione, quindi è sufficiente distribuire le librerie che contengono questi metodi al progetto per abilitare il supporto LINQ: implementazione semplice, non è necessario ricompilare le librerie che non sono interessate.
3. LINQ è universale e per certi versi indipendente dalla fonte. Ciò significa che puoi raggiungere un maggiore riutilizzo del codice nel tuo progetto.
4. LINQ ti permette di parallelizzare facilmente la tua applicazione usando PLINQ semplicemente aggiungendo .AsParallel() a te IEnumerable - non c'è bisogno di scrivere codice sofisticato per la sincronizzazione (questo però richiede .Net 4.0, comunque).

Aiuterà anche il tuo caso se tu avessi un ulteriore sostegno da parte dei colleghi, quindi prova a vedere se anche a qualcun altro piacerebbe usare Linq. Creare una serie di benchmark di esempio realistici (utilizzando i dati reali raccolti da non-cherry) sarebbe una buona idea.

A volte le organizzazioni fanno cose per un motivo o per un altro a causa della temuta linea di ragionamento "lo abbiamo sempre fatto in questo modo" e non perché il lavoro o il management sentono davvero che è il modo migliore di fare le cose. Avere una discussione in corso nella tua squadra è un buon modo per fare cambiamenti lontano da quella linea di pensiero.

Prima di tutto, sii specifico su quali parti del LINQ vuoi adattare.

In generale, per creare il cambiamento, devi definire cosa stanno già utilizzando, i problemi che stanno avendo, i modi in cui LINQ può risolvere questi problemi, quanto di un aumento delle prestazioni che potrebbero avere con LINQ in base alla tua valutazione. Non puoi aspettarti di portargli qualcosa di sconosciuto e fargli vedere il quadro generale. Dovrai portare loro quella foto.

Nella mia esperienza, alcuni gruppi di sviluppo tendono a non gradire LINQ. Di quelli che ho incontrato a chi non piace o che non vogliono usarlo, ci sono stati 3 tipi. Mi riferisco principalmente a LINQ to SQL / Entities / XML qui.

Per prima cosa, ci sono quelli che stanno usando altri / vecchi metodi di gestione degli oggetti come CSLA o Microsoft Enterprise Library. Sono a loro agio con questo, hanno investito del tempo e non vogliono interrompere il loro lavoro esistente aggiungendo LINQ.

In secondo luogo, ci sono quelli che hanno più "mani in mano" pensando ai codificatori che vedono LINQ come qualcosa che un programmatore "vero" non farebbe, una sorta di trucco o scorciatoia. Uno dei due in cui mi sono imbattuto era addirittura contrario all'uso di generici e oggetti IEnumerable integrati a favore della codifica di questi stessi algoritmi. Questo sembra il più comune tra i programmatori ex-C ++.

In terzo luogo, ci sono quelli che stanno ancora pensando in termini di 10-12 anni fa di programmazione client-server VB6 anche se lo stanno codificando in C #. LINQ spaventa e li confonde.

Non so se la tua organizzazione cade in uno di questi. Il primo almeno spera che tu possa andare verso LINQ in qualche nuovo sviluppo. Potresti anche essere in grado di mostrare loro alcuni dei vantaggi di LINQ to Objects e farli sentire più a loro agio con esso. Gli altri due sono più difficili e dovrai affrontare la resistenza spostandoli nella direzione LINQ, anche se in modo limitato.

Se non altera le dipendenze esterne, non vedo perché avrebbero bisogno di microgestire questo in primo luogo. Probabilmente il tuo primo errore è stato chiedere a loro. Personalmente, lo userei solo Quando vedono che puoi portare a termine il lavoro con un decimo del codice che altri stanno usando, arriveranno. 'Certo, è meglio essere sicuri che andrà a finire meglio dell'approccio attuale.