Front end first o Back end first. De las dos, ¿cuál es una buena práctica de diseño de sistemas?


30

Ahora mismo tengo un cliente que me exige que desarrolle un sistema de inscripción escolar. Ahora es la primera vez que tengo este tipo de desafío. La mayoría del software anterior que creé no es tan complejo.

Sé que la mayoría de ustedes han creado softwares complejos, solo quiero su consejo sobre esto. ¿Debo diseñar primero el front-end o el back-end?

¡Gracias!

Aquí hay una conclusión de un artículo que encontré en Internet hace un tiempo. Solo que compartir

http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157

Desarrolladores front-end versus back-end (mi opinión)

Mi toma personal

Nuevamente, es una cuestión de entrenamiento, algunas generalizaciones generales del accidente cerebrovascular:

Desarrolladores frontales

  • Por lo general, no tengo un título de CS o un título de CS de una escuela de tercer nivel.
  • Trabaja en lenguajes similares a los básicos (ver PHP es Básico)
  • Tener una habilidad visual para convertir documentos de Photoshop a CSS / HTML / etc.
  • Tener una alta tolerancia para la programación iterativa, debido a los lenguajes libres de tipo

Desarrolladores finales

  • Tener un título de CS o mucha experiencia
  • Me tienden a ser más sistemáticos en su enfoque de resolución de problemas.
  • No te importe pasar días buscando el único objeto que está goteando
  • Prueba y crea herramientas para resolver problemas


2
smh, esta es la razón por la que le digo a la gente que soy un desarrollador de software vs desarrollador web.
favor

10
¿Qué tienen que ver estas generalizaciones sobre los desarrolladores front-end y back-end con la pregunta?
Erik Reppen

Front End Dev! = Back End Devs, aunque la mayoría de las veces, las transiciones en blanco y negro continúan.
Abhinav Gauniyal

Creo que la única respuesta válida aquí sería 'Depende ...'
Oliver Weiler

Respuestas:


43

Si comienza en la parte posterior y avanza, corre el riesgo de malinterpretar al cliente. Como creará cosas que no pueden ver y comprender fácilmente, no pueden participar fácilmente para verificar si cumple con los requisitos. Esto significa que puede desperdiciar mucho trabajo.

Si comienza en la parte delantera y retrocede, corre el riesgo de que el cliente piense que está casi listo, cuando todo lo que ha hecho es dibujar un formulario simple en la pantalla. Luego pueden preguntarse por qué está tomando tanto tiempo, ya que lo terminaron en pocos días. También corre el riesgo de pintarse en una esquina, cuando se da cuenta de que tiene que hacer un trabajo complicado para casar el frente con la parte posterior, cuando un front-end más adecuado hubiera sido más simple.

OMI, deberías trabajar en ella primero. Escriba el frente y el reverso juntos, para cada característica del sistema. Esto le da al cliente una mayor visibilidad del progreso y le da la oportunidad de decir "no, eso no es lo que quise decir", sin causarle demasiada angustia.

Dicho esto, si este es un proyecto muy grande en el que necesita considerar el hardware del servidor o las capacidades de cualquier software en el que confíe (por ejemplo, qué base de datos está usando), entonces probablemente debería pensar primero en esa parte.


Creo que es una explicación más concisa. Pero sería mejor hacer el back-end primero porque creo que es más fácil crear el front-end si tienes un back-end bien estructurado.
drexsien

3
Si piensan que el front-end lo es todo, podrías mencionar Google ...
l0b0

1
Es por eso que debe crear una GUI de maqueta que le muestre al cliente y decir "¿Es esto lo que quiere que haga el programa?", Y una vez que esté resuelto, la descarta y comienza a construir el back-end.
gablin

1
+1. @andsien: Si ya tienes tu opinión, ¿por qué preguntaste? Según mi experiencia, Paul tiene razón, el desarrollo basado en características es casi siempre la mejor estrategia.
Doc Brown

3
@andsien: "es más fácil crear el front-end si tienes un back-end bien estructurado". En mi humilde opinión, es un malentendido peligroso. El problema es: no sabe si su back-end está bien estructurado hasta que lo haya usado para crear funciones para la interfaz.
sleske

9

El software tiene muchas dimensiones, por lo tanto, un frente demasiado simple es una pregunta pobre y es muy, muy difícil proporcionar una respuesta sensata y útil.

Una vista es la estructura estática de los datos. Hay al menos tres dimensiones en esta vista: capas arquitectónicas ("de adelante hacia atrás"), casos de uso y actores, así como costos o riesgos de implementación.

