design - son - ¿Cuándo diseñas primero la GUI y el código de back-end, o viceversa?

tecnologias backend (9)

A menudo prefiero comenzar con el código de back-end cuando el proyecto es "intensivo en datos" (crear, leer, actualizar y eliminar elementos, mostrar listas de datos).

GUI primero al desarrollar prototipos rápidos.

Cuando estoy trabajando en un proyecto, a veces primero diseño la GUI y luego escribo el código de fondo para que funcione, pero otras veces hago lo contrario y hago la GUI una vez que tengo el sistema funcionando. ¿Cómo se elije qué camino tomar para codificar y hay algún tipo particular de proyecto o circunstancia que lo respalde de alguna manera?

Creo que escribir primero la GUI y mostrar un prototipo rápido al usuario final ayuda a compartir la misma visión del producto final. En mi humilde opinión, considero que el código del lado del servidor no depende del código GUI.

Hay dos preguntas para determinar: a) cuál es más importante b) cuál es más difícil.

Si está escribiendo una solicitud de procesamiento de pedidos, es claro que su éxito va a depender más de la interfaz de usuario que del código de back-end. Entonces probablemente debas diseñarlo primero, obtener un cierto nivel de aprobación por parte de tus clientes, y luego diseñar el backend para que coincida con él.

También se debe decir que el diseño no se termina hasta que ambos estén diseñados, y lo que haga en segundo lugar puede implicar el rediseño de lo que haga primero.

Necesita crear algo que permita que sus probadores comiencen inmediatamente. Intenta pensar desde esa perspectiva.

Si están trabajando en pruebas de UI manuales, denles un shell de UI con stubs para toda la funcionalidad. Si hay una interfaz para probar, asegúrese de que funcione (incluso si devuelve datos ficticios) para que puedan comenzar a trabajar con ella, etc.

La mayoría de las veces es la IU. Podrías mostrarlo a tus usuarios y obtener retroalimentación inmediata que es realmente útil.

Ni ni. Por lo general, dividimos el proyecto en tareas. Algunas tareas son parte de la construcción de la interfaz de usuario solicitada y algunas son parte de la implementación de la funcionalidad necesaria detrás de ella. Diferentes personas trabajan en diferentes tareas, por lo tanto, parte del equipo está haciendo la interfaz de usuario y otra parte está implementando funcionalidades detrás de ella. Entonces trabajamos en paralelo tanto en la interfaz de usuario como en la funcionalidad.

Solo es importante llevar las tareas al orden correcto. Es inútil si tenemos la funcionalidad lista, pero la interfaz de usuario para usarla demorará otras dos semanas. También es inútil tener la interfaz de usuario para algo preparado, pero no funcionará durante otras dos semanas, ya que falta la funcionalidad de back-end.

Es por eso que tratamos de especificar pequeños hitos. Nadie comienza a trabajar en otro hito hasta que todas sus tareas del actual estén terminadas. Un hito siempre agrupa la funcionalidad frontend y back-end. Entonces, si se ha alcanzado un hito, la interfaz para cada funcionalidad implementada debe estar lista y cada funcionalidad de back-end implementada debe tener una interfaz para probarla.

