Como es costumbre voy a empezar esta blog con un video, siempre que veo un nuevo tema me gusta encontrar uno para poder tener una idea de que es lo que se refiere el tema, con que se puede comparar o en que idea me puedo centrar, bueno aquí va:

El nombre de este paradigma lo dice todo, Test driven development, hacer que todo tu desarrollo sea movido a base de pruebas, es decir, cada vez que vayas a generar una sección de código debe pasar por un sistema de pruebas, si se pasan toda esta serie de pruebas, el código se adjunta al proyecto completo y si no es así se debe continuar con una revisión del código.

Lo que me hace recordar mucho este tema es a la platica que nos dió uno de los invitados de la clase (wink, wink), el nos platicó acerca de una variable de este paradigma, no recuerdo el nombre al 100% pero recuerdo que se refería a que en cada commit y cada cambio que se hiciera en tu código (cada vez que lo guardes), una serie de pruebas correrían, si se pasan todo seguiría a la normalidad pero si no, todas los cambios se borran, me parece una forma un poco loca de desarrollar pero a la vez pienso que podría evitar muchos problemas estilo domino, por ejemplo si cometes un error en una parte del código y no te das cuenta hasta que corres pruebas después de 30 commits, vas a tener que regresar en todo el código escrito en esos 30 commits para poder darte cuenta en que fue que la regaste.

Ventajas

Desde mi punto de vista las ventajas del TDD son que puedes ir avanzando con firmeza sin tener que preocuparte por errores en el camino, hace que el desarrollo sea más productivo y eficaz, en vez de hacer grandes párrafos de código los cuales son muy propensos a que la cagues en un punto y ni siquiera te des cuenta el TDD te ofrece la capacidad de darte cuenta de esos errores al momento y que los puedas resolver en ese instante.

Desventajas

Sinceramente depende mucho de el tipo de proyecto y el tipo de equipo en el que trabajes, desde mi punto de vista el TDD es uno de los mejores paradigmas de desarrollo pero pues evidentemente todo en esta vida tiene un costo y en el caso del TDD, es generar todas las pruebas necesarias que le aplicaras a tu ya generado código, que por una parte es una buena inversión a futuro pero a la vez es una inversión de tiempo que debes de tener en cuenta en el momento de gestionar tus tiempos e incluirlo en los horarios del proyecto.

Encontré esta repo en github que te ayuda a aprender TDD usando HTML y JavaScript, así que es hora de hacerle fork y probar el TDD más a fondo!

En resumen TDD = increible herramienta para que tu código sea algo así:

y no sea algo así:

Pueden ver mi trabajo en grupoargon.co

En los últimos años las metodologías ágiles han tenido un boom increíble esto ya que realmente funcionan y mejoran nuestro rendimiento en cualquier actividad de productividad, en nuestro caso como desarrolladores, estas metodologías nos vienen muy bien, ya que para empezar normalmente somos muy desorganizados y como siempre lo hemos mencionado en este blog, normalmente comenzamos por la parte de la programación y dejamos la planeación para el final, algo que en un ambiente de trabajo con una metodología ágil implementada probablemente no pasaría.

Para las personas que aun no saben que es agile aquí les dejo un video, en resumen habla de que agile no es una metodología en sí si no una base de principios y valores que un equipo debe de seguir para lograr el objetivo de convertirse en un equipo “ágil”, pero bien agile también propone el uso de metodología como scrum o kanban en mi caso les voy a platicar un poquito de kanban ya que es la herramienta con la que he trabajado y la que me parece más eficiente.

Y bien aquí les dejo otro video sobre kanban para que entendamos como funciona, kanban es un sistema de productividad en el cual generas tareas y las colocas en un “kanban board”, este está dividido en tres partes: pendiente, trabajando y terminado, las tareas se van colocando en estos tres apartados conforme se va trabajando hasta haber logrado terminar cada una de las tareas exitosamente, en mi caso desarrollé un videojuego con la ayuda de kanban, mi equipo y yo hicimos un tablero en Trello donde pusimos todas las tareas necesarias para poder tener un producto tangible, obviamente este proceso no es perfecto, ya que normalmente muchas de las tareas se van modificando, eliminado o agregando nuevas tareas conforme se va progresando en el desarrollo del proyecto pero la idea base de kanban es esta, en equipos pequeños o para tener una bitácora personal de productividad pienso que kanban es una herramienta muy poderosa pero siento que si se escala a equipos muy grandes puede ser un poco caótico, no digo que no se pueda aplicar pero en la parte de la administración de tareas y asignación el ser parte de un equipo muy grande probablemente se vaya a ver afectado el nivel de productividad.

Aquí hay un pequeño ejemplo de como trabajamos en mi equipo de desarrollo, podemos ver las distintas secciones de cada una de las tareas, de esta forma podemos escoger lo que queremos hacer en el día y atacar cada tarea individualmente.

Ahora, que tiene que ver todo esto con el diseño orientado a objetos, pues bien, todo lo que hemos hablado de POO, puede ser manejado con una metodología ágil, esta es la ventaja de agile, no es exclusiva para un solo tipo de tarea, si hay un proceso involucrado en una tarea, probablemente se le pueda aplicar una metodología ágil para mejorarla.

