Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Emergence

307 visualizaciones

Publicado el

Clean Code; Cap 12

Publicado en: Software
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Emergence

  1. 1. Emergence Clean Code; Cap 12 DanielYepes Restrepo 7 Marzo - 2016
  2. 2. Limpiando el código via Diseño Emergente Hay cuatro reglas básicas que se pueden seguir para garantizar un buen diseño: • Que pueda correr todos los test • Que no contenga duplicados • Que exprese la intención del programador • Que minimice el número de clases y métodos
  3. 3. Regla de diseño simple 1: Que corra todos los test Un sistema que se prueba exhaustivamente y pasa todos los test todo el tiempo, es un sistema testeable, es algo obvio, pero muy importante. Un sistema al que no se le puede realizar un test, no es fiable. El crear un sistema que pueda ser testeado, nos lleva a crear un diseño en el cual nuestras clases sean pequeñas y de un solo propósito
  4. 4. Regla de diseño simple 2-4: Refactoring Una vez que tenemos los test, estamos en toda facultad para dejar el código y las clases limpias. Esto lo hacemos incrementando el refactoring del código. Durante esta fase de refactoring podemos aplicar cualquier cosa que nos ayude para generar un buen diseño de software. Incrementar cohesión, reducir el acoplamiento, modularizar problemas del sistema, reducir clases y métodos, escoger buenos nombres y así…
  5. 5. No duplicados La duplicación representa mas trabajo, mas riesgos e innecesaria complejidad. Se puede manifestar de varias maneras, como: Líneas de código similares. O duplicación en implementación: e.g dos métodos de una clase collection
  6. 6. Un código limpio, requiere la voluntad de hacerlo incluso en pocas líneas o fragmentos.
  7. 7. Para lograr esto, podemos usar el Patrón de método de la plantilla, que es una técnica común para remover duplicados en código de alto nivel.
  8. 8. Expresividad Para cada desarrollador a la hora de programar, le es fácil escribir código que el entiende, porque en el momento en el que lo escribe, esta en completo entendimiento del problema, pero no será lo mismo para quien mantendrá el código. Para minimizar el potencial de defectos cada que se introducen cambios, es critico para el programador el entender lo que hace el sistema. Así como los sistemas se vuelven mas complejos, toman mucho mas tiempo para un desarrollador el entender y hay mas chances de malinterpretar el código. Por lo tanto, el código debería reflejar la intención del autor, lo mas claro que el autor lo pueda hacer, significa menos tiempo para otros en tratar de entenderlo. Lo que reduce defectos y corta costos de mantenimiento.
  9. 9. Como desarrollador puede expresarse de varias maneras: • Escogiendo Buenos nombres. El querer saber del nombre de una clase o de una función y no estar sorprendidos al descubrir que responsabilidades tiene. • Al mantener las funciones y las clases cortas. Clases y funciones cortas usualmente son fáciles de nombrar, de codificar y de entender. • Al usar nomenclatura estándar. • Las pruebas unitarias bien escritas, también son expresiones. El objetivo principal de una prueba es de servir como documentación por ejemplo. Alguien que lea el test, debe estar en la capacidad para entender rápidamente de que se trata determinada clase.
  10. 10. Minimizar clases y métodos En un esfuerzo para crear clases y métodos cortos, debemos crear muchas pequeñas clases y métodos. Lo que sugiere esta regla es que también tengamos una mínima cantidad de clases y métodos. El objetivo es tener un sistema pequeña mientras tenemos funciones y clases pequeñas. Aunque sin embargo, de las cuatro reglas es la que menos prioridad tiene, es mucho mas importante el tener tests, eliminar duplicados y el expresarse.

×