jueves, julio 21, 2016

No hagamos repositorios para el acceso a datos

Este artículo está pensado sobre todo para el desarrollo usando el .NET Framework. Quizás aplique para los demás también, ya que casi cada Framework tiene su ORM.

Hace ya varios años que leí la opinión de Ayende Rahien acerca de que el patrón repository era el nuevo singleton. Tiempo después Jimmy Bogard también escribió sobre alternativas.

A mi entender el patrón repository consiste en abstraer el acceso a datos para que el resto del código no tenga que lidiar con los detalles del acceso a datos (conexiones, consultas, SQL, etc) al momento de acceder a colecciones de datos.

Con  el creciente uso de ORMs el patrón repository ya no es necesario. Ahora podemos usar algo como Entity Framework y dejar que se encargue de esos detalles para los que construíamos un repositorio. Entity Framework (o cualquier ORM) hacen eso y más sin que tengamos que escribir tanto código de "plomería". Escribo este post porque aun veo a programadores que intentan usar el patrón repositorio aún y cuando están usando un ORM.


No veo la utilidad de abstraer la abstracción del ORM (como EF) bajo el patrón repository. No es necesario, es querer apegarse a un patrón de diseño solo porque antes se usaba. Sí, se usaba porque era necesario; pero ya no lo es. La meta no es usar patrones, la meta es tener software funcionando que sea fácil de modificar.

Escribí un poco sobre esto cuando traté el tema de la arquitectura en capas, aunque el artículo no se trataba precisamente del patrón repositorio.

martes, junio 14, 2016

El código no es lo más importante

Aunque me gusta mucho trabajar en el código, debo reconocer que no es lo más importante. No es para lo que nos contratan. Lo usamos como una herramienta para lograr un objetivo: tener software funcionando. Eso es lo que espera el usuario o cliente de nosotros. De nada sirve el código "elegante" si no hay software resolviendo problemas.

En ocasiones olvidamos que la meta no es lograr cierta arquitectura,  poder utilizar ese framework,  lenguaje que está de moda o familiarizarnos con cierta tecnología. La meta es resolver un problema. Y hacerlo de la manera más eficiente, es decir, que no vaya a generar otro problema después.

Tampoco se trata de no darle importancia al código y hacer un cochinero

Aunque el código no es la meta y no es lo más importante, es necesario escribir código de calidad y evitar la deuda técnica. En ocasiones, por tratar de de dar una solución "rápida" al negocio, escribimos código que resuelve el problema de momento; pero que si lo dejamos así sería difícil darle mantenimiento, sería complicado modificarlo o adaptarlo a nuevas necesidades. A esto le llamamos "Deuda Técnica", ya que como toda deuda, al principio te saca del apuro; pero tarde o temprano tendremos que pagarla y eso nos va a costar más entre más tiempo pase.

Aunque el código no es para lo que nos contratan, al ser nuestra herramienta principal de trabajo debemos mantenerlo limpio y fácil de modificar. Pero no perdamos de vista el objetivo: tener software funcionando, resolviendo problemas del mundo real.

martes, marzo 08, 2016

Errores al Realizar Estimaciones

Casi siempre antes de iniciar un proyecto, es necesario saber cuanto tiempo nos vamos a tardar. Esto es para saber si realmente vale la pena hacerlo o no. Cuando el proyecto es personal no es tan complicado calcular, bueno por lo menos no es un riesgo; pero cuando es un proyecto que se va a cobrar y el cliente o jefe quiere saber si vale la pena realizarlo, a veces esa presión no nos deja estimarlo bien. Muchas veces los errores son cosas que pasan seguido y se pueden evitar si las identificamos.

El primer error es no querer estimar, es común escuchar o pensar "yo no sé estimar" y ese es nuestro pretexto para no ser responsables del estimado. Es normal no atinarle al tiempo que se lleva una tarea, sobre todo si es la primera vez que estimamos cuanto tiempo se lleva algo. Estimar es una habilidad que se obtiene practicando. Si queremos ser mejores estimando, debemos estimar más. Entre más lo evitemos, menos aprendemos a realizarlo.

Otro error al estimar es el ser muy optimista. Esto es pensar que todo va a salir bien a la primera. O que las cosas no van a cambiar. Cuando estamos trabajando en un proyecto de software, las cosas "nunca" van de acuerdo al diseño original (por algo lo llamamos desarrollo). Cuando estimamos debemos tomar en cuenta que lo más probable es que nuestra primera propuesta de solución no sea la adecuada. Siempre hay que agregar el "colchón" por si las dudas.

Ser muy pesimista es un error también, generalmente pasa después de que tuvimos problemas en proyectos anteriores por ser muy optimistas. Aquí el síntoma es que le ponemos tanto "colchón" a las tareas que puede parecer que el proyecto no vale la pena desarrollarlo por todo el tiempo que se llevaría. Encontrar el balance viene con la práctica.

