Refactorización

Refactorización es el proceso de cambiar un sistema de software de tal manera que no altera el comportamiento externo del código pero mejora su estructura interna. Es una forma disciplinada de limpiar el código que minimiza las posibilidades de introducir errores. (Si quieres saber más sobre código limpio te invito a leer este artículos)

Con la refactorización puede tomar un mal diseño, incluso un caos, y volver a trabajar en un código  bien diseñado. Cada paso es simple, incluso simplista. Sin embargo, el efecto acumulativo de estos  pequeños cambios puede mejorar radicalmente el diseño. 

El problema de la refactorización es que puede ser costoso y altamente peligroso, puesto que se debe cambiar código que funciona por código que no sabemos si puede funcionar. Como solución a este inconveniente se recomienda que el código tenga pruebas unitarias automatizadas.

En este post solo veremos algunos método de refactorización, si quieres conocer un catalogo más amplio y detallado puede ingresar a https://www.refactoring.com/catalog/. 

Los métodos son:

1. Rename: Consiste en cambiar el nombre de variables, métodos o clases según sea el caso con el fin de tener un código limpio, de esta forma el código sea más legible, mantenible entre otras características.
2. Extract Function: En ocasiones se tienen métodos que tienen muchas líneas, realiza más responsabilidades de las que debería hacer o simplemente no queda claro para que se quiere ese método. Para solucionar lo anterior se debe crear un método o métodos donde se realice la operación que se quiere extraer del método principal con el fin de separar las responsabilidades o entender mejor el método.
3. Inline: Un caso especifico del método en linea se presenta cuando tenemos uno o mas métodos cuyos códigos son lo suficientemente auto-explicativos como para poder prescindir de ellos. Bastará con sustituir las llamadas al método por el cuerpo de dicho método; pero esto también ocurre con las variables, en ocasiones se tiene una variables que solo se usa para almacenar un valor y posteriormente retornarlo.
4. Extract Class: Cuando una clase hace el trabajo de dos, resulta torpe. En su lugar, cree una nueva clase y coloque los campos y métodos responsables de la funcionalidad relevante en ella.
5. Encapsulated Fields: Consiste en cambiar los modificadores de acceso que se requieran. Por ejemplo se cambian métodos públicos a privados porque solamente se acceden desde la misma clase.

El camino es largo y conlleva aprender más métodos y adquirir nuevas destrezas pero te aseguro que dando este primer paso veras cambios significativos en tu código.

Para poner en práctica estos métodos puedes ingresar a mi repositorio https://github.com/cedaniel200/Refactorizacion donde encontraras una series de ejercicios simples para afianzar los conceptos vistos.

Adicionalemente te recomiendo este excelente libro de Martin Fowler llamado Refactoring: Improving the Design of Existing Code 1era Edición o su 2da edición.

Espero que si realizas mis ejercicios propuestos, al finalizarlos, me dejes un comentario con la retroalimentación de los mismos.

Para finalizar te recomiendo este otro artículo donde hablo acerca de los principios SOLID una destreza que debes adquirir si sigues el camino para ser un excelente desarrollador de software.

Programación Orientada a Objetos (POO) desde un Enfoque Simple

Este paradigma es descubierto en el año 1966, por Ole Johan Dahl y Kristen Nygaard, dos años antes que la programación estructurada, pero es adoptado después de esta.

Dentro de la POO existen dos conceptos claves.

• Clase: Modelo o plantilla a partir del cual podemos crear los objetos.
• Objeto: Un objeto es una unidad de software de estado y comportamiento relacionados, también puede describirse como la instancia de una clase.

Profundicemos un poco en los objetos, estos a menudo se utilizan para modelar los objetos del mundo real, esto incluye conceptos, cosas tangibles e intangibles que se encuentran en la vida cotidiana. Los objetos del mundo real comparten dos características: 

• Estado 
• Comportamiento

Por ejemplo, los perros tienen estado (nombre, color, raza, hambre) y comportamiento (ladrar, buscar, menear la cola). Un objeto almacena su estado en campos, atributos o variables  y expone su comportamiento a través de métodos o funciones, los métodos operan el estado interno de un objeto, pero para que dicho objeto o una clase realice alguna acción se debe enviar un mensaje, pero no basta con esto, ya que, para que el objeto o la clase procese el mensaje que recibe, debe poseer un método de coincidencia. Ilustremos lo anterior con un ejemplo escrito en Java.

