En un proyecto para un solo hombre (páginas web o aplicaciones de escritorio) en el que eres tanto el diseñador como el desarrollador, ¿qué es mejor hacer primero, diseñar o escribir código?¿Qué es mejor hacer primero, diseñar la interfaz o escribir el código?
Por interfaz Supongo que se refiere a la interfaz de usuario, a diferencia de una API. Siempre diseño la interfaz primero. Cuando estoy codificando soy perezoso, hago lo que sea que haga el trabajo con el mínimo esfuerzo. Esto conduce a interfaces que no tienen sentido solo porque esa era la manera más fácil (o más limpia) de hacerlo en el código. Pero antes de que haya escrito el código, no tiene prejuicios y tomará mejores decisiones sobre cuál será una buena interfaz.
Sin embargo, seguirán siendo malas decisiones. Puedes pensar que sabes lo que se siente natural, pero no lo sabes. Pruébalo en las personas! Observe lo que hacen, cómo intentan usar su software, hágales preguntas y adaptarse en consecuencia. Si lo haces a menudo, no importa si primero diseñas o codificas. Esta es la manera de hacer un producto de primera categoría.
+1 porque comienza por UI. – Simone
Normalmente diseño el proyecto en papel (o con herramientas de diagramas), luego escribo la parte central y finalmente la interfaz de usuario. GUI es el último. Para que pueda hacer pruebas primero con la parte lógica del programa y solo después con la parte de presentación.
Digamos que la dirección del desarrollo parece ir desde el centro de una cebolla a la parte exterior.
Desde una perspectiva de sentido común diría que un diseño de maqueta (piense en lápiz y papel) es lo mejor para comenzar. Defina lo que quiere que haga el programa/sitio y cómo debería verse sin entrar en detalles. Si tiene un objetivo claro establecido desde el principio en cuanto a las funciones y el diseño en un orden de implementación de proyecto más pequeño, no debería ser tan grande.
Debo decir que siempre hago el código antes del diseño, y rara vez creo borradores de maqueta. Además, nunca sigo mi propio consejo.
¿Qué codifica exactamente * a * si no tiene un diseño? Estoy de acuerdo en que tener uno en mente o en papel a veces es suficiente, pero no veo cómo se puede comenzar a escribir código sin ninguno. –
Tal vez "hacer el código antes del diseño" no sea la manera correcta de expresarlo.Por lo general, generalmente comienzo a codificar la red troncal y más implementaciones técnicas primero y luego creo una interfaz de usuario básica para probar estas funciones. Terminar todo el código antes del diseño es obviamente una forma bastante estúpida de hacerlo. Pero como dije, no creo que lo haga como debería (según mi propio consejo). –
Ésta es creo un paso común a paso:
+1 porque comienza por UI. – Simone
Le sugiero que haga una impresión azul de su interfaz de usuario y luego haga la codificación y la interfaz simultáneamente. Será mejor ya que puede obtener la salida instantáneamente si lo desea y también puede cambiarla.
Esto es una especie de prueba de página HTML.
Creo que al decir "diseñar la interfaz" se refiere a la interfaz gráfica. Como PNL enseña, manejarás mejores cosas que ya ves, por lo que la visualización ayuda mucho en el diseño de un nuevo proyecto.
Es por eso que comienzo proyectos siguiendo mi primera idea visual dibujando las maquetas de las páginas que sé exactamente cómo van a funcionar, con lápiz y papel (me alegra leer que muchos colegas estimados también lo hacen).
Esto me permite conceptualizar las entidades de aplicación (que son probables clases) y las funcionalidades (que pueden traducirse directamente en métodos).
Llegados a este punto, escribo la interfaz de programación, que para mí es la parte más importante de una aplicación, tanto desde el principio como desde el futuro.
Normalmente no es un estilo de programación completamente nuevo, ya que muchos programadores tienen sus patrones preferidos y su sintaxis y código para reutilizar o el entorno/entorno en el que tienen que trabajar, pero de todos modos lo considero una tarea fundamental .
Antes de escribir el código también diseño la base de datos, cuyo uso también se delega a los métodos de nivel inferior utilizados por los métodos de interfaz que ya escribí (el 90% de los proyectos en los que trabajé tenía DB-dased). me viene a la mente acerca de atributos o tablas auxiliares que pueden completar mejor la información manejada por la aplicación o mejorar las funcionalidades.
Cuando tengo tiempo, también hago algunas tablas y diagramas usando Excel, definiendo las tareas completas de CRUD para cada tabla (obviamente no todas las tablas pueden necesitar todas las tareas de CRUD).
Esto me permite escribir en pocas ocasiones también las consultas SQL generales, lo que también reduce el trabajo de escribir código, evitando cambiar la atención a otros dialectos SQL.
Empiezo a escribir el código como la tarea final, y en este punto el trabajo ya está hecho.
Escribir la lógica de la aplicación con el fondo explicado me permite pensar y escribir solo en los principales idiomas elegidos para realizar el proyecto, que generalmente es PHP para el procesamiento del lado del servidor y JavaScript para la GUI del cliente.
Experimenté la verdad de una frase que un maestro solía decir con frecuencia: un buen trabajo es el 90% de planificación, el 10% de realización.
Estoy totalmente de acuerdo: cuando se hace una buena planificación, el resto es simplemente empacar todas las piezas.
Feliz codificación y un año nuevo de la suerte! :)
Normalmente hago todos los wireframes de las pantallas primero, luego el diagrama de la base de datos, luego código, y luego hago el frontend.
Piénselo lógicamente: la interfaz/interfaz es la razón por la cual la base de datos y su código están allí, y no al revés.
Veo tanta gente que pasa demasiado tiempo en arquitectura y diseño de bases de datos, mientras que la interfaz se descuida.
Al usuario final no le importa cómo se ve su base de datos, qué código escribe o cuántas capas tiene.
"Cuando terminamos de construir nuestra casa y nos mudamos, y tuvimos la fiesta de bienvenida, finalmente contratamos a un arquitecto, hizo un gran diseño". Puedes sentirlo ;)? –
Si bien creo que debe comenzar con la interfaz de usuario, supongo que la lógica del programa es bastante simple, como lo es con muchas aplicaciones web. Si tengo algoritmos difíciles y complejos, empiezo en el otro extremo, porque el diseño de ese código afectará a todo mi proyecto, mientras que la IU generalmente puede contenerse. Es importante que la lógica se establezca de manera simple y clara para que pueda mantenerse. Por ejemplo, cuando está creando un lenguaje de programación, comience con el cálculo del núcleo, no con la sintaxis. – luqui