Para poder saber el tiempo que nos lleva realizar un proyecto debemos poder definir las tareas  necesarias para completarlo. Otro error frecuente es no descomponer el proyecto en tareas concretas. A veces por no ponernos a pensar un momento a que se refiere cada tarea, podemos llevarnos una sorpresa al momento de realizarla y darnos cuenta que en realidad se lleva menos o más tiempo del que habíamos pensado. Es importante estimar cada parte del proyecto.

El último error de mi lista es no revisar que tan cerca estuvimos del estimado original una vez que terminemos cada tarea y el proyecto. Para poder aprender necesitamos saber que tan cerca o lejos estuvimos y entender el porqué. Esto nos va a ayudar a tomar esos factores en cuenta la próxima vez.

jueves, febrero 25, 2016

Enseñar menos para que aprendan más

Hace años empecé a dar clases de programación por las noches. El sistema que utilizan en la universidad donde trabajo es por cuatrimestres. Es decir, en lugar de dos cursos por año (semestres). Los alumnos toman tres cursos por año de cuatro meses cada uno. Esto provoca que los temas tengan que verse con cierta urgencia, porque "siempre" estamos contra reloj.

Una crítica constante de los estudiantes había sido que voy muy rápido, lo cual yo justificaba por el hecho de que en cuatro meses debía enseñarles muchos conceptos.  Eso sí, terminaba el curso a tiempo; pero muchos conceptos apenas y los tocaba. Los conceptos básicos no los practicábamos lo suficiente.

Para algunas personas esta forma exprés funciona, ya que practican por su cuenta y llegan a conocer los conceptos a detalle una vez que llega la necesidad. Sentía que parte de mi función era solo dárselos a conocer, exponerlos a las técnicas o tecnologías y después ellos/ellas vieran por su cuenta que partes tomar. Aplicar lo nuevo lleva su tiempo y en un cuatrimestre tiempo es lo que no tenemos.

Ahora lo que me ha funcionado es enseñar menos y repetirlo varias veces. Escribiendo varios ejercicios que ejecutan los mismos conceptos una y otra vez. Ya que estos se dominan, entonces empezar a introducir nuevos conceptos. Esto hace que algunos conceptos no alcance a enseñarles, lo cual no me gusta del todo. Quizás a alguien le podría haber servido conocer que existe cierta técnica; pero he notado que aunque estoy enseñando menos la mayoría está aprendiendo más. Por lo menos los grupos van más parejos. Al ser más repetitivo, los alumnos más avanzados pueden aburrirse un poco; aunque también les ayuda a su confianza poder realizar los ejercicios con facilidad en lugar de ir apresurados con los nuevos temas.

Ahora enseño menos, con más repeticiones (en forma de ejercicios) para aprender más.

domingo, diciembre 13, 2015

¿Para qué conocer otras tecnologías?

Aunque no trabajemos con otras tecnologías es bueno conocerlas. Podemos aplicar conceptos que son comunes en otros entornos. No tenemos que conocerlo a detalle; pero sí saber de qué se trata. Al hacer eso nos daremos cuenta que quizás ya existan implementaciones de aquellos conceptos en nuestro entorno que probablemente no los aprovechamos por desconocer cómo se usan.

Hace años casi todo el desarrollo de software en el que trabajaba era ASP. NET Web Forms. Con esa tecnología podía lograr casi todos los proyectos que me pedían. En aquel tiempo se puso de moda Ruby On Rails; pero hacerlo correr en Windows era muy complicado. De cualquier forma, como era algo que muchas de las personas que sigo (en el internet) lo mencionaban, me propuse conocerlo. Aplicar lo nuevo lleva su tiempo por lo que quería estar preparado. Hacer un hola mundo y después unos proyectos sencillos, como ejercicio, para conocer el Framework.

Aunque no fui a trabajar tiempo completo en proyectos de Ruby on Rails, esa experiencia me sirvió para ASP.NET, ya que basándose en esas ideas se desarrolló ASP.NETMVC. Cuando se lanzó el framework ya tenía un poco de ventaja, porque ya conocía el patrón MVC en Web gracias a que conocía otras tecnologías. Lo mismo pasó con Nuget, por ejemplo, el concepto de un administrador de paquetes no era común en .NET pero sí en otros ambientes. Conocer cómo trabajan esos otros entornos, nos ayuda a mejorar y a estar preparados para lo que venga.
 
Ahora ASP.NET 5 es una versión completamente nueva, que está principalmente basada en nodejs, el haber trabajado en nodejs (aunque no pagara mi sueldo) me ayuda a entender las decisiones tomadas al desarrollar la nueva versión de ASP.NET y me facilita aplicar los conceptos necesarios para aprovechar mejor el marco de aplicaciones. Así hay varios ejemplos de un lado a otro, algunas características de C#, por ejemplo, se agregarán a JavaScript.
Como programadores podemos especializarnos en ciertas tecnologías para el desarrollo de software, sin embargo es conveniente poner atención a lo que sucede en otras comunidades de desarrollo de software, podemos aprender conceptos y técnicas que podríamos aplicar a nuestra especialidad. También podríamos descubrir que nos gustan otros lenguajes o plataformas y que ahora nos quisieramos especializar en ellos.

