¿El desarrollo de las aplicaciones de CLI se considera "atrasado"? [cerrado]

37

Soy un DBA incipiente con mucha experiencia en programación.

He desarrollado varias aplicaciones CLI no interactivas que resuelven algunas tareas repetitivas diarias o eliminan el error humano de tareas más complejas, aunque no tan cotidianas. Estas herramientas ahora forman parte de nuestra caja de herramientas.

Creo que las aplicaciones CLI son excelentes porque puedes incluirlas en un flujo de trabajo automatizado.

También la filosofía de Unix de hacer una sola cosa pero hacerlo bien, y dejar que la salida de un proceso sea la entrada de otra, es una excelente manera de construir un conjunto de herramientas que se consolidaría en una ventaja estratégica. p>

Mi jefe comentó recientemente que el desarrollo de herramientas CLI es "atrasado", o constituye una "regresión".

Le dije que no estaba de acuerdo, porque la mayoría de las herramientas CLI que existen ahora no son heredadas, sino proyectos en vivo con versiones mejoradas que se lanzan todo el tiempo.

¿Este tipo de desarrollo se considera "hacia atrás" en el mercado?

¿Se ve mal en un currículum?

También consideré todas las soluciones, ya sean web o de escritorio, deberían tener opciones de línea de comandos, no interactivas. Algunas personas lo consideran un desperdicio de recursos de programación.

¿Este objetivo es digno en un proyecto de software?

También creo que para una aplicación web o de escritorio, tener una interfaz CLI alternativa es una excelente manera de demostrar que la lógica de negocios está completamente desconectada de la GUI.

    
pregunta Tulains Córdova 29.05.2013 - 16:55

7 respuestas

21

Tener la capacidad de trabajar con un CLI no es lo que consideraría al revés. Se ve muy bien en un currículum, especialmente si puede girarlo en su currículum con una frase como "Usado (Powershell / Bash) para crear un conjunto de herramientas de automatización para enviar mensajes SMS cuando la base de datos no funcionó".

Cuando soy responsable de contratar personas, busco un conocimiento práctico de la CLI.

    
respondido por el Jonathan Arkell 30.05.2013 - 00:55
49

Básicamente, se trata de "usar la herramienta adecuada para el trabajo".

Si tiene que interactuar con un usuario, querrá algún tipo de GUI. Tenemos décadas de investigación y experiencia que demuestran que hacen que la informática sea mucho más intuitiva y productiva. Es por eso que las GUI se han llevado inexorablemente al mundo desde 1984: simplemente funcionan mejor para interactuar con las personas.

Pero si está automatizando un programa con scripts, su programa no está interactuando con la gente; está interactuando con un guión. Y la mejor interfaz para eso es una basada en texto, por razones que deberían ser intuitivamente obvias.

El desarrollo de los programas CLI para que los usuarios trabajen directamente se considera al revés y con buena razón. Pero si eso no es lo que estás haciendo, si estás escribiendo herramientas de productividad de automatización, entonces no estás haciendo nada malo al darles un CLI.

    
respondido por el Mason Wheeler 29.05.2013 - 17:07
35

La Programación del Arte de Unix de Eric Raymond es el trabajo canónico del argumento que está formulando. No intentaré condensar su excelente libro en un par de párrafos. Sin embargo, tenga en cuenta que los argumentos se aplican principalmente a los programadores, a los administradores que automatizan las tareas mediante scripts o a los usuarios avanzados de software altamente técnico como CAD.

Incluso con usuarios altamente técnicos, debes considerar qué sombreros están usando en ese momento. Por ejemplo, escribo software integrado para equipos de redes para la vida. Todos nuestros productos tienen una CLI y una GUI, pero los desarrolladores prefieren la CLI casi universalmente, debido a su flexibilidad, capacidad de script, disponibilidad, velocidad, etc.