En conclusión agile es una herramienta muy poderosa para poner orden a nuestro proceso de desarrollo de software y poder tener la máxima productividad en nuestro día a día.

Pueden ver mi trabajo en grupoargon.co

Las revisiones de código son una parte fundamental a la hora de desarrollar un proyecto de software, ya que esta practica se encarga de mejorar la calidad y beneficiar de forma positiva al equipo de desarrollo.

Este video me pareció super interesante esta bastante largo (lo vi en velocidad x2) lo recomiendo mucho:

¿Qué debemos revisar?

Esta es una pregunta que nos salta como programadores, porque según nosotros todo esta perfecto cuando estamos escribiendo código, puede que hasta estemos siguiendo al pie de la letra los requerimientos y las clases generadas en base a ellos pero somos humanos y cometemos errores, más de los que deberíamos, entonces tener una segunda opinión sobre nuestro trabajo siempre es una forma muy buena de trabajar.

Tipos de Code Review

Formal Code Review

El FCD es un tipo de forma de revisar código donde normalmente los equipos crean un proceso de desarrollo donde se planea, se prepara, se desarrolla y después se tiene una junta de revisión donde se valoran todos los materiales desarrollados y finalmente se agendan los cambios a tratar.

Lightweight Code Review

Aquí puedo rescatar 3 tipos muy importantes.

Instant Code Review: En este caso una persona esta programando mientras otra esta viendo exactamente lo que esta haciendo, de esta forma se pueden ver los errores de forma fácil y rápida.

Synchronous Code Review: En este caso el programador genera un código y posteriormente pide a otro programador hacer una revisión.

Asynchronous Code Review: El programador termina su desarrollo y deja su trabajo disponible para revisión y este pasa a hacer otras tareas.

Aquí les dejo un video de las mejores prácticas de code review:

Conclusión

Sinceramente este tema se me hace muy interesante e importante ya que desde mi punto de vista tener un código limpio y escalable es una prioridad en la actualidad y ver que tenemos muchísimas herramientas disponibles para hacer code reviews en tiempo real me parece muy positivo para nosotros, no me imagino como hacían hace muchos años utilizando el modelo de FCR donde a fuerzas tenías que estar en una junta para revisar tu código y tener a tu jefe gritándote por los errores que cometiste, ahora sería lo mismo pero al menos sería un grito en un comentario en tu commit y no en la vida real 😝

Pueden ver mi trabajo en grupoargon.co

Ya que vimos todo el proceso de pasar de clases a tablas y la forma de representar todas estas clases en UML, viene lo que nos interesa más a todos nosotros: el código. Después de haber pasado por este proceso tan importante de concebir las clases, las relaciones, los atributos y métodos de cada una de nuestras entidades podemos comenzar a generar nuestro código, pero pienso que es importante tener en cuenta incluso antes de presionar las teclas en nuestra computadora es reconocer cual será el alcance de nuestras clases en nuestro esquema de proyecto y elegir si tendremos una forma de hacer un refactor a nuestras clases en algún punto en el futuro.

Aquí comparto un video que ejemplifica como pasaríamos clases representadas en UML a clases de java:

Como mencioné es de suma importancia tener en cuenta el alcance del proyecto ya que esto va a definir muchos pasos importantes que tendremos que tomar a lo largo de nuestro desarrollo, es por esto que tenemos que tener bien definidas nuestras clases, en este caso las representaré en UML.

Por ejemplo en esta imagen tenemos 2 clases las cuales heredan de documento: libro y email, cosas importantes que tendremos que tomar en cuenta al pasarlas a código sería la encapsulación de los datos.

Esta sería la forma en la que lo convertiríamos en código:

Cosas importantes a destacar es la forma en la que nuestros atributos tienen el acceso definido como privado o público, aspectos muy importantes de la programación orientada a objetos.

Esta sería la forma en la que se implementaría la clase libro, como se puede ver hereda de documento por lo cual tiene todos los métodos y atributos de las súper clase documento.

En conclusión tener todas tus clases en diagramas es una forma que facilita mucho el trabajo al estar codificando todo el trabajo a un lenguaje en específico.

Pueden ver mi trabajo en grupoargon.co

Este tema me da un flashback al semestre pasado cuando llevaba clase de bases de datos con la maestra Ana Delia, ya que este tema fue de los primero que vimos y realmente al principio es muy difícil de entender pero conforme te vas relacionando más con el y vas haciendo diferentes ejercicios sobre el tema cada vez vas mejorando y comprendiendo más, al menos eso fue en mí caso, bueno, me doy cuenta que ni siquiera he mencionado a que tema me refiero el tema es: mapeo de objetos a bases de datos.

Para introducirnos a el tema aquí hay un video que explica como se convierten los objetos a diagramas relacionales:

La forma en la que estuvimos desarrollando estos mapeos en la clase de bases de datos fue por medio de bases relacionales, donde cada una de las entidades tenían sus atributos y se relacionaban con otras entidades distintas.

