SlideShare uma empresa Scribd logo
1 de 25
Refactorización
DAVID SANTA ARBOLEDA
UNIVERSIDAD PONTIFICA BOLIVARIANA
Agenda
1. Introducción
2. Qué es refactorización?
3. La metáfora de los dos sombreros
4. Ventajas de refactorización
5. Hacer Test
6. Ejemplos
7. Refactorización de serial date CleanCode Capitulo 16
1. Conseguir que funcione
2. Hacer que sea correcta
8. Otros ejemplos
Introducción
Muchas veces:
1. Tenemos código ya hecho que está funcionando.
2. Necesitamos tocar ese código para que haga más cosas, para hacer más eficiente un
algoritmo, más vistosa la salida del programa, etc.
Pero es normal:
1. Que cuando queramos modificar el código, encontremos que no es del todo amigable .
2. Que introducir las modificaciones nos cuesta más de la cuenta porque hay métodos muy
largos que no se entienden bien, hay pocos comentarios, hay trozos de código que nos sirven
en parte, pero no del todo, clases muy grandes de las que nos sirven algunos métodos pero
nos sobra el resto, etc.
Solución
Una solución a lo anterior seria:
◦ añadir la funcionalidad como podamos
◦ copiar código y pegarlo en otro sitio
◦ modificarlo para que se parezca a lo que queremos añadir
◦ Entre otras cosas
Esta solución funciona, pero deja el código más “feo" de lo que estaba.
Solución
La otra solución es la refactorización, que es:
◦ Una limpieza de código
◦ Algo que no arregla errores ni incorpora funcionalidades
◦ Algo que Altera la estructura interna del código sin cambiar su
comportamiento externo
◦ Si durante una refactorización se ha cambiado el comportamiento del
software o web, es que has generado un error o bug
La metáfora de los dos sombreros
La metáfora de los dos sombreros
Un programador tiene a su disposición dos sombreros. Uno de ellos
etiquetado "hacer código nuevo", y el otro con la etiqueta "arreglar
código".
1. Cuando empieza a programar, se pone el sombrero de "hacer
código nuevo".
2. Cuando ve que algo que se puede mejorar, se pone el sombrero
de "arreglar código".
La metáfora de los dos sombreros
No mete nada nuevo, esta cambiando código de sitio, haciendo
métodos más pequeños, entre otras cosas.
El código funcionando exactamente igual que antes, pero hecho de
otra manera que le facilita seguir con su trabajo. Nuevamente se
cambia el sombrero por el de "hacer código nuevo" y sigue
programando.
La metáfora de los dos sombreros
1. Si añadimos código nuevo, NO arreglamos el existente.
2. Si estamos arreglando el existente, NO añadimos funcionalidades
nuevas.
3. Código correcto: Que es acertado o adecuado a determinadas
condiciones o circunstancias.
4. Código Funciona: Realizar la función que le es propia.
Ventajas de hacer refactorización
1. Mejorar la facilidad de comprensión del código
2. Cambiar su estructura y diseño
3. Eliminar código muerto
4. Facilitar el mantenimiento en el futuro
Hacer test
Una cosa importante de la refactorización es que se parte de un código que más
o menos funciona, se modifica y el código debe seguir funcionando igual que
antes. Si hacemos refactorización con frecuencia, es importante tener algún
medio de probar que el código sigue funcionando después de "arreglarlo".
Una opción es, después de arreglar el código, compilarlo, ejecutarlo y probar
que más o menos sigue funcionado, especialmente en las partes de código que
hemos tocado.
Otra opción algo más "profesional" es hacer unos pequeños programas de
prueba. Estos programas (conocidos como test unitarios)
“Pasos” para hacer refactorización
Mirar Que no
1. Hayan comentarios inapropiados, obsoletos
2. código comentado, duplicado o muerto
3. Haya demasiados argumentos en las funciones
4. Hayan funciones muertas
5. Hayan varios lenguajes en un archivo de código
6. Comportamiento incorrecto en los limites
7. Exceso de información
8. Desorden
9. Entro otros
Ejemplos
1. a=33*b-Math.round(b+cerdoGordo);
2. // calcula la cantidad de grasa de un chorizo de mi pueblo
a=33*b-Math.round(b+cerdoGordo);
3. public double calculaCantidadGrasaChorizo (double b, double cerdoGordo)
{
return 33*b-Math.round(b+cerdoGordo);
}
a=calculaCantidadGrasaChorizo (b, cerdoGordo);
Ejemplos
Refactorización de SerialDate
1. Aquí el autor analiza una biblioteca de java llamada SerialDate. El dice que va a destrozar lo
que hizo el creador de esta biblioteca, no es con mala intención, solo va hacer una revisión
profesional
2. Debemos sentirnos cómodos y que deberíamos agradecer cuando alguien nos hace una
revisión de código. A través de las criticas es cómo podemos aprender, como hacen médicos,
pilotos o abogados, nosotros como programadores tenemos que aprender hacerlo.
3. SerialDate es una clase que representa una fecha en java, java ya cuenta con una, pero esta
(SerialDate) nos ayuda a representar las fechas sin preocuparnos de la hora del días , la zona
horaria y otros aspectos , a diferente que la que presenta java que puede ser muy precisa y
muy incomoda porque la fecha depende de la zona horaria.
Conseguir que funcione
Esta clase cuenta con pruebas unitarias , todas son satisfactorias , pero no prueban todo lo que
puede fallar y hay funciones que nunca se invocan.
Para mirar mas a fondo utilizo una herramienta de cobertura llamada clover para verificar mejor
y vio que de las 185 instrucciones solo se ejecutan 91 instrucciones.
El entonces empieza cambiando, descomentado, quitando código, y agregando pruebas triviales,
para hacer que funcione a totalidad el código y las pruebas.
Conseguir que funcione
Antes
if (baseDOW > targetWeekday)
Despues
if (baseDOW >= targetWeekday)
Conseguir que funcione
Hacer que sea correcta
java.text.*
java.util.*
Hacer que sea correcta
Otros ejemplos
Otros ejemplos
Otros ejemplos
public List getVentas(Date fechaDesde, Date fechaHasta, boolean
incluyeVentasPendientes, String nombreVendedorLike, String
productoEmpiezaCon, BigDecimal montoMinimo, BigDecimal
montoMaximo, ...) {……}
La solución: generar un objeto que cumpla esta misión, en principio como
agrupador de los parámetros de búsqueda:
public List getVentas(BusquedaVentas busqueda) {….}
Otros ejemplos
Referencias
http://www.chuidiang.com/ood/refactoring/refactoring.php
http://ddsutn.com.ar/cursos/cursadas-anteriores/miercoles-a-la-
noche-2012/seguimientoclasesmienoche2012/refactoring