Sin embargo, ese mismo grupo de desarrolladores exactamente prefiere la GUI en nuestro software de control de versiones, a pesar de que su CLI es más potente y está soportada y documentada tan bien como la GUI. La diferencia es que somos los usuarios finales del software de control de versiones, no los administradores ni los desarrolladores.

Considere cuidadosamente en qué roles están sus usuarios cuando están usando sus utilidades, y planifique la interfaz de usuario como corresponde. Si su jefe lo menciona, lo más probable es que necesite mejorar la documentación y / o capacitación en el CLI por lo menos. Si constantemente le está diciendo a la gente que la función solo está disponible en la CLI cuando la esperan para la GUI, es probable que necesite reconsiderar sus prioridades de desarrollo, teniendo en cuenta las necesidades de sus usuarios.

    
respondido por el Karl Bielefeldt 29.05.2013 - 18:25
16

No solo Unix está controlado por programas de línea de comandos. Microsoft también se dirige hacia allí.

Microsoft ha estado presionando a PowerShell desde hace algún tiempo. Todo su software de servidor actual (Exchange, SharePoint, Server 2012, System Center, etc.) se puede controlar completamente a través de la línea de comandos de PowerShell. Y PowerShell se basa en pequeñas funciones que hacen una cosa bien y canalizan los datos a la siguiente (aunque canaliza objetos en lugar de solo texto).

La mayoría de las GUI para esos programas son simplemente una interfaz para los comandos de PowerShell, muchos incluso le dicen qué comandos se ejecutarán para facilitar las secuencias de comandos. Todo lo que puede hacer desde la GUI que puede hacer desde PowerShell. Lo contrario no es cierto: hay bastantes funciones que están expuestas solo en PowerShell.

Entonces, si * nix siempre lo ha hecho, y Microsoft se está dirigiendo de esa manera ... ¡no me parece muy al revés!

    
respondido por el Grant 29.05.2013 - 22:13
4

Definitivamente no diría que es algo malo. Lo bueno de los programas CLI es que al implementarlos, puede tener un alcance muy restringido. Por ejemplo, si quiero escribir un clon de cat o "un programa para imprimir el contenido de un archivo en la pantalla", eso es muy factible con CLI.

Sin embargo, si no usas CLI, entonces tendrías un programa básico con una GUI que mostraba algo de texto. Pero también tendrías que vincularse para abrir un cuadro de diálogo de archivo y conectarlo ... pero alguien también quiere poder modificar el texto y guardarlo en otro lugar ...

Scope creep es ridículo con las aplicaciones GUI. Sin embargo, es muy fácil de evitar con las aplicaciones CLI. "¿Desea editar el archivo y luego volver a guardarlo? cat foo > ed > bar " Con las aplicaciones CLI es trivial para sus usuarios (no usted, el desarrollador) combinarlo con otras herramientas.

Ahora, dicho esto, los programas CLI están comenzando a verse como "hacia atrás". Esto se debe a que gran parte del desarrollo de aplicaciones en estos días ocurre en los mercados donde los usuarios que combinan su herramienta con otras herramientas son casi imposibles. No voy a entrar en eso aquí, pero sí escribí un publicación del blog sobre cómo "los mercados imponen una mentalidad de maestro de nada", que es todo lo contrario de una aplicación CLI bien diseñada (para hacer una cosa y hacerlo bien)

    
respondido por el Earlz 29.05.2013 - 19:55
4

La GUI y la CLI tienen su lugar. La GUI es ideal para permitir que un usuario realice ciertas operaciones enlatadas rápidamente. La CLI es para cuando desea hacer cosas que la GUI no le permite hacer. El CLI suele ser más poderoso y más difícil de usar.

Una buena herramienta CLI le permite al usuario hacer cosas que la persona que escribió la herramienta nunca pensó. Un ejemplo es el comando 'encontrar' de UNIX. Este comando:

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

