Cosa pensi di sviluppare per la riga di comando prima?


20

Quali sono le tue opinioni sullo sviluppo per la riga di comando prima, quindi aggiungere una GUI dopo il fatto semplicemente chiamando i metodi della riga di comando?

es.

W: \ todo addTask "incontro con Giovanni, Re: Accesso peer review" "ufficio di John" "2008-08-22" "14:00"

carichi todo.exe e chiama una funzione chiamato AddTask che esegue alcune convalide e genera la riunione in un database.

Alla fine si aggiunge una schermata per questo:

 
============================================================ 

Event: [meeting with John, re: login peer review] 

Location: [John's office] 

Date:  [Fri. Aug. 22, 2008] 

Time:  [ 2:00 PM] 

[Clear] [Submit] 

============================================================ 

Quando si clic su Invia, si chiama la stessa funzione addTask.

È questo considerato:

  • un buon modo per codificare
  • solo per i neofiti
  • orrendo !.

Addendum: "libreria condivisa denominata sia dalla GUI e gli eseguibili CLI"

sto notando una tendenza qui per C'è qualche motivo convincente per cui dovrebbero essere separati, a parte forse la dimensione dei binari stessi?

Perché non basta chiamare lo stesso eseguibile in diversi modi:

  • "todo /G" quando si desidera che il full-on interfaccia grafica
  • "todo /I" per un prompt interattivo entrotodo.exe (scripting, ecc)
  • plain old "todo <function>" quando vuoi solo fare una cosa e averne finito.

Addendum 2:

'stato detto che "il modo in cui [ho] ha descritto le cose, si [sarebbe] bisogno di generare un eseguibile ogni volta che la GUI ha bisogno di fare qualcosa"

Ancora, questo non era il mio intento. Quando ho menzionato che la GUI di esempio ha chiamato "la stessa funzione AddTask", non intendevo la GUI richiamare il programma da riga di comando ogni volta. Sono d'accordo che sarebbe totalmente antipatico. Avevo inteso (vedi il primo addendum) che tutto questo è contenuto in un singolo eseguibile, poiché era un piccolo esempio, ma non penso che il mio fraseggio precludesse necessariamente una libreria condivisa.

Inoltre, vorrei ringraziare tutti voi per il vostro contributo. Questo è qualcosa che mi ritorna in mente e apprezzo la saggezza della tua esperienza.

  0

In Windows si segnano un eseguibile sia come un programma di console, o come gui. Non è possibile avere entrambi abilitati allo stesso tempo. 20 dic. 082008-12-20 16:38:03

  0

Principalmente vero. Ma un'app CLI può fungere da wrapper per un'altra app GUI. Se l'app CLI non supera il flag/G, l'app GUI non crea semplicemente una finestra. Vedere MsDev.com/.exe per un esempio simile 12 gen. 092009-01-12 15:43:27

16

Vorrei andare con la costruzione di una libreria con un'applicazione a riga di comando che si collega ad essa. Successivamente, è possibile creare una GUI che si collega alla stessa libreria. Chiamare una riga di comando da una GUI genera processi esterni per ciascun comando ed è più dirompente per il sistema operativo.

Inoltre, con una libreria è possibile eseguire facilmente test unitari per la funzionalità.

Ma anche se il codice funzionale è separato dall'interprete della riga di comando, è possibile riutilizzare l'origine per una GUI senza avere i due tipi contemporaneamente per eseguire un'operazione.


7

Inserire la funzionalità condivisa in una libreria, quindi scrivere una riga di comando e un front-end della GUI. In questo modo la transizione del livello non è legata alla riga di comando.

(Inoltre, in questo modo aggiunge un altro problema di sicurezza: non dovrebbe avere la GUI prima per assicurarsi che sia il DIRITTO todo.exe che viene chiamato?)


1

dipende Kinda sul vostro obiettivo per il programma, ma Sì, lo faccio di tanto in tanto, è più veloce da codificare, più facile da eseguire il debug e più facile scrivere casi di test rapidi e sporchi. E fintanto che strutturo correttamente il mio codice, posso tornare indietro e aggiungere una GUI in un secondo momento senza troppo lavoro.

Per quelli che suggeriscono che questa tecnica si tradurrà in UI orribili, inutilizzabili: hai ragione. Scrivere un'utilità della riga di comando è un modo terribile di progettare una GUI. Prendete nota, tutti là fuori pensando di scrivere un'interfaccia utente che non è un CLUI - non prototiparlo come un CLUI.

Ma, se si sta scrivendo un nuovo codice che non dipende da un'interfaccia utente, quindi fare clic.


5

Joel ha scritto un articolo che contrasta lo sviluppo ("unix-style") della GUI prima (metodo "stile Windows") alcuni anni fa. Lo chiamò Biculturalism.

Penso che su Windows diventerà normale (se non lo è già) per avvolgere la logica in assembly .NET, a cui è possibile accedere sia da una GUI che da un provider PowerShell. In questo modo ottieni il meglio da entrambi i mondi.


2

Probabilmente è meglio iniziare con una riga di comando prima di assicurarsi di avere la funzionalità corretta. Se i tuoi utenti principali non possono (o non vogliono) utilizzare la riga di comando, puoi aggiungere una GUI al di sopra del tuo lavoro.

Ciò renderà la tua app più adatta allo scripting e limiterà la quantità di anticipo Bikeshedding in modo che tu possa arrivare più rapidamente alla soluzione reale.


2

Se si intende mantenere la versione della propria riga di comando della propria app, non vedo alcun problema nel farlo in questo modo - non è tempo perso. Finirai comunque a codificare la funzionalità principale della tua app per la riga di comando e così avrai una buona parte del lavoro svolto.

non vedo lavorare in questo modo come una barriera per una bella interfaccia utente - hai ancora il tempo per inserire uno e fare è utilizzabile ecc

Credo che questo modo di lavorare sarebbe veramente solo funziona se si intende che l'app completata abbia entrambe le varianti della riga di comando e della GUI. È abbastanza facile prendere in giro un'interfaccia utente e sviluppare le funzionalità in esso e quindi abbellire l'interfaccia utente in seguito.

Accetto con Stu: la funzionalità di base deve trovarsi in una libreria chiamata dalla riga di comando e dal codice della GUI. Chiamare l'eseguibile dall'interfaccia utente non è necessario in fase di esecuzione.


2

@jcarrascal

non vedo il motivo per cui questo ha a che fare la GUI "cattivo?"
Il mio pensiero sarebbe che ti costringerebbe a pensare a quello che la logica del "business" in realtà ha bisogno di realizzare, senza preoccuparsi troppo di cose che sono belle. Una volta che sai cosa dovrebbe/può fare, puoi costruire la tua interfaccia attorno a ciò in qualsiasi modo abbia più senso.

Nota a margine: non iniziare un argomento separato, ma qual è il modo preferito per rispondere alle risposte/commenti alle domande? Ho considerato sia questo che ho modificato la domanda stessa.


3

Penso che dipenda dal tipo di applicazione che si sta sviluppando. Progettare per la riga di comando ti mette sulla strada giusta a ciò che Alan Cooper definisce "Modello di implementazione" in The Inmates are Running the Asylum. Il risultato è un'interfaccia utente non intuitiva e difficile da utilizzare.

37signals consiglia inoltre di progettare l'interfaccia utente prima in Getting Real. Ricorda, a tutti gli effetti, nella maggior parte delle applicazioni, l'interfaccia utente è il programma. Il back-end code è lì solo per supportarlo.


2

Ho fatto esattamente questo su uno strumento che ho scritto e ha funzionato benissimo. Il risultato finale è uno strumento per script che può essere utilizzato anche tramite una GUI.

Sono d'accordo con il sentimento che si dovrebbe garantire che la GUI sia facile e intuitiva da usare, quindi potrebbe essere saggio persino sviluppare entrambi allo stesso tempo ... una piccola riga di comando seguita da un wrapper GUI per assicurati di fare le cose in modo intuitivo.

Se si è certi di implementare entrambi allo stesso modo, il risultato è un'app che può essere utilizzata in modo automatico, il che credo sia molto potente per gli utenti esperti.


0

Gli strumenti della riga di comando generano meno eventi delle applicazioni GUI e in genere controllano tutti i parametri prima dell'avvio. Questo limiterà il tuo gui perché per un gui, potrebbe essere più sensato chiedere i parametri come il tuo programma funziona o dopo.

Se non ti interessa la GUI, non preoccuparti. Se il risultato finale sarà una GUI, prima esegui il gui, quindi esegui la versione da riga di comando. O potresti lavorare su entrambi allo stesso tempo.

--Massive edit--

Dopo aver trascorso qualche tempo sul mio progetto attuale, mi sento come se ho chiuso il cerchio della mia risposta precedente. Penso che sia meglio fare prima la riga di comando e poi avvolgere una gui su di essa. Se è necessario, penso che tu possa fare un grande gui in seguito. Eseguendo la riga di comando per prima cosa, tutti gli argomenti vengono premuti per primi, quindi non ci sono sorprese (finché i requisiti non cambiano) quando si esegue l'UI/UX.


0

@Maudite

La riga di comando applicazione controllerà params su fronte e l'interfaccia grafica non sarà - ma continuerà a essere ancora controllando i stessi params e averli inseriti nel alcune funzioni operaie generiche.

Sempre lo stesso obiettivo. Non vedo la versione della riga di comando che influisce sulla qualità della GUI.


5

La mia tecnica per programmare la funzionalità di back-end prima senza aver bisogno di un'interfaccia utente esplicita (specialmente quando l'interfaccia utente non è ancora il mio lavoro, ad esempio, sto creando un'applicazione Web che è ancora in fase di progettazione) è scrivere test unitari.

In questo modo non ho nemmeno bisogno di scrivere un'applicazione console per deridere l'output del mio codice backend - è tutto nei test, e a differenza della tua app della console non devo gettare il codice per i test via perché sono ancora utili in seguito.


1

Di solito inizio con una libreria di classi e una GUI separata, davvero scadente e di base. Dato che la riga di comando comporta l'analisi della riga di comando, mi sento come se aggiungessi un sovraccarico inutile.

Come bonus, questo offre un approccio simile a MVC, poiché tutto il codice "reale" si trova in una libreria di classi. Naturalmente, in una fase successiva, Refactoring della libreria insieme a una vera GUI in un EXE è anche un'opzione.


1

Se si esegue correttamente lo sviluppo, dovrebbe essere relativamente semplice passare a una GUI più avanti nel progetto. Il problema è che è piuttosto difficile farlo bene.


1

John Gruber ha avuto un buon posto sul concetto di aggiunta di una GUI per un programma non progettato per uno: Ronco Spray-On Usability

Riassunto: Non funziona. Se l'usabilità non è progettata in un'applicazione dall'inizio, aggiungerla in un secondo momento è più lavoro di quanto chiunque sia disposto a fare.


0

Esegui un programma che esponi come servizio web. quindi fai il gui e la riga di comando per chiamare lo stesso servizio web. Questo approccio consente inoltre di creare un web-gui e anche di fornire le funzionalità come SaaS ai partner extranet e/o di proteggere meglio la logica di business.

Ciò consente al programma di partecipare più facilmente a un ambiente SOA.

Per il servizio Web, non esagerare. fai yaml o xml-rpc. Mantienilo semplice.


1

Un approccio migliore potrebbe essere quella di sviluppare la logica come lib con un'API ben definite e, in fase di dev, senza interfaccia (o un'interfaccia hard coded) allora si può wright CLI o GUI successiva