La imagen anterior es una de las tareas que nos dejó la maestra Ana para poder entender como se hacían estos mapeos, de forma que ella nos daba un diagrama de clases y nosotros lo convertíamos a algo que se podría pasar a SQL cosas a destacar es la forma en la que cada una de las entidades, que en un diagrama de clases serían las clases en sí, tienen llaves primarias que son atributos únicos con los cuáles se van a caracterizar como únicos y también tienen llaves foráneas que son atributos traídos de otras entidades que se obtienen por medio de una relación, por ejemplo un libro tiene como llave foranea el número de editorial de la entidad editorial ya que hace una referencia dentro de ella.

Por otro lado existe el caso que no quieras que tu base de datos sea realcional y quieres utilizar algo como firebase, bueno en mi caso que he utilizado firebase anteriormente yo creo que sería lo más adecuado que hablara de esta herramienta y como podríamos hacer algo parecido a lo que esta acá arriba 👆🏼, pues firebase lo que hace es guardar tu información en un árbol formado de colecciones y documentos, básicamente un documento es un objeto en sí y una colección es una serie de documentos guardados en un mismo lugar, cada uno de los documentos tiene un ID único.

Aquí va una foto:

Este es uno de mis proyectos de firebase como podemos ver tenemos una colección llamada empleados y en cada uno de los documentos tenemos un ID generado automáticamente por firebase y dentro de ese documento estan los atributos de esa instancia, de esta forma podemos almacenar cuantos objetos queramos en nuestras colecciones.

Es muy diferente la forma en la que lo pasaríamos de un objeto tradicional a firebase que como lo haríamos a una base de datos como sql, ya que firebase trabaja muy diferente y podemos técnicamente guardar el objeto a la base de datos directamente, en vez de estar convirtiendo el objeto a un diagrama de entidad relación.

En conclusión depende mucho de cómo te guste a ti tener guardada tu información y realmente lo que más importa es la forma en la que la vas a recuperar ya que en el caso de usar SQL o alguna base de datos relacional tendrás que utilizar queries, mientras que en la no relacional dependerá del framework.

Pueden ver mi trabajo en grupoargon.co

Ya que sabemos que es UML y como funciona podemos indagar un poquito más y ver hasta donde podemos llegar con esta herramienta tan poderosa.

Podemos dividir el UML en 2 puntos importantes, diagramas estructurales y de comportamiento.

Diagramas estructurales

Diagrama de Clase

Diagrama de Objeto

Como mencione en el diagrama de estructurales un diagrama de objeto es cuando convertimos un diagrama de clase a las instancias reales de nuestro software, poniendo en ejemplo la imagen anterior, rellenaríamos nuestro diagrama de clase con una cuenta que podría ser la cuenta “platino”, después tendríamos nuestro libro de registros el cual podría ser del área de Zapopan, el grupo de contacto podría ser una colonia y finalmente el contacto una persona real.

Diagrama de Paquete

Diagrama de Despliegue

Diagramas de comportamiento

Diagrama de estado

Diagrama de casos de uso

En conclusión podemos ver todos estos diferentes diagramas nuevos que si se los vamos agregando a nuestra planeación, tendremos un proyecto mejor estructurado y podremos programarlo más fácilmente.

Pueden ver mi trabajo en grupoargon.co

UML por sus siglas en ingles, unified modeling language, es un lenguaje visual, el cuál tiene como objetivo dar una representación visual de la estructura y comportamiento de un sistema, normalmente de software pero también es aplicable a otros proyectos, desde financieros a arquitectónicos.

Aquí, un vídeo explicando un poco cómo funciona y para que sirve el UML:

Como podemos ver en el vídeo, se habla de objetos y clases, que sorpresa, como he mencionado en posts anteriores, los objetos es la forma de vanguardia para crear código, por medio de las clases podemos representar de una forma más acertada que es lo que pasa en nuestro entorno y en nuestro software en sí.

En los diagramas de clases es donde creamos nuestro “plano” para poder generar objetos, por ejemplo tenemos la clase animal, la cual tiene ciertos atributos, en este caso son la edad y el género, así como también tiene un comportamiento representado por métodos, en este caso, un método que te diga si es mamífero, y otro para procrear, a su vez, tenemos otras tres clases que heredan de animal, las cuales tendrán el mismo comportamiento de la clase animal pero se le agregaran otros atributos y otros métodos ya que por ejemplo una zebra puede correr pero un pez no. En este caso un objeto sería una instancia de esta clase, por ejemplo podríamos tener el objeto Donald, el cual es un pato generado a base de la clase pato que hereda de la clase animal, esta instancia tendrá todos los atributos de animal y de pato, así como sus métodos.

Otras características de UML es la visibilidad de métodos y atributos y las relaciones entre clases.

Desde mi punto de vista, UML nos sirve mucho ya que crea estos planos que proveen una vista general de nuestro proyecto y nos ayuda a tener bien cimentado que objetos estarán interactuando en nuestro código, para poder representar lo que queremos que exista dentro de nuestro software.

Pueden ver mi trabajo en grupoargon.co