Una vista es la estructura dinámica del procesamiento. Hay al menos tres dimensiones para esta vista, también.

Una tercera vista son los componentes arquitectónicos, que se dividen naturalmente en capas, admiten casos de uso y tienen costos y riesgos.

Podría seguir, pero el punto es este.

Desarrolladores front-end versus back-end (mi opinión)

Es aproximadamente la forma menos útil de ver el problema. Los desarrolladores reales, y sus opiniones sobre ellos, importan muy, muy poco aquí. Lo que importa son

  • Casos de uso y actores

  • Modelo de datos lógico para soportar esos casos de uso

  • Proceso que se realiza como parte del caso de uso

  • Componentes que usará para construir esos elementos lógicos y de procesamiento del caso de uso.

Es por eso que la mayoría de la gente dice que necesita descomponer su sistema por historia de usuario o caso de uso.

No hacer generalizaciones generales sobre las personas que estarán desarrollando.


7

Ninguno. ¿Qué necesita tu aplicación para poder hacer? Asegúrese de que la válvula caliente entregue agua caliente, la válvula fría entregue agua fría, que el agua fluya en primer lugar, que pueda extender las tuberías donde sea necesario y luego preocuparse por implementar la tubería real en todas las habitaciones de la casa o lo que la casa hará En realidad parece exactamente.

La parte frontal es solo una máscara con algunos interruptores y palancas. El back-end es solo una cosa que recibe solicitudes para recuperar y procesar datos. Llegue a un punto donde pueda implementar rápidamente ambos en cualquier combinación deseada primero.

Pero hagas lo que hagas, no dejes que el diseño de uno dicte el diseño del otro. De esa manera yace la locura.

Obtenga las herramientas en su lugar para que sus desarrolladores puedan construir lo que necesiten para su cliente, independientemente de cuántas veces cambien de opinión. Luego compílelo según las especificaciones y vuelva a encenderlo hasta que los pequeños malditos finalmente estén contentos.

Además, comparar desarrolladores front-end con desarrolladores back-end en 2008 es hace mucho tiempo en años web. En aras de la diversión, me gustaría corregir / agregar algunas cosas a esa vieja castaña ya que la hemos vinculado en la pregunta, pero también (con suerte) incluir algunos consejos en:

Desarrolladores frontales

Por lo general, no tengo un título de CS o un título de CS de una escuela de tercer nivel.

Votación a mano alzada. ¿A cuántas personas con títulos de CS se les han enseñado las mejores prácticas en el front-end? ¿O cómo no hacer un lío con JavaScript? ¿O cómo manejar los problemas de CSS de IE6-IE9? La industria de los libros de texto, que dirige la academia, es demasiado holgazana e hinchada para manejar tecnología en constante cambio, por lo que ha recibido muy poca atención "seria" en las universidades. Esto ha sido excelente para los que florecen tarde como yo.

Trabaja en lenguajes similares a los básicos (ver PHP es Básico)

¿Porque PHP es tecnología del lado del cliente? ¿O porque JavaScript, que se inspiró principalmente en Scheme, tiene más en común con Basic que con Visual Basic, que ahora ya no es una preocupación permanente en el front-end y que nunca estuvo realmente, pero todavía está disponible para aplicaciones web .NET de back-end? El blog compara desarrolladores web autodidactas de código abierto con desarrolladores web graduados de CS que usan tecnología popular corporativa en este punto, creo. Me he encontrado insufrible y competente en partes iguales en ambos lados de esa pelea en particular, pero todavía está en OT allí.

Tener una habilidad visual para convertir documentos de Photoshop a CSS / HTML / etc.

Más atención al detalle que "habilidad visual", que es un poco amplia. No todos tenemos habilidades estéticas de diseño. Pero sí, la mayoría de nosotros tenemos que aprender estas cosas al nivel de Jr. y en realidad es bastante crítico para escribir una buena interfaz de usuario que no use martillos JS cuando los escalpelos CSS lo harán.

Tener una alta tolerancia para la programación iterativa, debido a los lenguajes libres de tipo

Esta es la razón por la que quieres que las piezas que mencioné anteriormente estén colocadas primero. Pasamos los botones presionados, usted produce / recupera los productos. Los empaquetamos y los entregamos. No hay ninguna razón para que estas cosas estén estrechamente vinculadas entre sí. También realmente, la mecanografía estricta no debería interferir con un proceso iterativo si no apestas en OOP, que la mayoría de las personas a las que les gusta ser arrogantes acerca de un idioma que técnicamente no tiene clases, de hecho lo hacen, por lo general. Pero incluso si apestan, la parte frontal solo necesita un punto de acceso predecible y puede hacer lo que quiera en la parte posterior siempre que no haga algo tonto como escribir dinámicamente JavaScript que no sea JSON o unir estrechamente el comportamiento exitoso de back-end a la estructura HTML "solo así" * tos * desarrolladores de Java * / tos *