Mais conteúdo relacionado

Mais procurados

Modelos de ciclo de vida del software
Modelos de ciclo de vida del softwareModelos de ciclo de vida del software
Modelos de ciclo de vida del softwareIEO Santo Tomás
 
Dealing with Merge Conflicts in Git
Dealing with Merge Conflicts in GitDealing with Merge Conflicts in Git
Dealing with Merge Conflicts in Gitgittower
 
Learning git
Learning gitLearning git
Learning gitSid Anand
 
MODELO VISTA CONTROLADOR
MODELO VISTA CONTROLADORMODELO VISTA CONTROLADOR
MODELO VISTA CONTROLADORRené Pilataxi
 
Ingeniería de software II- Parte 3.2
Ingeniería de software II- Parte 3.2Ingeniería de software II- Parte 3.2
Ingeniería de software II- Parte 3.2Marta Silvia Tabares
 
EstáNdares De Calidad Aplicadas Al Software
EstáNdares De Calidad Aplicadas Al SoftwareEstáNdares De Calidad Aplicadas Al Software
EstáNdares De Calidad Aplicadas Al Softwareeduardo89
 
Web 1.0 y Web 2.0
Web 1.0 y Web  2.0Web 1.0 y Web  2.0
Web 1.0 y Web 2.0mmaranju
 
Modelo vista controlador
Modelo vista controladorModelo vista controlador
Modelo vista controladorEmilio Sarabia
 
