Este documento presenta un resumen de las diferentes soluciones al problema de crear una red social simple utilizando las metodologías Ágiles de Londres, Chicago y Buenos Aires. Se describen los enfoques de diseño y pruebas de cada solución, y se analizan sus ventajas y desventajas frente a cambios y extensibilidad. La solución de Buenos Aires utiliza un enfoque middle-out y TDD, resultando en un modelo más simple con menos clases, líneas de código y casos sin probar.

1. Ágiles 2020
Buenos Aires vs. (London vs. Chicago)

2. Jazmin Alvarez Vico
➢ Programadora, docente y estudiante de Ciencias de la
Computación en FCEyN de la UBA.
➢ Feminista. Parte de @MujeresDelDC.
➢ Ayudante en las materias de Ingeniería de Software I y
Didáctica de la Computación.
➢ Docente de tecnología en el Bachillerato Popular para
adultes Chilavert.
➢ La pueden seguir en tw: @Jazz_vico y ig: @jaz.vico

3. ➢ Socio Fundador de 10Pines
➢ Socio Fundador de FAST
➢ Profesor de FCEyN UBA
➢ Director Adjunto del Depto. de
Computación de FCEyN UBA
...
➢ Sobre todo, programador apasionado
Hernán Wilkinson

4. Introducción

5. ¿Qué es ...?

7. ¿Qué es
Buenos Aires?

8. https://alagorra.10pines.com

9. Episodios
Episodios de Buenos Aires vs. …
Aún faltan varios donde veremos
persistencia y otras cosas
https://alagorra.10pines.com

10. El nombre “Buenos Aires” es solo por una cuestión
de marketing
No podemos arrojarnos el hecho de que “todo
Buenos Aires” programe de la forma que
mostraremos
Words of Caution

11. El objetivo no es generar una nueva “grieta” sino
hacer una análisis crítico de las distintas técnicas
para sacar conclusiones y mejorar nuestra forma
de desarrollar
Words of Caution

12. Descripción del Problema

13. ➢ Registrar un nuevo usuario
➢ Loguearse
➢ Crear “posts” (publicaciones)
○ Palabras “inapropiadas” como elephant, ice cream y orange
➢ Obtener los posts de un usuario (timeline)
➢ Seguir a otro usuario
➢ Obtener los posts propios y de los que sigo (wall)
➢ Obtener todos los usuarios
➢ Obtener los usuarios seguidos por uno en particular
Descripción del Problema

14. Ejemplo: Registrar nuevo usuario

15. ➢ Descripción de la API
➢ Tests de Aceptación
➢ User Interface (No provista pero usada en los videos)
El ejercicio viene con

16. Solución London

17. Esquema de solución

18. Hacer fallar el primer test

19. Hacer fallar el primer test

20. Hacer pasar el primer test

21. ➢ Proceso Outside-In
➢ Diseño orientado al problema computable, no al
negocio
➢ Organización del proyecto en base al problema
computable
➢ Uso de DTOs para comunicación entre “capas”
➢ Uso de ids en vez de objetos
➢ Se expone la password a objetos externos
Conclusiones - Diseño

22. ➢ Tests de APIs de caja blanca
○ Opinión de Hernán: Solo los podes hacer así si ya
sabes cómo vas a hacer la implementación
➢ Hay casos sin testear
○ Usuario con username vacío
○ Se puede usar followers y followees que no
existen
○ Podés seguirte a vos mismo
○ etc.
Conclusiones - Tests

23. ➢ 11 minutos en escribir el primer test
○ Clases: UserAPI, UserService, RegistrationData,
User, UserBuilder
○ 4 Mocks con varias configuraciones
➢ 4 minutos para hacerlo pasar
➢ 5 clases para registrar un usuario
Algunos Números...

24. Solución Chicago

25. Esquema de solución (CreateUser)

26. Primer Test

27. ➢ Proceso Inside-out
➢ Clases que representan Casos de usos
➢ Una clase por API
➢ UseCaseContext, APIContext → Objetos globales
➢ DTOs para comunicación entre “capas”
○ CreateUserRequest igual a User
➢ Uso de variables de instancia públicas
➢ Clases sin/poco comportamiento (estructuras de
datos)
Conclusiones - Diseño

28. ➢ Se expone la password a objetos externos, que además
es público
➢ Se puede postear con palabra inapropiadas
➢ Hay casos sin testear
○ Usuario con username vacío
○ Si follower o followee no existe, lo relaciona con
null
○ Podés seguirte a vos mismo
○ etc.
Conclusiones - Diseño/Tests

29. ➢ La primera vez que corre tests, son 2 tests juntos y
pasan de entrada (Episodio 6 - 14:15)
➢ 5 clases para crear usuario
○ CreateUser, CreateUserRequest,
UseCasaeContext, Repository, User
Algunos Números...

30. Solución Buenos Aires

31. ➢ Empezar haciendo TDD del modelo del negocio
➢ Seguir estrategia “Middle-Out”
➢ Dejar Interfaces para el final siguiendo la idea de
tecnología perfecta
Cómo es el proceso

32. Middle-out
obj1
obj2
obj3
obj4
obj5
obj6 obj7
obj8
obj9 objX
Empezar testeando con TDD los
objetos del medio del árbol de
ejecución

33. Middle-out
obj1
obj2
obj3
obj4
obj5
obj6 obj7
obj9 objX
Empezar testeando con TDD los
objetos del medio del árbol de
ejecución
Test1
Modelo
Tests
obj8

34. Middle-out
obj1
obj2
obj3
obj4
obj5
obj6 obj7
obj8
obj9 objX
Empezar testeando con TDD los
objetos del medio del árbol de
ejecución
Test1 Test2
Modelo
Tests

35. Middle-out
obj1
obj2
obj3
obj4
obj5
obj6 obj7
obj8
obj9 objX
Empezar testeando con TDD los
objetos del medio del árbol de
ejecución
Test1 Test2
Modelo
Tests
Test3

36. Middle-out
obj1
obj2
obj3
obj4
obj5
obj6 obj7
obj8
obj9 objX
Test
1
Test
2
Modelo
Tests
Test
3
RestI
nt
RestI
nt
Test
Interfaces

37. ➢ Se escriben “test funcionales”
(también llamados “sociales”)
➢ No se simulan objetos del sistema
➢ Solo se simula (priorizando stubs) objetos fuera
del sistema, no controlables por los tests. Ej:
○ LocalDateTime.now()
○ UUID.random().toString()
○ Base de datos/Servicios externos/etc.
Cómo es el proceso

38. ➢ Empezar por el Modelo del Negocio
➢ Usar una metáfora para tener una “vista
concreta” del negocio
➢ Heurísticas de Diseño:
○ Usar Objetos Completos
○ User Objetos Válidos
○ Favorecer el uso de Objetos Inmutables
○ No usar null/nil
○ Modelar la solución de manera sistémica
○ Reificar la arquitectura del sistema en el mismo sistema (subsistemas)
Diseño

39. Arquitectura

40. ¡A Programar!

41. ➢ Primer test:
○ Tiempo en escribir el test: 2 min.
○ Tiempo en hacer pasar el test: 30 seg.
○ Cantidad de clases de modelo: 1
➢ Segundo test:
○ Tiempo en escribir el test: 50 seg.
○ Tiempo en hacer pasar el test: 15 seg.
○ Cantidad de clases de modelo: 1
➢ etc ...
Hechos

43. Estadísticas de Modelo e
Interfaz

44. Estadísticas del Modelo

45. Estadísticas de la Interfaz

46. Estadísticas sobre el Total

47. Comportamiento respecto de
Errores

48. Comportamiento respecto de Errores

49. Impacto Frente al Cambio y la
Extensibilidad

50. ➢ Cambio: Que el usuario tenga conozca un homePage
○ El homePage es una url que no se valida
➢ Extensión: Poder dar “like” a una publicación
○ Puede ser cualquier usuario, no solo followees
Cambios y Extensiones entre London y Buenos Aires

51. Agregar url a User

53. London

54. url

55. urlurl
url

56. urlurl
url

57. Buenos Aires

58. url

59. url

60. Estadísticas

61. Clases modificadas en cada paso

62. Clases modificadas en cada paso

63. COMENTARIO: En London los tests de Aceptación no pasaban aunque sí pasasen
los tests de programador, indicativo de que hay casos sin testear en los tests de
programador
Diferencias en el código fuente en cada paso

67. Like a Publication

70. Estadísticas

71. Clases modificadas en cada paso

73. Diferencias en el código fuente en cada paso

74. Diferencias en el código fuente en cada paso

75. Conclusiones

76. ➢ Pudimos resolver el mismo problema con:
○ menos clases
○ menos líneas de código
○ más tests
○ más cobertura
○ más casos de error cubiertos
Conclusiones

77. ➢ Pudimos cambiar y ampliar la solución con:
○ cambios más chicos
○ menos clases modificadas
○ menos diferencias a nivel código
Conclusiones

78. Conclusiones
Los números indican que la solución “Buenos Aires”
es más simple y reacciona mejor al cambio

79. ¿Por qué?

80. ➢ Concentrarnos primero en modelar el
negocio y después en la tecnología
➢ Por seguir un proceso middle-out usando TDD
➢ Seguir buenas heurísticas de diseño
Por qué y Recomendaciones

81. ➢ Minimizar el uso de mocks(*) ya que:
○ generan test de caja blanca
○ son tests frágiles
○ terminan generando inseguridad frente al cambio (más en
leng. dinámicamente tipados)
➢ No empezar el desarrollo por las interfaces:
○ porque se prioriza la tecnología en vez del negocio
○ lleva más tiempo escribir los test y hacerlos pasar
(*) Mocks != Test Doubles
Recomendaciones

82. Material

83. ➢ repo: https://github.com/sandromancuso/cleancoders_openchat
➢ London:
○ branch: openchat-outside-in
➢ Chicago:
○ branch: openchat-unclebob
Soluciones London vs. Chicago

84. ➢ repo: https://github.com/hernanwilkinson/openchat-buenosaires
➢ agregar url:
○ branch: empezando-desde-user
○ commit: Tests de Aceptación de url en User
○ rev. number: 129a87b7d80a33da93f6e3a6c124514793515faa
➢ likes:
○ branch: master
○ commit: >> Likes: Especificación y tests de Aceptación
○ rev. number: db911fae0dfd4867a74ade31cec903b5149f2be4
Solución Buenos Aires

85. ➢ repo: https://github.com/hernanwilkinson/openchat-london
➢ agregar url:
○ branch: manteniendo-interface
○ commit: Test de UserAPIShould fallando
○ rev. number: 041ffa718c0c05718b05d90f1447e1940d1b61c1
➢ likes:
○ branch: default-url
○ commit: >> Likes: Especificación y tests de Aceptación
○ rev. number: da98f3c44ba08b6e8265e0f909bcbb4e255422d0
Solución London de Agregar url y likes

86. Preguntas

87. Muchas gracias

88. info@10pines.com
10pines.com
+54 (011) 6091-3125 / 4893-2057
Av. Leandro N. Alem 896 6° - Bs. As. - Argentina
@10pines
Creative Software Development