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

Sono un principiante DBA con molta esperienza nella programmazione.

Ho sviluppato diverse CLI, app non interattive che risolvono alcune attività ripetitive quotidiane o eliminano l'errore umano da attività più complesse anche se non così quotidiane. Questi strumenti fanno ora parte della nostra cassetta degli attrezzi.

Trovo che le app CLI siano fantastiche perché puoi includerle in un flusso di lavoro automatizzato.

Anche la filosofia Unix di fare una cosa sola, ma di farla bene, e lasciare che l'output di un processo sia l'input di un altro, è un ottimo modo di costruire un insieme di strumenti che si consoliderebbero in un vantaggio strategico.

Il mio capo ha recentemente commentato che lo sviluppo di strumenti CLI è "arretrato" o costituisce una "regressione".

Gli ho detto che non ero d'accordo, perché la maggior parte degli strumenti CLI che esistono ora non sono legacy ma progetti live con versioni migliorate rilasciate continuamente.

Questo tipo di sviluppo è considerato "arretrato" sul mercato?

Sembra brutto su un curriculum?

Ho anche considerato tutte le soluzioni, siano esse web o desktop, dovrebbero avere opzioni da linea di comando, non interattive. Alcune persone lo considerano uno spreco di risorse di programmazione.

Questo obiettivo è degno in un progetto software?

Penso anche che per un'app Web o desktop, avere un'interfaccia CLI alternativa sia un ottimo modo per dimostrare che la logica aziendale è completamente disaccoppiata dalla GUI.

Avere la capacità di lavorare con una CLI non è certo ciò che considererei al contrario. Sembra fantastico su un curriculum, soprattutto se puoi farlo girare sul tuo curriculum con una frase del tipo "Usato (Powershell / Bash) per creare una suite di strumenti di automazione per inviare messaggi SMS quando il database era inattivo".

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

Fondamentalmente si riduce a "utilizzare lo strumento giusto per il lavoro".

Se devi interagire con un utente, ti consigliamo una sorta di GUI. Abbiamo decenni di ricerca ed esperienza che dimostrano che rendono l'informatica molto più intuitiva e produttiva. Ecco perché le GUI hanno assunto inesorabilmente il mondo fin 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 è basata su testo, per ragioni che dovrebbero essere intuitivamente ovvie.

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

The Art of Unix Programming di Eric Raymond è il lavoro canonico per l'argomento che stai facendo. Non proverò a 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à utilizzando gli script o agli utenti esperti di software altamente tecnico come il CAD.

Anche con utenti altamente tecnici, devi considerare quali cappelli indossano in quel momento. Ad esempio, scrivo software incorporato per apparecchiature di rete per vivere. Tutti i nostri prodotti hanno sia una CLI che una GUI, ma gli sviluppatori preferiscono quasi universalmente la CLI, a causa della sua flessibilità, capacità di scrittura, disponibilità, velocità, ecc.

Tuttavia, quello 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 così come la GUI. La differenza è che siamo gli utenti finali del software di controllo della versione, non amministratori o sviluppatori.

Quindi, considera attentamente quali ruoli ricoprono i tuoi utenti quando usano le tue utility e pianifica di conseguenza l'interfaccia utente. Se il tuo capo lo sta citando, è probabile che tu debba migliorare la documentazione e / o la formazione sulla CLI almeno. Se comunichi costantemente alle persone che una funzionalità è disponibile nella CLI solo quando se la aspettano per la GUI, probabilmente dovrai ripensare le tue priorità di sviluppo, tenendo meglio conto delle esigenze dei tuoi utenti.

Non è solo Unix a essere guidato da programmi a riga di comando. Anche Microsoft sta andando in quel modo.

Microsoft sta spingendo PowerShell da qualche tempo. Tutto il loro attuale software server (Exchange, SharePoint, Server 2012, System Center, ecc.) Può essere completamente controllato dalla riga di comando di PowerShell. E PowerShell si basa su piccole funzioni che fanno bene una cosa e reindirizzano i dati a quella successiva (anche se convoglia oggetti al posto del solo testo).

La maggior parte delle GUI di questi programmi sono semplicemente un frontend per i comandi di PowerShell, molti addirittura ti dicono quali comandi eseguirà per rendere più facile lo scripting. Tutto quello che puoi fare dalla GUI che puoi fare da PowerShell. Il contrario non è vero: ci sono alcune funzioni che sono esposte solo in PowerShell.

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

Non direi assolutamente che è una brutta cosa. La cosa bella dei programmi CLI è che quando li implementi puoi avere un ambito molto limitato. Ad esempio, se voglio scrivere un catclone o "un programma per stampare il contenuto di un file sullo schermo", è molto fattibile con la CLI.