Sin embargo, en cierto sentido, puede decir que primero hacemos el código de back-end y luego la IU, ya que cuando se dice que un hito necesita ofrecer una interfaz de usuario para probar la funcionalidad, no significa que esta es la UI final que enviaremos. Por lo general, cerca del final, cuando casi toda la funcionalidad de back-end está lista y probada, a menudo hacemos una revisión de UI. Esto se debe a que la interfaz de usuario para las pruebas debe estar lista para un hito, pero puede no ser siempre agradable o la interfaz de usuario que finalmente enviaremos. A menudo, la interfaz de usuario ralentizaría todo el proyecto (nuestras aplicaciones suelen ser muy intensivas en UI, ya que no nos gusta producir aplicaciones con UI estándar aburridas, queremos UI atractivas que te hagan decir: "¡Guau, eso se ve increíble!") , por lo tanto, a menudo necesitamos implementar una UI intermedia para tener una IU lista para el hito y para la prueba. Con más frecuencia que menos, modernizamos la interfaz de usuario como último paso antes de la publicación. Como ya tenemos UI para todo, no es gran cosa si no podemos modernizar algunas partes (debido a limitaciones de tiempo), después de todo, hay una interfaz de usuario, simplemente no es bonita, pero está funcionando y probada. Así que trataremos de renovar tanto como sea posible dentro del marco de tiempo dado, sabiendo todo el tiempo que si debemos detener el proceso de renovación mañana, tenemos una aplicación totalmente funcional y con capacidad de desplazamiento. La actualización de la interfaz de usuario solo está puliendo, es bueno tenerla, pero también podría lanzarla sin ella.

Realmente van de mano a mano. No puede diseñar su interfaz de usuario sin tener al menos un diseño básico del back-end para las funciones que cubrirá la interfaz de usuario. Y se agrega una nueva característica de back-end, parte del diseño consiste en descubrir cómo se expone esa función al usuario y cómo se adapta al flujo de trabajo existente.

Por cierto, realmente no me gusta la interfaz de usuario rápida y sucia "solo para darles a los evaluadores acceso a la función". Una vez que construya la interfaz de usuario, rara vez tendrá tiempo más tarde en el proyecto para reconstruirla desde cero (suponiendo que se trata de un proyecto en un horario :-)). Si está construyendo una interfaz de usuario, compila el píxel perfecto, de la manera en que le gustaría que se vea cuando se envíe al cliente.

De lo contrario, terminas con algo así como esta monstruosidad . :-)

Por cierto, si necesita construir un prototipo de UI para las pruebas de usabilidad, asegúrese de que esté construido con algo que no pueda integrarse en el código de producción. Por ejemplo, construya el prototipo en Flash si está escribiendo código C ++ / C # / Java.

Supongo que esto depende del tipo de proyecto, y sí, soy consciente de que no es realmente una respuesta, ya que todos lo hacen. Pero por lo general, puede visualizar cómo la parte delantera también quiere mirar desde el fondo.

Siempre tendría un ojo en la parte delantera, ya que al final del día esa es la parte que será visible. Además, por lo general, ayuda a tener una idea de lo que se espera al visualizar, incluso si en forma de bloque o por correo postal se observa lo que desea ver en cuanto a lo que está codificando realmente.

Por supuesto, siempre ayuda si es para un cliente y te dan los visuales de antemano :) De esa manera, siempre y cuando coincidas con los visuales, puedes ir a la ciudad sin diversión relacionada con la parte trasera.

Mi manera es:

Escriba en papel muy específicamente lo que quiero que haga la aplicación
Dibuje en papel las vistas básicas de la aplicación, según lo que quiero que haga la aplicación
Piensa en los elementos básicos que se necesitan para estar en la aplicación
Haga un prototipo de una vista básica de la aplicación, ya sea en el SDK que estoy usando o en una aplicación de prototipos (una aplicación de creación de prototipos es mejor porque de esta manera ahorrará tiempo en caso de que vea en el proceso que lo que pensó no ayuda con el uso de la aplicación)
Transfiere el prototipo a tu SDK y escribe el código
Estudia las "leyes" de UX y aplica el diseño ... este es el punto en el que deberás cambiar tu código en consecuencia

Primero debe comenzar por recopilar los requisitos del usuario o del cliente y luego analizarlos. después de eso, puede seguir el siguiente modelo general del proceso de diseño:

Entonces, para hacer un diseño profesional, debe seguir estas tres capas, como lo declaró en el libro de ingeniería de software de Ian Sommerville.

En resumen, y si acortamos la respuesta, podemos decir que la mejor respuesta es trabajar en la GUI y en el diseño de la base de datos casi simultáneamente. Y después de hacer muchos cambios en ambos; finalmente, ambos diseños se producirán casi al mismo tiempo.