# Reuniones de desarrollo
### Pedidos pendientes
- Evaluar librerías a actualizar.
- Escoger una librería para comparar deepEquals para evitar rendereos en react cuando el reducer genera un nuevo objeto pero que tenía el mismo contenido. (En la web, se debería exigir que los reducer no cambien el state si el contenido va a ser igual.) Y preparar un ejemplo, e incluir una propuesta para corroborar que el estandar se cumple (tipo de test que lo corrobore) [Librería](https://bit.dev/lodash/lodash/is-equal)
- Mockear getDocs para utilizarlos en los tests de actionError, actionReducer, genDerivatedAction y genConfirmAction
- Incluir en los tests del getDocs, un tests por cada acción que corrobore el resultado de getDocs.

## Jueves 22 de Julio
- Clarificación con respecto a los estándares: Props de componentes: ¿Si una prop que no recibo en todos los casos, no debiese ser requerido.?
- Nico:
- Expectativa: Que las funciones nunca sean definidas en un lugar donde se creen más de una vez (funciones dentro de funciones)
- Problema: hoy no es parte del estándar
- R. de C: No habíamos identificado su costo.
- Nico:
- Expectativas: Las funciones helpers debiesen puras
- Problema: No es parte del estándar
- R de C: No estabamos consciente del costo de tener funciones helpers no puras dentro de dominios distintos a los componentes.
- Jhon:
- Expectativas: Me gustaría tener disponibles funciones helpers para reutilizar en el updateDB
- Problema: Hoy tengo que copiar y pegar funciones
- R de C:

## Jueves 9 de Julio
- Nico:
- Expectativa: Disminuir la incertidumbre de los diseños de solución y que el rol del desarrollador solo consista en evaluar técnicamente los cambios en la implementación del código
- Síntomas:
- No tenemos categorías de conjuntos de acciones que nos ayuden a no olvidar acciones necesarias.
- Causalidad: Los desarrolladores hacen muchas cosas cuando diseñan = El diseño tiene muchos niveles de resolución.
- Hoy el equipo de diseño diseña con acciones distintas a las acciones que están implementadas en el código.
- El equipo de diseño no tiene accesible la información de cómo funciona la implementación
- Los desarrolladores deben:
- Preocuparse de extrapolar la implementación desde las imágenes y textos explicativos que define el equipo de diseño.
- Preocuparse de considerar todas las acciones que se ven involucradas en un feature (ya que se pueden generar bugs donde no consideramos un escenario)
- Causalidad: No existe un mapa común que permita diseñar y comprender las decisiones sobre: qué acciones están involucradas en un feature y cómo estas deben cambiar para habilitar un nuevo feature.
- Solución:
- Crear un excel que permita diseñar los primeros niveles de un feature, y garantizar tener un diseño completo antes de meterse al código a diseñar la implementación y estimarla.
- Cuándo se actualiza la versión del excel (al mismo tpo que se hace el merge)?
- Decisiones sobre el excel:
- [¿Cómo proyectamos el proceso ideal?](https://hackmd.io/Wf-PTwKsRWiNDk-Pf4sX9g)
- Equipo de diseño: ¿Podrían diseñar un feature utilizando el excel?
- ¿Podrían utilizar el excel para diseñar los dominios y subdominios a intervenir?
- ¿Qué podríamos reemplazar del trabajo que hoy se realiza en el changelog por el excel?
- ¿En qué parte del excel podríamos definir las acciones derivadas y de confirmación?
- ¿Qué nivel de detalle es necesario definir en las celdas del excel: descripción de las consecuencias?
- ¿Qué mejoras podría tener el excel para ser más útil para diseñar?
- Decisiones
- Categorías de conjuntos de acciones (Bundle de dependencias)
- Utilizar el excel para diseñar los primeros niveles del diseño
- Reuniones de asesorías para presentar un cambio
- Pedidos:
- Generar categorías "independientes" de acciones
- Repartir las acciones del excel para popularlo.
- Propuesta de excel del cron en el mismo nivel de descripción.
- Evaluar el "merge" de los excel.
- Anibal:
- Expectativa: Tener un proceso claro y específico para hacer diagnóstico que nos permita guardarlos para futuras referencias, compartirlos para que más de una persona pueda continuar un diagnóstico, y que sirva para justificar el tiempo dedicado.
- Realidad: No tenemos un protocolo de diagnóstico, por lo que la única expectativa actual es comprender la relación de causalidad.
- Causalidad: Nos falta profundizar en el proceso de diagnóstico para encontrar las etapas y las preguntas comunes a todos los diagnósticos.
- Solución:
- Proponer un protocolo y corroborar con nuestra experiencia su utilidad
- ¿Cuales son las etapas del diagnóstico?
- ¿Cuáles son los constructos que nos permiten comprender los diagnósticos?
- ¿Cuáles son las preguntas claves que nos permiten avanzar eficientemente en un diagnóstico?

- Jhon:
- Expectativa:
- Realidad:
- Causalidad:
- Solución:
- Crear un array de la forma `[ {type, value } ]` donde type indica lo que tiene value, por ejemplo, type: Array of strings y value seria `['a','b']` entonces que ese array tenga la mayoria de los casos de lo que probamos en los esquemas, entonces cuando hagamos un nuevo esquema lo usemos, como un base, y si necesitamos agregarle cosas usemos inmutability helper, y ya con el array listo usamos un forEach y dentro de el test() y asi considero que tendriamos menos codigo repetido, no serian tan largos los tests y probariamos muchas mas posibilidades

## Jueves 2 de Julio
- Nico:
- Problema: Las consecuencias generan transformaciones en un subconjunto de modelos, pero las queries llaman a todos los modelos requeridos por todas las funciones de consecuencia. ¿Cómo simplificamos/explicitamos esa relación para disminuir bugs y tiempo?
- ¿Debiesemos documentar mejor las deconstrucDocuments?
- Corroborar que las queries no se traen modelos innecesarios para las consecuencias
- ¿Debiesemos documentar exhaustivamente los keys de deconstructDocuments?
- ¿Debiesemos exigir un estándar en las condiciones de las consecuencias?
- ¿Debiesemos centralizar los estados de los modelos y reutilizarlos en el cron?
- Construir un array con una lista exahustiva de los posibles estados de los modelos. Por ej: Pedido: cancelado, vencido, con diseño, borrador, etc... Y exigir todas las condiciones en cada una de las funciones de consecuencia. [mucha incertidumbre]
- Nacho:
- Contexto:
- ¿Para qué revisamos?
- Aprender y no volver a cometer los mismos errores
- No "dejar pasar" omisiones
- Mejorar la calidad del código: ¿Cuánto tiempo le deberíamos dedicar? -> Genera un nuevo estándar de reivisión
- ¿Qué partes de la revisión se podrían automatizar?
- Automatización del reconocimiento explícito de las líneas no testeadas y editadas.
- Qué elementos revisamos:
- Omisiones
- Errores
- Oportunidades de mejora: Actualmente solo son abordados si hay rechazo.
- Mala documentación
- ¿Cómo revisamos, qué supuestos asumimos?
- Proceso de estimación: (incertidumbre)
- 200 líneas por hora.
- Identificar todos los sub dominios, y estimarlos desde el changelog.
- Proceso de revisión:
- Revisar código y comentar el PR.
- Escribir un comentario general sobre los elementos comentados que ameritan rechazo.
- ¿Cuales son los elementos/herramientas más eficientes para revisar?
- Coverage de tests.

- ¿Cuales son los elementos/herramientas más eficientes para aplicar cambios?
- Sugerencias de github para sugerir cambios.
-
- ¿Podríamos priorizar o separar las revisiones para poder hacer un deploy antes?
- ¿Hay alguna manera de corroborar "omisiones" los estándares para no requerir la revisión?
- Problema: ¿Cómo hacer más predecible la revisión de código? (incertidumbre y eficiencia)
- Causalidad:
-
- Solución:
- Compartir una heurística para estimar:
- Estimar promedio de revisión por elemento (Acción en la api, acción en la web, componente, ...)
- Estimar porcentaje del tiempo de implementación (Por ej: 30% del tiempo de implementación)

## Pedidos:
- Nico: Propuesta de etapas de la articulación del problema y cuál es su objetivo de esta etapa en la reunión.
- Nico: Automatización del reconocimiento explícito de las líneas no testeadas y editadas.
- ¿Evaluar qué estándar cuenta con evidencia empirica que no sea el código o que lo corroboró el desarrollador?
- Nico: Transformar los dominios de diseño en un checklist de implementación.

## Jueves 25 de Junio
- Nico
- Problema: Algunos archivos cargan muy lentamente, demoran en guardarse y por lo tanto aumentan el tiempo de implementación.
- Solución:
- Cada vez que se edite una acción en la api, se debe extraer a la carpeta Actions3S, en una carpeta con el nombre de la acción y escoger entre: un index.js que contenga las funciones (schema, getDocs, getErrors, actionReducer, genDerived, genConfirmation) que serán invocadas manualmente en su respectivo archivo. O una carpeta con un index que exponga las funciones que están definidas en: schema.js, getDocs.js, getErrors.js
- Los tests también deben extraerse, dejarlos dentro de la carpeta de acciones llamada __tests__ y definir un archivo por tipo de tests.
- Extraer las funciones de las acciones (schema, getDocs, getErrors, actionReducer, genDerived, genConfirmation) y dejarlas en una nueva librería llamada Actions3S, donde cada acción es una carpeta que contiene los archivos: schema.js, getDocs.js, getErrors.js ... y también deben moverse a esa carpeta los tests.
- Beneficios:
- Contras:
- Decisión:
- Pedir primer "ejemplo" y un "documento" (escoger formato) para anotar el diagnóstico de los tests que no cumplen con los estándares actuales.
- Estrategia:
- Separar las acciones en sus funciones y que cada desarrollador tome algunas (por ejemplo: lucho getDocs, nico getErrors...)
- Aprovecharemos de diagnosticar los tests que no están cumpliendo estándares actuales

- Nico:
- Problema: Incertidumbre sobre los atributos de los modelos en la api
- Solución:
- Crear generadores de modelos tipados
- Crear funciones que transformen el formato de los modelos ()
- ¿En cuántos lugar podríamos reutilizarlo?
- Sería útil un ejemplo que muestre los beneficios.
- Supuesto que se quieren corroborar:
- Cantidad de "transformaciones" actuales por cada modelo, dado que si tiene pocas, el valor de este proyecto disminuye.
- Criterios
- Eficiencia implementación
- Incertidumbre del tiempo de implementación
- Utilizarlos en las acciones refactorizadas
- Utilizarlos en los tests

- Nico:
- Problema: Los diseños de la api se deben realizar prospectando el código. Hay incertidumbre por parte del equipo de diseño, sobre los tiempos que implica el desarrollo y corroborarlo es "muy caro" debido a que hay que prospectar.
- Solución:
- Crear un excel que contenga la información de las acciones, los modelos, el cron, que nos permita diseñar los primeros niveles de la planificación.
- Template de las acciones.
- Excel con la información.
- Cuándo se actualiza la versión del excel (al mismo tpo que se hace el merge)
- Pedido:
- Propuesta de Formato de excel.

## Pedidos:
- Propuesta del formato del excel para diseñar.
- Pedir primer "ejemplo" y un "documento" (escoger formato) para anotar el diagnóstico de los tests que no cumplen con los estándares actuales.

## Jueves 18 de Junio
1. Nacho
- Problema: No hemos logrado ser suficientemente exhaustivos en la revisión de los escenarios dentro de nuestro proceso de desarrollo.
- Propuesta de solución
- Preguntas: ¿Cómo los test unitarios y de integración nos pueden ayudar a no tener que revisar cada una de las celdas de la propuesta?
- Criterios a considerar:
- Costo de mantención/actualización
- Claridad comunicacional
- Efectividad en las revisiones
- Exhaustividad
2. Lucho
- Problema: me rechazaron una entrega porque pasaba un objeto a los componentes hijos y no utilizaba ninguna key del objeto pero definí los propTypes con shape porque hice copy/paste de donde sí se usan las keys
- Solución: El estándard "Si recibo un objeto, pero solo lo entrego a mis hijos, lo defino como objeto" se debería tomar como un mínimo, ya que tomar a PropTypes.object como “mejor” que PropTypes.shape({…info}) no tiene sentido.
3. Nico
- Problema: Algunos archivos cargan muy lentamente, demoran en guardarse y por lo tanto aumentan el tiempo de implementación.
- Alternativas de solución:
- Extraer las funciones de las acciones (schema, getDocs, getErrors, actionReducer, genDerived, genConfirmation) y dejarlas en una nueva librería llamada Actions3S, donde cada acción es una carpeta que contiene los archivos: schema.js, getDocs.js, getErrors.js ... y también deben moverse a esa carpeta los tests.
- Beneficios:
- Script para crear nueva acción con opciones? ->
- Template.
- Contras:
- Decisión:
- hacer los imports a mano hasta que todas las acciones estén sobre el nuevo modelo, ahí invertir en un modelo para simplificar el actual getDocs, para que sea "automático".
- Separar los reducers "generales" en un conjunto de reducers ordenado por modelo. Ejemplo: ActionReducer () => actionReducerTask(), actionReducerCommitment() ... Y cada reducer implementaría el código de como esa acción afecta solamente a ese modelo. (como está en la web)
- Beneficios:
- Queda aislado el cambio que cada acción hace a cada modelo, por lo que se puede implementar y testear más rápidamente.
- Contras:
- Implementación costosa
- Redundancia de código ya que las mismas acciones pueden tener calculos similares que habría que reutilizar a través de acciones helpers.
- No disminuye tanto la cantidad de líneas como la otra opción.
4. ¿Cómo automatizamos los estándares?
- Soluciones
- Implementar githooks para evitar commitear con errores de lint.
- CI: tests
### Decisiones
- Si los "arreglos" toman menos de 20 min. No se rechaza el compromiso. A menos que necesites modificar código que se ejecuta.
- Si hay arreglos que toman menos de 20 min, debo asegurarme de que el receptor lo arregle antes de entregar mi compromiso de revisión.

## Jueves 11 de Junio
- Nacho:
- Problema: No hemos logrado ser suficientemente exhaustivos en la revisión de los escenarios dentro de nuestro proceso de desarrollo.
- Propuesta de solución
- Preguntas: ¿Cómo los test unitarios y de integración nos pueden ayudar a no tener que revisar cada una de las celdas de la propuesta?
- Criterios a considerar:
- Costo de mantención/actualización
- Claridad comunicacional
- Efectividad en las revisiones
- Exhaustividad
- Nico:
- Problema: Cumplir con los estándares de los tests
- Alternativas de solución
- Crear un checklist de los tests
- Definir el proceso de hacer tests
- Criterios considerados para la decisión:

- Decisiones:
- Pedidos:
## Jueves 4 de Junio
### Pedidos a realizar en equip:
- Nico: Utilizar los estándares del actionReducer y definir un checklist en el dominio general de los tests.
- Nico: Protocolo de Proceso de diagnóstico: Entender el estado en que está el c´ódigo es el objetivo del diagnóstico. (Qué supuestos valen la pena corroborar)
- Nacho: Definir las etapas y las decisiones del proceso de desarrollo: Incluir los escenarios definidos en decisiones. |=> clarificación => prospección (diagnóstico del estado actual de los dominios a intervenir) => Reunión de definición de la solución => diseño de solución
- Nico: Agregar en la metodología: no generar un timestamp desde el local para enviar a la api. Solo se puede utilizando la hora del servidor getStimatedServerTime.

0. Pato:
- Problema: Si hay muchos usuarios conectados después de calcular el cron, el servidor se congestiona.
- Alternativas de solución:

2. Reunión con aníbal:
- Problema: Al enviar una acción derivada a "muchos usuarios", todos los usuarios intentan comunicarse al mismo tiempo con el servidor. (kpi)
- Alternativas de solución:
- Enviar las acciones derivadas a los usuarios en vez de enviar la acción 'GET_UPDATES',

3. Jhon
- Problema:
- Alternativas de solución:
- En los docs, no usar en el objeto que se retorna alguna key que dependa de la información que se busca en los documentos, por ejemplo, si la acción recibe solo el id del request, se busca la información del receptor y el emisor, no se debe usar user[senderID] y user [receiverID] ya que no sabemos si el request existe en la BD.
- Criterios considerados para la decisión:
- Decisión:
4. Jhon:
- Problema:
-Solución: Pasar siempre los mismos atributos en el payload de las acciones de confirmación y derivadas, no usar spread para ver si se pasan o no, ya que genera confusión para entender cuando se recibe o no, además cuando no se manda llega undefined a la web, cosa que se debe evitar

3. Decisión: Generalizar los estándares de tests que tenemos para actionReducer, basándonos en la experiencia.
- Problema:
- Alternativas de solución:
- Los tests modificados deben estar de acuerdo al estándar.
- Usar sleep0 para mockear funciones asincronas.
- ...
- ¿En qué etapa se levanta la necesidad?: Etapa de prospección: Identificar deuda técnica (en este caso de los tests) -> Checklist de los tests.
- Criterios considerados para la decisión
- Menor tiempo para tener "fresco el código" para resolver deuda técnica.
- Dado el estado en que está el código, tanto así que hay mucha incertidumbre, esta deuda es requisito para entregar.
- Decisión
- En el escenario en que el emisor no "pueda" pagar la deuda técnica reconocida, el receptor crea un pedido con la jefatura de deuda técnica y mi jefatura debe asignarle el proyecto correcto y lo adjunta en la entrega del compromiso.
- En el escenario donde la deuda técnica no me permite realizar el pedido (es requisito para el pedido), debo pagar la deuda técnica en un pedido previo, antes de realizar el pedido.
- Crear checklist de tests, y definir los tests a priori:
- Estándares de tests...
- Heurística para saber cuántos tests amerita el subdominio:
- Definir los inputs que cambian del test.
- Pedidos:
- Nico: Utilizar los estándares del actionReducer y definir un checklist en el dominio general de los tests.
- Nico: Protocolo de Proceso de diagnóstico: Entender el estado en que está el código es el objetivo del diagnóstico. (Qué supuestos valen la pena corroborar)
- Nacho: Definir las etapas y las decisiones del proceso de desarrollo: Incluir los escenarios definidos en decisiones. |=> clarificación => prospección (diagnóstico del estado actual de los dominios a intervenir) => Reunión de definición de la solución => diseño de solución

5. Como disminuir el costo de la mantenibilidad de los tests
- Problema:
- Alternativas de solución

-5. Trabajar en dominios distintos
- Problema: Trabajo duplicado si dos personas trabajan al mismo tiempo en la misma deuda técnica.
- Alternativas de solución:
-
5. Pato:
- Problema: Tests de updateDB. Ahora tienen muy poca utilidad. Mejorar su standard o no testear. ¿Qué debiese corroborar los tests de updateDB?
- Solución :
6. - Problema:
- Solución: Que el formato de docs de getDocs para un elemento sea similar para distintas acciones:
- Por ejemplo para un compromiso, se usa:
- docs.priority.['id'] = compromiso
- docs.commitment.id = compromiso
- docs.commitment = compromiso

6. Pato:
-Problema: Falta incluir en el nombre de los argumentos del objeto que devuelve getDocs que tengan en cosinderación el formato.
- Solución:

7. Pato:
- Problema: Se generan fechas en la aplicación, enviando así el timezone del app a la api.
- Alternativas de Solución:
- No utilizar new Date() ya que hereda el timezone local?
- Decidir el estándar sobre cómo utilizar las fechas, y homologar todos los casos que existen.
8. Anibal:
- Problema: Cómo nos aseguramos de que la metodología apoya prácticamente el trabajo de desarrollo de los desarrolladores.
- Alternativas de solución

## Jueves 14 de Mayo

### Expectativas
- Presentación Miguel
- Poner al día al equipo: Bug con atrás y la importancia de getActionError. Pedido nico de formato de proceso.
- Presentación de jhon sobre mejoras en los props del componente RequestView. [foto](https://lh3.googleusercontent.com/-RfWbWwzavoU/Xr2Mp15b85I/AAAAAAAAGGA/JheMjXmG4A0P_UqRIYiedCmSKcNyl87fQCK8BGAsYHg/s0/captura.png)

- Mejora con respecto a las librerías:
- [¿devDependencies vs dependencies?](https://medium.com/@dylanavery720/npmmmm-1-dev-dependencies-dependencies-8931c2583b0c
)
- ¿Cuál es el propósito del file bootstrap/vendor.js?
- Presentación de Pato: pausas en el appstate y la api
- Muchachos algo que no especifique bien en la presentación de la nueva prop, es que creo que si debemos modificar alguna función helper cuyo valor dependa del sitio de donde se vea el RV utilicemos un switch, para que así vayamos mejorando el código, igual es una idea que si quieren la hablamos en la próxima reunión para definir si hace sentido meterlo como un estándar
https://lh3.googleusercontent.com/-RfWbWwzavoU/Xr2Mp15b85I/AAAAAAAAGGA/JheMjXmG4A0P_UqRIYiedCmSKcNyl87fQCK8BGAsYHg/s0/captura.png
## Decisiones

## Jueves 8 de Mayo
- Pato:
- Considerar revisiones de código como parte del desarrollo.
- ¿Qué nivel de detalle incluir en propTypes?
- Cada acción?
- Solamente atributos que se usan en ese componente?
- Solamente lo que usa el componente y todos los hijos?
- Solamente lo "required"?
- Todo el modelo?
- Generalizar los estándares de tests que tenemos para actionReducer
- Que el formato de docs de getDocs para un elemento sea similar para distintas acciones:
- Por ejemplo para un compromiso, se usa:
- docs.priority.id = compromiso
- docs.commitment.id = compromiso
- docs.commitment = compromiso
- ¿Los schemas de las acciones deben ser estrictos? Es decir, debe ser un error cuando la acción viene con atributos desconocidos?
- Tests de updateDB. Ahora tienen muy poca utilidad. Mejorar su standard o no testear.
- Revisar RV juntos:
- ¿Podemos reconocer malas prácticas, e incluirlas en la metodología sobre los propiedades que recibe el componente?
### Decisión
- Proptypes
- Si recibo un array, pero solo lo entrego a mis hijos, defino el tipo de sus elementos.
- Si recibo un objeto, pero solo lo entrego a mis hijos, lo defino como objeto
- Si recibo algo que uso, debe estar definido las key que se usan (Shape)
- Es requerido si el componente falla cuando no recibe esa prop.
## Jueves 30 de Abril
### Expectativas
- Presentación de pato de diseño de pausar perfiles [10 min explicación y 20 min. preguntas]
- Decisión: ¿Seguimos abriendo temas aunque no hayamos avanzado en los que ya definimos?
- Nacho: Si se van a hacer cambios que afecten la funcionalidad del código después de la revisión de usabilidad, hay que avisar para volver a revisar la usabilidad. ¿Qué cambios a partir de los estándares de desarrollo generan cambios en la usabilidad?

### Decisiones
- Pregunta: ¿Exigimos todos los tests de las acciones en el nuevo estandar o lo dejamos como una oportunidad de mejora que puede o no ser aprovechada?
- Si hay dos merge seguidos, no se puede subir a clientes antes de que se testee nuevamente la funcionalidad.
- Si hay cambios en la revisión del código, que puedan afectar la funcionalidad, debe ser revisada nuevamente.
## Jueves 23 de Abril
### Decisiones
- Si quiero presentar una conversación en la reunión necesito basarme en una imagen de código.
- Reunión sobre escenarios.
- Reunión sobre changelog.
### Expectativas
- Actualización periódica de rethinkDB, Node y librerías en web/api (30 min)
- Importancia: Estar al día con las ultimas versiones para tener las ultimas mejoras/bug fixes/features y para que adaptarse a posibles breaking changes en cambios de versiones grandes sea más fácil vs tener que hacer un pedido grande a Pato/Luis y arreglar todos los breaking changes cada cierto tiempo (meses)
- Node 13.12 o LTS?
- Docker image rethinkDB 2.4.2
- Frecuencia: Cada 2 semanas?
- Pedidos
- Listar librerías que pueden ser actualizadas.
- Con versión actual vs última versión
- Qué breaking changes tiene
- Tiempo estimado de actualización
- Mockear getDocs para utilizarlos en los tests de actionError, actionReducer, genDerivatedAction y genConfirmAction
- Incluir en los tests del getDocs, un tests por cada acción que corrobore el resultado de getDocs.
- Escenarios de Equip:
- Dado un feature que tiene X escenarios por ejemplo en RV, cuáles son los escenarios que se ven afectados por los del feature: un ejemplo es la cuestión de las reuniones. "Se puede cambiar de fecha y enviar propuesta de reunión al mismo tiempo?" "Que pasa si pido clarificación y reunión al mismo tiempo?", "Puedo enviar propuesta de reunión sin escuchar un audio", o sea es satisfacer las dudas del comportamiento de hoy + lo nuevo que está implementando. Estas son notas que Nacho trata de poner en Figma pero que no es completa de la parte de Nacho su respuesta es "si lo programaste y es un escenario que puede pasar te lo puedo cobrar", de nuestra parte es como que dude, no tengo en la cabeza todos los caminos que esto puede tomar, no hay una lista que se pueda chequear facil, y si no lo explicitas en lo que me pides es muy poco probable que lo aborde si no es obvio
- Servidores de staging no pueden tener más de 2 versiones de la app corriendo
- Usar $apply en update los menos posible, dado que se puede mutar el primer parámetro del update si no se tiene cuidado.
- [imagen](https://lh3.googleusercontent.com/-susKDbVqoGU/XqGVSgGKseI/AAAAAAAAEjA/YvZMLzbmN7U44BPK8f5iDpd34ciwCzJKACK8BGAsYHg/s0/2020-04-23.jpg)

## Jueves 16 de Abril
### Expectativas
- Tests de equip (1 hr)
- Inquietudes
- [¿Cómo revisamos los tests? -> test coverage](https://timdeschryver.dev/blog/reading-code-coverage)
- Generar funciones generadoras de objetos genéricos para testear en lib3S.
- Proceso:
- Crear nueva acción
- Definir
1. schema
2. getActionError
3. actionReducer
3.1 Definir tests
3.1.1 Corrobora las branches
3.1.2 Corrobora los inputs
3.1.3 ...
5. genDerived
6. genConfirm
7. getDocs
- Modificar una acción
- Incluir en los estándares
- nthCalledWith
- Dates3S.getDate en vez de new Date
- .mockName
- Pasar un objeto con todas las queries utilizadas por cada acción y checkear calls de todqas las queries e incluso las que no se deben llamar.
- Base/default test debe matchear con base/default data definida en describe principal.
- Proceso para definir un test: Corroborar las branches del actionReducer, la consecuencia de distintas fechas,y todos los inputs posibles (lo que permite el schema y getActionError)
- Mockear getDocs para utilizarlos en los tests de actionError, actionReducer, genDerivatedAction y genConfirmAction
- Comenzar a utilizar el Template de tests como estándar de desarrollo
- ¿Cómo consideramos el tiempo para el refactor de los tests que ya existen? (qué amerita rechazo?)
- ¿Cómo definimos el template?
- Cuales son los requisitos que necesitamos para asegurarnos de hacer tests completos, y no solo cumplir con nuestra entrega
- Cuál es el formato template vs doc vs snippets de diseño.
- Actualización periódica de rethinkDB, Node y librerías en web/api (30 min)
- Importancia: Estar al día con las ultimas versiones para tener las ultimas mejoras/bug fixes/features y para que adaptarse a posibles breaking changes en cambios de versiones grandes sea más fácil vs tener que hacer un pedido grande a Pato/Luis y arreglar todos los breaking changes cada cierto tiempo (meses)
- Node 13.12 o LTS?
- Docker image rethinkDB 2.4.2
- Frecuencia: Cada 2 semanas?
- Pedidos
- Listar librerías:
- Con versión actual vs última versión
- Qué breaking changes tiene
- Tiempo estimado de actualización
- Fraccionar en tiempo real un nuevo feature (30 min)
-
### Decisiones
- Los pedidos deben tener la versión del documento "Estándares de desarrollo" a utilizar para la revisión.
- Tener reunión para la construcción del estándar de los tests del actionreducer: Definir las reglas implementadas en el template, evaluando el costo de implementar.
### Pedidos
- Pedido de merge del template a nico

## Jueves 9 de Abril
## Expectativas
- Estándares de los tests de action reducer -> templates
- mock de funciones asíncronas: mocks que se comporten como una función asíncrona (pato)
- Proceso para incluir prácticas a la metodología
- Mala práctica de espacios vacíos? https://github.com/alliende/equip_web/pull/1019#discussion_r400436756
- Malas prácticas del frontend https://hackmd.io/ijrxWuF4TJSiUlf9PPosFA?view
- schemas y action error: conciencia de por qué es importante ese checkeo y qué es lo que hay que checkear (pato)
- que en el objeto docs que usamos en los tests de getActionError, actionReducer, genDerivatedAction y genConfirmAction usemos lo mismo que obtenemos en getDocs, dejar de usar docs: { ...docs } (Jhon)
- Reunión previa a rechazos para corroborar que se rechazan por los estándares. (Jhon)

## Decisones
- Generalizar las reglas de los tests, no solo del action reducer, sino que afecte a todos.
- ¿Es necesario una reunión para alinearnos en que el rechazo es efectivamente por que no cumplí un estándar? -> Repercutir en re-articular el estándar.
- Reuniones de 10min, agendadas. opti de pato, lucho css.

## Pedidos
- Pedir templates de test a pato para revisarlo para la siguiente reunión. REQ: probar con una acción.
- Pedir a pato que defina la función helper para definir mocks async en lib3s
- Pedir a lucho una alternativa de resolución del problema de jhon, para evaluar los costos y beneficios de este patrón. https://github.com/alliende/equip_web/pull/1019#discussion_r400436756
- Nico: Generar mejores constructos para definir los escenarios.
## Jueves 2 de Abril
### ¿Qué es lo que más les frustra del proceso de desarrollar en equip?
1. Escenarios del requestView: Los escenarios estan desagregados en variables pero no existe una abstracción que los ordene y simplifique su acceso, por lo que cada cambia potencialemente genera bugs.
- Función "reducer" que permita conocer los estados posibles de un componente.
- Utilizar herencia en los componentes
2. Me cuesta mucho ver las consecuencias de los cambios que estoy realizando en los indicadores.
3. El gran tamaño de los pedidos, y la dificultad de estimarlos correctamente
- Cuando un pedido supere una cantidad de horas, subdividirlo internamente creando hitos
- Mejorar el proceso de desarrollo: Comenzar por los componentes, luego por las acciones, corroborar y seguir con los siguientes componentes y así en adelante.
4. Eficiencia del código
- Aumentar el conocimiento de la complejidad de el código, generar buenas prácticas de desarrollo.
5. Claridad sobre los atributos de los modelos
- typescript
6. Los tests utilizan los modelos incompletos, y no son actualizados posteriormente.

### [Presentación de optimización](https://docs.google.com/presentation/d/1q-wcrfXrkgZ6LFrx2z5h-y7kNkALDPtuFWFf68wFoiM/edit?usp=sharing)
1. **Pedido:** Evaluar el tradeoff (pros y contras) de incluir la regla de utilizar maps al querer buscar elementos en un array cuando no conocemos la cantidad de elementos a buscar. (pedido en borradores de nico a pato)
2. **Pedido:** Definir el formato de las buenas prácticas para incluirlo en la metodología (pedido compartido con nacho y nico)
3. **Decisión:** Preguntarle a nico cada vez que queramos incluir un indice en una tabla de la BD.

### Changelog
1. **Decisión:** No incluir el css a menos de que se estén modificando y sea su no comunicación pueda generar bugs
2. Pedir descripción sucinta a los diseñadores del feature para agregarla en el changelog
3. Sería interesante distinguir entre los estándares que afectan la ejecución del código con los estándares que generan deuda técnica.

### Inquietudes pendientes
- Estandares de los tests de actionreducer
- Template de los tests
- Definir el proceso de desarrollo comenzando por la parte gráfica y subdivididos en pedidos. (pedido compartido con nacho y nico)
- [Buenas prácticas en el frontEnd](https://hackmd.io/ijrxWuF4TJSiUlf9PPosFA?view)
- [Mala práctica en front-end](https://github.com/alliende/equip_web/pull/1019#discussion_r400436756)