Add separation of concern

[icarito]

@Freihart512 observa un vacío en este punto, que lleva a una incorrecta o deficiente modularización / componentización - podríamos explicitar este principio desde el principio del bootcamp e incluir preguntas en el PF?

https://en.wikipedia.org/wiki/Separation_of_concerns

[icarito]

La idea es empezar a abrir una conversación y ver como promovemos conocimiento de este principio.

[unjust]

Creo si. Pero no creo si pertenece a este grupo de objetivos tal cual, no se si un proyecto ahora usa front-end-web-dev

[unjust]

separation-of-concerns para yml
Me gustaría escuchar que opinan otros en eso - específicamente cómo evaluamos en un project feedback o test.

[Freihart512]

yo exponía este tema particularmente en el proyecto de social network y posteriores porque a las estudiantes les estamos diciendo que deben tener en un archivo todo lo de Firebase (es decir, crear un servicio) con la premisa de que sera mas facil testar pero esto nos este generando muchos problemas porque el resultado de eso es ver test de una linea que no hacen realmente nada

no se esta tomando en cuenta el potencial de tener un "servicio" y cual es su función dentro del proyecto, esto tiene repercusiones en próximos proyectos por ejemplo

MDlinks: donde deberían aplicar el mismo concepto aprendido (servicio) para crear su fuente de datos es decir todo lo relacionado con la lectura de archivos

React/Angular: vemos que nunca comprendieron ese concepto y no son capaces de separar el consumo del api de los componentes lo cual complica hacer testing y demas en particular en angular donde se usa mas obiamente el concepto de "service" les esta costando mucho trabajo cuando al final es algo que debieron al menos haber repetido su uso en 3 proyectos diferentes

entiendo que hablar de arquitectura no esta dentro del scope pero creo que al menos este tema en particular tiene mucho impacto en la mitad del bootcamp por lo que seria interesnate que lo charlaramos

[Freihart512]

De igual manera no sé si aquí mismo deberíamos tocar este tema, pero está la parte de componentes es un tema que repetimos mucho, pero creo que las estudiantes no lo tienen claro es decir si vemos sus proyectos de social network y de la última esta Angular/React no hay componentes hay páginas es decir se crean un componente por página y ahí meten todo lo cual complica el mapa mental de la estudiante porque está pensando en un problema gigante en vez de muchos pequeños y esto es algo que podríamos tal vez empezar a trabajar tal vez de data lovers donde podemos trabajar con una carta un componente de filtros o similares para que desde temprano en el bootcamp el concepto de componente lo vayan teniendo claro asi cuando lleguemos a angular o react sea un poco mas sencillo y enfocarnos mas en el flujo de comunicacion entre los componentes

no se que opinen @icarito @mfdebian

[mfdebian]

Estoy de acuerdo con agregar la separación de intereses como un OA al bootcamp, creo que es de esos OAs "invisibles", de los que todxs lxs coaches tratan de traspasarle a las estudiantes, pero no está presente como un Objetivo de Aprendizaje de sus proyectos; Creo que al agregarlo también daría pié a que pudiéramos tener otra conversa sobre la diferencia entre un component y una page, aunque esa quizás es un poquito más difícil de generar una única definición compartida entre todxs los Bootcamps o incluso entre distintos frameworks con distintas filosofías, pero en el ejemplo de Angular y React están más claros.

[mfdebian]

Suggested change

	- separation of concerns
	- separation-of-concerns

Ese pequeño cambio nomas habría que hacerle, pero además habría que agregar a los archivos de internacionalización de OAs un título y (ojalá) un link que explique el concepto, tanto en ES como PT!

Con eso estamos 😏

¡Mil gracias @icarito y @Freihart512 ! 🥳

[unjust]

@icarito @Freihart512 Creo que deberiamos abrir esta conversacion en #coaches-laboratoria en slack y ver que opinan.