Lo sviluppo delle app CLI è considerato "arretrato"? [chiuso]

Avere la capacità di lavorare con una CLI non è certo ciò che considererei indietro. Sembra fantastico in un curriculum, specialmente se puoi farlo girare sul tuo curriculum con una frase come "Used (Powershell / Bash) per creare una suite di strumenti di automazione per inviare messaggi SMS quando il database non funziona".

Quando sono responsabile dell'assunzione di persone, una conoscenza pratica della CLI è qualcosa che cerco.

In pratica si tratta di "usare lo strumento giusto per il lavoro".

Se devi interagire con un utente, ti servirà una sorta di GUI. Abbiamo decenni di ricerche ed esperienze che dimostrano che rendono il computing molto più intuitivo e produttivo. Ecco perché le GUI hanno inesorabilmente conquistato il mondo sin dal 1984: funzionano solo meglio per interagire con le persone.

Ma se stai automatizzando un programma con script, il tuo programma non interagisce con le persone; sta interagendo con una sceneggiatura. E la migliore interfaccia è quella basata su testo, per ragioni che dovrebbero essere intuitivamente ovvie.

Lo sviluppo dei programmi CLI per gli utenti con cui lavorare direttamente è considerato arretrato, e a ragione. Ma se non è quello che stai facendo, se stai scrivendo strumenti di produttività dell'automazione, allora non stai facendo nulla di sbagliato dando loro una CLI.

La programmazione Art of Unix di Eric Raymond è il lavoro canonico per l'argomento che stai facendo. Non cercherò di condensare il suo eccellente libro in un paio di paragrafi. Tuttavia, tieni presente che l'argomento si applica principalmente ai programmatori, agli amministratori che automatizzano le attività tramite script o agli utenti di software altamente tecnico come CAD.

Anche con utenti altamente tecnici, devi considerare quali cappelli indossano in quel momento. Ad esempio, scrivo software embedded per apparecchiature di rete per vivere. I nostri prodotti hanno sia una CLI che una GUI, ma gli sviluppatori preferiscono quasi universalmente la CLI, grazie alla sua flessibilità, scriptability, disponibilità, velocità, ecc.

Tuttavia, lo stesso identico gruppo di sviluppatori preferisce in modo schiacciante la GUI sul nostro software di controllo della versione, anche se la sua CLI è più potente ed è supportata e documentata altrettanto bene della GUI. La differenza è che siamo gli utenti finali del software di controllo della versione, non amministratori o sviluppatori.

Quindi, considera attentamente in che ruolo si trovano i tuoi utenti quando utilizzano le tue utilità e pianifica l'interfaccia utente di conseguenza. Se il tuo capo lo menziona, è molto probabile che tu abbia bisogno di migliorare la documentazione e / o la formazione sulla CLI. Se comunichi costantemente alle persone che una funzionalità è disponibile solo sulla CLI quando la prevedono per la GUI, è probabilmente necessario ripensare le priorità di sviluppo, tenendo in maggiore considerazione le esigenze degli utenti.

Non è solo Unix che è guidato dai programmi a riga di comando. Microsoft si sta dirigendo anche in questo modo.

Microsoft ha spinto PowerShell per un po 'di tempo. Tutti i loro attuali software server (Exchange, SharePoint, Server 2012, System Center, ecc.) Possono essere completamente controllati tramite la riga di comando di PowerShell. E PowerShell si basa su piccole funzioni che fanno bene una cosa e trasmettono i dati a quella successiva (anche se convogliano oggetti invece di solo testo).

La maggior parte delle GUI di questi programmi sono semplicemente un frontend dei comandi di PowerShell, molti addirittura ti dicono quali comandi eseguire per semplificare lo scripting. Tutto ciò che puoi fare dalla GUI che puoi fare da PowerShell. Il contrario non è vero: ci sono alcune funzioni esposte solo in PowerShell.

Quindi, se * nix lo ha sempre fatto e Microsoft si sta dirigendo in quel modo ... non mi sembra molto arretrato!

Non direi assolutamente che è una brutta cosa. La cosa bella dei programmi CLI è che quando li si implementa si può avere un ambito molto ristretto. Ad esempio, se voglio scrivere un clone cat o "un programma per stampare il contenuto di un file sullo schermo", questo è molto fattibile con la CLI.

Tuttavia, cosa succede se non hai usato la CLI, beh allora avresti un programma di base con una GUI che mostrava del testo. Ma poi dovresti anche legare per aprire una finestra di dialogo dei file e collegarla ... ma poi qualcuno vorrà anche essere in grado di modificare il testo e salvarlo altrove ..

L'oscilloscopio è ridicolo con le app della GUI. È così estremamente facile da evitare anche con le app CLI. "Vuoi modificare il file e poi salvarlo nuovamente? cat foo > ed > bar " Con le app CLI è banale per i tuoi utenti (non tu, lo sviluppatore) per combinarlo con altri strumenti.