Automovil auto = new Automovil();

auto.encender();

Como podemos ver, creamos a partir de la clase Automovil un objeto llamado auto al cual le enviamos el mensaje auto.encender() ya que queremos que encienda, pero para que esto se de la clase Automovil debe tener un método que coincida con encender(). 

Teniendo claro y comprendiendo los conceptos de Clase y Objeto, podemos hablar del Diseño Orientado a Objetos (DOO), que como menciona Rober C Martin en su libro Arquitectura limpia, "podemos utilizar  tres palabras mágicas para explicar la naturaleza del DOO: encapsulación, herencia y polimorfismo. La implicación es que el DOO es la combinación adecuada de estas tres cosas"

Encapsulación: Describe la capacidad de un objeto para ocultar sus datos y métodos del resto del mundo. Ocultar el estado interno y exigir que toda la interacción se realice a través de los métodos de un objeto se conoce como encapsulación de datos. Vemos la encapsulación con las variables privadas y métodos publicos de una clase.

Herencia: Diferentes tipos de objetos a menudo tienen una cierta cantidad de características en común entre sí, sin embargo, cada uno también define características adicionales que los hacen diferentes. La programación orientada a objetos permite que las clases hereden el estado y el comportamiento de uso común de otras clases. De aquí que Rober C Martin en su libro Arquitectura limpia la defina como "La redeclaración de un grupo de variables y funciones dentro de un ámbito de inclusión".

Polimorfismo: Es la capacidad de diferentes objetos para responder de manera diferente al mismo mensaje. Ejemplo: Tenemos dos clase EstudiantePregrado y EstudiantePosgrado que Heredan de la clase Estudiante, el polimorfismo nos permitiría que una variable de tipo Estudiante no se limite a referirse a un objeto de la clase EstudiantePregrado, ya que, puede hacer referencia a cualquier objeto de las clases descendientes de Estudiante.

Para finalizar hablemos de la Abstracción una palabra muy utilizada cuando hablamos de POO pero que es?, bueno se podría decir que la abstracción consiste en captar las características esenciales de un objeto, así como su comportamiento.

En mi repositorio de GitHub https://github.com/cedaniel200/Programacion-Orientada-a-Objetos encontraras algunos talleres donde puedes practicar los temas vistos y más, en caso de no poder solucionarlos, no te preocupes cada taller tiene una posible solución.

Clean Code Capítulo 3 Funciones

Al crear software debemos proporcionar mecanismos para llevar a cabo diferentes acciones, por esto aparecen las Funciones. En Clean Code, se hace énfasis en lo importante que es crear cada función para hacer una cosa, que vayan contando una historia y que cada una lleve a la siguiente. Si observamos secciones en funciones (por ejemplo declaraciones, inicializaciones y filtros), es una clara señal que la función hace más de una cosa, otro caso es cuando una función hace lo que dice que hace en su nombre, pero hace algo extra (se está incumpliendo la regla de hacer una cosa) generando un efecto secundario inesperado, siempre recordemos que las funciones son sin efecto secundarios, por lo tanto, si es necesario, se debe pensar en refactorizar. Una función debe responder a algo o hacer algo, pero no las dos cosas, de ahí que surge la separación de consultas de comando, el autor lo expresa de la siguiente manera "Su función debe cambiar el estado de un objeto o devolver información sobre el mismo, pero ambas operaciones causan confusión".

Al darles nombre no olvidemos el capítulo nombres con consentido, por esto se debe usar nombre descriptivos, que revelen la verdadera intención o acción de la función, una recomendación es utilizar verbos y palabras claves como por ejemplo writeField(name). write (Verbo), Field (Palabra Clave).