jueves, noviembre 19, 2015

La experiencia

Hace poco escribí sobre lo que es un programador senior. Algo que no anoté como característica fue la experiencia como tal, aunque esas características te las da la experiencia. La mayoría tienden a medir la experiencia en años; pero la experiencia no es solo la cantidad de tiempo que llevas usando cierta tecnología, importan los diferentes retos a los que te has enfrentado a lo largo del tiempo que llevas usándola.

Además de los años trabajando se necesita que esos años hayan sido en diferentes escenarios, que se haya aplicado la tecnología para resolver diversos problemas. Si solo has trabajado en un proyecto en los últimos años, tú experiencia puede ser parcial por solo haberte enfrentado a un problema en particular.

También es necesario haber usado las diferentes versiones de la tecnología en la que estás trabajando. Continuando con el ejemplo de llevar años trabajando en el mismo proyecto. Podríamos decir que el programador tiene experiencia en la tecnología si se ha enfrentado a retos actualizando la aplicación a las nuevas versiones.

El hablar de experiencia me recuerda al negocio de Starbucks, el café es más caro que en otros lugares; pero uno no va solo por el café, sino por la experiencia. Del mismo modo cuando se selecciona a un programador experimentado para un proyecto, no se hace solo por los años que lleva programando, sino por los diferentes retos a los que se ha enfrentado al trabajar en diversos escenarios.

Artículos relacionados:
Aplicar lo nuevo lleva su tiempo
La práctica hace al maestro 
¿Qué es un programador senior? 

martes, septiembre 29, 2015

Debemos dar estimados

Unos de los aspectos importantes para decidir si un proyecto se aprueba o no es conocer lo que va a costar y cuánto tiempo va a tomar el desarrollo. Como programador me gustaría no tener que realizar estimaciones de cuanto me voy a tardar, me gustaría solo programar y ya. "Estará listo cuando esté listo" es una de las respuestas favoritas. Sin embargo como consumidor, cuando solicito un servicio, me gusta saber cuánto se van a tardar y cuánto me va a costar.


Por ejemplo, cuando llevo el carro al taller mecánico, me gusta saber qué le van a hacer, cuánto me va a costar y el tiempo. Aun sin saber de mecánica, debo saber si vale la pena arreglarlo o quizás me conviene andar en taxi por un tiempo, incluso ver la opción de vender ese carro y comprar otro.

Lo mismo pasa cuando planeamos realizar trabajos de construcción, por ejemplo, alguna ampliación en la casa. Antes de conocer los detalles me gustaría saber cómo cuánto cuesta, para ver si estoy listo para tener esa inversión. No puedo simplemente crear historias de usuario para la nueva habitación, pedirle al equipo de construcción que empiece y que diario me vayan platicando qué hicieron el día anterior, lo que harán hoy y los obstáculos que han encontrado. Y mientras, yo pagar cada semana y esperar que me avisen cuando esté listo.

Si contrato a alguien que va empezando quizás no sepa cuánto se lleve terminar una construcción. Por su falta de experiencia no me hará las preguntas necesarias para poder hacer un análisis, crear un diseño para determinar el tiempo y costo. Si contrato a un profesional yo espero que sepa recabar toda la información necesaria para poder realizar el análisis, diseño y presentarme un proyecto con el tiempo y costo estimado. 

Lo mismo esperan nuestros clientes si contratan a un profesional. Una vez que nos exponen su necesidad nosotros debemos de realizar las preguntas necesarias para poder realizar un análisis, crear un diseño y estimar el tiempo y costo del proyecto.

El profesional es el experto en el tema. Es la persona capacitada para tomar las mejores decisiones en el proyecto. Es por eso que es el profesional quien debe ser responsable de que el proyecto se termine en tiempo y dentro de presupuesto. No debemos dejar que el cliente, que no necesariamente conoce como se desarrolla el proyecto, corra el riesgo de nuestras decisiones profesionales. Tampoco debemos esperar que siga pagando retrasos de proyecto debido a nuestras malas decisiones.

A veces como programadores nos da miedo presentar un presupuesto a un cliente, preferimos cobrarle por hora para no correr riesgos; pero como profesionales debemos ser nosotros los responsables del proyecto.

Puede haber imprevistos, por eso se debe tomar un tiempo para "lo que pudiera pasar". Además se puede ir ajustando el estimado conforme haya cambios en los requerimientos. No por eso debemos evitar la responsabilidad y comprometernos a entregar algo en tiempo y forma.