Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

of

Buenas practicas desarrollando software Slide 1 Buenas practicas desarrollando software Slide 2 Buenas practicas desarrollando software Slide 3 Buenas practicas desarrollando software Slide 4 Buenas practicas desarrollando software Slide 5 Buenas practicas desarrollando software Slide 6 Buenas practicas desarrollando software Slide 7 Buenas practicas desarrollando software Slide 8 Buenas practicas desarrollando software Slide 9 Buenas practicas desarrollando software Slide 10 Buenas practicas desarrollando software Slide 11 Buenas practicas desarrollando software Slide 12 Buenas practicas desarrollando software Slide 13 Buenas practicas desarrollando software Slide 14 Buenas practicas desarrollando software Slide 15 Buenas practicas desarrollando software Slide 16 Buenas practicas desarrollando software Slide 17 Buenas practicas desarrollando software Slide 18 Buenas practicas desarrollando software Slide 19 Buenas practicas desarrollando software Slide 20 Buenas practicas desarrollando software Slide 21 Buenas practicas desarrollando software Slide 22 Buenas practicas desarrollando software Slide 23 Buenas practicas desarrollando software Slide 24 Buenas practicas desarrollando software Slide 25 Buenas practicas desarrollando software Slide 26 Buenas practicas desarrollando software Slide 27 Buenas practicas desarrollando software Slide 28 Buenas practicas desarrollando software Slide 29 Buenas practicas desarrollando software Slide 30 Buenas practicas desarrollando software Slide 31 Buenas practicas desarrollando software Slide 32 Buenas practicas desarrollando software Slide 33 Buenas practicas desarrollando software Slide 34 Buenas practicas desarrollando software Slide 35 Buenas practicas desarrollando software Slide 36 Buenas practicas desarrollando software Slide 37 Buenas practicas desarrollando software Slide 38 Buenas practicas desarrollando software Slide 39 Buenas practicas desarrollando software Slide 40 Buenas practicas desarrollando software Slide 41 Buenas practicas desarrollando software Slide 42 Buenas practicas desarrollando software Slide 43 Buenas practicas desarrollando software Slide 44 Buenas practicas desarrollando software Slide 45 Buenas practicas desarrollando software Slide 46
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

1 Like

Share

Download to read offline

Buenas practicas desarrollando software

Download to read offline

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

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Buenas practicas desarrollando software

  1. 1. 1 Buenas prácticas en el desarrollo de proyectos de software
  2. 2. ¿Quién soy? • Gabriel Moral • Desarrollador en Ding Twitter: @gabrielmoral Blog: www.elcaminodeunaprendiz.com 2
  3. 3. 3
  4. 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. 5. Algunos de los problemas más comunes al desarrollar software 5
  6. 6. 6 Cambiar código que no hemos escrito nosotros (o tal vez si)
  7. 7. 7
  8. 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. 9 Romper otra parte del sistema añadiendo nuevos cambios
  10. 10. 10
  11. 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. 12 Los despliegues a producción son largos y tediosos
  13. 13. 13
  14. 14. ¿Cómo podemos evitarlo? • Control de versiones. • Integración continua. • Continuous delivery. 14
  15. 15. 15 ¿Qué podría ocurrir si no seguimos todas estas prácticas?
  16. 16. 16 Deuda técnica
  17. 17. 17 Algunas prácticas para evitar todos estos problemas...
  18. 18. 18 Clean Code
  19. 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. 20
  21. 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. 22 EJEMPLOS
  23. 23. CLEAN CODE - LIBRO 23 Autor: Robert C. Martin
  24. 24. 24 Refactoring
  25. 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. 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. 27. REFACTORING - LIBRO 27 Autor: Martin Fowler
  28. 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. 29 EJEMPLOS https://refactoring.guru/refactoring/catalog
  30. 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. 31 Test unitarios
  32. 32. TEST UNITARIOS - ¿QUÉ ES? 32 Es una técnica para probar pequeñas partes de la aplicación en aislamiento.
  33. 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. 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. 35 EJEMPLOS
  36. 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. 37 Test driven development
  38. 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. 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. 40. TEST DRIVEN DEVELOPMENT - ¿CÓMO? 40
  41. 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. 42 EJEMPLOS
  43. 43. TEST DRIVEN DEVELOPMENT - LIBROS 43 Autor: Kent Beck Autores: Steve Freeman y Nat Pryce
  44. 44. ¿Están todas éstas prácticas recogidas en alguna metodología para desarrollar software? 44
  45. 45. Extreme programming. 45 ¿La cualidad más importante de todo programador? Tener EMPATÍA. - Kent Beck
  46. 46. 46 Gracias
  • sylarko

    Oct. 9, 2018

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

Views

Total views

47

On Slideshare

0

From embeds

0

Number of embeds

0

Actions

Downloads

1

Shares

0

Comments

0

Likes

1

×