Guia practica secuenciales en java con NetBeans 01
Guia practica secuenciales en java con NetBeans 01Guia practica secuenciales en java con NetBeans 01
Guia practica secuenciales en java con NetBeans 01Emerson Garay
 
A Practical Introduction to git
A Practical Introduction to gitA Practical Introduction to git
A Practical Introduction to gitEmanuele Olivetti
 
Huong dan su dung svn server (SVN subversion - SVN Hosting)
Huong dan su dung svn server (SVN subversion - SVN Hosting)Huong dan su dung svn server (SVN subversion - SVN Hosting)
Huong dan su dung svn server (SVN subversion - SVN Hosting)Văn Nguyễn Trung
 
Git basics to advance with diagrams
Git basics to advance with diagramsGit basics to advance with diagrams
Git basics to advance with diagramsDilum Navanjana
 

Mais procurados (20)

Conociendo a BlueJ
Conociendo a BlueJConociendo a BlueJ
Conociendo a BlueJ
 
Modelos de ciclo de vida del software
Modelos de ciclo de vida del softwareModelos de ciclo de vida del software
Modelos de ciclo de vida del software
 
Dealing with Merge Conflicts in Git
Dealing with Merge Conflicts in GitDealing with Merge Conflicts in Git
Dealing with Merge Conflicts in Git
 
Learning git
Learning gitLearning git
Learning git
 
Introduction to Git and Github
Introduction to Git and GithubIntroduction to Git and Github
Introduction to Git and Github
 
Mitos del software
Mitos del softwareMitos del software
Mitos del software
 
MODELO VISTA CONTROLADOR
MODELO VISTA CONTROLADORMODELO VISTA CONTROLADOR
MODELO VISTA CONTROLADOR
 
Ingeniería de software II- Parte 3.2
Ingeniería de software II- Parte 3.2Ingeniería de software II- Parte 3.2
Ingeniería de software II- Parte 3.2
 
EstáNdares De Calidad Aplicadas Al Software
EstáNdares De Calidad Aplicadas Al SoftwareEstáNdares De Calidad Aplicadas Al Software
EstáNdares De Calidad Aplicadas Al Software
 
Web 1.0 y Web 2.0
Web 1.0 y Web  2.0Web 1.0 y Web  2.0
Web 1.0 y Web 2.0
 
Devops and git basics
Devops and git basicsDevops and git basics
Devops and git basics
 
Modelo vista controlador
Modelo vista controladorModelo vista controlador
Modelo vista controlador
 
Guia practica secuenciales en java con NetBeans 01
Guia practica secuenciales en java con NetBeans 01Guia practica secuenciales en java con NetBeans 01
Guia practica secuenciales en java con NetBeans 01
 
A Practical Introduction to git
A Practical Introduction to gitA Practical Introduction to git
A Practical Introduction to git
 
Git.pptx
Git.pptxGit.pptx
Git.pptx
 
Control de versiones
Control de versionesControl de versiones
Control de versiones
 
Git 101 for Beginners
Git 101 for Beginners Git 101 for Beginners
Git 101 for Beginners
 
Huong dan su dung svn server (SVN subversion - SVN Hosting)
Huong dan su dung svn server (SVN subversion - SVN Hosting)Huong dan su dung svn server (SVN subversion - SVN Hosting)
Huong dan su dung svn server (SVN subversion - SVN Hosting)
 
Ingenieria Web
Ingenieria WebIngenieria Web
Ingenieria Web
 
Git basics to advance with diagrams
Git basics to advance with diagramsGit basics to advance with diagrams
Git basics to advance with diagrams
 

Semelhante a Refactorización

Physical computing cap 4-5
Physical computing cap 4-5Physical computing cap 4-5
Physical computing cap 4-5Botero7
 
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012Alfredo Chavez
 
Mejores formas de aprender a programar
Mejores formas de aprender a programarMejores formas de aprender a programar
Mejores formas de aprender a programarEduardo Enriquez
 
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012
Retos en la Adopción del Refactoring -  Junta General del MexALN 28/06/2012Retos en la Adopción del Refactoring -  Junta General del MexALN 28/06/2012
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012Alfredo Chavez
 
Desarrollo Web con PHP
Desarrollo Web con PHPDesarrollo Web con PHP
Desarrollo Web con PHPedima198517
 
