Scrittura del codice e utilizzo degli strumenti di trascinamento della selezione [chiuso]

0

Se trascini & rilascia, stai permettendo all'editor di creare il codice per te. Sicuramente significa che non stai davvero programmando. Stai costruendo un'applicazione che non ha una corretta logica di codice, corretta?

Trascino semplici controlli su un modulo Web in .NET, ma sicuramente non puoi contare al 100% sulla creazione di un'app in questo modo? Sebbene alcuni libri tutorial in .NET ti stiano trascinando e rilasciando dappertutto.

Un esempio, la lettura da un database usando ASP.NET. È possibile rilasciare controlli SQL sul markup o programmare il recupero nel codice sottostante.

Preferisco il codice dietro perché hai il controllo corretto imho.

Pensieri?

    
posta TeaDrinkingGeek 20.04.2011 - 11:38
fonte

17 risposte

2

Onestamente, si tratta principalmente dell'ambito del progetto. Come molti hanno menzionato qui, l'uso di strumenti visivi non ti rende meno un programmatore e può essere un risparmio di tempo. Tuttavia, devi essere in grado di fidarti dei tuoi strumenti e essere consapevole del codice generato dalle tue azioni.

I metodi vengono generati automaticamente? Il posizionamento usato è assoluto o relativo? Ho utilizzato Flex Builder e alcuni strumenti di Silverlight, oltre a buoni vecchi generatori Swing e il comportamento di tali strumenti può variare notevolmente. Mentre questi strumenti possono fornire velocità di progettazione e feedback visivo istantaneo di come può essere la tua applicazione, il codice può richiedere un grande successo di manutenibilità, specialmente se non conosci gli strumenti dentro e fuori.

Pertanto, entrambi gli approcci hanno qualche merito:

Visual Assisted Approach

  • Feedback visivo istantaneo.
  • Molto veloce per creare un'interfaccia utente.
  • Più difficile da recensire e gestire.
  • Le modifiche all'interfaccia utente possono avere conseguenze sorprendenti.
  • Alcuni metodi generati automaticamente non utilizzati potrebbe essere lasciato indietro.

Codificato a mano

  • Lo sviluppo più lento.

  • Più facile da mantenere (dato buono codice!).

  • Ottieni esattamente ciò che hai codificato: no funzioni avanzate, non documentate caratteristiche.

Il primo metodo è molto utile per i progetti in rapido movimento, in cui si desidera avere un rapido riscontro visivo. Il secondo metodo richiede più disciplina, ma è più utile per le applicazioni critiche che potrebbero dover essere mantenute per lungo tempo.

Certo, prendi tutto con un pizzico di sale. Se sei abituato a codificare un'interfaccia a mano, sarai più veloce e più efficiente andando in quel modo. D'altra parte, se tu (e il tuo team) siete a conoscenza di tutti gli artefatti generati da un editor visuale, la manutenibilità potrebbe non essere un problema per voi.

    
risposta data 26.04.2011 - 13:42
fonte
25

Non penso di capire cosa intendi con il trascinamento della selezione. Non utilizzo .NET, ma utilizzo Qt per le interfacce utente e utilizzo di Qt Creator per la creazione del layout dei widget.

Non penso che questo mi renda di meno un programmatore, dato che la logica attuale del programma è tutta fatta altrove, e io uso semplicemente Qt Creator per fare in modo che le cose si allineino in un modo che è:

  • molto meno tempo che richiede
  • molto più semplice da adattare alle esigenze degli utenti; e
  • generalmente più facile da capire rispetto a quando ho costruito manualmente tutti i layout in C ++.

Non mi vergogno di questo. Non vedo perché qualcuno sarebbe. Le mie applicazioni hanno una buona dose di logica e funzionalità, ma non si tratta solo dell'interfaccia utente. Sicuramente questo è il caso per la maggior parte delle persone? Le interfacce forniscono un mezzo per utilizzare le funzionalità, non sono la funzionalità in sé e per sé.

    
risposta data 07.02.2011 - 19:16
fonte
15

Trascinare le immagini visive in giro è solo uno dei tanti strumenti di sviluppo per semplificarti la vita, come un debugger, o qualcosa che genera automaticamente funzioni getter e setter, e non c'è nulla di intrinsecamente sbagliato in questo. È come usare una calcolatrice. Se ti affidi troppo a un bambino, allora non potresti mai diventare bravo nei tuoi orari. Tuttavia, una volta che si è esperti con i metodi, si potrebbe non avere il desiderio di più 634 * 592 a mano. Sì, puoi usare ancora i metodi che ti sono stati insegnati nella scuola elementare, ma a meno che non ci sia un valido motivo per esercitarlo, non è rilevante per il problema in questione, ed è più veloce usare gli strumenti.

