Giustificazione per l'apprendimento / implementazione di nuove tecnologie Microsoft [chiuso]

Non diventare obsoleto sembra un buon motivo per utilizzare la nuova tecnologia. Fluisce in entrambe le direzioni. Non vuoi che le tue abilità diventino obsolete, ma il tuo capo dovrebbe anche preoccuparsi che non sia in grado di trovare dipendenti disposti o in grado di lavorare su tecnologie obsolete. Se la maggior parte degli sviluppatori e dei datori di lavoro lascia una vecchia tecnologia per una nuova che potrebbe essere una ragione sufficiente per la tua azienda anche a farlo.

Per rispondere in modo specifico alla tua domanda, dovresti valutare ciascuna di queste tecnologie individualmente per vedere se soddisfano le tue esigenze. Ti darò la mia opinione, ma hai davvero bisogno di dedicare almeno mezza giornata alla ricerca e alla valutazione di ciascuna di esse, in quanto si applicano alle tue esigenze aziendali specifiche.

LINQ: Questo è qualcosa che puoi usare, anche senza framework di entità. LINQ è una tecnologia utilizzata per lavorare con raccolte di dati e puoi usarla nelle tue applicazioni anche se non la usi per caricare quei dati dal database. Fatti un favore e impara come usare le espressioni lambda e i metodi di estensione LINQ. Ti farà risparmiare tempo, ti semplificherà la vita come sviluppatore e ridurrai la quantità di codice che dovrai scrivere.

Entity Framework: questo sembra essere il futuro per l'accesso ai dati nel mondo Microsoft. La maggior parte dei nuovi framework, tecnologie e strumenti di Microsoft sono progettati per funzionare con framework di entità. Non è perfetto, ma è molto più bello dell'utilizzo di set di dati, soprattutto se si utilizza LINQ per le entità. Uno dei motivi principali per l'utilizzo del framework di entità è che riduce la quantità di codice SQL che è necessario scrivere, poiché il framework genererà per te. Nella mia esperienza, molti sviluppatori non sono molto bravi a scrivere SQL in ogni caso (e la maggior parte delle aziende non ha un DBA dedicato), quindi per la maggior parte delle applicazioni il framework di entità dovrebbe rendere le cose più veloci ed efficienti. Il framework Entity ti permetterà anche di lavorare con POCOs che hanno meno overhead e sono più facili da utilizzare rispetto ai dataset.

MVC: potrebbe essere difficile da giustificare, in quanto la maggior parte delle applicazioni potrebbe non trarne alcun beneficio. Sulla base degli ultimi annunci di lavoro che ho visto, MVC è ancora in minoranza (sebbene stia guadagnando terreno velocemente). Per la maggior parte delle applicazioni aziendali, MVC potrebbe essere eccessivo e il trascinamento di alcuni controlli su una pagina di aspx sarà sufficiente. MVC ha una curva di apprendimento e per essere produttivo e ottenere il massimo da esso devi veramente capire HTTP, HTML, CSS e JavaScript. MVC funziona bene quando è necessario disporre di un'applicazione Web davvero personalizzata in cui le prestazioni sono una priorità. Se questo non è il caso, e i dipendenti non hanno molta esperienza con esso, probabilmente non c'è un valido business case per usarlo.

Servizi Web WCF: è necessario fornire dati alle applicazioni client remote? WCF è probabilmente la strada da percorrere. Stai solo scrivendo un'applicazione web che verrà eseguita sullo stesso server o rete locale del tuo database? Non usare WCF, non ne hai bisogno e servirà solo a complicare le cose con astrazioni inutili.

In breve, usa una nuova tecnologia quando ha senso e prenditi il tempo per scoprire quando è così. Ci vuole un sacco di tempo per imparare nuove tecnologie, ma non dovrebbe richiedere molto tempo per valutarle e imparare se saranno utili alla tua situazione specifica. Questo è qualcosa che i più alti della tua azienda dovrebbero già fare, ma se non lo sono, devi farlo e poi prenditi il tempo per educarli su ciò che hai imparato.