Seminario de Test Development Driven
Seminario de Test Development DrivenSeminario de Test Development Driven
Seminario de Test Development DrivenParadigma Digital
 
Meetup: Sesion #1 Unit Testing & Simian Army
Meetup: Sesion #1 Unit Testing & Simian ArmyMeetup: Sesion #1 Unit Testing & Simian Army
Meetup: Sesion #1 Unit Testing & Simian ArmyOsvaldo Mercado Coss
 
Trabajando con código heredado y ser feliz
Trabajando con código heredado y ser felizTrabajando con código heredado y ser feliz
Trabajando con código heredado y ser felizDiego Caballero
 
Volviendo a poner el “soft” en software
Volviendo a poner el “soft” en softwareVolviendo a poner el “soft” en software
Volviendo a poner el “soft” en softwareDanijel Arsenovski
 
Como escribir buenos tests al hacer TDD
Como escribir buenos tests al hacer TDDComo escribir buenos tests al hacer TDD
Como escribir buenos tests al hacer TDDHernan Wilkinson
 
Diseño de programacion
Diseño de programacion Diseño de programacion
Diseño de programacion Naty Colin
 
Vuelta_a_los_origines_Testing.pdf
Vuelta_a_los_origines_Testing.pdfVuelta_a_los_origines_Testing.pdf
Vuelta_a_los_origines_Testing.pdfPabloMorales831994
 

Semelhante a Refactorización (20)

Physical computing cap 4-5
Physical computing cap 4-5Physical computing cap 4-5
Physical computing cap 4-5
 
Tdd en java
Tdd en javaTdd en java
Tdd en java
 
Buenasprcticas
BuenasprcticasBuenasprcticas
Buenasprcticas
 
Capitulo 2
Capitulo 2Capitulo 2
Capitulo 2
 
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012
 
El coste de no usar integración continua
El coste de no usar integración continuaEl coste de no usar integración continua
El coste de no usar integración continua
 
Mejores formas de aprender a programar
Mejores formas de aprender a programarMejores formas de aprender a programar
Mejores formas de aprender a programar
 
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012
Retos en la Adopción del Refactoring -  Junta General del MexALN 28/06/2012Retos en la Adopción del Refactoring -  Junta General del MexALN 28/06/2012
Retos en la Adopción del Refactoring - Junta General del MexALN 28/06/2012
 
Emergence
EmergenceEmergence
Emergence
 
Desarrollo Web con PHP
Desarrollo Web con PHPDesarrollo Web con PHP
Desarrollo Web con PHP
 
7iSF-4 test driver development
7iSF-4   test driver development7iSF-4   test driver development
7iSF-4 test driver development
 
Seminario de Test Development Driven
Seminario de Test Development DrivenSeminario de Test Development Driven
Seminario de Test Development Driven
 
Meetup: Sesion #1 Unit Testing & Simian Army
Meetup: Sesion #1 Unit Testing & Simian ArmyMeetup: Sesion #1 Unit Testing & Simian Army
Meetup: Sesion #1 Unit Testing & Simian Army
 
Unidad ii. tdd
Unidad ii. tddUnidad ii. tdd
Unidad ii. tdd
 
Trabajando con código heredado y ser feliz
Trabajando con código heredado y ser felizTrabajando con código heredado y ser feliz
Trabajando con código heredado y ser feliz
 
Volviendo a poner el “soft” en software
Volviendo a poner el “soft” en softwareVolviendo a poner el “soft” en software
Volviendo a poner el “soft” en software
 
Como escribir buenos tests al hacer TDD
Como escribir buenos tests al hacer TDDComo escribir buenos tests al hacer TDD
Como escribir buenos tests al hacer TDD
 
Diseño de programacion
Diseño de programacion Diseño de programacion
Diseño de programacion
 
Vuelta_a_los_origines_Testing.pdf
Vuelta_a_los_origines_Testing.pdfVuelta_a_los_origines_Testing.pdf
Vuelta_a_los_origines_Testing.pdf
 
Esto es ingeniería inversa
Esto es ingeniería inversaEsto es ingeniería inversa
Esto es ingeniería inversa
 