Tuttavia, se non avessi usato la CLI, allora avresti un programma base con una GUI che mostrava del testo. Ma poi dovresti anche legare nell'aprire una finestra di dialogo del file e collegarlo .. ma poi qualcuno vuole anche essere in grado di modificare il testo e salvarlo altrove ..

Scree creep è ridicolo con le app GUI. È così estremamente facile evitarlo con le app CLI. "Vuoi modificare il file e quindi salvarlo di nuovo? cat foo > ed > bar" Con le app CLI è banale per i tuoi utenti (non tu, lo sviluppatore) combinarlo con altri strumenti.

Ora, detto questo, i programmi CLI stanno iniziando a essere visti come "all'indietro". Questo perché un sacco di sviluppo di applicazioni in questi giorni avviene nei mercati in cui gli utenti che combinano il tuo strumento con altri strumenti sono quasi impossibili. Non ne parlerò qui, ma ho scritto un post sul blog su come "i mercati impongono la mentalità da padrone di nessuno", che è l'esatto contrario di un'app CLI ben progettata (per fare una cosa e farlo bene )

La GUI e la CLI hanno entrambe il loro posto. La GUI è ottima per consentire a un utente di eseguire rapidamente determinate operazioni predefinite. L'interfaccia della riga di comando è per quando si desidera eseguire operazioni che la GUI non consente di fare. L'interfaccia della riga di comando è in genere più potente e più difficile da utilizzare.

Un buon strumento CLI consente all'utente di fare cose che 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 limitato a 5 livelli in basso) che hanno un nome che inizia con 'xyzzy' e sono stati modificati più di 3 giorni fa e quindi li elimina (nota: codice non testato). E questo è un uso moderatamente semplice. Puoi usare un file manager per fare quel genere di cose, ma ci vorrà più tempo ed è soggetto a errori. Naturalmente, essere più potenti significa che la CLI può essere utilizzata più facilmente e creare problemi per te!

Un buon sviluppatore potrebbe scrivere uno strumento CLI in modo tale che abbia anche una GUI che consenta di eseguire una serie limitata di operazioni. L'utente può iniziare con la GUI e apprendere in seguito le complessità della CLI.

Una buona lettura (lunga e di parte (?)) Sul compromesso CLI / GUI è disponibile su:

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

No, non è affatto all'indietro.

La "direzione" ha molto a che fare con la nostra prospettiva. Un utente soddisfatto dell'attuale percorso verso interfacce semplici "un'esperienza unica per tutti i dispositivi" vedrà sicuramente la CLI come ritorno al passato o regressione. Non è in linea con le loro aspettative generali.

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

C'è questo di Paul Ferris: http://www.linuxplanet.com/linuxplanet/opinions/1505/1

Personalmente, l'idea di sintassi differenzia i due. Quando la sintassi è in qualche modo presente in una GUI, il risultato non è quasi mai buono e flessibile come sintassi CLI ben ponderata. Quando questo è accoppiato con pipe e reindirizzamento, la GUI si abbassa perché non è molto utile al di fuori dei casi d'uso previsti.

La mia preferenza personale su questo è strumenti della CLI che offrono un'opzione --gui o --verbose sufficiente per consentire a un wrapper della GUI di interagire in modo robusto, comprese le barre di stato e altri elementi di base che le persone cercano nella GUI.

Naturalmente il costo di questo è essenzialmente due programmi con uno piuttosto inutile senza l'altro, ma il vantaggio principale è la possibilità di incorporare uno o più ottimi 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 al "caso d'uso" può fornire risultati simili a piping, reindirizzamento e scripting per quel caso d'uso, rendendolo disponibile per le persone che non eseguivano tali operazioni abbastanza regolarmente da raggiungere la padronanza pur non inibendo gli utenti della CLI.

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

Laddove esistono molti ambienti operativi diversi, i wrapper della GUI possono differire notevolmente senza influire anche sullo strumento CLI.

Lo vedo oggi 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 filesystem / dischi / dispositivi noti, eliminare la CLI non è difficile e può essere ovviamente copiato da script. Gli errori possono tuttavia essere dolorosi.

Laddove quelli che potrebbero non essere noti, o che forse l'esecuzione delle operazioni non sia stata eseguita abbastanza regolarmente per rimanere solida e priva di errori, l'esecuzione della GUI fornisce un ambiente che può essere facilmente verificato, le operazioni concatenate e quindi eseguite con sicurezza, senza script necessari.