Presentación sobre buenas practicas desarrollando software en la conferencia UCIENCIA 2018 - La Habana

1. 1
Buenas prácticas en el desarrollo de proyectos de software

2. ¿Quién soy?
• Gabriel Moral
• Desarrollador en Ding
Twitter: @gabrielmoral
Blog: www.elcaminodeunaprendiz.com
2

3. 3

4. ¿De qué vamos a hablar?
4
• Algunos de los problemas más comunes al desarrollar
software.
• Algunas prácticas para mejorar la calidad de nuestro software.

5. Algunos de los problemas más comunes al
desarrollar software
5

6. 6
Cambiar código que no hemos escrito nosotros
(o tal vez si)

7. 7

8. ¿Cómo podemos evitarlo?
• Acordar una guía de estilo para el código.
• Practicando Clean Code.
• Refactorizando nuestro código.
• Hablar en el idioma del negocio.
8
“Programa como si tuvieras que mantener ese código el resto de tu vida” - Yuriy Zubarev

9. 9
Romper otra parte del sistema añadiendo nuevos
cambios

10. 10

11. ¿Cómo podemos evitarlo?
• Tener tests es indispensable.
• Unitarios
• Integración
• De extremo a extremo
• Programar en parejas
11
“Teniendo tests duermo más tranquilo por las noches” - Anónimo

12. 12
Los despliegues a producción son largos y tediosos

13. 13

14. ¿Cómo podemos evitarlo?
• Control de versiones.
• Integración continua.
• Continuous delivery.
14

15. 15
¿Qué podría ocurrir si no seguimos todas estas
prácticas?

16. 16
Deuda técnica

17. 17
Algunas prácticas para evitar todos estos
problemas...

18. 18
Clean Code

19. CLEAN CODE - ¿QUÉ ES?
19
Es simple y directo.
Grady Booch.
Se puede leer.
Dave Thomas.
Lo ha escrito alguien al que le
importa.
Michael Feathers.
Hace lo que esperabas que haga.
Ward Cunningham.
Solo hace una cosa.
Robert C. Martin.

20. 20

21. CLEAN CODE - ¿POR QUÉ?
21
• Fácil de leer.
• Fácil de cambiar en el futuro.
• Fácil de testear.
• Es más barato.
Pasamos más del 70% de nuestro tiempo leyendo código y solo un 30% escribiendo código.

22. 22
EJEMPLOS

23. CLEAN CODE - LIBRO
23
Autor: Robert C. Martin

24. 24
Refactoring

25. REFACTORING - ¿QUÉ ES?
25
Refactorizar es el proceso de cambiar el código para hacerlo más
fácil de entender sin cambiar su comportamiento observable.

26. REFACTORING - ¿POR QUÉ?
26
• Mejora la lectura del código.
• Mejora el diseño.
• Facilita añadir nuevas funcionalidades.
• Es más barato.
A veces código que funciona y hace lo que tiene que hacer no es suficientemente bueno.
Cualquiera puede escribir código que entienda una máquina. Solo buenos desarrolladores
escriben código que entienden los humanos.
- Martin Fowler.

27. REFACTORING - LIBRO
27
Autor: Martin Fowler

28. REFACTORING - CATÁLOGO
28
• Add Parameter
• Change Bidirectional Association to Unidirectional
• Change Reference to Value
• Change Unidirectional Association to Bidirectional
• Change Value to Reference
• Collapse Hierarchy
• Consolidate Conditional Expression
• Consolidate Duplicate Conditional Fragments
• Decompose Conditional
• Duplicate Observed Data
• Dynamic Method Definition
• Eagerly Initialized Attribute
• Encapsulate Collection
• Encapsulate Downcast
• Encapsulate Field
• Extract Class
• Extract Interface
• Extract Method
• Extract Module
• Extract Subclass
• Extract Superclass
• Extract Surrounding Method
• Extract Variable
• Form Template Method
• Hide Delegate
• Hide Method
• Inline Class
• Inline Method
• Inline Module
• Inline Temp
• Introduce Assertion
• Introduce Class Annotation
• Introduce Expression Builder
• Introduce Foreign Method
• Introduce Gateway
• Introduce Local Extension
• Introduce Named Parameter
• Introduce Null Object
• Introduce Parameter Object
• Isolate Dynamic Receptor
• Lazily Initialized Attribute
• Move Eval from Runtime to Parse Time
• Move Field
• Move Method
• Parameterize Method
• Preserve Whole Object
• Pull Up Constructor Body
• Pull Up Field
• Pull Up Method
• Push Down Field
• Push Down Method
• Recompose Conditional
• Remove Assignments to Parameters
• Remove Control Flag
• Remove Middle Man
• Remove Named Parameter
• Remove Parameter
• Remove Setting Method
• Remove Unused Default Parameter
• Rename Method
• Replace Abstract Superclass with Module
• Replace Array with Object
• Replace Conditional with Polymorphism
• Replace Constructor with Factory Method
• Replace Data Value with Object
• Replace Delegation With Hierarchy
• Replace Delegation with Inheritance
• Replace Dynamic Receptor with Dynamic
Method Definition
• Replace Error Code with Exception
• Replace Exception with Test
• Replace Hash with Object
• Replace Inheritance with Delegation
• Replace Loop with Collection Closure
Method
• Replace Magic Number with Symbolic
Constant
• Replace Method with Method Object
• Replace Nested Conditional with Guard
Clauses
• Replace Parameter with Explicit Methods
• Replace Parameter with Method
• Replace Record with Data Class
• Replace Subclass with Fields
• Replace Temp with Chain
• Replace Temp with Query
• Replace Type Code with Class
• Replace Type Code with Module Extension
• Replace Type Code With Polymorphism
• Replace Type Code with State/Strategy
• Replace Type Code with Subclasses
• Self Encapsulate Field
• Separate Query from Modifier
• Split Temporary Variable
• Substitute Algorithm
https://refactoring.com/catalog/