encuentra los archivos en el directorio actual (pero limitado a 5 niveles abajo) que tienen un nombre que comienza con 'xyzzy' y se modificaron hace más de 3 días y luego los eliminan (nota: código no probado). Y eso es un uso moderadamente simple. Puede usar un administrador de archivos para hacer ese tipo de cosas, pero tomará más tiempo y es propenso a errores. Por supuesto, ser más poderoso significa que la CLI puede ser mal utilizada más fácilmente y crear problemas para ti mismo.

Un buen desarrollador podría escribir una herramienta CLI de tal manera que también tenga una GUI que permita realizar un conjunto limitado de operaciones. El usuario puede comenzar con la GUI y conocer las complejidades de la CLI más adelante.

Una buena (larga y sesgada (?)) leída en la compensación de CLI / GUI se encuentra en:

http://www.cryptonomicon.com/beginning.html
    
respondido por el rzzzwilson 30.05.2013 - 05:49
1

No, no está al revés en absoluto.

La "dirección" tiene mucho que ver con nuestra perspectiva. Un usuario satisfecho con la ruta actual hacia las interfaces simples, "una experiencia en todos los dispositivos" verá el CLI como un retroceso o una regresión con seguridad. No está en línea con sus expectativas generales.

Un programador, administrador o usuario avanzado puede verlo como la progresión lógica de las herramientas según su experiencia. Muchos de estos comienzan utilizando herramientas de GUI. Cuando quieren o necesitan escalar, rápidamente se dan cuenta de por qué existe el CLI y de que la progresión resuena con aquellos que crean más herramientas de CLI.

Hay algo de Paul Ferris: enlace

Para mí, personalmente, la idea de sintaxis diferencia las dos. Cuando la sintaxis está algo presente en una GUI, el resultado casi nunca es bueno y la sintaxis CLI tan flexible y bien pensada. Cuando esto se combina con tuberías y redireccionamiento, la GUI se desinfla debido a que no es muy útil fuera de los casos de uso planeados.

Mi preferencia personal en esto son las herramientas CLI que ofrecen una opción --gui o --verbose suficiente para permitir que un contenedor de GUI interactúe de una manera sólida, incluidas las barras de estado y otros elementos básicos que la gente busca en la GUI.

Por supuesto, el costo de esto es esencialmente dos programas con uno bastante inútil sin el otro, pero el mayor beneficio es poder incorporar una o más herramientas de CLI grandes en una GUI personalizada sin modificación a dichas herramientas de CLI. La mayoría de las veces, esto solo se hace para ofrecer una opción de GUI en una CLI particular, pero la idea de manejar múltiples herramientas con un "proceso" o una GUI orientada al "caso de uso" puede ofrecer resultados similares a la canalización, la redirección y la creación de scripts para ese caso de uso. ponerlo a disposición de las personas que no realizarían esas operaciones con la regularidad suficiente para alcanzar el dominio sin inhibir a los usuarios de la CLI.

Encontré este enfoque en SGI IRIX y realmente me gustó. Me encontré usando la GUI o la línea de comando según fuera necesario y lo bueno era saber exactamente lo que realmente hacían los botones de fantasía.

Donde hay muchos entornos operativos diferentes, las envolturas de GUI pueden diferir considerablemente sin afectar también a la herramienta CLI.

Veo esto en Linux hoy con cosas como las herramientas de disco / sistema de archivos, donde la GUI puede agregar mucho valor incluso a los usuarios conocidos de CLI.

En el caso de los sistemas de archivos / discos / dispositivos conocidos, eliminar la CLI no es difícil y, por supuesto, puede tener secuencias de comandos. Sin embargo, los errores pueden ser dolorosos.

Cuando no se conozcan, o tal vez no se realicen las operaciones con la regularidad necesaria para permanecer sólidas y sin errores, la ejecución de la GUI proporciona un entorno que puede verificarse fácilmente, las operaciones se pueden encadenar y luego ejecutar con confianza, no scripts requeridos.

    
respondido por el user94936 26.06.2013 - 05:46

Lea otras preguntas en las etiquetas