En la página 25 de Code Complete, se dice que es una buena idea poder reemplazar fácilmente las clases regulares de la interfaz de usuario por una línea de comandos uno.
Conociendo sus ventajas para las pruebas, ¿qué pasa con los problemas que puede traer?
¿Este trabajo adicional realmente valdrá la pena para los proyectos web y móviles? ¿Qué pasa con los proyectos pequeños y medianos? ¿Se aplican las mismas reglas? ¿Y si hace que tu diseño sea más complejo?
Ser capaz de reutilizar la funcionalidad en diferentes interfaces (por ejemplo, GUI vs CLI vs REST) no siempre es necesario, pero es bueno tener y habilitar serendipitous reuse para un sistema, ya que otras personas encuentran nuevas formas de interactuar con él.
Esto tiene algunos inconvenientes que deben ser ponderados:
Habiendo dicho eso, en mi experiencia la implementación de tales capas siempre terminó pagando el esfuerzo. En un par de casos logré implementar sistemas a tiempo porque terminamos teniendo que intercambiar medios (por ejemplo, de integración de servicios web a UI) unas semanas antes de la fecha de vencimiento.
Completamente aparte de las pruebas, la ventaja obvia de este enfoque es que hará que su proyecto sea automatizable y con scripts . Si soy capaz de enviar comandos de línea de comandos a un programa, puedo escribir un script para realizar tareas complicadas con mayor facilidad (y de manera más confiable) de lo que podría crear una macro para automatizar lo mismo en una GUI.
El hecho de que valga la pena o no, por supuesto, depende completamente de si tienes o no muchos usuarios que quisieran automatizar tu programa.
No es un trabajo extra, solo un trabajo diferente . Si lo haces bien, no solo no lo hará más complejo, sino que lo hará más simple porque te obligará a desacoplar tu diseño. Independientemente de si implementa o no la CLI, su diseño estará mejor para hacerlo posible.
Una ventaja clave que parece no haber sido mencionada es que ser capaz de hacer esto en gran medida obliga a un desacoplamiento estricto de la UI del código subyacente. Una de las principales ventajas de esto es que si necesita cambiar significativamente la GUI (por ejemplo, los estándares de iOS a los estándares de OSX o un motor gráfico a otro), eso es todos que debe cambiar, ya que El código subyacente no depende del diseño de la interfaz de usuario. no puede ser, porque si lo fuera, las herramientas de la línea de comandos no funcionarían.
Además de eso, poder automatizar las pruebas es una ventaja clave.
Sí, casi siempre es una buena idea.
Si sigue este enfoque, es probable que no tenga una lógica de negocios o acceso a datos en un mismo hilo como GUI, y detrás de algún controlador de GUI. Solo por este motivo vale la pena invertir.
Creo que es una buena idea. Además, el hecho de poder escribir un segundo extremo frontal de línea de comandos, demuestra en última instancia que la lógica de negocios está totalmente desconectada de cualquier arquitectura de servidor de aplicaciones en particular.
El único peligro que veo al hacer esto es que para llegar a cierta parte de la interfaz de usuario, el usuario normalmente tiene que atravesar otras partes de la interfaz de usuario.
Donde el desarrollador solo puede ejecutar la interfaz de usuario directamente. He visto situaciones en las que un desarrollador no podía reproducir un problema de usuarios hasta que realmente utilizaron el producto.
Así que tenlo en cuenta al crear pruebas.
No. Un terrible consejo.
Es un poco yagni (no lo vas a necesitar).
Exponer una interfaz de línea de comandos no es lo mismo que estructurar su aplicación de una manera que sea compatible con las pruebas unitarias, o que cumpla con cualquier parte de SOLID, o cualquier práctica de programación que recomiendo.
No funciona para ninguna IU que no se adapte a una interfaz de línea de comandos. MS Paint es una aplicación realmente simple, pero ¿cómo, en cualquier situación, vería un beneficio poder controlarlo desde una línea de comando?
No te ayudaría a implementar scripting. En realidad, obstaculizaría cualquier progreso en esa dirección.
Lo único positivo es que apareció en la página 25, por lo que al menos aparece una advertencia de que el resto del libro podría estar, ... maloliente. Lo leí hace mucho tiempo y no me gustó, así que estoy sesgado.
Vuelva a notar la frase: "[Es una buena idea poder reemplazar fácilmente las clases de interfaz de usuario normales por una línea de comandos uno". No significa que tenga que escribir un CLI, solo que podría hacerlo fácilmente.
Entonces, lo que dice es que su UI debe estar desacoplada del resto del código.
Depende y cuando digo que depende, no es solo cuestión de tener un par de casos de ventaja, sino que depende mucho de la aplicación y del público objetivo. Suponiendo que estamos eliminando los juegos de la ecuación, entonces todavía hay una gran variedad de aplicaciones que puede estar escribiendo donde un comando como es poco probable o nunca se implementará. En la parte superior de mi cabeza, cualquier aplicación dirigida a un entorno móvil (por ejemplo, iOS, Android, etc.) probablemente se incluirá en este encabezado.
Teniendo eso en cuenta, en el espacio de software general, cualquier aplicación que dependa mucho de la visualización (por ejemplo, PowerPoint, Maya , etc.) vea que se implementa un reemplazo de línea de comandos. De hecho, en el caso de software de gráficos como Maya, se puede argumentar que es un buen ejercicio mental para determinar cómo funcionaría una versión completa y correcta de la línea de comandos, y puede que no sea posible hacerlo desde el punto de vista del usuario. Por lo tanto, está claro que hay aplicaciones definitivamente comunes que pueden encontrarse donde es poco probable que se vea una interfaz como comando, o deseable incluso si las secuencias de comandos de la aplicación pueden ser deseables.
A continuación, si observamos la forma sugerida desde el punto de vista de la arquitectura general del software, puedo ver dónde tendría sentido preguntarse periódicamente: "¿Cómo puedo acceder a esta función sin la interfaz de usuario?" En general, si no hay forma de hacerlo y no está interactuando directamente con el usuario (por ejemplo, la entrada de gestos), es probable que tenga una situación en la que deba mejorarse la arquitectura general. Para permitir la facilidad de las pruebas, querrá poder acceder directamente al comando sin pasar por la interfaz de usuario, aunque no se puedan invocar a través de una línea de comando. Esto generalmente significa que una API sólida debe estar en su lugar y, en teoría, una buena API debe permitir el acceso a través de la línea de comandos o la interfaz de usuario. Además, a largo plazo, se ahorrará tiempo si necesita agregar una nueva interfaz de usuario a la aplicación.
Al final del día, creo que la sugerencia a la que intenta llegar tiene sentido (es decir, tener una buena API y crear una interfaz de usuario a partir de eso) pero la selección de palabras podría haber sido un poco mejor para obtener el punto a través
Basándose en lo que dijo Mason Wheeler, el hecho de poder interactuar con una aplicación a través de una línea de comandos hace que sea muy fácil automatizar las tareas.
Esto es particularmente útil en las pruebas.
Para dar un ejemplo práctico, si quiero ejecutar pruebas automatizadas en una aplicación, es posible que desee instalar la aplicación automáticamente. Para hacer esto, podría pasar los siguientes parámetros, "myApplication.exe / silentinstall".
Podría programarlo para que cuando especifique este modificador de línea de comandos, se realice una instalación silenciosa en segundo plano, sin el instalador de GUI. Cualquier entrada al instalador (como el directorio de instalación) podría recogerse de un archivo XML tal vez.
Toma otro ejemplo. Microsoft Test Manager GUI (viene con Visual Studio) permite a los usuarios iniciar ejecuciones de prueba desde su interfaz GUI, pero también proporciona una interfaz de línea de comandos para hacer lo mismo (utilizando una combinación de interruptores y entradas de línea de comandos). Esto significa que puedo armar un script de PowerShell o DOS para automatizar el lanzamiento de las pruebas, y luego puedo crear una tarea programada para que los scripts se ejecuten todas las noches, tal vez.
Algunas aplicaciones tienen modificadores de línea de comando que especifican que una aplicación se abra con ciertas opciones (por ejemplo, podría usar '/ maximizar' para abrir la aplicación en una ventana maximizada).
Hay muchos escenarios en los que se puede utilizar una interfaz de línea de comandos. Estos son sólo algunos ejemplos.
Depende.
A menudo dividimos nuestros programas como modelo / vista / controladores o modelo / vista / vista / modelo. Parece que el modelo debería permitir el acceso a la línea de comando, pero no estoy tan seguro acerca del controlador. Naturalmente, la vista es lo que se está reemplazando.
Puede haber alguna diferencia basada en la cadena de herramientas. Code Complete es un libro de Microsoft Press, ¿quizás esté utilizando las tecnologías de Microsoft para esta GUI? Si es así, creo que podría haber una casilla de verificación al crear la aplicación para exponer interfaces a través de COM o DCOM. Para algunas tecnologías de Microsoft, creo que las tablas de recursos y el paso de mensajes se combinan de manera intensiva con cualquier cosa que los Wizards le ayuden a crear prototipos rápidamente. Creo que está mejorando, pero si mantienes MFC o Forms, podría doler un poco.
En algunos casos, su programa basado en GUI puede ser una envoltura alrededor de una interfaz de administración o puede tener tan poca lógica propia, que no hay mucho que controlar mediante la interfaz de línea de comandos. La creación de una aplicación de consola por separado podría ser más rápida y seguir permitiéndole hacer un script, probar o usar lo que es importante.
El punto clave que supongo es que la sugerencia no es una regla. Si lo sigue, debería obtener pruebas de aceptación y unidad más sencillas o una interfaz alternativa para cuando usted o un cliente prefieran escribir en lugar de hacer clic. Si se paga a sí mismo, hazlo. Buena suerte.
Depende de cuán útil sea el programa de línea de comandos. Algunas cosas, como trazar una ruta en un mapa o jugar un juego en 3D, simplemente no se prestan a una interfaz de línea de comandos. Pero otras cosas, como las herramientas del sistema, son mucho mejores desde la línea de comandos que desde una GUI, por la sencilla razón de que se pueden incluir en un script.
Dr. Richard Hipp dijo una vez que su sistema operativo GUI ideal era un escritorio en blanco con un ícono para abrir las ventanas de comando y otro ícono para abrir un navegador web. Me siento casi de la misma manera. Si fuera útil como un programa de línea de comandos y no fuera demasiado difícil de construir de esa manera, lo haría. La GUI podría ser un programa completamente separado, ¡tal vez creado por otra persona!
En estos días (al menos para Java) parece que tarde o temprano todos los programas agregan un servicio web (SOAP o Ajax o ambos) tarde o temprano. Así que, en general, sí, piense de esa manera, pero es más probable que una línea de comando sea un frontend de servicios web si desea una mejor metáfora mental ... y una más probable.
Hay una forma diferente de ver las cosas. En lugar de suponer que una línea de comando es la única manera de ir, ¿por qué no asumir que el control de voz podría usarse en su lugar? Entonces se requiere un paradigma completamente diferente.
Antes de que Jobs se hiciera cargo de Apple, se estaban explorando mecanismos de control de voz muy sofisticados. Apple aplastó esto a favor de cosas como Siri.
Suspiro.
Popular y obvio no siempre son "los mejores".
Esto generalmente es una buena idea, sí.
Por metáfora, la gente puede pensar en esto como una forma de diseño RESTful. .... no es, per se, como una UI típica (G) podría implicar transacciones complejas de múltiples etapas como la creación de cuentas.
Better that one stays away from multi-stage complexity through shopping-cart-like models for transactional setup.
Una vez programé una metáfora de IU de arrastrar y soltar en el navegador. Reglas de interacción muy complejas en el back-end para hacer que la UX se sienta natural. Resolví esto haciendo que el sitio fuera una API y la GUI era una aplicación completa que generaba eventos sobre la acción. Un módulo captó estos eventos y, en un temporizador, los agrupó en "llamadas API" (para la eficiencia de la red).
El resultado fue un sistema central completamente RESTful. El segundo resultado fue que tenía una interfaz para terceros, que podía exponer utilizando perfiles de afiliación según el modelo de negocio.
Una ventaja es que se verá obligado a pensar en el flujo de la interfaz de usuario desde la perspectiva del usuario. (¿Qué estoy tratando de lograr? ¿Qué contexto necesito para configurar? Dado ese contexto, ¿cómo logro la meta?)
Hay una gran diferencia entre "crear cuenta bancaria" y "escribir más documentos de Word". Incluso si no crea una CLI, puede agregar valor solo para considerar el "contexto de CLI" necesario. ¡Los modelos no solo viven en el modelo de objeto de negocio!
Lea otras preguntas en las etiquetas design architecture user-interface command-line