Tácticas para confinar modificaciones

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.

Andrés Orozco

Lamentablemente así es la Ing. en software, es por eso que a muchos no les gusta y la mejor forma de aprenderlo es ya en equipos de trabajo, por eso se paga muy bien a las personas que tienen amplia experiencia en esto.

Eduardo Hidalgo Díaz Rugama

100% de acuerdo con @Andrés Orozco. También hay que tomar en cuenta que en Platzi los cursos no son extensivos, son intensivos. Son rápidos, efectivos y simples, no extensos y abarcativos. Es parte del formato de Platzi.

Carlos Eduardo Diaz Polanco

CONFINAR MODIFICACIONES
Aunque no existe necesariamente una relación precisa entre la cantidad de módulos afectados por un conjunto de cambios y el costo de implementar dichos 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 previstos 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 afectados directamente por él. Por ejemplo, si se modifica el módulo A para lograr una modificación particular, entonces el módulo B se cambia solo por el cambio al módulo A. B debe modificarse porque depende, en cierto sentido, de A.
DIFERIR ENLACE
Aplazar el tiempo de enlace es compatible con los escenarios previamente mencionados a costa de requerir infraestructura adicional para admitir el enlace tardío

Abril Darynka Tapia Sosa

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

Carlos Andres Castañeda Osorio

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

Reinaldo Mendoza

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

Roberto Dopazo

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.

Antonio Rafael González Ferrer

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.

Christian Gómez

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:

Coherencia Semántica. 1.1 Abstraer servicios comunes
Limitar Opciones
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.

Julian Parra

Pregunta, nunca he tenido muy claro el concepto que se refiere a Alta cohesión, bajo acoplamiento

Wilson Andrey Cárdenas Henao

Cohesión: La cohesión es la medida en la que un componente se dedica a realizar solo la tarea para la cual fue creado, delegando las tareas complementarias a otros componentes. (Una clase debe de hacer lo que respecta a su entidad, y no hacer acciones que involucren a otra clase ó entidad).

Acoplamiento: El acoplamiento es la medida en que los cambios de un componente tiende a necesitar cambios de otro componente. (Cuando modificamos los atributos de una clase, se tienen que modificar los atributos de otra clase.)
De ahi que debemos de buscar siempre una ALTA COHESIÓN y BAJO ACOPLAMIENTO.

Antonio Madrid

Una forma corta para recordarlo:
Alta cohesion: Pocas responsabildades, muy relacionadas.
Bajo acoplamiento: Poca dependencia entre componentes.

María Victoria Argañaras

Hace 4 años

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!!!

María Victoria Argañaras

Hace 4 años

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.

Cristian Camilo Cortes Ortiz

Hace 4 años

Gracias por tu aporte.

Juan Carlos Ortiz Romero

Hace 5 años

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.

Irving Juárez

Hace 2 años

Anticipar cambios en mi experienca es una de las peores cosas que se pueden hacer. Si algo no se necesita implementar ahora mismo en el sistema, incluso aunque 'probablemente' se use en el futuro, no se debe agregar.

Muchas veces se cambia de prioridad en la empresa y un feature que parecia probable, se vuelve solo codigo que estorba y nunca se uso. Y lo peor de todo, si en algun momento se vuelve a retomar ese feature, se hace desde cero, ya que nadie se acordo que ya habia un avance de eso

Francisco Ruiz Lezcano