Cada función debe ser de tamaño reducido, ¿Cuántas líneas? no sabría decirte con exactitud, pero si nos basamos en el libro, este nos recomienda que tengan una longitud aproximada de 20 líneas, en estas líneas hay que prestar mucha atención a los bloques y sangrados. Cuando hablo de bloques hago referencia a fragmentos de códigos dentro de if, else, for y similares, en este caso la recomendación es que su longitud sea de una sola línea (lo más probable es que se invoque a otra función); en cuanto al nivel de sangrado no debe ser mayor a dos, ayudando a que haya un nivel de abstracción por función haciendo más fácil de comprenderla, con lo anterior se puede leer el código de arriba a abajo (la regla descendente). Esta regla consiste en posicionar las funciones por nivel de abstracción, como lo explican en Clean Code "Queremos que tras todas las funciones aparezcan las del siguiente nivel de abstracción para poder leer el programa, descendiendo un nivel de abstracción por vez mientras leemos la lista de funciones".

Otra parte clave en las funciones son sus argumentos, cuyo número ideal es cero, posteriormente uno (mónadico) y dos (diádico); se debe evitar las funciones de tres argumentos (triádico), las de más de tres argumentos (poliádico) deben tener una motivo especial. Las formas monádicas habituales son tanto para preguntar sobre el argumento o para transformar el argumento en otra cosa, un caso poco habitual es para eventos, en este caso las funciones por lo general no devuelven nada. En este punto el autor desaconseja utilizar argumentos de indicador (Pasar un booleano a una función) ya que de una forma u otra está indicando que la función hace más de una cosa. Para las funciones diádicas se debe propender que los argumentos sigan y tengan un orden natural, cuando estos carecen de dicho orden debe el programador utilizar los mecanismos necesarios para evitarlas. Cuando una función requiere dos o más argumentos se suele utilizar Objetos Como argumentos, pero esto no es una trampa, pues suele suceder que las variables antes pasadas como argumentos pertenezcan a un concepto más grande. Los nombres de los argumentos deben ser claros y acordes al contexto.

Algunas funciones tienen argumentos de salida, es decir, ver argumentos que en vez de ser entrada son salidas, estos argumentos deben evitarse.

El manejo de errores en una función en muchos casos se hace por medio de códigos de error, que suelen estar en una clase o varias lo que va creando alto acoplamiento y cuando surge un nuevo tipo de error, es donde viene los dolores de cabeza, por esto es mejor emplear excepciones que devolver código de error. Al utilizar excepciones es inevitable utilizar Try/Catch esto empieza a generar estructuras anidadas por eso es una buena práctica extraer bloques Try/Catch, esto quiere decir que se debe crear una función donde se procesa el error (dónde está la estructura Try/Catch, el procesamiento de errores es una cosa), desde esta se invocará la función que realizará la acción.

Antes de terminar quiero mencionar las instrucciones Switch, donde el autor hace una mención específica diciendo "Mi regla general para las instrucciones Switch es que se pueden tolerar si solo aparecen una vez, se usan para crear objetos polimórficos y se ocultan tras una relación de herencia para que el resto del sistema no las pueda ver. Evidentemente, cada caso es diferente y en ocasiones se puede incumplir una o varias partes de esta regla".

Las funciones nos ayudan a realizar acciones concretas, es nuestro deber evitar el no repetir código, por eso se deben crear con la mayor responsabilidad y dedicación y sin miedo a reescribir cuantas veces se crea necesario hasta que el resultado satisfaga las necesidades.

Nota: Para más artículos relacionados ver Clean Code.

Clean Code Capítulo 2 Nombres con Sentido (2/2)

Continuando con la segunda parte del capítulo 2, vamos a seguir viendo aquellas reglas para crear nombres correctos. Si aún no has visto la primera parte te invito para que la veas.

Nombres de clases: Los nombre de clases no deben ser verbos. Los nombres deben proporcionar de manera clara el propósito de la clase, por lo general debe ser un sustantivo, evitando nombres genéricos. Algunos ejemplos de nombres correctos serían: Persona, Direccion, Cliente. Algunos nombres incorrectos de clases podrían ser: Info, Procesador, CalcularNomina.

Nombre de métodos: Debe ser un verbo como por ejemplo, eliminar, agregar, guardar. Los métodos de acceso, modificación deben tener como nombre su valor y usar como prefijo get, set e is. Como recomendación el autor dice, que “Al sobrecargar constructores use métodos de factoría estáticos con nombres que describan los argumentos”

