O desenvolvimento de aplicativos CLI é considerado "atrasado"? [fechadas]

Eu sou um novato em DBA com muita experiência em programação.

Eu desenvolvi vários aplicativos CLI não interativos que resolvem algumas tarefas repetitivas diárias ou eliminam o erro humano de tarefas mais complexas, embora não tão diárias. Essas ferramentas agora fazem parte da nossa caixa de ferramentas.

Acho que os aplicativos CLI são ótimos porque você pode incluí-los em um fluxo de trabalho automatizado.

Além disso, a filosofia do Unix de fazer uma única coisa, mas fazê-la bem, e deixar que a saída de um processo seja a entrada de outra, é uma ótima maneira de construir um conjunto de ferramentas que se consolidaria em uma vantagem estratégica.

Meu chefe comentou recentemente que o desenvolvimento de ferramentas CLI é "retrógrado" ou constitui uma "regressão".

Eu disse a ele que discordava, porque a maioria das ferramentas CLI existentes agora não são herdadas, mas projetos ao vivo com versões aprimoradas sendo lançadas o tempo todo.

Esse tipo de desenvolvimento é considerado "atrasado" no mercado?

Parece ruim em um currículo?

Também considerei todas as soluções, sejam elas na Web ou na área de trabalho, devem ter opções de linha de comando e não interativas. Algumas pessoas consideram isso um desperdício de recursos de programação.

Esse objetivo é digno em um projeto de software?

Também acho que, para um aplicativo da Web ou de desktop, ter uma interface CLI alternativa é uma ótima maneira de demonstrar que a lógica de negócios está completamente dissociada da GUI.

Ter a capacidade de trabalhar com uma CLI dificilmente seria o que eu consideraria ao contrário. Parece ótimo em um currículo, especialmente se você pode girá-lo em seu currículo com uma frase como "Usado (Powershell / Bash) para criar um conjunto de ferramentas de automação para enviar mensagens SMS quando o banco de dados estava inativo".

Quando sou responsável pela contratação de pessoas, um conhecimento prático da CLI é algo que procuro.

Basicamente, resume-se a "usar a ferramenta certa para o trabalho".

Se você precisar interagir com um usuário, precisará de algum tipo de GUI. Temos décadas de pesquisa e experiência mostrando que eles tornam a computação muito mais intuitiva e produtiva. É por isso que as GUIs dominam inexoravelmente o mundo desde 1984: elas funcionam melhor para interagir com as pessoas.

Mas se você estiver automatizando um programa com scripts, seu programa não está interagindo com as pessoas; está interagindo com um script. E a melhor interface para isso é baseada em texto, por razões que devem ser intuitivamente óbvias.

O desenvolvimento de programas CLI para os usuários trabalharem diretamente é considerado atrasado e por boas razões. Mas se não é isso que você está fazendo, se está escrevendo ferramentas de produtividade de automação, não está fazendo nada de errado, dando a eles uma CLI.

A Arte da Programação Unix, de Eric Raymond, é o trabalho canônico do argumento que você está argumentando. Não tentarei condensar seu excelente livro em alguns parágrafos. No entanto, lembre-se de que o argumento se aplica principalmente a programadores, administradores que automatizam tarefas usando scripts ou usuários avançados de software altamente técnico como o CAD.

Mesmo com usuários altamente técnicos, é necessário considerar quais chapéus eles estão usando no momento. Por exemplo, eu escrevo software incorporado para equipamentos de rede para ganhar a vida. Todos os nossos produtos têm uma CLI e uma GUI, mas os desenvolvedores preferem quase universalmente a CLI, devido à sua flexibilidade, capacidade de script, disponibilidade, velocidade, etc.

No entanto, esse mesmo grupo de desenvolvedores prefere a GUI em nosso software de controle de versão, mesmo que sua CLI seja mais poderosa e seja suportada e documentada tão bem quanto a GUI. A diferença é que somos os usuários finais do software de controle de versão, não administradores ou desenvolvedores.

Portanto, considere cuidadosamente as funções de seus usuários quando estiver usando seus utilitários e planeje a interface do usuário de acordo. Se seu chefe mencionar isso, é provável que você precise melhorar a documentação e / ou o treinamento na CLI, no mínimo. Se você está constantemente dizendo às pessoas que um recurso está disponível apenas na CLI quando eles esperam pela GUI, você provavelmente precisará repensar suas prioridades de desenvolvimento, levando em consideração as necessidades de seus usuários.

Não é apenas o Unix que é dirigido por programas de linha de comando. A Microsoft também está indo nessa direção.

A Microsoft pressiona o PowerShell há algum tempo. Todos os seus softwares de servidor atuais (Exchange, SharePoint, Server 2012, System Center, etc.) podem ser completamente controlados por meio da linha de comando do PowerShell. E o PowerShell conta com pequenas funções que fazem uma coisa bem e canalizam dados para a próxima (embora canalize objetos em vez de apenas texto).

A maioria das GUIs para esses programas é simplesmente uma interface para os comandos do PowerShell, muitos até informam quais comandos serão executados para facilitar a criação de scripts. Tudo o que você pode fazer na GUI do PowerShell. O inverso não é verdadeiro - existem várias funções expostas apenas no PowerShell.

Portanto, se o * nix sempre fez isso, e a Microsoft está indo nessa direção ... não me parece muito atrasado!

Definitivamente, eu não diria que é uma coisa ruim. O bom dos programas CLI é que, ao implementá-los, você pode ter um escopo muito restrito. Por exemplo, se eu quiser escrever um catclone ou "um programa para imprimir o conteúdo de um arquivo na tela", isso é muito viável com a CLI.