Último

EVOLUCION DE LA ENFERMERIA QUIRURGICA Y ETICA 1.pptx
EVOLUCION DE LA ENFERMERIA QUIRURGICA Y ETICA 1.pptxEVOLUCION DE LA ENFERMERIA QUIRURGICA Y ETICA 1.pptx
EVOLUCION DE LA ENFERMERIA QUIRURGICA Y ETICA 1.pptxaugusto2788
 
Modelos comunicacionales. Antonella Castrataro.pdf
Modelos comunicacionales. Antonella Castrataro.pdfModelos comunicacionales. Antonella Castrataro.pdf
Modelos comunicacionales. Antonella Castrataro.pdfnenelli2004
 
Día Mundial de la Seguridad y Salud en el Trabajo 2024
Día Mundial de la Seguridad y Salud en el Trabajo 2024Día Mundial de la Seguridad y Salud en el Trabajo 2024
Día Mundial de la Seguridad y Salud en el Trabajo 2024omarperdomo16
 
Introducción a la liturgia de la Iglesia_Curso_1
Introducción a la liturgia de la Iglesia_Curso_1Introducción a la liturgia de la Iglesia_Curso_1
Introducción a la liturgia de la Iglesia_Curso_1RogelioPineda13
 
Willer Gehizon Sanchez Mora
Willer Gehizon Sanchez MoraWiller Gehizon Sanchez Mora
Willer Gehizon Sanchez Morawillersanchez93
 
DIABETES MELLITUS trabajo de investigación
DIABETES MELLITUS trabajo de investigaciónDIABETES MELLITUS trabajo de investigación
DIABETES MELLITUS trabajo de investigaciónNatzueTorrescampos
 
LA DECLAMACIÓN Y LOS RECURSOS NO VERBALES
LA DECLAMACIÓN Y LOS RECURSOS NO VERBALESLA DECLAMACIÓN Y LOS RECURSOS NO VERBALES
LA DECLAMACIÓN Y LOS RECURSOS NO VERBALESfarfanataomitza
 

Último (7)

EVOLUCION DE LA ENFERMERIA QUIRURGICA Y ETICA 1.pptx
EVOLUCION DE LA ENFERMERIA QUIRURGICA Y ETICA 1.pptxEVOLUCION DE LA ENFERMERIA QUIRURGICA Y ETICA 1.pptx
EVOLUCION DE LA ENFERMERIA QUIRURGICA Y ETICA 1.pptx
 
Modelos comunicacionales. Antonella Castrataro.pdf
Modelos comunicacionales. Antonella Castrataro.pdfModelos comunicacionales. Antonella Castrataro.pdf
Modelos comunicacionales. Antonella Castrataro.pdf
 
Día Mundial de la Seguridad y Salud en el Trabajo 2024
Día Mundial de la Seguridad y Salud en el Trabajo 2024Día Mundial de la Seguridad y Salud en el Trabajo 2024
Día Mundial de la Seguridad y Salud en el Trabajo 2024
 
Introducción a la liturgia de la Iglesia_Curso_1
Introducción a la liturgia de la Iglesia_Curso_1Introducción a la liturgia de la Iglesia_Curso_1
Introducción a la liturgia de la Iglesia_Curso_1
 
Willer Gehizon Sanchez Mora
Willer Gehizon Sanchez MoraWiller Gehizon Sanchez Mora
Willer Gehizon Sanchez Mora
 
DIABETES MELLITUS trabajo de investigación
DIABETES MELLITUS trabajo de investigaciónDIABETES MELLITUS trabajo de investigación
DIABETES MELLITUS trabajo de investigación
 
LA DECLAMACIÓN Y LOS RECURSOS NO VERBALES
LA DECLAMACIÓN Y LOS RECURSOS NO VERBALESLA DECLAMACIÓN Y LOS RECURSOS NO VERBALES
LA DECLAMACIÓN Y LOS RECURSOS NO VERBALES
 

