Cosa pensi di sviluppare prima per la riga di comando?

https://stackoverflow.com/questions/18984

09-06-2019
|

Domanda

Quali sono le tue opinioni sullo sviluppo prima per la riga di comando, quindi sull'aggiunta di una GUI in un secondo momento semplicemente chiamando i metodi della riga di comando?

per esempio.

W:\ cose da fare AddTask "incontro con John, riferimento:login peer review" "Ufficio di John" "2008-08-22" "14:00"

carichi todo.exe e chiama una funzione chiamata AddTask questo esegue una certa convalida e inserisce la riunione in un database.

Alla fine aggiungi 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 fai clic su Invia, viene richiamata la stessa funzione AddTask.

Questo è considerato:

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

Addendum:

Sto notando una tendenza qui per "Biblioteca condivisa chiamata sia dalla GUI che dalla CLI Expetables". C'è qualche motivo convincente per cui dovrebbero essere separati, oltre a forse le dimensioni dei binari stessi?

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

"todo /G" quando desideri l'interfaccia grafica completa
"todo /I" per un prompt interattivo entro todo.exe (scripting, ecc.)
semplicemente vecchio "todo <function>" quando vuoi solo fare una cosa e farla finita.

Addendum 2:

È stato detto che "nel modo in cui [ho] descritto le cose, [dovresti] generare un eseguibile ogni volta che la GUI deve fare qualcosa".

Ripeto, non era questo il mio intento.Quando ho menzionato che la GUI di esempio chiamava "the same AddTask function," non intendevo che la GUI richiamasse ogni volta il programma della riga di comando.Sono d'accordo che sarebbe totalmente brutto.Avevo intenzione (vedi prima aggiunta) che tutto questo fosse contenuto in un unico eseguibile, poiché era un piccolo esempio, ma non penso che la mia frase precluda necessariamente una libreria condivisa.

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

Soluzione

Vorrei creare una libreria con un'applicazione da riga di comando che si collega ad essa.Successivamente, puoi creare una GUI collegata alla stessa libreria.La chiamata di una riga di comando da una GUI genera processi esterni per ciascun comando ed è più dannosa per il sistema operativo.

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

Ma anche finché il codice funzionale è separato dall'interprete della riga di comando, puoi semplicemente riutilizzare il sorgente per una GUI senza avere i due tipi contemporaneamente per eseguire un'operazione.

Altri suggerimenti

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

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

Joel ha scritto un articolo in cui metteva a confronto questo sviluppo ("in stile UNIX") con il primo metodo della GUI ("in stile Windows") qualche anno fa.Lo ha chiamato Biculturalismo.

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

La mia tecnica per programmare prima le funzionalità di backend senza la necessità di un'interfaccia utente esplicita (specialmente quando l'interfaccia utente non è ancora il mio lavoro, ad esempio sto progettando 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 console, non devo buttare via il codice per i test perché continuano sono utili in seguito.

Penso che dipenda dal tipo di applicazione che stai sviluppando.Progettare per la riga di comando ti mette sulla buona strada per ciò che Alan Cooper chiama "modello di implementazione" in I detenuti gestiscono il manicomio.Il risultato è un'interfaccia utente poco intuitiva e difficile da usare.

37signals consiglia inoltre di progettare innanzitutto l'interfaccia utente Diventare reale.Ricorda, a tutti gli effetti, nella maggior parte delle applicazioni, l'interfaccia utente È il programma.Il codice back-end è lì solo per supportarlo.

Probabilmente è meglio iniziare prima con una riga di comando per 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 tuo lavoro.

Ciò renderà la tua app più adatta allo scripting e limiterà la quantità di anticipo Deposito biciclette in modo da poter arrivare più velocemente alla soluzione effettiva.

Se prevedi di mantenere la versione da riga di comando della tua app, non vedo alcun problema nel farlo in questo modo: non è tempo sprecato.Finirai comunque per codificare la funzionalità principale della tua app per la riga di comando e quindi avrai gran parte del lavoro svolto.

Non vedo lavorare in questo modo come un ostacolo per una bella interfaccia utente: hai ancora il tempo per aggiungerne una e renderla utilizzabile, ecc.

Immagino che questo modo di lavorare funzionerebbe davvero solo se intendi che la tua app finita abbia sia varianti della riga di comando che della GUI.È abbastanza semplice prendere in giro un'interfaccia utente e incorporarvi le tue funzionalità, quindi abbellire l'interfaccia utente in un secondo momento.

Concordo con Stu:la funzionalità di base dovrebbe trovarsi in una libreria richiamata dalla riga di comando e dal codice della GUI.La chiamata dell'eseguibile dall'interfaccia utente comporta un sovraccarico non necessario in fase di esecuzione.

@jcarrascal

Non vedo perché questo debba rendere la GUI "cattiva?"
Il mio pensiero sarebbe che ti costringerebbe a pensare a ciò che la logica del "business" deve effettivamente realizzare, senza preoccuparti troppo del fatto che le cose siano belle.Una volta che sai cosa dovrebbe/può fare, puoi costruire la tua interfaccia attorno ad esso nel modo più sensato.

Nota a margine:Non per iniziare un argomento separato, ma qual è il modo preferito per rispondere alle/commenti sulle tue domande?Ho considerato sia questo, sia la modifica della domanda stessa.

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

Sono d'accordo con l'idea che dovresti assicurarti che la GUI sia facile e intuitiva da usare, quindi potrebbe essere saggio svilupparle entrambe contemporaneamente...una piccola funzionalità della riga di comando seguita da un wrapper GUI per assicurarti di fare le cose in modo intuitivo.

Se sei fedele all'implementazione di entrambi allo stesso modo, il risultato è un'app che può essere utilizzata in modo automatizzato, che ritengo sia molto potente per gli utenti esperti.