0

In aggiunta a ciò che ha detto Stu, disporre di una libreria condivisa consente di utilizzarlo anche dalle applicazioni Web. O anche da un plugin IDE.


1

Non lo farei per un paio di motivi.

Design:

A GUI e CLI sono due diverse interfacce utilizzate per accedere a un'implementazione sottostante. Generalmente vengono utilizzati per scopi diversi (la GUI è per un utente live, la CLI di solito è accessibile tramite script) e può spesso avere requisiti diversi. Accoppiare i due insieme non è una scelta saggia ed è destinata a causare problemi lungo la strada.

Performance:

Il modo in cui hai descritto le cose, è necessario generare un eseguibile ogni volta che l'interfaccia grafica richiede d o qualcosa. Questo è semplicemente brutto.

Il modo corretto per eseguire questa operazione consiste nel mettere l'implementazione in una libreria chiamata sia dalla CLI che dalla GUI.


0

Ci sono diversi motivi per cui farlo in questo modo non è una buona idea. Molti di loro sono stati citati, quindi mi limiterò a seguire un punto specifico.

Gli strumenti da riga di comando in genere non sono interattivi, mentre le GUI sono. Questa è una differenza fondamentale. Questo è ad esempio doloroso per le attività di lunga durata.

Il tuo strumento da riga di comando può al massimo stampare qualche tipo di informazioni sullo stato di avanzamento: newline, una barra di avanzamento testuale, un mucchio di output, ... Qualsiasi tipo di errore può essere emesso solo sulla console.

