Este mes vamos a aplicar algunos de los conocimientos adquiridos en anteriores meetups y llevarlos a la práctica, y para ello hemos pensado en hacerlo con una sesión de mob programming (que será la primera vez que lo hacemos en el grupo de PHPMad).
¿Qué es mob programming?
Mob programming es una estrategia de programación en la que un grupo de desarrolladores trabajan sobre una única tarea al mismo tiempo, en el mismo ordenador y, sobre todo, colaborando entre ellos.
¿ Objetivo del meetup ?
Refactorizar un código legacy cuya lógica de negocio está acoplada al framework y sin testear, como muchos nos encontramos en nuestros proyectos.
Vamos a testear dicho código y desacoplar la lógica de negocio de la infraestructura, para conseguir un código más legible, mantenible y fácil de extender con funcionalidades nuevas.
Aplicaremos la pirámide de tests y principios SOLID.
investigación de los Avances tecnológicos del siglo XXI
Mob programming: Refactorización de código legacy
1. Mob programming:
Refactorización de código legacy
Maikel González Baile
Software Engineer @Ontruck
@mgonzalezbaile
Luis Matesanz Barroso
CTO @Gstock
@sitocasla
#phpmadmobprogramming
2. ¿Por qué no una charla al uso?
● Charlas teóricas pero poco debate en posibles implementaciones.
● Mob programming, live coding, kata ...
● Serie de workshops para intentar llegar desde una aplicación con código
legacy a una aplicación distribuida y escalable.
3. Code Review Marketplace
Hemos creado un Marketplace en el que un
usuario puede crear una Pull Request y solicitar
su revisión a cualquier revisor registrado en la
plataforma.
El sistema calculará la cuota que el creador de
la PR debe pagar para ver las revisiones.
Casos de uso:
● Crear Pull Request:
○ Código, Revisores, Fecha de Revisión
● Calcular cuota
○ #LOC, Fecha de Revisión, #Revisores
● Enviar notificación a revisores
● Cambiar el código de la Pull Request
5. Show me the code
1. No sigue principios SOLID:
a. SRP: Crear PR + Persistir + API en una
misma función.
b. OCP: “nueva regla de negocio, notificar al
creador del PR”. ¿Podemos extender el
código sin modificarlo?
c. ISP: N/A No hay interfaces
d. DIP: N/A Acoplamiento hacia clases
concretas, no abstracciones.
2. Testeo complicado, lógica en el controller
y pre-persist.
3. Legibilidad del código compleja:
a. Cálculo del quote en un subscriber
b. Creación de la PR en el Controller
c. Envío de notificaciones en la Entidad
4. Escalar la aplicación. Por ejemplo: “nueva
regla de negocio, tu primera PR es gratis”
8. "A good architect maximizes the number
of decisions not made"
Uncle Bob - Clean Architecture
9. Retrospectiva
¿ Que mejoras has visto ?
¿ Es más fácil este dicho código ?
¿ Es más legible el código ?
Feedback:
https://es.surveymonkey.com/r/XJ92FPJ