Refactorización

  • 2. Agenda 1. Introducción 2. Qué es refactorización? 3. La metáfora de los dos sombreros 4. Ventajas de refactorización 5. Hacer Test 6. Ejemplos 7. Refactorización de serial date CleanCode Capitulo 16 1. Conseguir que funcione 2. Hacer que sea correcta 8. Otros ejemplos
  • 3. Introducción Muchas veces: 1. Tenemos código ya hecho que está funcionando. 2. Necesitamos tocar ese código para que haga más cosas, para hacer más eficiente un algoritmo, más vistosa la salida del programa, etc. Pero es normal: 1. Que cuando queramos modificar el código, encontremos que no es del todo amigable . 2. Que introducir las modificaciones nos cuesta más de la cuenta porque hay métodos muy largos que no se entienden bien, hay pocos comentarios, hay trozos de código que nos sirven en parte, pero no del todo, clases muy grandes de las que nos sirven algunos métodos pero nos sobra el resto, etc.
  • 4. Solución Una solución a lo anterior seria: ◦ añadir la funcionalidad como podamos ◦ copiar código y pegarlo en otro sitio ◦ modificarlo para que se parezca a lo que queremos añadir ◦ Entre otras cosas Esta solución funciona, pero deja el código más “feo" de lo que estaba.
  • 5. Solución La otra solución es la refactorización, que es: ◦ Una limpieza de código ◦ Algo que no arregla errores ni incorpora funcionalidades ◦ Algo que Altera la estructura interna del código sin cambiar su comportamiento externo ◦ Si durante una refactorización se ha cambiado el comportamiento del software o web, es que has generado un error o bug
  • 6. La metáfora de los dos sombreros
  • 7. La metáfora de los dos sombreros Un programador tiene a su disposición dos sombreros. Uno de ellos etiquetado "hacer código nuevo", y el otro con la etiqueta "arreglar código". 1. Cuando empieza a programar, se pone el sombrero de "hacer código nuevo". 2. Cuando ve que algo que se puede mejorar, se pone el sombrero de "arreglar código".
  • 8. La metáfora de los dos sombreros No mete nada nuevo, esta cambiando código de sitio, haciendo métodos más pequeños, entre otras cosas. El código funcionando exactamente igual que antes, pero hecho de otra manera que le facilita seguir con su trabajo. Nuevamente se cambia el sombrero por el de "hacer código nuevo" y sigue programando.
  • 9. La metáfora de los dos sombreros 1. Si añadimos código nuevo, NO arreglamos el existente. 2. Si estamos arreglando el existente, NO añadimos funcionalidades nuevas. 3. Código correcto: Que es acertado o adecuado a determinadas condiciones o circunstancias. 4. Código Funciona: Realizar la función que le es propia.
  • 10. Ventajas de hacer refactorización 1. Mejorar la facilidad de comprensión del código 2. Cambiar su estructura y diseño 3. Eliminar código muerto 4. Facilitar el mantenimiento en el futuro
  • 11. Hacer test Una cosa importante de la refactorización es que se parte de un código que más o menos funciona, se modifica y el código debe seguir funcionando igual que antes. Si hacemos refactorización con frecuencia, es importante tener algún medio de probar que el código sigue funcionando después de "arreglarlo". Una opción es, después de arreglar el código, compilarlo, ejecutarlo y probar que más o menos sigue funcionado, especialmente en las partes de código que hemos tocado. Otra opción algo más "profesional" es hacer unos pequeños programas de prueba. Estos programas (conocidos como test unitarios)
  • 12. “Pasos” para hacer refactorización Mirar Que no 1. Hayan comentarios inapropiados, obsoletos 2. código comentado, duplicado o muerto 3. Haya demasiados argumentos en las funciones 4. Hayan funciones muertas 5. Hayan varios lenguajes en un archivo de código 6. Comportamiento incorrecto en los limites 7. Exceso de información 8. Desorden 9. Entro otros
  • 13. Ejemplos 1. a=33*b-Math.round(b+cerdoGordo); 2. // calcula la cantidad de grasa de un chorizo de mi pueblo a=33*b-Math.round(b+cerdoGordo); 3. public double calculaCantidadGrasaChorizo (double b, double cerdoGordo) { return 33*b-Math.round(b+cerdoGordo); } a=calculaCantidadGrasaChorizo (b, cerdoGordo);
  • 15. Refactorización de SerialDate 1. Aquí el autor analiza una biblioteca de java llamada SerialDate. El dice que va a destrozar lo que hizo el creador de esta biblioteca, no es con mala intención, solo va hacer una revisión profesional 2. Debemos sentirnos cómodos y que deberíamos agradecer cuando alguien nos hace una revisión de código. A través de las criticas es cómo podemos aprender, como hacen médicos, pilotos o abogados, nosotros como programadores tenemos que aprender hacerlo. 3. SerialDate es una clase que representa una fecha en java, java ya cuenta con una, pero esta (SerialDate) nos ayuda a representar las fechas sin preocuparnos de la hora del días , la zona horaria y otros aspectos , a diferente que la que presenta java que puede ser muy precisa y muy incomoda porque la fecha depende de la zona horaria.
  • 16. Conseguir que funcione Esta clase cuenta con pruebas unitarias , todas son satisfactorias , pero no prueban todo lo que puede fallar y hay funciones que nunca se invocan. Para mirar mas a fondo utilizo una herramienta de cobertura llamada clover para verificar mejor y vio que de las 185 instrucciones solo se ejecutan 91 instrucciones. El entonces empieza cambiando, descomentado, quitando código, y agregando pruebas triviales, para hacer que funcione a totalidad el código y las pruebas.
  • 17. Conseguir que funcione Antes if (baseDOW > targetWeekday) Despues if (baseDOW >= targetWeekday)
  • 19. Hacer que sea correcta java.text.* java.util.*
  • 20. Hacer que sea correcta
  • 23. Otros ejemplos public List getVentas(Date fechaDesde, Date fechaHasta, boolean incluyeVentasPendientes, String nombreVendedorLike, String productoEmpiezaCon, BigDecimal montoMinimo, BigDecimal montoMaximo, ...) {……} La solución: generar un objeto que cumpla esta misión, en principio como agrupador de los parámetros de búsqueda: public List getVentas(BusquedaVentas busqueda) {….}

