Si el código front-end de un sitio web es desordenado, ¿afectará eso a la velocidad y eficiencia del codificador back-end?

TL; DR: sin daño, sin falta. Sin embargo, “No dañar” es bastante difícil de garantizar por completo.

Depende de lo que hagan los codificadores “back-end” y de cuánto tengan que interactuar con los codificadores “front-end”. También depende de lo que significa “desordenado”.

Asumiré que te refieres a desarrolladores del lado del cliente y desarrolladores del lado del servidor, ya que esto es lo que más comúnmente escuché que la gente llama “back-end” y “front-end” (aunque el lado del servidor puede tener un back-end y un front-end, también).

También supongo que se refiere a cualquier tipo de “desorden” en ese código, que podría ralentizar la implementación o el diseño o la depuración o implementación, si alguien no puede manejar ese desorden a toda velocidad:

* Si el código de front-end es más lento para depurar o implementar, entonces sí, afectará a los codificadores de back-end.
* Si el desarrollo front-end se ralentiza y, por lo tanto, el cuello de botella se desarrolla (ya sea por demasiadas personas que causan un impuesto a la comunicación o por muy poco trabajo para lograr una función de arriba hacia abajo tan rápido como pueden trabajar los desarrolladores de back-end) , entonces sí, les afectará.
* Si hay más desarrolladores de clientes con un salario como resultado, y esto afecta la tasa de quema y, por lo tanto, la vida útil de la empresa antes de que la empresa tenga éxito o muera, entonces sí, los afecta.
* Si no hay un gran contrato entre las dos áreas de código, lo que hace que los desarrolladores de back-end tengan que hacer cambios al final del ciclo de desarrollo (¿sprint?), O causar un mayor flujo en sus requisitos debido al front-end el desarrollador no pudo entender cómo debería ser esa interfaz desde el principio, esto los afectará.
* Si alguno de esos desarrolladores de back-end es full-stack (desarrollo del lado del cliente y del servidor), o podría ser full-stack, entonces sí, los afectará.
* Si los desarrolladores de back-end alguna vez tienen que ejecutar y depurar el front-end porque las prácticas en su empresa dictan que su trabajo no se realiza hasta que hayan cubierto algunas pruebas de integración de los cambios que han realizado, entonces sí, afectará ellos.
* Si el equipo alguna vez es regañado en su totalidad debido a un problema en el código enviado que tiene una causa raíz de que el código de front-end es “desordenado”, entonces sí, los codificadores de back-end se ven afectados.
* Si los desarrolladores front-end o back-end están gruñones porque el código es desordenado (revisiones de código, o simplemente por ideales), entonces sí, los codificadores de back-end se ven afectados.

Si tiene contratos sólidos que están bien pensados, y este pensamiento no se ralentiza con el código “desordenado”, y el desarrollador de back-end nunca tiene que ejecutar el código de front-end, y sus desarrolladores de front-end nunca se ralentizan porque el código es desordenado, y nunca contratas desarrolladores front-end o full stack que se ralentizan por el desorden, y nunca tienes errores causados ​​por el desorden, y tu equipo nunca se mete en problemas con la administración debido a el desorden, entonces podría no afectar a los desarrolladores de back-end. Es bastante difícil asegurarse de que no haya ningún efecto.

En la mayoría de los casos, probablemente respondería que no. Pero he visto problemas causados ​​por un error en el front-end que causan problemas en el backend debido a un código mal escrito.

Recuerdo que uno de esos proyectos era una pieza de código de seguimiento que notificaría al servidor cada pocos segundos sobre el estado del front-end (esto era antes de WebSockets). Alguien perdió un cero en el setInterval y no se notó de inmediato. El sitio se lanzó y fue popular en su primer día de lanzamiento. En lugar de establecer un valor de 10000 (10 segundos), se estableció un valor de 1000 (1 segundo). Entonces, lo que sucedió fue el código front-end DDoS’d del sitio.

Si bien no redujo la eficiencia de los desarrolladores de back-end, derribó el sitio y causó algunos dolores de cabeza mientras que los desarrolladores de back-end revisaron los registros y tuvieron que solucionar el problema.

Depende de qué parte del código del frente esté haciendo con el sitio web. Si se trata simplemente de un diseño simple y genera lo que se arroja el back-end, entonces es rápido. Si la parte “desordenada” del código tiene que lidiar con la lógica agregada del back-end al front-end, entonces sí, la velocidad y la eficiencia se verán afectadas.

Simplemente demuestra que si toda la lógica y los procesos se realizan en el lado del servidor en lugar del lado del cliente, tendría un sitio web más rápido. Esto se debe a que la velocidad de procesamiento solo dependerá de la velocidad del servidor. Si la lógica está en el front-end, tomará la velocidad del navegador del lado del cliente.

Por lo tanto, si hay más algoritmo y lógica al frente = menos velocidad y eficiencia. Si todo el algoritmo y la lógica están en la parte posterior = más velocidad y eficiencia.

Pero es posible que deba preguntarse si estas lógicas y algoritmos deben usarse con frecuencia o no.

Puede, porque el codificador de fondo a menudo está profundamente involucrado en la integración del código frontend en el software del lado del servidor (gestión de contenido / plantillas / API de JavaScript). HTML mal escrito, a menudo generado por un editor WYSIWYG como Dreamweaver, puede ser una pesadilla absoluta para integrarse en el backend.

En un momento estaba trabajando en una tienda de diseño web que tenía un excelente diseñador con poca experiencia escribiendo HTML y CSS directamente; En el transcurso de un par de años, me hice cargo de la mayor parte de la implementación y le pedí que solo me diera sus diseños de Photoshop en lugar de usar PS & DW para generar el HTML. Fue más rápido, más fácil y más limpio hacerlo a mano que manipular el código generado por la máquina. Durante el mismo tiempo, comencé a entrenarlo para que hiciera algo de HTML y CSS él mismo, pero se fue a enseñar diseño antes de llegar al punto de que podía confiar en él para hacer todo el marcado él mismo.

Probablemente no mucho.

Hay dos posibles problemas;

* Solicitudes interrumpidas, generalmente con “nulo” o “indefinido” como algunos parámetros. La gestión normal de errores debería cubrir esto fácilmente.

* Más solicitudes de las necesarias debido al almacenamiento en caché roto o inexistente en el lado del cliente y los ciclos de vida de la solicitud rota. El back-end podría mitigar el impacto con algo de caché por lo general.

Pero, en general, si el front-end es difícil de mantener y leer, no debería hacer que la vida de los desarrolladores de back-end sea mucho más difícil. Deben ser capaces de construir una API sólida que sea independiente del front end.

Puede, pero una preocupación mayor es que el front end será más costoso de mantener en el futuro.

También puede afectar el SEO y, en algunas situaciones, el tiempo de carga de la página puede aumentar.