29. 29
EJEMPLOS
https://refactoring.guru/refactoring/catalog

30. REFACTORING - SUGERENCIAS
30
• Nunca deberíamos refactorizar sin tests.
• No debemos separar la refactorización del código del proceso de desarrollo.
• Muchos IDEs/herramientas tienen opciones para refactorizar.

31. 31
Test unitarios

32. TEST UNITARIOS - ¿QUÉ ES?
32
Es una técnica para probar pequeñas partes de la aplicación en
aislamiento.

33. TEST UNITARIOS - ¿POR QUÉ?
33
• Permite probar partes de la aplicación.
• Incrementa la productividad al no perder tiempo ejecutando toda la aplicación.
• Son un arnés de seguridad para no romper las funcionalidades actuales
cuando se añade nuevo código.
• Documentan el comportamiento de la aplicación.
• Reduce el coste de la aplicación.

34. PARTES.
Preparar. Inicializar las dependencias y los objetos necesarios.
Actuar. Ejecutar el código que se quiere probar.
Afirmar. Afirmar que el resultado del código probado es el esperado.
CATEGORÍAS.
Estado.
Interacción.
REQUISITOS.
Fácil de escribir.
Legible.
Fallar solo por una razón.
Rápido.
TEST UNITARIOS - CARACTERÍSTICAS
34

35. 35
EJEMPLOS

36. TEST UNITARIOS - ADVERTENCIA
36
• Los tests unitarios por sí solos no garantizan el correcto comportamiento del
sistema.
• Es necesario añadir tests integración y otros tipos de tests para probar las
unidades en conjunto.

37. 37
Test driven development

38. TEST DRIVEN DEVELOPMENT - ¿QUÉ ES?
Es una aproximación al desarrollo de software en el cual se
escriben los tests antes de escribir el código de producción.
38

39. TEST DRIVEN DEVELOPMENT - ¿POR QUÉ?
39
• Nos ayuda a descubrir la interfaz
pública de la funcionalidad que
vamos a desarrollar.
• Ayuda a mantener la implementación
simple.
• Refactoring seguro.
• Documentan el comportamiento de la
aplicación.

40. TEST DRIVEN DEVELOPMENT - ¿CÓMO?
40

41. 1er requerimiento
Escribir una aplicación que salude a la persona que indiquemos. Por ejemplo, cuando la persona
se llama Mercedes la aplicación debería saludar "Hello, Mercedes".
2do requerimiento.
Dado que hay muchos usuarios que no incluyen el nombre queremos generar un saludo por
defecto. Por ejemplo, cuando el nombre no está incluido, la aplicación debería saludar "Hello, my
friend".
3er requerimiento.
Hay algunos usuarios que quieren que la aplicación grite. Por lo tanto cuando el nombre de la
persona sea en mayúsculas la aplicación debería saludar. Por ejemplo, cuando la aplicación ve
MARITZA debería de saludar "HELLO, MARITZA".
TEST DRIVEN DEVELOPMENT - EJEMPLO
41

42. 42
EJEMPLOS

43. TEST DRIVEN DEVELOPMENT - LIBROS
43
Autor: Kent Beck Autores: Steve Freeman y Nat Pryce

44. ¿Están todas éstas prácticas recogidas en alguna
metodología para desarrollar software?
44

45. Extreme programming.
45
¿La cualidad más importante de todo programador?
Tener EMPATÍA. - Kent Beck

46. 46
Gracias