EDIT: Dopo aver letto i tuoi commenti sopra ho avuto qualche altro pensiero. Potrebbe essere utile se sei in grado di adottare un approccio agile allo sviluppo di questa app e suddividerla in componenti diversi che possono essere completati completamente prima di passare a quello successivo. Il tuo manager potrebbe essere più propenso ad approvare il tempo extra per la nuova tecnologia se è in grado di vedere che stai facendo progressi costanti lungo la strada. Inoltre, non è necessario scegliere tra la scrittura dell'intera app in MVC e Entity Framework o nelle pagine ASPX e nei set di dati. È possibile utilizzare entrambi nella stessa app utilizzando un approccio ibrido. È possibile iniziare a utilizzare MVC e il framework di entità per alcuni componenti. Se le cose stanno andando bene e il tuo capo è felice, allora potresti continuare, ma se ritiene che impieghi troppo tempo, potresti sviluppare il resto dell'app con pagine ASPX e set di dati.

Mentre dovresti sicuramente imparare alcune delle nuove tecnologie MS, la mia recente esperienza di apprendimento su cose come WPF e WCF mi ha reso un po 'più cauto nell'apprendere le più recenti API MS.

Ora, LINQ è un grande vantaggio per la produttività che dovresti assolutamente usare; la cosa bella è che puoi introdurre gli oggetti LINQ in frammenti in tutti i tipi di situazioni casuali, con o senza la sintassi effettiva della query (in genere chiamo Where() senza la sintassi from-select , poiché è spesso più breve.) il doppio matematico di LINQ, Reactive Extensions, è qualcosa di cui dovresti essere a conoscenza, anche se sto ancora cercando di trovare un buon caso d'uso. Allo stesso modo, tutte le funzionalità di C # 3/4/5 sono utili, quindi dovresti studiarle e guardare i luoghi in cui saranno utili, anche se continui a utilizzare la "vecchia" roba BCL.

Tuttavia, prenderò l'avvocato del diavolo e suggerisco che le nuovissime librerie MS più grandi, come WCF e WPF, non valgono necessariamente la pena di essere apprese.

