language-agnostic - mock - dredd api

¿Qué piensas de desarrollar primero para la línea de comando? (21)

@Maudite

La aplicación de línea de comandos verificará los parametros por adelantado y la GUI no lo hará, pero seguirán verificando los mismos parámetros e ingresándolos en algunas funciones genéricas de los trabajadores.

Aún el mismo objetivo. No veo la versión de línea de comandos que afecte la calidad de la interfaz gráfica de usuario.

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

p.ej.

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

carga todo.exe y llama a una función llamada AddTask que valida y lanza la reunión en 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 haces clic en enviar, llama a la misma función AddTask.

Esto es considerado:

una buena forma 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 deberían estar separados, aparte 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 aviso interactivo dentro de todo.exe (scripting, etc.)
llana vieja "todo <function>" cuando solo quieres hacer una cosa y terminar con ella.

Addendum 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, este no era mi intento. Cuando mencioné que la GUI de ejemplo llamaba "la misma función AddTask ", no quise decir que la GUI llamara al programa de línea de comandos cada vez. Estoy de acuerdo que sería totalmente desagradable. Tuve la intención (ver primer apéndice) de que todo esto se llevara a cabo en un único ejecutable, ya que era un pequeño ejemplo, pero no creo que mi redacción impidiera necesariamente una biblioteca compartida.

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

@jcarrascal

No veo por qué esto tiene que hacer que la GUI sea "mala".
Mi pensamiento sería que te obligaría a pensar sobre lo que la lógica del "negocio" realmente necesita lograr, sin preocuparte demasiado por que las cosas sean bonitas. Una vez que sepa lo que debería / puede hacer, puede construir su interfaz de la forma que sea más sensata.

Nota al margen: no para comenzar un tema por separado, pero ¿cuál es la forma preferida de responder o comentar sus preguntas? Consideré esto y edité la pregunta en sí.

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

(Además, de esta manera se agrega otra preocupación de seguridad: ¿no debería la GUI primero asegurarse de que se está llamando a la DERECHA todo.exe?)

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

37signals también recomienda diseñar tu interfaz de usuario primero en Getting Real . Recuerde, para todos los efectos, en la mayoría de las aplicaciones, la interfaz de usuario es el programa. El código de fondo está ahí para apoyarlo.

Haga un programa que expone como un servicio web. luego haz la interfaz gráfica de usuario y la línea de comando para llamar al mismo servicio web. Este enfoque también le permite hacer un gui web, y también para proporcionar la funcionalidad como SaaS a los socios de extranet, y / o para asegurar mejor la lógica comercial.

Esto también le permite a su programa participar más fácilmente en un entorno SOA.

Para el servicio web, no te excedas. hacer yaml o xml-rpc. Mantenlo simple.

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

Estoy de acuerdo con el sentimiento de que debes asegurarte de que la GUI sea fácil e intuitiva de usar, por lo que podría ser conveniente desarrollar ambas al mismo tiempo ... una pequeña función de línea de comando seguida de un contenedor GUI para asegurarte de que estás haciendo cosas intuitivamente

Si es fiel a la implementación por igual, el resultado es una aplicación que se puede usar de manera automática, lo que creo que es muy poderoso para los usuarios avanzados.

Joel escribió un artículo que contrasta este desarrollo ("estilo unix") con el método GUI primero ("estilo Windows") hace unos años. Él lo llamó Biculturalismo .

Creo que en Windows se volverá normal (si no lo ha sido ya) para adaptar su lógica a los ensamblados de .NET, a los que puede 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 IU explícita (especialmente cuando la IU no es mi trabajo todavía, por ejemplo, estoy diseñando una aplicación web que todavía está en la fase de diseño) es para escribir pruebas unitarias.

De esta forma, 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 la consola, no tengo que arrojar el código para las pruebas porque aún son útiles más tarde.

Normalmente comienzo con una biblioteca de clases y una GUI básica, realmente horrible y básica. Como la Línea de Comandos involucra el análisis de la Línea de Comandos, siento que estoy agregando mucha sobrecarga innecesaria.

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

Probablemente sea mejor comenzar con una línea de comando primero para asegurarte de que tienes la funcionalidad correcta. Si sus usuarios principales no pueden (o no) 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 la creación de scripts, así como también limitará la cantidad de Bikeshedding inicial para que pueda llegar a la solución real más rápido.

Si hace su desarrollo correcto, entonces 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.

Si planea mantener su versión de la línea de comandos de su aplicación, entonces no veo ningún problema para hacerlo de esta manera, no se desperdicia tiempo. Igual terminará codificando la funcionalidad principal de su aplicación para la línea de comandos y tendrá una gran parte del trabajo realizado.

No veo que trabajar de esta manera sea una barrera para una interfaz de usuario agradable; todavía tienes tiempo para agregar una y hacer que se pueda usar, etc.