D'altra parte, se continui a raggiungere la calcolatrice moltiplicando 6 * 9 1 , probabilmente dovresti pensare di più ad ottenere la tua pratica. Con la pratica, ci sono molti blocchi di codice che conoscerai a memoria e non dovrebbe essere necessario trascinarli e rilasciarli.

Quindi ovviamente la risposta è: dipende.

  1. Che, come sanno tutti i fan di Douglas Adams, è 42.
risposta data 07.02.2011 - 20:49
fonte
8

è semplice: trascina e rilascia quando funziona, passa il codice mano quando non lo fa

non è una situazione o!

    
risposta data 07.02.2011 - 21:37
fonte
7

Tu sei in programmazione, è solo che hai meno controllo sul codice generato, che di solito è il motivo per cui preferiresti la codifica manuale. Potresti avere il meglio di entrambi i mondi: usa il drag & rilasciare per creare un prototipo rapido, quindi regolarlo a mano.

    
risposta data 07.02.2011 - 19:24
fonte
6

A meno che tu non stia codificando 1 e 0 direttamente sull'hardware, stai utilizzando un certo livello di astrazione. Questa è una cosa buona in quanto ci rende più produttivi. Gli assemblatori ci consentono di scrivere codice più velocemente rispetto a posizionare manualmente 0 e 1. I primi linguaggi come FORTRAN e C ci permettono di essere ancora più astratti. Lingue moderne come C #, JAVA e così via ci permettono di essere ancora più produttivi. Strumenti come Visual Studio e Qt Creator ci consentono di automatizzare alcune delle parti più noiose e banali delle nostre applicazioni. Permettendoci di concentrarci sulla logica più importante nella nostra applicazione.

Potresti guadagnare una piccola quantità di velocità codifica manualmente queste sezioni, sì, potresti, e se hai usato un linguaggio di livello inferiore come C lo rendi ancora più veloce, ma qualcuno con la conoscenza e il tempo potrebbe renderlo ancora più veloce se hanno scritto in assembler o anche direttamente in linguaggio macchina.

Non sapere come scrivere in Assembler ti rende meno un programmatore. In alcuni casi lo fa, ma per la maggior parte di noi non importa, secondo me. Come analogia, quanti ingegneri usano le regole delle diapositive invece dei calcolatori?

    
risposta data 08.02.2011 - 20:19
fonte
2

Non penso sia possibile costruire qualcosa di più di programmi banali con programmi drag-an'-drop di facile utilizzo o molto limitati con drag-an'-drop complessi (di solito specifici del dominio, altro complesso e bugger di Forms Designer).