No se exceda con el atractivo: Esta regla hace referencia a no utilizar nombres provenientes de formas coloquiales de decir las cosas o de jergas, dejando a un lado la claridad, ya que, si llega un nuevo programador que no conozca estas formas de decir las cosas, se llenará de desinformación. 

Un nombre por concepto: Es simple, cuando nos decidimos por una palabra para representar un concepto, esta debe ser constante por todo el código y no utilizarse en unos lados y en otros no. Por ejemplo, no es conveniente utilizar en algunos nombres de métodos la palabra get y en otros retrieve. 

No haga juego de palabras: Se refiere a no utilizar una palabra con dos fines distintos, por ejemplo, digamos que en nuestro código hemos venido utilizando la palabra remove para nombrar métodos que inactivan, y en algún momento somos tentados a utilizar remove para hacer referencia a un método que elimina, en este caso sería mejor utilizar el nombre delete para el método en cuestión.

Usar nombres de dominio de soluciones: No es necesario que todos los nombres utilizados sean extraídos del dominio del problema, ya que, los lectores del código son programadores y ellos conocen o están familiarizados con términos informáticos, de patrones, y demás. Por ejemplo para un programador va a tener mucho sentido si una clase tiene el nombre de ListAdapter.

Usar nombre de dominios de problema: Cuando no se pueda cumplir la regla anterior porque no existe un término en el ámbito de programación, se debe recurrir a un nombre del dominio del problema. El autor nos dice “Separar los conceptos de dominio de soluciones y de problemas es parte del trabajo de un buen programador y diseñador”.

Añadir contexto con sentido: Cuando los nombres no tiene sentido por sí mismo, es necesario crearle un contexto que enriquezca dicho nombre, esto puede hacerse convirtiendo variables en parte de un concepto mayor, es decir, extraer una clase de la cual hagan parte o en una función o método que aporte un contexto. Como última instancia usar prefijos.

No añadir contextos innecesarios: Se refiere a no agregar en los nombres más información de la necesaria. Imagine una clase llamada DireccionResidencia y otra DireccionTrabajo, estos nombres no son realmente adecuados para una clase, lo mejor sería una clase Direccion y estos nombres serían ideales para nombre de instancias. Otro caso es agregar prefijo al nombre de las clases.

Como hemos visto en estos dos post acerca de nombres con sentido, el elegir un nombre adecuado para cada parte del código es fundamental, tanto para la legibilidad como para entender qué se hizo o qué se va a hacer. Para dar un nombre adecuado es necesario emplear habilidad descriptiva, gran vocabulario, conocimiento técnico y dejar los miedos, es momento de empezar a buscar mejores nombres, agregar o quitar el exceso de contexto, refactorizar el código, cambiando los nombres que no sean adecuados en el código existente.

Nota: Para más artículos relacionados ver Clean Code

Guía para la Retrospectiva

Antes de iniciar con la guía par ala retrospectiva acá les dejo la referencia a otro Post donde mención una guía previa a la retrospectiva.  

https://cedaniel200.blogspot.com.co/2016/06/que-hacer-antes-de-una-retrospectiva.html

Ahora sí, manos a la obra.

La retrospectiva debe hacerse al final de cada sprint, en donde el Equipo scrum se reúne con el propósito de revisar el proceso, relaciones entre las personas y herramientas utilizadas. Identificando lo que ha salido bien y lo que no, con el fin de buscar soluciones. Al final se diseña un plan para mejorar las cosas a futuro. La duración recomendada de la Retrospectiva del Sprint es una hora por cada semana de duración del Sprint.

Material Necesario

• Marcadores, Lápices o bolígrafos.

• Post – its

• Product Backlog

• Sprint Backlog

• Graficas del proyecto

Actividades

Cada una de las actividades debe acotarse en el tiempo sin que la suma de las mismas supere el tiempo total de la duración de la retrospectiva.

1. Aspectos Generales: Se explica el fin de la retrospectiva, actividades y sus tiempos.

2. Identificando Problemas: Esta actividad consta de diferentes momentos los cuales son:

a. El facilitador hace un resumen de lo sucedido en el sprint apoyándose de los datos (Product Backlog, Sprint Backlog, graficas etc.). 

b. Los miembros del equipo mencionan los problemas que ellos crean y se anotan en los post-its ubicándolos en un lugar visible para todos.

c. Los post-its se deben agrupar según una afinidad o relación, cada uno de estos grupos de problemas deben tener un nombre representativo.

d. Cada miembro del equipo vota, para esto cuenta con cierto número de puntos (Se recomiendan 10 por miembro) que debe repartir entre los grupos que el considere que afectan más a los objetivos.

3. Descubriendo Causas: La entrada de esta actividad son los grupos generados de la actividad anterior, cabe mencionar que no se buscan culpables sino revisar cada uno de los engranajes (partes del proceso de trabajo, de interrelaciones y de colaboración) del proceso para identificar que está fallando. Se toman los grupos más votados y para cada uno de estos grupos se analiza su causa para ello se utiliza un diagrama de espina de pez o Ishikawa. 

Como se ve en la imagen el problema es el centro en este caso la espina dorsal y cada causa se va desplegando como espinas a partir de la dorsal o de otras causas, hasta encontrar las causas básicas.

4. Plan de Acción: En esta actividad surgen las propuestas de mejora para solucionar las causas que producen los problemas que ha afectado el sprint evaluado. Para esto cada miembro del equipo escribe sus soluciones en post-its, luego entre todos seleccionan las que se implementaran en los Sprint venideros. Lo anterior puede generar actividades o tareas necesarias para llevar a cabo las propuestas seleccionadas, esta lista de tareas son anotadas en post-its y puede ocurrir una o varias de las siguientes opciones:

a. Los miembros de quipo se autosignan la responsabilidad de ejecutar las tareas

b. Las tareas se agregan en el Product Backlog

c. Las tareas se agregan en el Sprint Backlog

5. Que ha salido bien: Cada miembro escribe en post-its lo que cree que ha salido bien, luego en grupo se analiza cada post-its, llegando a conclusión si en realidad ha salido bien y si es así cuál ha sido el motivo por el cual ha salido bien, para seguir haciéndolo así  o reforzarlos en caso de ser necesario.

6. Conclusiones: Se exponen las conclusiones a las que se ha llegado a medida que ha transcurrido la retrospectiva y si se ha cumplido o no con el objetivo de la misma.

7. Retrospectiva de la Retrospectiva: Brevemente se analiza si la reunión de retrospectiva ha salido bien. Que aspectos faltan por mejorar, que aspectos han estado bien y que aspectos se deben reforzar.

EJEMPLOS

A continuación se mencionan los tiempos para cada una de las actividades tomando como referencia un sprint de 15 días es decir dos semanas, lo cual nos da una retrospectiva de máximo dos horas de duración o 120 minutos.

1. Aspectos Generales: Duración de 8 minutos.

2. Identificando Problemas: Duración de 30 minutos.

3. Descubriendo Causas: Duración de 20 minutos.

4. Plan de Acción: Duración de 20 minutos.

5. Que ha salido bien: Duración de 25 minutos.

6. Conclusiones: Duración de 10 minutos.

7. Retrospectiva de la Retrospectiva: Duración de 7 minutos.

REFERENCIAS

http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf

https://proyectosagiles.org/2008/10/21/retrospectiva-agil-scrum/

http://eventos.kleer.la/public_events/813/watch/17047

¿Que hacer antes de una retrospectiva?

Se acerca la hora de la retrospectiva y estas a cargo de ella y no sabes como prepararte ni prepararla.

Acá  te dejo una Guía que te servirá tanto para organizarla como para llevarla acabo. También les dejo un Vídeo que habla sobre la retrospectiva en general pero en la cual en los primeros 11 minutos explican la guía.

Espero les sirva y buena suerte con la retrospectiva.

Guía       http://guiasagiles.org/#SesionesDeMejora
Vídeo     http://eventos.kleer.la/public_events/813/watch/17047

Adicionalmente acá les dejo un Post sobre como llevar la retrospectiva.

https://cedaniel200.blogspot.com.co/2016/06/guia-para-la-retrospectiva.html