Di solito inizio con una libreria di classi e una GUI separata, davvero scadente e di base.Poiché la riga di comando implica l'analisi della riga di comando, mi sento come se stessi aggiungendo un sacco di spese generali non necessarie.

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

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

Dipende un po' dal tuo 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 da scrivere casi di test rapidi e sporchi.E finché struttura il mio codice correttamente, posso tornare indietro e aggiungere una GUI in un secondo momento senza troppo lavoro.

A coloro che suggeriscono che questa tecnica si tradurrà in interfacce utente orribili e inutilizzabili:Hai ragione.Scrivere un'utilità da riga di comando è un modo terribile per progettare una GUI.Prendi nota, tutti là fuori stanno pensando di scrivere un'interfaccia utente che non lo è una CLUI: non prototiparla come CLUI.

Ma, se stai scrivendo un nuovo codice che non dipende di per sé da un'interfaccia utente, allora provaci.

Un approccio migliore potrebbe essere quello di sviluppare la logica come una libreria con un'API ben definita e, in fase di sviluppo, nessuna interfaccia (o un'interfaccia codificata), quindi è possibile scrivere la CLI o la GUI in un secondo momento

Non lo farei per un paio di motivi.

Progetto:

Una GUI e una CLI sono due diverse interfacce utilizzate per accedere a un'implementazione sottostante.Vengono generalmente utilizzati per scopi diversi (la GUI è per un utente live, di solito si accede alla CLI tramite script) e spesso possono avere requisiti diversi.Accoppiare i due insieme non è una scelta saggia ed è destinato a causare problemi lungo la strada.

Prestazione:

Per come hai descritto le cose, devi generare un eseguibile ogni volta che la GUI deve fare qualcosa.Questo è semplicemente brutto.

Il modo giusto per farlo è inserire l'implementazione in una libreria chiamata sia dalla CLI che dalla GUI.

John Gruber ha scritto un buon post sul concetto di aggiungere una GUI a un programma non progettato per una: Usabilità Ronco Spray-On

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

@Maudite

L'app da riga di comando controllerà i parametri in anticipo e la GUI no, ma controlleranno comunque il file Stesso params e inserendoli in alcune funzioni di lavoro generiche.

Sempre lo stesso obiettivo.Non vedo che la versione da riga di comando influenzi la qualità di quella della GUI.

Crea un programma che esponi come servizio web.quindi esegui la GUI e la riga di comando per chiamare lo stesso servizio web.Questo approccio consente inoltre di creare una GUI Web e anche di fornire la funzionalità SaaS ai partner Extranet e/o di proteggere meglio la logica aziendale.

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

Per il servizio web, non esagerare.esegui yaml o xml-rpc.Mantienilo semplice.

Oltre a cosa Stu detto, avere una libreria condivisa ti consentirà di utilizzarla anche dalle applicazioni web.O anche da un plugin IDE.

Ci sono diversi motivi per cui farlo in questo modo non è una buona idea.Ne sono stati menzionati molti, quindi mi limiterò a concentrarmi su un punto specifico.

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

Il tuo strumento da riga di comando stamperà nella migliore delle ipotesi qualche tipo di informazione sull'avanzamento: nuove righe, una barra di avanzamento testuale, una serie di output, ...Qualsiasi tipo di errore può essere restituito solo alla console.

Ora vuoi aggiungerci una GUI, cosa fai?Analizzare l'output del tuo strumento da riga di comando di lunga durata?Cerca AVVISO ed ERRORE nell'output per visualizzare una finestra di dialogo?

Nella migliore delle ipotesi, la maggior parte delle interfacce utente costruite in questo modo genera una barra di occupato pulsante per tutto il tempo in cui il comando viene eseguito, quindi mostra una finestra di dialogo di successo o fallimento quando il comando termina.Purtroppo, questo è il modo in cui vengono messi insieme molti programmi GUI UNIX, rendendo l'esperienza utente terribile.

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

Una riga di comando è un'interfaccia utente troppo scarsa per essere sicuri di sviluppare la libreria sufficientemente buona per l'utilizzo della GUI in un secondo momento.Dovresti 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 di cui la GUI avrà bisogno (report, avanzamento, finestre di dialogo di errore, i18n, ... )

Gli strumenti da riga di comando generano meno eventi rispetto alle app GUI e in genere controllano tutti i parametri prima di iniziare.Ciò limiterà la tua GUI perché per una GUI potrebbe avere più senso chiedere i parametri mentre il tuo programma funziona o successivamente.

Se non ti interessa la GUI, non preoccuparti.Se il risultato finale sarà una GUI, crea prima la GUI, quindi esegui la versione da riga di comando.Oppure potresti lavorare su entrambi contemporaneamente.

--Modifica massiccia--

Dopo aver dedicato un po' di tempo al mio progetto attuale, mi sento come se avessi chiuso il cerchio rispetto alla mia risposta precedente.Penso che sia meglio eseguire prima la riga di comando e poi inserirvi una GUI.Se ne hai bisogno, penso che potrai creare un'ottima GUI in seguito.Eseguendo prima la riga di comando, si ottengono prima tutti gli argomenti, quindi non ci sono sorprese (fino a quando i requisiti non cambiano) quando si esegue l'interfaccia utente/UX.

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

Solo una piccola precisazione:La GUI non dovrebbe 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 nelle operazioni di base.

Quando è una grande idea?

Quando vuoi assicurarti che l'implementazione del tuo dominio sia indipendente dal framework della GUI.Vuoi codificare in giro il quadro no in il quadro

Quando è una cattiva idea?

Quando sei sicuro che la tua struttura non morirà mai

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow