a complejidad es el principal problema de hacer software mantenible y usable. Hablaremos de las estrategias que [John Ousterhout]. Presentada por Héctor Patricio en SG Virtual Conference 2020

1. A Philosophy of
Software Design
Héctor Iván Patricio Moreno
Unidos compartiendo y aprendiendo
#SGVirtual

2. Agenda
1. ¿Por qué es necesaria una filosofía de diseño del software?
2. El libro y el autor
3. La complejidad
4. Programación táctica contra estratégica
5. División modular
6. Ocultar Información
7. Documentación

3. ¿Por qué es necesaria?

4. Los proyectos de software fallan
mucho más de lo esperado

5. El diseño de software
sigue siendo un arte
oscuro

6. Nadie nos enseña a
ser buenos
diseñadores de
software

7. John
Ousterhout
- TCL/TK
- RAMCloud
- Raft

9. CS190
Stanford

10. La naturaleza de la
complejidad

11. “Anything related to the structure of a
system that makes it hard to work on
the development of that system”

12. No hay un elemento único del sistema
que lo haga complejo

13. Una vez que incrementó la complejidad
es difícil reducirla

14. Es Incremental

16. Síntomas de la
complejidad

17. Amplificación de cambios

18. Carga cognitiva

19. Desconocidos desconocidos

21. Código funcional no
es suficiente

22. Desarrollo
Táctico | Estratégico

23. Desarrollo Táctico

24. Pensado a corto
plazo

25. Programadores 10X

27. “Move fast and break
things”

28. Deuda técnica

29. Llevada por
funcionalidades

31. Desarrollo
estratégico

32. Pensado a largo
plazo

33. Tarda más en
acelerar pero al final
es más rápido

34. Guiado por
ABSTRACCIONES

36. Abstracción
La representación de los elementos
relevantes de una entidad del mundo real en el
software

38. Una interfaz es una
abstracción

39. 15 principios del
buen diseño de
software

40. 1. La complejidad es
incremental

42. 2. Código “que
funciona” no es
suficiente

44. 3. Has pequeñas
inversiones para
mejorar el diseño del
sistema

45. Refactor

46. 4. Los módulos
deberían ser
profundos

48. 5. Las interfaces
deben estar diseñadas
para hacer el caso
común fácil

50. 6. Es más importante
tener una interfaz
fácil que una
implementación fácil

51. 7. Los módulos de
propósito general
son más profundos

52. 8. Separa el código de
propósito general del
específico

53. 9. Diferentes capas
deben tener
diferentes
abstracciones

55. 10. Jala la
complejidad hacia
abajo

56. 11. Desaparece los
errores y casos
especiales

57. 12. Diséñalo dos
veces

58. 13. Comentarios
deben describir
cosas que no son
obvias

59. Comentarios de Interfaz

60. Comentarios de implementación

61. Si algo no es fácil de comentar, podría
haber un problema de diseño

62. 14. El software debe
estar diseñado para
facilidad de lectura

63. Dijiste que tu
código era fácil
… de escribir

64. 15. Los incrementos
en el software
deberían ser
abstracciones, no
características

65. ¿Preguntas?

66. <- En nuestro blog
escribimos más acerca
de esto.