Supongo que esta forma de trabajar solo funcionaría si pretendes que tu aplicación final tenga tanto variantes de línea de comandos como de GUI. Es bastante fácil burlarse de una interfaz de usuario y construir su funcionalidad en eso y luego embellecer la interfaz de usuario más tarde.

De acuerdo con Stu: su funcionalidad base debe estar en una biblioteca a la que se llama desde la línea de comandos y el código GUI. Llamar al ejecutable desde la UI es una sobrecarga innecesaria en el tiempo de ejecución.

Depende en cierto modo de tu objetivo para el programa, pero sí lo hago de vez en cuando: es más rápido codificar, más fácil de depurar y más sencillo escribir casos de prueba rápidos y sucios. Y mientras yo estructure mi código de manera adecuada, puedo volver y fijarme en una GUI más tarde sin demasiado trabajo.

Para aquellos que sugieren que esta técnica dará lugar a UI horribles e inutilizables: tienes razón. Escribir una utilidad de línea de comandos es una manera terrible de diseñar una GUI. Tome nota: todos los que están pensando en escribir una interfaz de usuario que no sea una CLUI, no prototen como una CLUI.

Pero, si está escribiendo un código nuevo que no depende de una interfaz de usuario , apúntelo .

Me gustaría construir una biblioteca con una aplicación de línea de comandos que se vincule con ella. Después, puede crear una GUI que enlace a la misma biblioteca. Llamar a una línea de comando desde una GUI engendra procesos externos para cada comando y es más perjudicial para el sistema operativo.

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

Pero incluso si su código funcional está separado de su intérprete de línea de comando, entonces puede simplemente reutilizar el origen para una GUI sin tener los dos tipos a la vez para realizar una operación.

No lo haría por un par de razones.

Diseño:

Una GUI y una CLI son dos interfaces diferentes utilizadas para acceder a una implementación subyacente. Generalmente se usan para diferentes propósitos (la GUI es para un usuario en vivo, CLI usualmente se accede mediante secuencias de comandos) y, a menudo, puede tener diferentes requisitos. Acoplando los dos juntos no es una buena elección y seguramente te causará problemas en el camino.

Actuación:

La forma en que ha descrito las cosas, necesita generar un ejecutable cada vez que la GUI necesita hacer algo. Esto es simplemente feo.

La forma correcta de hacerlo es colocar la implementación en una biblioteca llamada tanto por la CLI como por la GUI.

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

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

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

Su herramienta de línea de comandos imprimirá, en el mejor de los casos, 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 que solo puede enviar a la consola.

Ahora, si quieres agregar una GUI además de eso, ¿qué haces? Analizar el resultado de su herramienta de línea de comandos de larga ejecución? ¿Buscar WARNING y ERROR en esa salida para arrojar un cuadro de diálogo?

En el mejor de los casos, la mayoría de las IUs construidas de esta manera arrojan una barra ocupada durante todo el tiempo que se ejecuta el comando, y luego muestran un diálogo de éxito o falla cuando el comando sale. Tristemente, así es como muchos programas GUI de UNIX se unen, lo que hace que sea una experiencia de usuario terrible.

La mayoría de las respuestas aquí son correctas al decir que probablemente debas abstraer la funcionalidad real de tu programa en una biblioteca, luego escribir una interfaz de línea de comando y la GUI al mismo tiempo para ello. Toda la lógica de su negocio debe estar en su biblioteca, y tanto la IU (sí, una línea de comando es una IU) solo debe hacer lo que sea necesario para la interfaz entre su lógica empresarial y su UI.

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

John Gruber hizo una buena publicación sobre el concepto de agregar una GUI a un programa no diseñado para uno: Ronco Spray-On Usability

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

~~Las herramientas de línea de comandos generan menos eventos que las aplicaciones de GUI y, por lo general, verifican todos los parámetros antes de comenzar.~~ ~~Esto limitará su GUI porque, para una GUI, podría tener más sentido pedir los params a medida que su programa funcione o después.~~

Si no le importa la GUI, no se preocupe. Si el resultado final será una GUI, primero haga la GUI, 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 pasar un tiempo en mi proyecto actual, siento como si hubiera completado el círculo de mi respuesta anterior. Creo que es mejor hacer primero la línea de comando y luego envolver una GUI en ella. Si es necesario, creo que puedes hacer una buena interfaz gráfica de usuario después. Al hacer primero la línea de comando, obtienes todos los argumentos primero para que no haya sorpresas (hasta que los requisitos cambien) cuando estás haciendo la UI / UX.

Esa es exactamente una de mis realizaciones más importantes sobre la codificación y desearía que más personas adoptaran ese enfoque.

Solo una pequeña aclaración: la GUI no debe ser un envoltorio alrededor de la línea de comando. En su lugar, uno debería ser capaz de conducir 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. Desea codificar el marco no en el marco

¿Cuándo es esta una mala idea?

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

Además de lo que dijo Stu , tener una biblioteca compartida también te permitirá usarla desde aplicaciones web. O incluso desde un plugin IDE.