No entanto, e se você não usasse a CLI, bem, você teria um programa básico com uma GUI que exibia algum texto. Mas então você também teria que abrir uma caixa de diálogo de arquivo e conectá-la.

A fluência do escopo é ridícula nos aplicativos da GUI. É extremamente fácil evitar isso com os aplicativos CLI. “Você deseja editar o arquivo e depois salvá-lo novamente? cat foo > ed > bar” Com os aplicativos CLI, é trivial para seus usuários (não você, o desenvolvedor) combiná-lo com outras ferramentas.

Agora, dito isso, os programas CLI estão começando a ser vistos como "invertidos". Isso ocorre porque muito do desenvolvimento de aplicativos atualmente acontece em mercados onde os usuários que combinam sua ferramenta com outras são quase impossíveis. Não vou falar disso aqui, mas escrevi uma postagem no blog sobre como "os mercados reforçam a mentalidade de mestre-de-nada", que é o oposto de um aplicativo CLI bem projetado (para fazer uma coisa e fazê-lo bem) )

A GUI e a CLI têm seu lugar. A GUI é ótima para permitir que um usuário execute determinadas operações enlatadas rapidamente. A CLI é para quando você deseja fazer coisas que a GUI não permite que você faça. A CLI é geralmente mais poderosa e mais difícil de usar.

Uma boa ferramenta de CLI permite que o usuário faça coisas nas quais a pessoa que escreveu a ferramenta nunca pensou. Um exemplo é o comando 'find' do UNIX. Este comando:

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

localiza arquivos no diretório atual (mas limitado a 5 níveis abaixo) que têm um nome iniciando 'xyzzy' e foram modificados há mais de 3 dias atrás e os excluem (nota: código não testado). E esse é um uso moderadamente simples. Você pode usar um gerenciador de arquivos para fazer esse tipo de coisa, mas isso levará mais tempo e estará sujeito a erros. Obviamente, ser mais poderoso significa que a CLI pode ser mal utilizada mais facilmente e criar problemas para você!

Um bom desenvolvedor pode escrever uma ferramenta CLI de forma que também tenha uma GUI que permita a execução de um conjunto limitado de operações. O usuário pode começar com a GUI e aprender as complexidades da CLI posteriormente.

Uma boa leitura (longa e tendenciosa (?)) Na troca CLI / GUI está em:

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

Não, não é ao contrário.

A "direção" tem muito a ver com a nossa perspectiva. Um usuário satisfeito com o caminho atual em direção a interfaces simples "uma experiência em todos os dispositivos" verá a CLI como um retrocesso ou regressão, com certeza. Não está de acordo com suas expectativas gerais.

Um programador, administrador ou usuário avançado pode vê-lo como a progressão lógica das ferramentas de acordo com sua experiência. Muitos deles começam usando ferramentas da GUI. Quando eles querem ou precisam escalar, eles descobrem rapidamente por que a CLI existe e essa progressão ressoa com aqueles que constroem mais ferramentas da CLI.

Existe isso por Paul Ferris: http://www.linuxplanet.com/linuxplanet/opinions/1505/1

Para mim, pessoalmente, a idéia de sintaxe diferencia os dois. Quando a sintaxe está presente em uma GUI, o resultado quase nunca é bom e tão flexível quanto a sintaxe da CLI. Quando isso é associado a pipes e redirecionamentos, a GUI fica plana por não ser muito útil fora dos casos de uso planejados.

Minha preferência pessoal são as ferramentas CLI que oferecem uma opção --gui ou --verbose suficiente para permitir que um wrapper da GUI interaja de maneira robusta, incluindo barras de status e outros elementos básicos que as pessoas procuram na GUI.

É claro que o custo disso é basicamente dois programas, um inútil sem o outro, mas o principal benefício é poder incorporar uma ou mais excelentes ferramentas CLI em uma GUI personalizada, sem modificação nas ferramentas CLI. Na maioria das vezes, isso é feito apenas para oferecer uma opção de GUI em uma CLI específica, mas a idéia de conduzir várias ferramentas com uma GUI orientada para "processo" ou "caso de uso" pode fornecer resultados semelhantes ao canal, redirecionamento e script para esse caso de uso, disponibilizando-o para pessoas que não realizariam essas operações regularmente o suficiente para alcançar o domínio, sem inibir os usuários da CLI.

Eu encontrei essa abordagem no SGI IRIX e realmente gostei. Eu me peguei usando a GUI ou a linha de comando, conforme necessário, e o legal era saber exatamente o que os botões sofisticados estavam realmente fazendo.

Onde existem muitos ambientes operacionais diferentes, os wrappers da GUI podem diferir consideravelmente sem afetar a ferramenta CLI também.

Hoje vejo isso no Linux com coisas como ferramentas de disco / sistema de arquivos, nas quais a GUI pode agregar muito valor, mesmo para usuários familiares da CLI.

No caso de sistemas de arquivos / discos / dispositivos conhecidos, eliminar a CLI não é difícil, e pode ser feito com scripts, é claro. Erros podem ser dolorosos no entanto.

Onde esses fatores podem não ser conhecidos, ou talvez a execução das operações não seja feita regularmente o suficiente para permanecer sólida e livre de erros, a execução da GUI fornece um ambiente que pode ser facilmente verificado, as operações encadeadas e depois executadas com confiança, sem a necessidade de scripts.