Personalmente mi piace molto il drag-an'-drop per cose come la progettazione dell'interfaccia utente, in quanto toglie un sacco di noia di codice che crea un controllo, imposta proprietà, imposta posizione, schiuma, risciacquo, ripetizione, blah blah. .. e mi permette di arrivare agli algoritmi interessanti e alla risoluzione dei problemi più velocemente (una volta che l'interfaccia utente è fuori mano). Costruttori di drag-an'-drop personalizzati che tentano di creare fantasiose creazioni di workflow e business logic e quindi di consentire espressioni di codice complesse per la valutazione del runtime, sono un po 'più titubante. Tendono ad essere più restrittivi in ciò che può effettivamente essere costruito e non possono ancora fare tutto ciò che devono fare. In questi casi preferirei semplicemente scrivere il codice a mano.

    
risposta data 07.02.2011 - 19:15
fonte
2

Quando apro Visual Studio per la codifica, sì ... mi definisco un "programmatore". Ma la storia inizia quando dico di conoscere lo strumento su cui sto lavorando. Parlando in particolare di Visual Studio, se scrivo completamente la pagina aspx invece di trascinare e rilasciare gli strumenti dalla toolbox ... allora non sarò un buon programmatore perché non sto ottimizzando completamente il mio tempo.

    
risposta data 08.02.2011 - 21:25
fonte
2

Noun programming (plural programmings)

...

3.(computing) The act of writing a computer program. "Management wanted to know how much programming the project would need."

4.The software that controls a machine, or the logic or expressed in such software; operating instructions A robot's programming doesn't allow for love.

link

Stai ancora programmando, proprio come sto ancora cucinando quando faccio un pasto congelato nel microonde. Solo perché ci vuole meno abilità non lo rende invalido, ma non mi vedrai nemmeno sulla rete di Food reclamando quanto siano buoni i miei pasti in stile Lean Cuisine.

    
risposta data 20.04.2011 - 14:22
fonte
2

If you drag & drop, you're letting the editor to build code for you. You're building an application that has no proper code logic, correct?

All'inizio c'era Frontpage. Trascinando e rilasciando gli elementi creati molte tabelle e tabelle nidificate. Questo è dannoso per la manutenzione. Ma è anche un concetto obsoleto.

I drag simple controls on a web form in .NET, but surely you cannot rely 100% on building an app that way?

Gli IDE sono strumenti di produttività. È più veloce da trascinare e rilasciare. Se non è necessario scrivere il codice manualmente, non farlo.

Oggi, Visual Studio consente il trascinamento di molti elementi senza produrre molto codice cestino. Inoltre oggi Microsoft ha investito un bel po 'di tempo e denaro nella ricerca di buoni valori predefiniti. Di fatto, esiste un'intera campagna sull'usabilità di framework / tool intitolata caduta nella fossa di successo.

Quindi, dovresti approfittare di tutti gli investimenti di MS. Usa gli strumenti.

    
risposta data 20.04.2011 - 22:41
fonte
1

I clienti non si preoccupano di ciò che ti preoccupa , si preoccupano solo dei codici bug esenti forniti in tempo e in budget che, soprattutto, aggiungono valore al business.

I costruttori di GUI che accelerano lo sviluppo e aumentano la qualità del codice evitando che errori umani ignorati siano il marchio di uno sviluppatore scadente.

Gli zeri e gli zeri più belli fatti a mano che in realtà non forniscono alcun valore al business sono completamente inutili.

    
risposta data 20.04.2011 - 23:17
fonte
0

Non c'è niente di sbagliato nell'usare un editor DnD per progettare interfacce utente. Considerando che stai progettando un'interfaccia grafica che sia in grado di vedere l'aspetto della tua interfaccia e che potrebbe essere interagito mentre costruisci ha senso, e se non riesci a far sì che l'editor DnD ti dia il look / comportamento giusto, puoi vai sempre nel codice generato e perfeziona.

    
risposta data 07.02.2011 - 19:40
fonte
0

Bene, lo dirò dalle due aree di sviluppo che conosco abbastanza bene da commentare: lo sviluppo di WPF / Silverlight. Non uso quasi mai il drag 'n drop con nessuno di questi perché trovo che il codice che crea, in particolare la roba XAML, rende tutti i tipi di pazzi margini e ipotesi su ciò che stai cercando di fare. Quando crei un modulo o un tipo di schermo in WPF / Silverlight, devi assicurarti che i controlli siano in grado di scalare correttamente quando l'utente sta ridimensionando le cose. Certo, ci sono momenti in cui vuoi definire un margine, ma dovresti farlo secondo i tuoi termini, non quelli dell'IDE. Quando stavo facendo più cose con Windows Form, ho fatto decisamente affidamento sul drag 'n drop perché era così facile da legare ai set di dati in quel modo, ma ti ritrovavi a dover annullare come 1/3 del codice che era stato generato - che è diventato molto brutto.

Oggigiorno con WPF e MVVM è molto più pulito e si presta alle applicazioni di codifica manuale, che a lungo termine separano anche i veri sviluppatori da quelli che possono rilasciare un modulo sulla finestra e creare una semplice app crud. Ad ogni modo, penso che sia buono scrivere codice piuttosto che lasciar cadere cose sullo schermo perché consente di creare codice veramente efficiente e non solo pezzi di codice gonfiati. Sto anche scavando in profondità in ASP.NET MVC Framework per un progetto imminente che devo fare e sono felice di essermi allontanato da draggy droppy, perché questo sicuramente NON ti aiuterà con il MVC quadro!

    
risposta data 08.02.2011 - 20:14
fonte
0

Lo guardo in termini di strumenti e risultati. Ogni metodo, drag-and-drop o codifica a mano, è solo uno strumento. Il mio lavoro è determinare per attività quale strumento mi dà risultati migliori? (Nota: i risultati desiderati per attività variano notevolmente).

A volte potrei voler scrivere a mano perché il mio risultato desiderato è che capisco e controllo completamente il codice. O che ho piccoli dettagli che devono essere calibrati in modo preciso.

A volte potrei voler usare le tecniche di trascinamento della selezione perché il mio risultato desiderato è che voglio produrre un gran numero di risultati veloci.

In pratica, li uso entrambi. Dividerò un compito in una serie di compiti, e per una sottoattività particolare determinerò se è più preferibile la codifica manuale o il drag-and-drop. Quindi utilizzare lo strumento migliore per l'attività. A volte viene scelta la codifica manuale perché sono già in modalità di codifica manuale. Se un'attività particolare richiede esclusivamente uno strumento particolare, non c'è molto da preoccuparsi.

"Sicuramente questo significa che non stai davvero programmando. Stai costruendo un'applicazione che non ha una corretta logica di codice, giusto?" Per quanto DnD non stia davvero programmando: probabilmente nella maggior parte dei casi tecnicamente sono d'accordo con quella classificazione. Ma in realtà, se il DnD o la codifica manuale possono produrre lo stesso risultato, la denominazione non significa nulla.

(Inoltre, con DnD stai ancora costruendo un'applicazione che ha una logica di codice, è solo che la maggior parte dei dettagli viene gestita da un programma. In un modo simile a come quando scriviamo in linguaggi di alto livello, stiamo ancora scrivendo per una macchina da qualche parte, ma la maggior parte (o tutti) dei dettagli del codice macchina ci stanno prendendo cura di noi.)

Infine, la quantità o il tipo di lavoro inserito in una creazione non è un indicatore della qualità della creazione. Per me personalmente, la codifica a mano sembra un lavoro "reale" o una programmazione "reale" perché richiede più tempo, pensieri o altre risorse da parte mia. Ma alla fine della giornata, la mia programmazione è giudicata principalmente dai miei programmi, non dai miei processi.

    
risposta data 25.04.2011 - 21:19
fonte
0

Hai un capo fastidioso che ha parlato di timeline prima che potesse dire mamma quando è nato?

La maggior parte di noi lo fa.

Sì, impari molto se hai tutto il tempo del mondo per capire da solo le cose. Ora per i mortali minori, che hanno scadenze e famiglia, e si spera che anche alcune priorità personali, preferirebbero usare un po 'di aiuto.

L'uso di drag-n-drop non è solo programmazione, ma per cose come la progettazione dell'interfaccia utente, è un invio di Dio.

E francamente, anche se prendo la tua discussione e dico che sono un programmatore sciatto se uso drag-n-drop quale grandezza si ottiene imparando MFC o WPF? Perché non spendere energia per ottimizzare o mettere a punto la logica dell'applicazione e lasciare che le basi siano prese in considerazione?

    
risposta data 26.04.2011 - 10:39
fonte
0

Se hai le conoscenze di programmazione rilevanti, perché dovresti preoccuparti se è da trascinare e rilasciare o puro codice. Se è possibile assicurarsi che il codice generato non sia difettoso e sia corretto secondo i concetti di programmazione di base e supporti la logica di programmazione che si svilupperà, non vedo quasi nessun grosso svantaggio. In effetti renderà la vita del programmatore molto più facile, a condizione che tu sia un buon programmatore.

Se sei un novizio della disciplina della programmazione, hai un problema con il trascinamento della selezione. Quello che saprai sulla lingua specifica alla fine della giornata non sarebbe il modo corretto di eseguirlo e ottimizzarlo. Ma se sei un programmatore esperto e se riesci a formulare un giudizio sul codice che viene creato automaticamente, trascina e rilascia definitivamente la tua efficienza. Questo è il motivo per cui immagino ci siano strumenti supportati per il drag-drop disponibili, per sviluppare velocemente le applicazioni, quanto sia strong la logica, la preoccupazione del programmatore; perché lo strumento non sarà in grado di creare la logica ma supportarne uno.

Per un esempio di strumenti di integrazione in business intelligence; sicuramente sono puri strumenti drag-and-drop per quanto riguarda la logica. Il programmatore dovrebbe sicuramente sapere cosa sta facendo. Salva solo il dolore della scrittura del codice per fare un'integrazione. Ci saranno differenze minime se si confronta la codifica con il trascinamento e il rilascio in questo contesto. Credo che la codifica sia più incline agli errori in questo modo, poiché tenterai di reinventare la ruota durante l'arco di un progetto e oltre.

Con tutte le idee e gli esempi che vorrei concludere dicendo, trascinare e rilasciare è rendere il lavoro facile per i ragazzi esperti ed essere più produttivi. Non sono gli strumenti per le persone che iniziano a programmare (ma possono avere eccezioni) la programmazione, potrebbe essere la codifica sul blocco note sarà sicuramente vantaggi per come persona che sta avviando. Se conosci correttamente il tuo contesto, sicuramente sarai in grado di utilizzare il trascinamento e il rilascio estremamente produttivo.

    
risposta data 26.04.2011 - 11:01
fonte
-2

Preferisco scrivere tutto il codice di un sito web, HTML, CSS, JS, AJAX e PHP.

Ma preferisco usare il drag & rilascia strumenti come Visual Studio, per creare applicazioni basate sugli oggetti.

    
risposta data 23.04.2011 - 04:39
fonte

Leggi altre domande sui tag