Gli strumenti di progettazione degradano l'esperienza di programmazione? [chiuso]

Ultimamente mi sono guardato intorno, in particolare alcuni degli strumenti di MS disponibili, e sto notando una grande attenzione agli strumenti di progettazione e ai maghi. Non solo per lo sviluppo dell'interfaccia utente ma per tutto.

• Entity Framework ha il modellatore
• RIA Services dispone della procedura guidata di DomainService
• Il flusso di lavoro ha tutto il progettista del flusso di lavoro ... (Non lo so, non l'ho usato davvero)

C'è di più, ma penso che tu abbia l'idea. Ci sono molti strumenti di progettazione. Usando alcuni di questi trovo che:

Complicano le cose oltre i casi d'uso prescritti

(ovvero tutti i video dimostrativi tecnici)

Ho valutato alcune di queste tecnologie di recente, e provando a lavorare con loro finisco per dover analizzare esattamente ciò che i designer, i modellatori e i maghi stanno facendo per me ... altrimenti mi perdo quando devo davvero provare a fare qualcosa con qualunque cosa sia stata creata.

Questo finisce per essere un caso in cui devo combattere lo strumento o combattere la sua produzione in modo tale che avrei potuto fare tutto da solo senza di essa - e avere una comprensione molto più forte di ciò che sta succedendo. Lo trovo particolarmente esasperante con il designer Silverlight e la procedura guidata per i servizi di dominio dei servizi RIA.

Mi ritrovo a chiedere "A che serve questo strumento se devo capire i suoi meccanismi interni o riscrivere metà del suo output per usarlo?"

Non sono così veloci

Il punto di forza di questi strumenti è aumentare la produttività e questo punto può cambiare nel tempo usando lo strumento e non si applica necessariamente ai progettisti dell'interfaccia utente (sebbene, in alcuni casi, continui a farlo -> Sto guardando il tuo designer Silverlight) . Trovo che posso hackerare un po 'di codice molto più velocemente di quanto posso trascinare, ridimensionare, spostare, qualunque cosa in un designer.

L'interfaccia utente si frappone al modello

Forse sono solo io, ma quando sto usando qualcosa che ricorda uno strumento di progettazione UML finisco per passare più tempo a disporre tutto in modo che le mie linee non si incrociano e in modo da poter vedere tutto sullo schermo piuttosto che modellare ciò che sto cercando di raggiungere.

Non sono divertenti

La metà del motivo per cui codice per vivere è che mi diverto. Fare clic sulle caselle di controllo e selezionare le caselle combinate e quindi correggere tutto ciò che viene fuori non è divertente.

Non mi sembra di essere solo

La comunità sembra non voler nemmeno questi strumenti. Il miglior esempio che mi viene in mente al momento è Entity Framework Code-First.

Quindi chiedo:

1. Gli strumenti di progettazione migliorano effettivamente la produttività?
2. Sono assassini divertenti?
3. La "comunità" sta effettivamente chiedendo più strumenti di progettazione o i venditori stanno solo pensando che siamo?

La mia ipotesi è che buoni strumenti di progettazione migliorino la produttività e non togliano il "divertimento". Tuttavia, è solo una supposizione perché devo ancora trovare un buon strumento di progettazione.

Personalmente non ho chiesto strumenti di progettazione.

1. Penso che probabilmente dipende. Se sei uno sviluppatore abbastanza inesperto, probabilmente utilizzare gli strumenti di progettazione è più produttivo che digitarlo. Sono abbastanza sicuro di essere stato più produttivo nei miei primi giorni di VB6 usando il designer di quanto non l'avrei fatto a mano. L'altra cosa da considerare è come la tecnologia (almeno come l'IDE la presenta) si presta alla modifica manuale. VB6 e .NET WinForms certamente non (o piuttosto probabilmente non vuoi modificare manualmente il file di codice "generato" (o parte di). Con WPF e ASP.NET penso che uno sviluppatore abbastanza inesperto inizierà con designer ma si è rapidamente laureato alla modifica diretta di XAML / ASP. Una volta che sai cosa stai facendo, è sicuramente più veloce modificare direttamente il markup. Ripensando a EF v1.0,

2. Dipende se il markup è divertente con cui lavorare. WPF e ASP (.NET) possono essere divertenti. VB6 / WinForms - no, non voglio modificare le sezioni di codice generate più del necessario.

3. Non penso che la comunità lo faccia esplicitamente. Anche se quando apprende qualcosa di nuovo, il designer può rendere più facile la deglutizione in blocchi di apprendimento.

come al solito dipende

Quando ho investigato per la prima volta utilizzando i servizi Web, Java aveva un tutorial di 50 pagine e .NET aveva una procedura guidata. Indovina quale è stato utilizzato?

Lo stesso qui, nessuno strumento di progettazione.

Progetto l'ERD del database su carta e scrivo un deployer che emette le istruzioni "create table", in questo modo posso cancellare e ricostruire a piacimento. Aiuta anche per il controllo delle versioni del database.

Trovo che la carta 11x17 (A3) possa essere un ottimo posto per progettare sistemi molto compelex. Prendi una buona gomma e matite (preferisco Staedtler ).

Dal punto di vista del venditore, tutti questi fantasiosi strumenti di design sembrano servire a uno scopo simile a sconti / licenze per studenti gratuite. L'idea è di permetterti di creare qualcosa con il minimo sforzo e costo. Una volta che sei investito, scommettono che imparerai ad espandere le tue abilità con i loro strumenti piuttosto che a imparare qualcun altro.

Questo non vuol dire che gli strumenti non abbiano usi produttivi legittimi. Esso dovrebbe essere utile per esaminare il codice generato e imparare da esso. Sfortunatamente, come ha notato Ken Henderson, il codice è spesso illeggibile e non qualcosa che si desidera utilizzare come modello per lavori futuri. Mi vengono in mente diverse sezioni della Programmazione dei servizi WCF , in cui l'autore spiega come scrivere il codice manualmente o come farlo generare da Visual Studio. Inevitabilmente, l'opzione generata richiede una sezione di follow-up per la rimozione di codice estraneo.

Gli strumenti di progettazione migliorano effettivamente la produttività?

Possono essere purché il tuo progetto sia semplice e non troppo complesso per loro. La mia esperienza ti ha colpito il muro non appena si tenta di implementare / risolvere un problema del mondo reale.

Sono assassini divertenti?

WF (Workflow) e WPF sono stati divertenti ma anche assassini quando il VS 2008 si è schiantato ogni 30 minuti.

La "comunità" sta effettivamente chiedendo più strumenti di progettazione o i venditori stanno solo pensando che siamo?

Molti degli strumenti rilasciati da MS recentemente sembrano essere tentativi disperati di mantenere gli sviluppatori. La battaglia è attualmente in corso nel mercato degli smart phone. Chi vincerà il cast di sviluppatori, MS, Google o Apple?

È sempre stato il modo, anche nel tempo in cui distinguevamo tra sviluppatori che sapevano solo fare clic sui maghi e sviluppatori che sapevano quale codice generavano i maghi e che potevano modificarlo per i casi limite.

Il fatto che tu abbia ancora più strumenti, maghi e designer che fanno cose sotto le coperte per impedirti di tagliarti a pezzi taglienti è un vantaggio per gli sviluppatori che o non vogliono sapere o non hanno l'ampiezza di esperienza o abilità per comprendere il codice generato. Immagino che ci sia un punto debole tra ciò che vuoi che il computer faccia per te e ciò che devi fare tu stesso in quanto l'alternativa è programmare i linguaggi interamente basati sul trascinamento dei blocchi su un modulo. (Lavoravo su una cosa del genere in un ambiente specifico del dominio, non avrei voluto usarlo!)