¿Qué opinas de desarrollar primero para la línea de comando?

https://stackoverflow.com/questions/18984

09-06-2019
|

Pregunta

¿Cuáles son sus opiniones sobre desarrollar primero para la línea de comandos y luego agregar una GUI después del hecho simplemente llamando a los métodos de la línea de comandos?

p.ej.

W:\ todo AddTask "reunión con John, re:iniciar sesión en revisión por pares" "Oficina de John" "2008-08-22" "14:00"

cargas todo.exe y llama a una función llamada AddTask eso hace alguna validación y arroja la reunión a una base de datos.

Eventualmente agregas una pantalla para esto:

============================================================

Event:    [meeting with John, re: login peer review]

Location: [John's office]  

Date:     [Fri. Aug. 22, 2008]  

Time:     [ 2:00 PM]

[Clear]  [Submit]

============================================================

Cuando hace clic en enviar, llama a la misma función AddTask.

¿Se considera esto:

una buena manera de codificar
solo para los novatos
¡horrendo!.

Apéndice:

Estoy notando una tendencia aquí para "biblioteca compartida llamada por los ejecutables GUI y CLI." ¿Hay alguna razón convincente por la que tendrían que separarse, aparte quizás del tamaño de los binarios mismos?

¿Por qué no simplemente llamar al mismo ejecutable de diferentes maneras?

"todo /G" cuando quieras la interfaz gráfica completa
"todo /I" para un mensaje interactivo dentro todo.exe (guiones, etc.)
simple y viejo "todo <function>" cuando sólo quieres hacer una cosa y terminar de una vez.

Anexo 2:

Se mencionó que "de la forma en que [he] descrito las cosas, [necesitarías] generar un ejecutable cada vez que la GUI necesite hacer algo".

Nuevamente, esta no era mi intención.Cuando mencioné que la GUI de ejemplo llamaba "lo mismo AddTask función", no quise decir que la GUI llamó al programa de línea de comando cada vez.Estoy de acuerdo en que sería totalmente desagradable.Tenía la intención (ver el primer anexo) de que todo esto se mantuviera en un solo ejecutable, ya que era un ejemplo pequeño, pero no creo que mi redacción impidiera necesariamente una biblioteca compartida.

Además, me gustaría agradecerles a todos por sus aportes.Esto es algo que sigue volviendo a mi mente y aprecio la sabiduría de su experiencia.

Solución

Yo optaría por crear una biblioteca con una aplicación de línea de comandos que la enlace.Luego, puede crear una GUI que enlace a la misma biblioteca.Llamar a una línea de comando desde una GUI genera procesos externos para cada comando y es más perjudicial para el sistema operativo.

Además, con una biblioteca puedes realizar fácilmente pruebas unitarias de la funcionalidad.

Pero incluso siempre que su código funcional esté separado de su intérprete de línea de comandos, puede reutilizar la fuente de una GUI sin tener los dos tipos a la vez para realizar una operación.

Otros consejos

Coloque la funcionalidad compartida en una biblioteca, luego escriba una línea de comandos y una interfaz gráfica de usuario para ella.De esa manera, la transición de su capa no estará vinculada a la línea de comandos.

(Además, de esta manera se agrega otra preocupación de seguridad:¿No debería la GUI asegurarse primero de que se llama al todo.exe CORRECTO?)

Joel escribió un artículo que contrasta este desarrollo ("estilo Unix") con el primer método GUI ("estilo Windows") hace unos años.el lo llamo biculturalismo.

Creo que en Windows será normal (si aún no lo ha sido) empaquetar su lógica en ensamblados .NET, a los que luego podrá acceder desde una GUI y un proveedor de PowerShell.De esa manera, obtienes lo mejor de ambos mundos.

Mi técnica para programar la funcionalidad backend primero sin necesidad de una interfaz de usuario explícita (especialmente cuando la interfaz de usuario aún no es mi trabajo, por ejemplo, estoy diseñando una aplicación web que aún está en la fase de diseño) es escribir pruebas unitarias.

De esa manera, ni siquiera necesito escribir una aplicación de consola para simular la salida de mi código backend: todo está en las pruebas y, a diferencia de la aplicación de consola, no tengo que desechar el código de las pruebas porque todavía son útiles más adelante.

Creo que depende del tipo de aplicación que estés desarrollando.Diseñar para la línea de comando lo coloca en la vía rápida hacia lo que Alan Cooper llama "modelo de implementación" en Los internos están manejando el asilo.El resultado es una interfaz de usuario poco intuitiva y difícil de utilizar.

37signals también recomienda diseñar su interfaz de usuario primero en Volverse real.Recuerde, a todos los efectos, en la mayoría de aplicaciones, la interfaz de usuario es el programa.El código de fondo está ahí solo para respaldarlo.

Probablemente sea mejor comenzar primero con una línea de comando para asegurarse de que tiene la funcionalidad correcta.Si sus usuarios principales no pueden (o no quieren) usar la línea de comando, entonces puede agregar una GUI además de su trabajo.

Esto hará que su aplicación sea más adecuada para secuencias de comandos y también limitará la cantidad de dinero inicial. Depósito de bicicletas para que pueda llegar a la solución real más rápido.

Si planea conservar la versión de línea de comandos de su aplicación, no veo ningún problema en hacerlo de esta manera; no es una pérdida de tiempo.Aún así terminarás codificando la funcionalidad principal de tu aplicación para la línea de comandos, por lo que tendrás una gran parte del trabajo realizado.

No veo que trabajar de esta manera sea una barrera para una buena interfaz de usuario: todavía tienes tiempo para agregar una y hacer que sea utilizable, etc.

Supongo que esta forma de trabajar solo funcionaría si pretendes que tu aplicación terminada tenga variantes de línea de comandos y GUI.Es bastante fácil simular una interfaz de usuario e incorporar su funcionalidad y luego embellecer la interfaz de usuario más adelante.

De acuerdo con Stu:su funcionalidad básica debe estar en una biblioteca que se llama desde la línea de comandos y el código GUI.Llamar al ejecutable desde la interfaz de usuario supone una sobrecarga innecesaria en tiempo de ejecución.

@jcarrascal

No veo por qué esto tiene que hacer que la GUI sea "mala".
Mi idea sería que te obligaría a pensar en lo que realmente necesita lograr la lógica "empresarial", sin preocuparte demasiado de que las cosas sean bonitas.Una vez que sepa lo que debe/puede hacer, puede construir su interfaz en torno a eso de la forma que tenga más sentido.

Nota al margen:No quiero comenzar un tema aparte, pero ¿cuál es la forma preferida de abordar las respuestas/comentarios sobre sus preguntas?Consideré tanto esto como editar la pregunta en sí.

Hice exactamente esto en una herramienta que escribí y funcionó muy bien.El resultado final es una herramienta programable que también se puede utilizar a través de una GUI.

Estoy de acuerdo con la idea de que debes asegurarte de que la GUI sea fácil e intuitiva de usar, por lo que podría ser prudente incluso desarrollar ambas al mismo tiempo...una pequeña función de línea de comando seguida de un contenedor GUI para garantizar que esté haciendo las cosas de manera intuitiva.

Si es fiel a implementar ambos por igual, el resultado es una aplicación que se puede usar de manera automatizada, lo cual creo que es muy poderoso para los usuarios avanzados.

Normalmente empiezo con una biblioteca de clases y una GUI separada, realmente mala y básica.Como la línea de comando implica analizar la línea de comando, siento que estoy agregando muchos gastos generales innecesarios.

Como beneficio adicional, esto brinda un enfoque similar a MVC, ya que todo el código "real" está en una biblioteca de clases.Por supuesto, en una etapa posterior, también es una opción refactorizar la biblioteca junto con una GUI real en un EXE.

Si realiza correctamente el desarrollo, debería ser relativamente fácil cambiar a una GUI más adelante en el proyecto.El problema es que es un poco difícil hacerlo bien.

Depende un poco de su objetivo para el programa, pero sí, hago esto de vez en cuando: es más rápido de codificar, más fácil de depurar y más fácil de escribir casos de prueba rápidos y sucios.Y siempre que estructure mi código correctamente, puedo volver atrás y agregar una GUI más tarde sin demasiado trabajo.

Para aquellos que sugieren que esta técnica dará como resultado interfaces de usuario horribles e inutilizables:Tienes razón.Escribir una utilidad de línea de comandos es una forma terrible de diseñar una GUI.Tome nota, todos están pensando en escribir una interfaz de usuario que no es un CLUI: no cree un prototipo como CLUI.

Pero, si está escribiendo código nuevo que no depende de una interfaz de usuario, entonces hazlo.

Un mejor enfoque podría ser desarrollar la lógica como una biblioteca con una API bien definida y, en la etapa de desarrollo, sin interfaz (o una interfaz codificada), luego puede escribir la CLI o GUI más adelante.

No haría esto por un par de razones.

Diseño:

Una GUI y una CLI son dos interfaces diferentes que se utilizan para acceder a una implementación subyacente.Generalmente se utilizan para diferentes propósitos (la GUI es para un usuario en vivo, generalmente se accede a la CLI mediante secuencias de comandos) y, a menudo, pueden tener diferentes requisitos.Acoplar los dos no es una buena elección y seguramente le causará problemas en el futuro.

Actuación:

De la forma en que ha descrito las cosas, debe generar un ejecutable cada vez que la GUI necesite hacer algo.Esto es sencillamente feo.

La forma correcta de hacer esto es colocar la implementación en una biblioteca a la que llaman tanto la CLI como la GUI.

John Gruber tuvo una buena publicación sobre el concepto de agregar una GUI a un programa no diseñado para eso: Usabilidad del spray Ronco

Resumen:No funciona.Si la usabilidad no está diseñada en una aplicación desde el principio, agregarla más tarde es más trabajo del que cualquiera está dispuesto a hacer.

@Maudita

La aplicación de línea de comandos comprobará los parámetros desde el principio y la GUI no, pero seguirán comprobando el mismo parámetros e ingresarlos en algunas funciones genéricas del trabajador.

Sigue siendo el mismo objetivo.No veo que la versión de la línea de comandos afecte la calidad de la GUI.

Haga un programa que exponga como un servicio web.luego haga la interfaz gráfica de usuario y la línea de comando para llamar al mismo servicio web.Este enfoque también le permite crear una interfaz gráfica de usuario web y también proporcionar la funcionalidad como SaaS a los socios de extranet y/o proteger mejor la lógica empresarial.

Esto también permite que su programa participe más fácilmente en un entorno SOA.

Para el servicio web, no se exceda.haga yaml o xml-rpc.Mantenlo simple.

Además de lo que estu Dicho esto, tener una biblioteca compartida le permitirá usarla también desde aplicaciones web.O incluso desde un complemento IDE.

Hay varias razones por las que hacerlo de esta manera no es una buena idea.Se han mencionado muchos de ellos, así que me limitaré a un punto específico.

Las herramientas de línea de comandos generalmente no son interactivas en absoluto, mientras que las GUI sí lo son.Ésta es una diferencia fundamental.Esto es doloroso, por ejemplo, para tareas de larga duración.

Su herramienta de línea de comandos, en el mejor de los casos, imprimirá algún tipo de información de progreso: nuevas líneas, una barra de progreso textual, un montón de resultados, ...Cualquier tipo de error solo puede enviarse a la consola.

Ahora quieres ponerle una GUI encima, ¿qué haces?¿Analizar el resultado de su herramienta de línea de comandos de larga ejecución?¿Busca ADVERTENCIA y ERROR en esa salida para mostrar un cuadro de diálogo?

En el mejor de los casos, la mayoría de las UI creadas de esta manera muestran una barra de ocupado pulsante mientras se ejecuta el comando y luego le muestran un cuadro de diálogo de éxito o fracaso cuando el comando sale.Lamentablemente, así es como se combinan muchos programas GUI de UNIX, lo que la convierte en una experiencia de usuario terrible.

La mayoría de los que responden aquí tienen razón al decir que probablemente debería abstraer la funcionalidad real de su programa en una biblioteca y luego escribir una interfaz de línea de comandos y la GUI al mismo tiempo.Toda su lógica de negocios debe estar en su biblioteca, y cualquiera de las UI (sí, una línea de comando es una UI) solo debe hacer lo que sea necesario para interconectar su lógica de negocios y su UI.

Una línea de comando es una interfaz de usuario demasiado pobre para garantizar que desarrolle su biblioteca lo suficientemente bien para usar la GUI más adelante.Deberías empezar con ambos desde el principio o empezar con la programación de la GUI.Es fácil agregar una interfaz de línea de comandos a una biblioteca desarrollada para una GUI, pero es mucho más difícil al revés, precisamente debido a todas las funciones interactivas que necesitará la GUI (informes, progreso, cuadros de diálogo de error, i18n, ... )

Las herramientas de línea de comandos generan menos eventos que las aplicaciones GUI y generalmente verifican todos los parámetros antes de comenzar.Esto limitará su interfaz gráfica de usuario porque, para una interfaz gráfica de usuario, podría tener más sentido solicitar los parámetros a medida que su programa funciona o después.

Si no te importa la GUI, no te preocupes.Si el resultado final será una interfaz gráfica de usuario, primero cree la interfaz gráfica de usuario y luego haga la versión de línea de comando.O podrías trabajar en ambos al mismo tiempo.

--Edición masiva--

Después de dedicar un tiempo a mi proyecto actual, siento que he cerrado el círculo de mi respuesta anterior.Creo que es mejor hacer primero la línea de comando y luego incluir una interfaz gráfica de usuario en ella.Si es necesario, creo que puedes crear una excelente interfaz gráfica de usuario después.Al ejecutar primero la línea de comando, obtendrá todos los argumentos primero para que no haya sorpresas (hasta que cambien los requisitos) cuando realice la UI/UX.

Ese es exactamente uno de mis descubrimientos más importantes sobre la codificación y desearía que más personas adoptaran ese enfoque.

Sólo una pequeña aclaración:La GUI no debe envolver la línea de comando.En cambio, uno debería poder controlar el núcleo del programa desde una GUI o una línea de comando.Al menos al principio y solo operaciones básicas.

¿Cuándo es esta una gran idea?

Cuando desee asegurarse de que la implementación de su dominio sea independiente del marco de la GUI.quieres codificar alrededor el marco no en el marco

¿Cuándo es esto una mala idea?

Cuando estás seguro de que tu marco nunca morirá

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow