¿Puede ser útil construir una aplicación comenzando con la GUI?

La tendencia en el diseño y desarrollo de aplicaciones parece estar comenzando con las "entrañas": el dominio, luego el acceso a los datos, luego la infraestructura, etc. La GUI parece llegar más tarde en el proceso. Me pregunto si alguna vez podría ser útil construir primero la GUI ...

Mi razonamiento es que al construir al menos un prototipo de GUI, obtienes una mejor idea de lo que debe suceder detrás de escena y, por lo tanto, estás en una mejor posición para comenzar a trabajar en el dominio y el código de soporte.

Puedo ver un problema con esta práctica en que si el código de soporte aún no está escrito, no habrá mucho para que la capa GUI realmente haga. Quizás construir objetos simulados o clases descartables (algo así como se hace en las pruebas unitarias) proporcionaría una base suficiente para construir la GUI inicialmente.

¿Podría ser esta una idea factible para un proyecto real? Tal vez podríamos agregar GDD (GUI Driven Development) al acrónimo estable ...

Construir prototipos rápidos de GUI es una buena idea, y he oído que se usa en muchos proyectos. La retroalimentación temprana es realmente valiosa. Sin embargo, tiene sus peligros:

• Es muy tentador (para los gerentes / usuarios) seguir usando el código prototipo y construir la aplicación final sobre él, lo que puede tener muy malas consecuencias a largo plazo (esto realmente sucedió en uno de los proyectos en los que he trabajado, y resultó en un producto "funcional" con arquitectura inexistente y mucho dolor de cabeza de mantenimiento para nosotros)
• Para el usuario promedio, la GUI es la aplicación . Por lo tanto, una vez que ven una GUI bonita, tienden a creer que la mayor parte del trabajo real está hecho, por lo que pueden enfadarse mucho con el "pequeño trabajo restante" que se prolonga tanto tiempo: - /

Mitigar estos riesgos requiere una discusión activa y posiblemente la educación de sus usuarios y / o gerentes.

El problema que veo con eso es que el objetivo parece ser totalmente atrasado.

"Mi razonamiento es que al construir al menos un prototipo de GUI, obtienes una mejor idea de lo que debe suceder detrás de escena y, por lo tanto, estás en una mejor posición para comenzar a trabajar en el dominio y el código de soporte".

Esta es, en mi opinión, la forma incorrecta de mirar una capa empresarial y una GRAN manera de encontrar un diseño pobre e inexplicable. Una capa de datos que está bien diseñada para expresar completamente los datos se puede usar en cualquier interfaz de usuario. Una capa de datos diseñada para trabajar para las necesidades de una interfaz de usuario específica puede no ser adaptable a otra cosa, ni siquiera a pequeñas adiciones de funciones a esa interfaz de usuario.

La experiencia con los sistemas diseñados de la forma en la que está hablando me lleva a concluir que la mayoría de los diseños que utilizan esta metodología terminan siendo de corta duración y / o demasiado complicados. También tienden a crear un acoplamiento entre la interfaz de usuario y la capa de datos que nunca deberían estar allí.

Se debe alentar la independencia de la capa de datos y la capa de IU. Es por eso que construir la capa de datos para representar simplemente todos los datos en lugar de apuntar a una IU específica simplemente funciona mejor a largo plazo.

La construcción de un prototipo puede ser bueno para la recopilación de requisitos y el acuerdo, pero luego debe desecharse. En realidad, no use nada del código prototipo en el producto real.

Creo que @ Péter tiene razón al sugerir que construir prototipos de GUI es una buena idea. Me gustaría complementar con las posibles dificultades de proporcionar la experiencia del usuario de una manera retrospectiva, es decir, centrarse primero en las ontologías, la arquitectura y la infraestructura y la experiencia inmediata del usuario:

• El usuario que ha llevado al final de la línea de tiempo de desarrollo invalida sus estimaciones de los datos y la forma en que se utiliza su aplicación.
• Sus elaborados diseños que desarrolló prematuramente demuestran que son maquinaciones intencionadas que tienen muy poco o ningún uso al final.
• Su aplicación puede ser llevada a un estado en el que entregar experiencias de usuario deficientes se convierta en la norma.

Usted hace las agallas y luego el usuario obtiene lo que salió de sus suposiciones, mientras que usted debe preocuparse por lo que necesita el usuario y construir las agallas en consecuencia. La razón por la cual las personas recurren a hacerlo al revés es simplemente porque la presentación, con la que el usuario interactúa, desde donde los comportamientos de la aplicación surgen naturalmente, es la parte más compleja del sistema que nunca se explora por completo o la gente simplemente se siente muy felices de preocuparse por construir cosas para evitar tener que pensar realmente por qué / para qué / para quién lo están construyendo. Erigir una estructura enorme que es estructuralmente sólida es un juego de niños, lo más difícil es lograr que satisfaga las necesidades funcionales (y estéticas) de todos.

Para cada experiencia craptastic, flujo peculiar, información mal colocada, falta de funcionalidad obvia, cosas que simplemente son incorrectas, instancias cada vez que has rogado preguntar "¿qué genio se le ocurrió eso ?", Yace algo que se ignora, se niega o reveló al usuario como la vanguardia de los esfuerzos de desarrollo.

En general, el modelo debe desarrollarse antes de la vista. Una vez que tenga una base lógica de su aplicación, puede crear una o más vistas de ese modelo (por ejemplo, puede mostrar los datos en una tabla o en un gráfico). Por lo general, el modelo es más importante que la GUI. Esto es especialmente cierto para el desarrollo empresarial donde la GUI generalmente se realiza de manera estándar.

Sin embargo, a veces la GUI es realmente la parte más importante de la aplicación. A veces, desea ver los datos de una manera novedosa y específica, y los toma a partir de ahí, y luego desarrolla el modelo. Por ejemplo, CashCurve es una aplicación en la que el punto está en la GUI, mientras que el modelo de datos en sí mismo es algo aburrido estándar que cualquiera puede modelar en pocos minutos. (Descargo de responsabilidad: no estoy afiliado a CashCurve, solo soy un usuario muy satisfecho).

Esto también es relevante para el diseño de servicios web u otras API, solo allí se conoce como diseño de " contrato primero ".

Entonces, en cuanto a todo, no hay una regla sobre qué diseñar primero; a veces es modelo, y a veces es GUI. Como regla general, iría con "diseñar la parte más importante primero".

Hay que tener en cuenta las advertencias al diseñar primero la GUI, como que el usuario probablemente tendrá problemas para comprender que la aplicación está lejos de estar completa cuando solo existe un prototipo de GUI, pero otras respuestas lo han cubierto bastante bien, por lo que no entraré en detalles.

Creo que es una forma extremadamente buena de abordar el diseño de aplicaciones, especialmente en un entorno de desarrollo ágil. La mayoría de los proyectos exitosos en los que he trabajado han comenzado con un prototipo que finalmente se convirtió en algo real.

Debe comprender que la GUI es la ventana del sistema (es decir, base de datos, sistema de archivos, etc.). En una situación en la que los requisitos del proyecto son tan vagos como una pila de granizados, entonces no tendrá la menor esperanza de obtener una solución correcta al comenzar en el backend. Casi siempre, el desarrollador de backend bien intencionado desarrolla un montón de API que no tiene relevancia para las interacciones del usuario.

Al comenzar con la GUI, el cliente tiene una mejor idea de lo que quiere. A medida que avanza esta etapa, el desarrollo de la GUI (utilizando simulaciones y apéndices) da lugar a un modelo de dominio. Este modelo de dominio se puede transferir al backend y los desarrolladores pueden comenzar a desarrollar la persistencia y la lógica transaccional.

¿Y por qué querrías tirar el prototipo? No estamos tratando con estadios construidos con fósforos. Solo refactoriza la maldita cosa en algo bueno.

No me suena nada mal si la persona que mira la GUI entiende que es solo un shell y, literalmente, los botones y los procesos no funcionan (lanzar una nueva NotImplementedException ();;)).

Si utiliza una arquitectura de estilo MVC, no preveo ningún problema de mantenimiento o construcción en el futuro, ya que la "Vista" no define nada de ese tipo de cosas. Los "Controladores" y el "Modelo" pueden venir más tarde con cualquier infraestructura que necesite para las necesidades de escalabilidad / diseño, etc.

En cuanto a la administración, dibuje un gráfico circular grande con 3 porciones, etiquételas como "M", "V" y "C". Déle a la V alrededor del 20% y explique que el resto del pastel es "TBC";).

En cualquier sistema de tamaño razonable, lo que debe suceder detrás de escena está relacionado con el aspecto de la GUI. La GUI le dará solo algunos de los requisitos. A menudo hay muchos componentes que no tienen una GUI.

Después de que se desarrolle el sistema, se pueden requerir interfaces adicionales (incluidas nuevas GUI). Comprender e implementar los requisitos comerciales es fundamental para que esto tenga éxito.

Donde diseñar la GUI y otros mecanismos de entrada y salida puede ayudar es validar el modelo. Es posible que no se requieran atributos que nunca se envían. (Puede haber razones para mantenerlos, pero probablemente serán requisitos de auditoría o de regulación).

Como otros han mencionado, una vez que tenga una GUI que funcione, muchos clientes pensarán que ha terminado. Sin embargo, es posible que no tenga ninguna infraestructura detrás. Los prototipos en papel pueden ser una buena opción para validar el diseño y el contenido de la GUI.

No pase por alto que puede necesitar ajustar la interfaz después del desarrollo. He escuchado el informe de un reemplazo fallido de la interfaz de pago para un proceso de pago de cinco pasos. Una interfaz mucho más simple no les dio a los usuarios la sensación adecuada de seguridad y tuvo una tasa de finalización mucho más baja. Escucha Speed ​​Bumps: el ingrediente mágico en marketing .