La ragione principale è che sono enormi e non particolarmente ben progettati (il primo è un sintomo di quest'ultimo). Recentemente ho parlato brevemente del motivo per cui WPF fa schifo . Per quanto riguarda WCF, il whitepaper fa sembrare che possa facilmente interagire facilmente con "Java EE server in esecuzione su un non -Sistema Windows "e" Applicazioni partner in esecuzione su una varietà di piattaforme ", ma la verità è che le API WCF sono molto orientate al SOAP e hanno un supporto molto limitato per i protocolli non SOAP. MS avrebbe potuto facilmente progettare un sistema generale che consenta protocolli innestabili, e forse la capacità è nascosta (non documentata) da qualche parte, ma per quanto posso dire hanno scelto di progettare un sistema molto più limitato che può fare solo SOAP e HTTP limitato (purché il corpo del messaggio sia un oggetto .NET serializzato, IIRC). Ho studiato brevemente Entity Framework, ma ho notato alcune lamentele sul fatto che non era in grado di supportare alcuni scenari che il LINQ-to-SQL (molto più semplice) può gestire immediatamente.

IMO il design di tutte queste librerie è fondamentalmente imperfetto perché usa molti componenti strettamente accoppiati tra loro, un grafico delle dipendenze delle classi in ogni struttura sarebbe probabilmente enorme e somiglia a un caos confuso di scribble Linee. E anche se il design fosse buono, non saremmo in grado di dire perché non ci sono documenti architettonici pubblici che approfondiscono i dettagli di livello inferiore, e i documenti MSDN per la maggior parte non sono molto buoni (tendono a diventare sempre meno utile guardando le classi di livello inferiore e inferiore.)

Anche la dimensione delle librerie sembra un difetto; Ho imparato oltre 20 anni di programmazione che la semplicità è una virtù, che Microsoft non ha mai apprezzato.

Ma potresti chiedere, "e allora?" Bene, con librerie così grandi potresti non sentirti mai veramente come tu le capisci. Ciò significa che quando si vuole fare qualcosa al di fuori dei casi d'uso per i quali Microsoft ha specificamente progettato WCF / WPF / EF, non si saprà come, ed è possibile che nessuno al di fuori di Redmond sappia come. E quando qualcosa va storto, avrai difficoltà a capire cosa è andato storto. E a 15 anni da quando Microsoft è passata alla propria prossima API di nuova generazione, a nessuno piacerà mantenere il software basato su una base che è così poco conosciuta.

Anche a causa della vastità e complessità di queste nuove API, l'alternativa multipiattaforma a .NET, Mono, ha scarso supporto o nessun supporto per loro. Probabilmente avrai poca difficoltà a utilizzare le tabelle dei dati digitate su Linux o Mac, ma Entity Framework? Dimenticalo. Non sarei sorpreso se Mono mai lo supporta.

Ho usato LINQ-to-SQL in un nuovo progetto e non è male. In un certo senso potrebbe essere migliore, ma penso che l'esperienza degli sviluppatori sia sostanzialmente migliore di ADO.NET. Un limite significativo: L2S è di gran lunga il più semplice se si modificano le tabelle in modalità "connessa", diversamente dal vecchio ADO.NET che è stato specificamente progettato per funzionare senza una connessione al database attiva. Comunque, dal momento che LINQ-to-SQL è (secondo Mono people) un quarto delle dimensioni di Entity Framework, è un peccato che MS abbia deciso di smettere di lavorare su di esso.

Ho sviluppato il software basato su Microsoft Windows per più di dieci anni prima di passare completamente al software libero e open source e ho rinunciato allo sviluppo di MS. Sto scrivendo questo da una lunga esperienza personale.

Oltre alle altre ragioni per le quali sono passato a FOSS, la ragione relativa alla programmazione è che non c'è quasi mai alcuna giustificazione per l'apprendimento / implementazione di tecnologie proprietarie. Il nocciolo della questione è che Microsoft non è impegnata a supportare ogni singolo pezzo di tecnologia che abbia mai distribuito. Troppo spesso la SM introduce modifiche deprecating alle proprie API e framework. Ciò rende obsolete molte delle API esistenti e le loro conoscenze. Anzi, lo fanno persino con il loro software per l'utente finale. Ad esempio, MS Office 2007/2010 non è simile a MS Office 2003 e, cosa più importante, Windows 8 è una svolta radicale rispetto alle piattaforme esistenti. In particolare, ci sono sicuramente tutte le nuove API e framework per Windows 8 e non sarà possibile supportare Windows 8 (in futuro, se non ora) senza implementarli. Questa tendenza a rendere costantemente obsolete e, ancora più importante, le tecnologie e le conoscenze esistenti, non supportate , è una delle ragioni principali del business per implementare qualsiasi nuova tecnologia rilasciata da MS. Se la SM smette di supportare la vecchia tecnologia domani, dove vai con il codice legacy? Dove prendi gli aggiornamenti per questo?

Nota anche che non ti sto chiedendo di abbandonare lo sviluppo di MS e passare a FOSS. Volevo solo aiutarti qui, avendo avuto una lunga esperienza nella tecnologia MS.

Penso che la cosa principale da fare sia capire quali sono i benefici concreti dell'adozione di una nuova tecnologia e presentare quelli come giustificazione per farlo, piuttosto che il proprio desiderio di non diventare obsoleto. Dici che non hai "motivi di lavoro", ma sicuramente puoi trovarne alcuni con la ricerca ...

Forse passare a una struttura / tecnologia più recente consente di progettare app che funzionano con un ingombro di memoria ridotto, sono più reattive, sono più veloci da implementare, ecc. Sarebbero tutte ragioni commerciali concrete. Quindi, suppongo che suggerirei di ritirarmi un po 'e di indagare "perché la gente ha iniziato a utilizzare MVC, LINQ, Entity Framework, servizi Web WCF, ecc. In primo luogo?" Rispondi a questa domanda e probabilmente troverai qualche giustificazione commerciale da offrire. Che sia sufficiente o meno abbandonare la filosofia del "andare con ciò che funziona" è un'altra questione e potrebbe essere una funzione della tua abilità di venditore.

What I currently use works fine and my development time is fast

Sfortunatamente, Microsoft non gliene frega nulla, ciò che conta per loro è venderti più strumenti. Ciò significa creare nuove tecnologie, il che significa che devi anche acquistare più formazione! Win-win, per loro.

Per te, significa una battaglia costante per imparare cose nuove, e una volta che hai iniziato a farti del bene e la tua produttività di sviluppo è veloce come una volta ... c'è qualcos'altro da imparare e tu devo ricominciare tutto da capo. C'è un motivo per cui il software è generalmente di scarsa qualità, perché non è trattato come i servizi "professionali" come l'ingegneria o l'architettura, ma mantiene le cose che funzionano. Li buttiamo via e ricominciamo da capo.

Ma questo povero stato del mondo non ti aiuta. Quindi il mio consiglio è di usare una combinazione di "stare al passo con la tecnologia" e "non voler restare indietro". Il tuo capo dovrebbe occuparsi del reclutamento, se lo facessi solo con VB6 dev, allora sarà abbastanza difficile reclutare nuovi dipendenti (beh, in realtà probabilmente lo troverai molto facile, tutti i ragazzi che ti piaceva VB6, ma questa è un'altra questione).

Direi che è necessario verificare se la nuova tecnologia x ti aiuterà a fare lo sviluppo futuro ancora più velocemente - poi smetterà di essere un compito personale o semplicemente dispendioso, e diventerà un compito di miglioramento del business, le società continueranno a parlare di come R & D "innovazione" li aiuta a rimanere competitivi.

Come sviluppatore, devi spingere il management a utilizzare le nuove tecnologie e giustificarlo dimostrando i vantaggi e il valore che apporterà alla società (ad esempio prestazioni, funzionalità, facilità d'uso, manutenzione). La gestione è generalmente contraria al cambiamento e non giustifica il cambiamento di qualcosa, a meno che non apporti alcuni vantaggi aggiuntivi rispetto a ciò che è attualmente in uso.

L'uso di una nuova tecnologia "bleeding edge" è utile anche per il team di marketing, in modo che possano commercializzare la società come al passo con le attuali tendenze tecnologiche e non rimanere bloccate in passato utilizzando tecnologie e piattaforme legacy.

Avrai bisogno di alcuni progetti più piccoli nel tuo tempo libero se la tua azienda non ti lascerà imparare da loro. L'apprendimento che fai nel tuo tempo privato dovrebbe darti il business case da fare al tuo capo per i miglioramenti nelle nuove tecnologie. Se ti senti troppo bruciato dal tuo lavoro quotidiano per imparare nuove cose, potresti dover prendere un qualche settimana di permesso , riposare per alcuni giorni, quindi fare una sessione di allenamento intensivo per te.

Di 'ciò che farai su Microsoft , una cosa su cui non puoi ignorare è rendere disponibili strumenti per sviluppatori e formazione su no costo . Installa l'ultimo programma di installazione di Microsoft Web Platform sul tuo PC, quindi accendi il programma e attendi di vedere tutti i file gratuiti strumenti di sviluppo e piattaforme che puoi provare. Visita MSDN , ASP.Net e < a href="http://channel9.msdn.com/"> Canale9 siti web e controlla i loro tutorial.

Sto ancora sviluppando in ASP Classic se riesci a crederci, ma con alcune ore di persuasione ho convinto il mio capo che .Net è la strada da percorrere, facendo un caso commerciale per questo. Il prossimo anno inizieremo la transizione del nostro codice legacy.

Il modo migliore per giustificare l'uso delle nuove tecnologie è quando puoi dimostrare che migliorano la produttività degli sviluppatori. Ciò significa più lavoro svolto a un costo inferiore. Questa è l'unica cosa che conta dal punto di vista del business.

Alcuni esempi:

1. Strumenti che semplificano lo sviluppo dello sviluppatore
2. Librerie che forniscono funzionalità che altrimenti dovrebbero essere sviluppate in house
3. Linguaggi più potenti che possono risultare in codice più facile da leggere o meno righe di codice da scrivere / eseguire il debug