Notas do Editor

  1. Antes de empezar hablar del cap 17 de clean code, hare una definición de refectoring
  2. Lo ideal es hacer la refactorización sobre la marcha , según se va escribiendo código (aunque casi nunca lo hacemos). La idea la explica perfectamente la metáfora de los dos sombreros
  3. 1.Hay que programar hasta que tiene hecha alguna parte del programa y le hace una primera prueba, compilando y viendo que funciona. Y deja programar 2.Se pone a leer el código de nuevo
  4. Cuando se pone el sombrero de arreglar código
  5. Tenemos que tener en cuenta
  6. Los programas unitarios que se explicaron en exposiciones pasadas
  7. Aplicar lo del capitulo 17 de cleancode, no ses necesario aplicar todos los pasos, aplique los que cree necesario Los menciono por encima por que ya los explicaron
  8. si en un trozo de código o en un método nos vemos en la necesidad o creemos que es adecuado poner un comentario,  es porque ese código no es lo suficientement claro. Si no es lo suficientemente claro, debe rehacerse para que lo sea. lo ideal es hacer un método con el nombre lo suficientemente claro como para que no necesite comentario
  9. Es muy difícil decir y entender todo lo que hizo el autor de cleancode, entonces dire los mas relevante SerialDate David Gilbert, este es un programador experimentado y competente, muestra un elevado grado de profesionalidad y disciplina es su código, por ende se puede considerar de calidad, pero aun así como dice el autor
  10. 25 de diciembre de 2004 fue sábado y el siguiente sábado fue el 1 de enero de 2005 pero al ejecutarlo devuelve 25 de diciembre como siguiente sábado, error
  11. La línea 719 nunca se ejecuta, osea que 718 siempre es false, pero en el código indica que debe ser true. La variable adjust siempre es negativa y no puede ser mayor o igual a 4, osea q esta incorrecto Esto era por un comportamiento incorrecto en los limites(se habla en el cap 17 que ya expusieron), nos basamos en nuestra intuición y si encontramos un error nos quedamos solo con ese, tenemos que mirar mas a fondo, que un error puede conllevar a mas errores
  12. Arreglando o refactorizando
  13. Aplica lo del cap 17