Escenarios: Mantenibilidad

Mantenibilidad
En este caso el estimulo es un pedido de cambio (llega un requerimiento y tenemos que cambiar el sistema).

Familias de tácticas:
1.- Confinar modificaciones. Las tácticas van a intentar trabajar sobre nuestros módulos para que cada cambio que nos pidan esté confinado a sólo un módulo. Cuando logramos esto logramos que las dependencias entre módulos sean más ligeras y el cambio que nos proponen no afecte a muchas partes del sistema.
a) Coherencia semántica. Habla de la relación entre las responsabilidades de los módulos. Hablamos de acoplamiento y cohesión. Si logramos encontrar la cohesión en un módulo entonces vamos a poder hacer que ese módulo sea más mantenible. De lo contrario es posible que ese módulo cambie por diferentes razones.

Abstraer servicios comunes. Cuando encontramos que la aplicación tiene servicios más genéricos de no necesario podemos abstraerlos a un punto común y que las dependencias vayan de los módulos cohesivos a un servicio o modulo externo.

b) Generalizar. Al generalizar un módulo podemos separar lo específico de lo genérico.
c) Limitar opciones disponibles. Limitar el rango de modificación nos ayuda a que sea más mantenible.
d) Anticipar cambios. Prepararnos para algún cambio que nosotros mismo sepamos que se deberá de dar en el futuro tomando en cuenta una estrategia sobre como incorporar el nuevo cambio. Los patrones de diseño suelen estar orientados a esto (Patrón estrategia).

2.- Prevenir efectos domino. Trabaja estrictamente con las dependencias, es decir cuando podemos detectar que un cambio generaría problemas en otros módulos o dependencias.

3.- Diferir enlace. Como podemos hacer para que un cambio en el código no requiera desplegar toda la aplicación.

Demasiada teoría hasta el momento a mi punto de vista, hubiera estado bien tener más ejemplos reales o en una pizarra para explicar de forma más dinámica.

Para extender un poco el tema de Acomplamiento / Cohesión:

Escenario: Mantenibilidad

Estimulo: Pedido de cambio / Nuevo requerimiento
Tácticas para que la respuesta sea que se pudo hacer el cambio, probarlo y desplegarlo
Familias de tácticas

• Confinar modificaciones
  • Coherencia semántica
    ** Abstraer servicios comunes
  • Generalizar
  • Limitar las opciones disponibles
  • Anticipar los cambios
• Prevenir efectos domino
• Diferir enlace

Apuntes:

Mantenibilidad

Confinar modificaciones. Las tácticas van a intentar trabajar sobre nuestros módulos para que cada cambio que nos pidan esté confinado a sólo un módulo. Cuando logramos esto logramos que las dependencias entre módulos sean más ligeras y el cambio que nos proponen no afecte a muchas partes del sistema.
• Coherencia semántica. Habla de la relación entre las responsabilidades de los módulos. Hablamos de acoplamiento y cohesión. Si logramos encontrar la cohesión en un módulo entonces vamos a poder hacer que ese módulo sea más mantenible. De lo contrario es posible que ese módulo cambie por diferentes razones.
o Abstraer servicios comunes.
• Generalizar. Al generalizar un módulo podemos separar lo específico de lo genérico. • Limitar opciones disponibles. Limitar el rango de modificación nos ayuda a que sea más mantenible.
• Anticipar cambios.

Escenarios: Mantenibilidad

El estimulo es un pedido de cambio. dentro de la mantenibilidad hay tres familias de tácticas:

• Confinar Modificaciones: Van a trabajar sobre nuestros módulos para que cada cambio solo se limite a un modulo. esto hace que las dependencias entre módulos sean más ligeras.
  Tácticas:

1. Coherencia Semántica.
   1.1 Abstraer servicios comunes
2. Limitar Opciones
3. Anticipar Cambios

• Prevenir efecto domino: Trabaja estrictamente con las dependencias, se trata de conocer cuando puede detectar cuando algún cambio generaría problemas en uno o varios módulos o dependencias.
• Diferir enlace: Se trata de como hacer que algún cambio en el código no requiera de desplegar toda la aplicación entera.