Lo único que lamento es que no puedo hacer +1 en tu pregunta más de una vez. Es una pena que haya tenido que desplazarme hacia abajo 2 respuestas a esta pregunta para finalmente encontrar la que dice que preguntar sobre el orden en el que se deben desarrollar el frente y la espalda es la pregunta incorrecta. También estoy de acuerdo con tu opinión sobre el título de CS. Y el comentario final de los "tardíos".
Shivan Dragon

5

No hay una única respuesta correcta a esto. Cualquiera de los dos enfoques puede ser bueno (y malo) en ciertas situaciones.

Le recomiendo que considere el enfoque TDD, donde uno es liderado por pruebas (de aceptación y unidad).

Comience armando un esqueleto del sistema: la infraestructura básica, con la funcionalidad mínima absoluta. Esto es solo para mostrar que su concepto funciona y que los diferentes componentes pueden trabajar juntos. Esto también incluye una interfaz de usuario básica (si corresponde), lo suficiente para hacer y / o mostrar algo mínimo.

Luego, desarrolla los detalles, característica por característica : escriba una prueba de aceptación para una característica / escenario específico, haga que falle y luego escriba código para satisfacerla. Esto lo hace trabajar hacia adentro desde el exterior : el sistema recibe algún mensaje de entrada, por lo que debe manejar / convertir ese mensaje, hacer algo con él y luego propagar los resultados a la interfaz de usuario. En el camino descubrirá los conceptos de dominio y los representará con nuevas clases, desde la interfaz de usuario hacia la capa de dominio y viceversa.

Para este enfoque, una lectura recomendada es Crecer software orientado a objetos, guiado por pruebas .


1

API primero

Los ingenieros de ambos equipos deben trabajar juntos en la API entre el front-end y el back-end. Luego, ambos equipos pueden comenzar a trabajar según la API diseñada. Esto tiene la ventaja de que otro equipo de front-end también puede comenzar el trabajo (tal vez móvil, después del cliente web) además de la ventaja obvia de que los equipos pueden comenzar a trabajar en paralelo.

Combine con un enfoque iterativo y debería verse así:

  1. Diseña una API simple
  2. Ambos equipos se desarrollan y prueban según la API
  3. Examen de integración
  4. Mostrar al cliente y recibir comentarios.
  5. Mejora la API y repite.

0

Comience con la interfaz, pero primero, ¿por qué no pueden encontrar una aplicación que ya existe? Esto daría más información sobre este proyecto. ¿Tienen algunos requisitos únicos o creen que se puede construir más barato?

Obtenga una comprensión completa de sus expectativas de seguridad y de lo que exige la ley. No estoy seguro de qué tipo de escuela es esta, pero la información del estudiante generalmente requiere cierta confidencialidad.

Si los estudiantes potenciales ingresan los datos en un sitio web, el diseño gráfico será más problemático.

En función de sus solicitudes, dibuje maquetas de la interfaz. Si crees que la interfaz gráfica de usuario no es directa, es posible que tengas que hacer algo funcional para que puedan verlo en acción. Pueden ver la inscripción como algún tipo de 'asistente' que se ramifica en diferentes direcciones según la entrada de datos.

Entonces puede comenzar a obtener información persistente en la base de datos.


1
el problema empezando por el extremo delantero (basado en la experiencia) es que cuando se olvida de algunas funcionalidades, que pueden estropear su parte final y podría terminar para arriba dando vueltas alrededor de intentar arreglarlo
drexsien

1
@andsien: ¿estás hablando de diseñar o construir? No comenzaría a construir un front end sin diseñar primero el backend.
JeffO

ops mi culpa estoy pensando en construir ... gracias por ese jeff.
drexsien

0

Sí, me di cuenta de que el OP preguntó hace un tiempo. Comience en el extremo posterior, pero HAGA ARRIBA el extremo frontal para permitir que el usuario vea lo que imagina. La parte delantera, por todo lo que vale, son solo las campanas y los silbatos. La parte de atrás es donde está el dinero, y una vez que lo tienes claro, la FE es solo la salsa sobre la carne.