Ora, detto questo, i programmi CLI stanno iniziando a essere visti come "indietro". Questo perché in molti casi lo sviluppo di applicazioni avviene in mercati dove gli utenti che combinano il tuo strumento con altri strumenti sono quasi impossibili. Non entrerò in questo qui, ma ho scritto un post di blog su come "i marketplace rafforzano la mentalità di master-of-none", che è l'esatto opposto di un'app CLI ben progettata (per fare una cosa e per farlo bene)

La GUI e la CLI hanno entrambi il loro posto. La GUI è ottima per consentire a un utente di eseguire rapidamente determinate operazioni di inscatolamento. La CLI è per quando vuoi fare cose che la GUI non ti permette di fare. La CLI è solitamente più potente e più difficile da usare.

Uno strumento CLI buono consente all'utente di fare cose a cui la persona che ha scritto lo strumento non ha mai pensato. Un esempio è il comando 'trova' di UNIX. Questo comando:

find . -type f -name xyzzy\* -maxdepth 5 -mtime +3 -exec rm {} \;

trova i file nella directory corrente (ma limitati a 5 livelli in basso) che hanno un nome che inizia con 'xyzzy' e sono stati modificati più di 3 giorni fa e quindi cancellati (nota: codice non testato). E questo è un uso moderatamente semplice. Puoi usare un file manager per fare questo genere di cose, ma ci vorrà più tempo ed è soggetto ad errori. Ovviamente, essere più potenti significa che la CLI può essere più facilmente abusata e creare problemi per te!

Un buon sviluppatore potrebbe scrivere uno strumento CLI in modo tale da avere anche una GUI che consente di eseguire un insieme limitato di operazioni. L'utente può iniziare con la GUI e apprendere in seguito le complessità della CLI.

Una buona lettura (long e biased (?)) sul compromesso CLI / GUI si trova su:

http://www.cryptonomicon.com/beginning.html

No, non è affatto indietro.

La "direzione" ha molto a che fare con la nostra prospettiva. Un utente soddisfatto del percorso attuale verso interfacce semplici, "uno sperimenta tutti i dispositivi" vedrà la CLI come un ritorno al passato o una regressione di sicuro. Non è in linea con le loro aspettative generali.

Un programmatore, un amministratore o un utente esperto potrebbero vederlo come la progressione logica degli strumenti in base alla loro esperienza. Molti di questi iniziano con gli strumenti della GUI. Quando vogliono o hanno bisogno di ridimensionare, capiscono rapidamente perché la CLI esiste e quella progressione risuona con quelli che creano più strumenti CLI.

C'è questo di Paul Ferris: link

Per me personalmente, l'idea della sintassi distingue i due. Quando la sintassi è piuttosto presente in una GUI, il risultato è quasi mai buono e flessibile come la sintassi CLI ben congegnata. Quando questo è accoppiato con pipe e reindirizzamento, la GUI diminuisce perché non è molto utile al di fuori dei casi d'uso pianificati.

Le mie preferenze personali su questo sono gli strumenti CLI che offrono un'opzione --gui o --verbose sufficiente a consentire a un wrapper della GUI di interagire in modo robusto incluse le barre di stato e altri elementi di base che la gente guarda alla GUI.

Ovviamente il costo di questo è essenzialmente di due programmi con uno piuttosto inutile senza l'altro, ma il vantaggio principale è quello di poter incorporare uno o più grandi strumenti CLI in una GUI personalizzata senza modifiche a detti strumenti CLI. Molto spesso questo viene fatto solo per offrire un'opzione GUI su una particolare CLI, ma l'idea di guidare più strumenti con una GUI orientata al "processo" o "caso d'uso" può fornire risultati simili a piping e reindirizzamento e scripting per quel caso d'uso, rendendolo disponibile alle persone che non eseguono tali operazioni regolarmente abbastanza da raggiungere la maestria pur non inibendo ancora gli utenti della CLI.

Ho incontrato questo approccio su SGI IRIX e mi è piaciuto molto. Mi sono ritrovato a usare la GUI o la riga di comando, se necessario, e la cosa bella era sapere esattamente cosa stavano effettivamente facendo i pulsanti di fantasia.

Dove ci sono molti diversi ambienti operativi, i wrapper della GUI possono differire considerevolmente senza influenzare lo strumento CLI.

Oggi lo vedo in Linux con cose come strumenti disco / filesystem, in cui la GUI può aggiungere molto valore anche agli utenti familiari della CLI.

Nel caso di file system / dischi / dispositivi noti, eliminare la CLI non è difficile, e ovviamente può essere copiato. Gli errori possono tuttavia essere dolorosi.

Dove potrebbero non essere conosciuti, o forse eseguire le operazioni non è fatto abbastanza regolarmente per rimanere solido e privo di errori, l'esecuzione della GUI fornisce un ambiente che può essere facilmente verificato, operazioni concatenate e quindi eseguito con sicurezza, no script richiesti.