Gli strumenti, come Windows Workflow, inibiscono la crescita dello sviluppo? [chiuso]

Windows Workflow è un'astrazione, proprio come WPF, EF, Windows e ogni linguaggio di programmazione esistente. Come tutte le buone astrazioni, fornisce un modo per sfruttare i concetti fondamentali, basandosi sulle idee create dagli altri e migliorando su di esse.

Senza astrazioni, non ci sarebbe alcuna crescita e nessuna civiltà (come la conosciamo).

Gli eccellenti sviluppatori di software sanno come smontare queste astrazioni e comprendere i principi sottostanti. Le medie imparano solo le astrazioni e le usano per costruire programmi, e non c'è niente di sbagliato in questo.

Non penso che uno strumento sia ciò che inibisce la crescita di uno sviluppatore più di quanto uno strumento specifico possa inibire la crescita di un falegname (a meno che non sia un strumento mal fatto ). Ciò che inibisce la crescita è la compiacenza. Quando ho passato i processi di assunzione, ho incontrato sviluppatori con anni di esperienza con .NET e numerosi progetti di successo, ma non conosco molto oltre le basi della sintassi e dell'uso del designer (e succede anche ad altri piattaforme mature pure, è solo che ci sono moltissimi sviluppatori .NET, si corre su questo fenomeno più frequentemente).

La chiamo sindrome M. Night Shyamalan / Tyler Perry. Il successo genera compiacimento. Shyamalan ha avuto successo con la trovata "epica torsione" e ha sentito il bisogno di farne una parte di ogni film piuttosto che ... imparare a scrivere una storia migliore. Tyler Perry ha avuto molto successo scrivendo Moral Plays, ora ha circa 20 film fuori che per la maggior parte sono essenzialmente gli stessi. Uno sviluppatore che ha successo usando gli strumenti di base (il che è del tutto possibile) corre il rischio di diventare compiacente e di non spingere se stesso per saperne di più. Puoi fare una carriera di successo.

Gli strumenti non sono da incolpare, la mancanza di passione è.

Ho lavorato molto con strumenti di questo tipo generale (non specificamente WW ma simili) e la mia esperienza è stata quella di sembrare come se ti consentissero di astrarre una serie di funzionalità. Questo è il loro punto di forza.

Ci sono molte ruote in questo mondo, non c'è valore per noi come programmatori che ne inventano di più. Perché non estrapolare alcune di quelle cose non che noi non conosciamo come fare, ma precisamente che abbiamo fatto abbastanza volte che la prospettiva di farlo di nuovo è davvero poco attraente. Se abbiamo un buon strumento affidabile che è stato ben testato dal venditore e collegato al loro sistema operativo (o è open source e ben supportato o altro) quale motivo dovremmo giustificare non usandolo?

La pratica è stata, secondo la mia esperienza, che in molti casi sarebbe stato più veloce scriverlo noi stessi che utilizzare lo strumento fornitori e che per tutte le astrazioni offerte, si finisce comunque per dover comprendere gli interni di nove librerie diverse e le peculiarità di chiamare cinque API diverse e il motivo per cui lavoreranno in questo ambiente ma non funzioneranno in quell'ambiente e in realtà forse non sono supportate così come sembravano e potrebbe essere il caso che se avessimo avuto scritto qualcosa per la nostra situazione specifica, probabilmente sarebbe stato più veloce, si sarebbe comportato meglio e ci avrebbe risparmiato un sacco di mal di testa.

Non succede sempre così. Ma spesso, mi dispiace dirlo, lo fa.

Ci sono stati, naturalmente, alcuni esempi in passato in cui le nuove tecnologie fornivano l'astrazione che rendeva la programmazione più facile o addirittura obsoleta. Posso pensare

• l'invenzione di linguaggi di programmazione di livello superiore (non hai più bisogno di imparare l'assemblatore)

• l'invenzione dei fogli di calcolo (consente agli utenti di risolvere molti problemi senza alcuna programmazione)

• Database SQL (una query SQL scritta in 20 minuti può sostituire un programma 1-developer-week in tecnologie pre-SQL)

• designer grafici dell'interfaccia utente

• l'ampia adozione di linguaggi di programmazione con gestione automatica della memoria (anziché gestione manuale della memoria)

E sì, ognuno di questi strumenti potrebbe aver cambiato o ridotto la necessità di determinate abilità di sviluppo (ad esempio, la necessità di programmatori assembler). Quindi, si potrebbe sostenere che inibiscono la crescita di tali abilità. D'altro canto, anche la necessità di nuove e diverse abilità è aumentata - ad esempio, la programmazione SQL è un mestiere a sé stante.

Per quello che so della WW, tuttavia, c'è assolutamente una ragione no per credere che avrà un'influenza simile a quella degli esempi precedenti - la gamma di applicazioni in cui ciò dà reali benefici è anche IMHO piccolo.

Questi strumenti e strutture non inibiscono la crescita, promuovono la crescita in diverse direzioni. Ci sono molti pezzi necessari per costruire sistemi computazionali complessi, alcuni di questi sono funzionalità fondamentali o comuni come i livelli DB, i framework UI, i livelli di comunicazione ... Altri pezzi implicano la conoscenza di business o di dominio per implementare la funzionalità dell'applicazione.

Alcuni sviluppatori lavoreranno su quei pezzi fondamentali e la loro crescita sarà in quelle aree. Altri sviluppatori prenderanno questi componenti e li costruiranno in un sistema, e la loro crescita avverrà in quelle aree di visualizzazione più grandi.