Ponerle Profesional al curso, y no considerar un estudio exhaustivo fue un error, como se puede observar para mi, cada clase explicada, requiere quizás hasta una hora entera viendo ejemplos y probando punto a punto lo explicado.

Demasiada teoría, solo estoy tomando notas porque se que lo puedo necesitar, la información tiene valor, lo puedo ver pero creo que podrían haber recomendado leer un pdf y tendría el mismo resultado que ver los videos

De verdad que clase a clase entiendo un poquito mas por que mi tech leader o el CTO de donde trabajo toman las decisiones que toman, entiendo la teoría destrás de esas decisiones, y ahora puedo yo empezar a tomar mejores decisiones para mis contribuciones al proyecto. Muy potente!!!

Este curso esta tremendo, super completo, pero no es para personas que no tengan experiencia trabajando en la industria.

Todos los conceptos se aplican directamente a situaciones a resolver día a día en el trabajo del programador. Incluso a mi siendo junior me estan sirviendo los conceptos para plantear mejor mis propuestas e ideas con mis colegas.

Así que si sienten que no pueden bajar la teoría a la práctica les recomiendo que retomen el curso cuando ya tengan esa experiencia porque si no es dificil que puedan pensar en situaciones donde se aplica todo lo que dice el profe.

Familias de tácticas:
1.- Confinar modificaciones. Las tácticas van a intentar trabajar sobre nuestros módulos para que cada cambio que nos pidan esté confinado a sólo un módulo. Cuando logramos esto logramos que las dependencias entre módulos sean más ligeras y el cambio que nos proponen no afecte a muchas partes del sistema.
a) Coherencia semántica. Habla de la relación entre las responsabilidades de los módulos. Hablamos de acoplamiento y cohesión. Si logramos encontrar la cohesión en un módulo entonces vamos a poder hacer que ese módulo sea más mantenible. De lo contrario es posible que ese módulo cambie por diferentes razones.
Abstraer servicios comunes. Cuando encontramos que la aplicación tiene servicios más genéricos de no necesario podemos abstraerlos a un punto común y que las dependencias vayan de los módulos cohesivos a un servicio o modulo externo.
b) Generalizar. Al generalizar un módulo podemos separar lo específico de lo genérico.
c) Limitar opciones disponibles. Limitar el rango de modificación nos ayuda a que sea más mantenible.
d) Anticipar cambios. Prepararnos para algún cambio que nosotros mismo sepamos que se deberá de dar en el futuro tomando en cuenta una estrategia sobre como incorporar el nuevo cambio. Los patrones de diseño suelen estar orientados a esto (Patrón estrategia).
2.- Prevenir efectos domino. Trabaja estrictamente con las dependencias, es decir cuando podemos detectar que un cambio generaría problemas en otros módulos o dependencias.
3.- Diferir enlace. Como podemos hacer para que un cambio en el código no requiera desplegar toda la aplicación.

🤖
Escenario Mantenibilidad
En este caso el estimulo es un pedido de cambio (llega un requerimiento y tenemos que cambiar el sistema).

• Confinar modificaciones: Aunque no necesariamente existe una relación precisa entre el número de módulos afectados por un conjunto de cambios y el costo de implementar esos cambios, restringir las modificaciones a un pequeño conjunto de módulos generalmente reducirá el costo. El objetivo de las tácticas en este conjunto es asignar responsabilidades a los módulos durante el diseño de modo que los cambios anticipados tengan un alcance limitado.
• Prevenir efectos dominó: Un efecto dominó de una modificación es la necesidad de realizar cambios en los módulos que no se ven directamente afectados por él. Por ejemplo, si el módulo A se cambia para lograr una modificación particular, entonces el módulo B se cambia solo debido al cambio al módulo A. B tiene que modificarse porque depende, en cierto sentido, de A.
• Diferir enlace: Las dos categorías tácticas que hemos discutido hasta ahora están diseñadas para minimizar la cantidad de módulos que requieren cambios para implementar modificaciones. Nuestros escenarios de modificabilidad incluyen dos elementos que no se satisfacen al reducir la cantidad de módulos que se van a cambiar: el tiempo de implementación y permitir que los no desarrolladores realicen cambios. Aplazar el tiempo de enlace es compatible con ambos escenarios a costa de requerir infraestructura adicional para soportar el enlace tardío.