El papel de la arquitectura en la velocidad de entrega de software

Charla impartida en https://salmorejotech.com 2019. En esta charla hablamos sobre los factores que influyen en el desempeño de las organizaciones que dependen de la entrega de software. Exploramos el papel que juegan la arquitectura y el diseño de software y como ignorar algunos de estos aspectos nos llevaron a escribrir una gran bola de barro en Audiense.

Contamos la historia de cómo ha evolucionado la base de código de Audiense durante sus 8 años de vida y vemos ejemplos de código (lo malo, lo no tan malo, lo nuevo y lo nuevo nuevo), diagramas de arquitectura y anécdotas reales que han ido amoldando nuestra forma actual de entender el desarrollo de software.

Las slides no tienen mucho valor si no se ha visto la charla pues es sólo un apoyo visual a la misma.
Vídeo: https://www.youtube.com/watch?v=7s5y9pThRsk

Podéis escribirme en http://twitter.com/aartiles24

Transcript

1. El papel de la Arquitectura en la Velocidad de Entrega de Software Alfredo Artiles Co-founder & CTO @aartiles24
3. Agenda ¿Qué factores influyen en nuestra velocidad de entrega de software? Historia de nuestra Gran Bola de Lodo Enséñame tus Hexágonos
4. Cubano de nacimiento y cordobés de adopción (adicto al salmorejo). Lic. en Ciencias de la Computación por la Universidad Central de Las Villas Investigador en el grupo investigación EATCO de la UCO Emprendedor en proyectos como MayoCordobés, e24Presenter, FollowFriday.com y Audiense Combino mi pasión por el desarrollo de software con el ajedrez, el deporte y mi familia ¿Quién Soy?
5. Audiense Insights
6. Strive for Awesomeness
7. ¿Qué factores influyen en la velocidad de entrega de software? Accelerate: https://www.amazon.es/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339
8. Métricas de Rendimiento < 1día > 1/día < 1hora < 15%
9. Fuente: https://cloud.google.com/devops/state-of-devops/ Resultados del DORA
10. Entrega Continua Foto: https://flic.kr/p/9RqUnZ
11. Nuestros Miedos https://flic.kr/p/uDCCVE
12. Miedo a Liarla Parda https://flic.kr/p/eeoHep
13. Miedo a que No Funcione https://flic.kr/p/kkVZ
14. Miedo a Delegar https://flic.kr/p/8orAW7
15. Miedo a Tocar https://flic.kr/p/9H1HZT
16. Miedo a la Imperfección https://flic.kr/p/uB715f
17. Fuente: https://trunkbaseddevelopment.com Trunk Based Development
18. La solución a nuestros miedos Mantenibilidad del código Arquitectura débilmente acoplada Monitorización Despliegues automáticos Integración continua (CI) Trunk based development (TBD)
19. Parte II Historia de una Gran Bola de Lodo escrita en JavaScript
20. Nuestro Monolito https://flic.kr/p/ngKjxo
21. ¿Cuándo deja de ser bueno un monolito? Necesidades de escalabilidad independiente de diferentes componentes del dominio Diferentes componentes o módulos necesitan escribirse en diferentes lenguajes Necesidad de despliegues independientes Big ball of Mud (gran bola de barro)
22. https://twitter.com/simonbrown/status/847339104874381312 Monolito Modular
23. Nuestra Gran Bola de Barro https://flic.kr/p/aMeqJn
24. Code is going to get messy. There is no shame in that. Seeing code as messy is a sign that you have learned something. Kent Beck
25. Geología del Software https://flic.kr/p/vLbPwW
26. Big design up front is dumb. Doing no design up front is even dumber. Dave Thomas
27. ¿Compensa el coste de la calidad? Fuente: https://martinfowler.com/articles/is-quality-worth-cost.html
28. Programming is not about building software; programming is about designing software. Jack W. Reeves, 1992 Fuente: https://www.developerdotstar.com/mag/articles/reeves_design.html
29. El rol del arquitecto de software
30. Arquitectura Hexagonal
31. Onion Architecture
32. Event Storming
33. Context Mapping
34. Brotes de Hexágonos Brotes de Hexágonos
35. Anti-corruption Layers
36. Green Field
37. No podemos olvidarnos del diseño previo El diseño es el código El coste de la calidad compensa Arquitecto no es un rango ni un rol individual La solución a los problemas de un monolito no siempre es microservicios Lecciones Aprendidas
38. Parte III Enséñame tus Hexágonos
40. Lógica de Negocio en los Controladores
41. Controlador acoplado a Mongoose
42. Definición de esquema en Mongoose
43. Toda la lógica de negocio escrita en el controlador
44. Arquitectura Hexagonal Simple
45. Controlador sólo conoce acción
46. Factoría de acción inyecta implementación de infraestructura Implementación de acción sólo conoce interfaz
47. Arquitectura Hexagonal sin Modelado del Dominio
48. Controlador sólo conoce acción
49. Factoría inyecta demasiados colaboradores Bajo grado de modelado del dominio
50. Implementación de action sólo conoce interfaces de los colaboradores pero coordina demasiados
51. Arquitectura Hexagonal Y DDD en Typescript
52. Estructura de carpetas de módulos de nuestro bounded context Reports
53. App Service sólo conoce interfaz del repositorio
54. El dominio está totalmente desacoplado de los detalles de infraestructura y casos de usos
55. Implementación del repositorio con MongoDB Único punto donde nos acoplamos a tecnologías de 3ros
56. Implementación del repositorio en memoria Útil para outside-in TDD
57. Uso de los app services desde el legacy en javascript usando el código transpilado
58. Tests unitarios con implementación en memoria de repositorios
59. $ npx arkit -d Reports/src/CustomRankings/ -f Reports/src/ CustomRankings/application/GetCustomRanking.ts -o ~/ deps.png El diseño es el código
60. Recursos
61. Hay miles de métodos pero sólo unos pocos principios. Quien entiende los principios podrá elegir sus propios métodos. Quien ignora los principios fracasará con cualquier método. Harrington Emerson
62. ¡Gracias! @aartiles24