Lamentablemente, es lo que los clientes quieren, por lo general, pero creo que ese comportamiento debe ser desalentado. No los obsesione con lo visual y siga con su aspecto prototipo hasta que puedan verificar que están obteniendo el comportamiento básico que desean. Los clientes a menudo no pueden separar los dulces visuales de la característica útil y harán que pierdas mucho tiempo en las cosas menos importantes solo para culparte cuando la aplicación falla en su intención final a largo plazo.
Erik Reppen

@ErikReppen He tenido esa experiencia muchas veces: quería mostrarle al cliente "el usuario ingresará los datos en un campo de texto" y el cliente verá "el campo del formulario tendrá exactamente 400 píxeles de ancho y la página tendrá un color azul pálido fondo con texto Arial 11pt ... "Pero sigo pensando que es mejor que nunca demorar un front end. De lo contrario, es posible construir un sistema completo que entre en conflicto con alguna suposición no declarada en su caso de uso principal.
octern

Puede hacer una demostración de un front end pero mantenerlo simple y llanamente. Alejarlos de la tontería exacta de Photoshop a menos que así sea como exigen que se les venda. Y ahí radica el problema. Es lo que esperan, pero la mayoría de las veces son demasiado estúpidos para priorizar los píxeles de "en realidad hace que nuestros clientes hagan lo que nos gustaría que hicieran".
Erik Reppen

errr, ¿no es por eso que tenemos CSS? (aunque yo no siento su dolor). Yo siempre y deliberadamente tengo una FE feo, pero funcional, y dejan claro que estamos hablando de casos de uso, flujo de trabajo ... y puedo prettify más tarde. (pero la verdadera respuesta es requisitos-> base de datos-> FE)
Mawg

0

Ampliando mi comentario:

Primero reúna los requisitos, luego conviértalos en Casos de uso y diseño.

Primero viene una definición detallada de la base de datos. No me importa si el cliente no lo asimila por completo, los obligo a sentarse y mirarlo, y cerrar la sesión (posiblemente luego obligándome a darse cuenta de que una vez que sus muchachos más expertos en tecnología deberían hacerlo ), antes de continuar.

¿Cómo puedes comenzar con FE, sin BE? ¿FE para qué? Define tu base de datos !! Eso es lo que manipula la FE.

Ok, no habrá problemas y ajustes posteriores, y hacerlo de acuerdo que es bueno para obtener un simple, muestra, interfaz gráfica de usuario frente al cliente lo antes posible, ya que la punta del iceberg particular, es lo que la mayoría entiende más.

Sin embargo, yo 1) enfatizo que esto es solo una maqueta aproximada, para marsopas de discusión, y 2) deliberadamente lo hago feo, pero funcional , de modo que aquellos que no entienden pueden molestar y decirme que haga ese cuadro de entrada exactamente 400px de ancho y el fondo azul claro.

Creo que la mayoría de las respuestas aquí (y las he seguido) tienden a centrarse demasiado en el cliente, pero, desde un punto de vista puramente s / w, afirmo que no se puede diseñar un FE para manipular un BE sin primero diseñando ese BE.


"no se puede diseñar un FE para manipular un BE sin diseñar primero ese BE". Oh sí, puedes, eso se llama un "prototipo". Puede ser un primer paso valioso al iniciar un nuevo sistema.
sleske

¿Qué es la creación de prototipos? Sin guerra de llamas, simplemente apareció en mi cabeza. Entiendo lo que es un prototipo, pero tal vez porque vengo de un campo diferente, siempre lo veo como: obtener los requisitos, convertirlos en casos de uso y diseño. Si no tiene su d / b clavado, entonces hará mucho trabajo innecesario, así que primero resuelva eso y luego descubra cómo manipularlo (según los requisitos). YMMV ... continúa ...
Mawg

Podría decirse que no es blanco y negro, de lo contrario, la pregunta no se habría hecho, pero SER el primero, siempre, OMI. De hecho, estoy haciendo uno de esa manera en este momento para las clientas que solo tienen un vago sentimiento borroso en lugar de los requisitos (nunca debería haberlos tocado, pero esa es una historia completamente diferente :-)
Mawg

1
Mi experiencia es que los requisitos del usuario deben ser lo primero, y la arquitectura debe seguir. Pero, por supuesto, esto depende de los detalles técnicos, algunas cosas son difíciles de cambiar más adelante. Al menos es importante estar al tanto de las compensaciones.
sleske

Sospecho que podríamos estar diciendo lo mismo de diferentes maneras (+1)
Mawg
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.