Ora vuoi dare uno schiaffo a una GUI, cosa fai? Analizza l'output del tuo strumento da riga di comando a lunga esecuzione? Scansione per AVVISO ed ERRORE in quell'uscita per generare una finestra di dialogo?

Nella migliore delle ipotesi, la maggior parte delle UI costruite in questo modo lanciano una barra di occupato pulsante per tutto il tempo che il comando viene eseguito, quindi mostrano una finestra di dialogo di successo o di errore quando il comando viene chiuso. Purtroppo, questo è il modo in cui un sacco di programmi GUI di UNIX sono messi insieme, rendendolo una terribile esperienza utente.

La maggior parte dei repeater qui ha ragione nel dire che dovresti probabilmente astrarre la funzionalità effettiva del tuo programma in una libreria, quindi scrivere un'interfaccia della riga di comando e la GUI allo stesso tempo per esso. Tutta la tua logica di business dovrebbe essere nella tua libreria e l'interfaccia utente (sì, una riga di comando è un'interfaccia utente) dovrebbe solo eseguire tutto ciò che è necessario per interfacciare tra la tua logica aziendale e l'interfaccia utente.

Una riga di comando è un'interfaccia utente troppo scadente per assicurarsi di sviluppare la libreria in modo che la GUI possa utilizzarla in un secondo momento. Si dovrebbe iniziare con entrambi fin dall'inizio, o iniziare con la programmazione della GUI. È facile aggiungere un'interfaccia a riga di comando a una libreria sviluppata per una GUI, ma è molto più difficile il contrario, proprio a causa di tutte le funzionalità interattive necessarie per la GUI (reporting, avanzamento, finestre di dialogo di errore, i18n, ...)


0

Questa è esattamente una delle mie più importanti realizzazioni sulla codifica e vorrei che più persone adottassero tale approccio.

Solo un piccolo chiarimento: la GUI non deve essere un wrapper attorno alla riga di comando. Invece si dovrebbe essere in grado di guidare il nucleo del programma da una GUI o da una riga di comando. Almeno all'inizio e solo operazioni di base.

Quando è una buona idea?

Quando si desidera assicurarsi che l'implementazione del dominio sia indipendente dalla struttura della GUI. Si vuole codificare intorno il quadro non in quadro

Quando si tratta di una cattiva idea?

Quando si è certi che il quadro non morirà mai