lunes, octubre 23, 2017

Limite de edad al buscar programador(a)

He notado que varias ofertas de empleo para programadores tienen un limite de edad, dicen algo como: "se solicita programador (o programadora) de 20 a 34 años" como si después de cierta edad se nos empezara a olvidar como programar. Por lo que he visto, entre más mayor sea el programador más experiencia de vida tiene y hay que explicarle menos el porqué de las cosas. Programar no es una actividad física que requiera de juventud.

La edad no define las ganas de trabajar. He conocido tanto a personas que siempre quieren echarle ganas al trabajo, como personas que siempre tienen flojera y nomas quieren estar jugando, de todas las edades. Si esto es cierto entonces ¿Por qué habrá esta restricción de edad en las ofertas de empleo?


He pensando que lo hacen para pagar menos, entre mayor es la persona generalmente tiene más compromisos y por lo tanto más gastos. Necesita más dinero y tiempo para sus compromisos fuera del trabajo. Un joven quizás no necesite tanto dinero y pueda quedarse hasta tarde porque le gusta lo que hace.

Hace tiempo en un episodio del dev3cast, Gabriel me preguntó que si yo contrataría a alguien mayor. Me tomó de sorpresa la pregunta y titubeé  al contestar. Me sentí mal por eso; pero así de pronto pensé que prefería contratar a alguien más joven que yo. La razón por la que no pensaba en contratar a alguien mayor es porque en ese tiempo hablamos de contratarlo no como empleado de la empresa donde trabajo, sino como ayudante para proyectos que hago por mi cuenta. Esos proyectos generalmente los hacia para clientes que me conocen y les "gusta" la forma en que trabajo. Pensaba que con un joven sería más fácil que hiciera las cosas a mi modo, sin tener que darle explicaciones del porqué.

Ahora que he iniciado una empresa de desarrollo de software por mi cuenta, me doy cuenta que esto no es necesariamente buena idea... porque aunque mis clientes lleguen a mí debido a que me conocen como  programador y piense (yo) que quieren el código como si fuera hecho por mi mismo (en realidad no, lo que quieren es una solución, el código no importa), el trabajo lo puede hacer cualquier persona sin importar la edad que tenga. Incluso, ahora que he tratado con varios jóvenes, el tener cierta edad puede ser una ventaja que no tienen los jóvenes, por la simple experiencia que te da la vida. Explicar los requerimientos y entender las prioridades para una persona mayor puede ser más fácil.

Al final lo importante es la actitud y la responsabilidad de cada persona, como empresa buscamos gente que saque el trabajo sin excusas, sin tener miedo a aprender, la edad no importa.

miércoles, junio 28, 2017

La tentación de la capitis

Cada que inicio un nuevo proyecto lo veo como una oportunidad para organizar diferente la estructura, la arquitectura, a fin de mejorar la forma en que se desarrolla el proyecto.

En esta etapa es fácil caer en la tentación de crear varias capas (capitis), con esto me refiero a la intención de separar toda la lógica o "responsabilidades" en proyectos separados. Intentar que el modelo del dominio del problema quede "puro", es decir, limpio de dependencias externas. Sin "manchas" con detalles de frameworks. Que alguien al abrir el proyecto vea nombres de carpetas que tengan que ver con el negocio, y no con detalles "sucios" como controllers, views, etc.

Es divertido definir la capa de negocio (o dominio) y estar programando abstracción, tras abstracción. Para después crear proyectos de implementaciones concretas usando cierta tecnología, librería o framework. Como no queremos tener implementaciones concretas, entonces definimos interfaces. Las cuales serán consumidas por la capa de presentación, claro que sin conocer las implementaciones concretas. Así será "fácil" cambiar (pensamos) de  implementación sin afectar la aplicación en un futuro.

Por poner un ejemplo (cuando se trabaja con .NET) se puede llegar a tener un proyecto "Negocio" que solo tiene clases que contienen el "core" del problema e interfaces para todo lo demás que necesita contener dependencias de terceros. Después se agrega un proyecto para cada tecnología que necesitas para realmente hacer las cosas, como "Negocio.EntityFramework" que es una implementación de nuestro proyecto usando EntityFramework para guardar los datos. Y nos sentimos bien porque en un futuro "podríamos" tener un proyecto "Negocio.FileSystem" que guarda los datos en disco directamente o una implementación que los guarde en MongoDB "Negocio.MongoDb". Esto por poner ejemplos. También podemos abstraer el Web como una presentación más y llegar a tener más interfaces e implementaciones concretas que podemos cambiar. Hay veces que se agrega una capa de "servicios" que lo único que haces es llamar a la capa de acceso a datos, incluso a veces es peor y llama a una capa de repositorios que entonces esa sí llama a la base da datos.

Lo que termina pasando, la mayoría de las veces que he visto esa arquitectura, es que solo se tiene una implementación para cada Interfaz. Es decir tantas abstracciones para nada. Solo es más código para ocultar la implementación concreta, al final esa abstracción contendrá fugas para así poder acceder a la funcionalidad que tiene la implementación concreta. A veces se usa el pretexto de que las pruebas serán más fáciles; pero la verdad es que en muchos de esos proyectos ni si quiera hay pruebas unitarias.

Darle mantenimiento a un proyecto así es más complejo de lo necesario, por varias razones:
  1. Es más difícil encontrar la implementación concreta de un método porque la mayoría del código tiene llamadas a interfaces, debes buscar en otro proyecto la implementación.
  2. La configuración necesaria es mayor, se necesita configurar todos los tipos en un contenedor de dependencias o usar el patrón de service locator (que tiene sus propias desventajas) para instanciar las clases concretas que implementan las interfaces del core.
  3. La cantidad de código escrito es mayor (sin ningún beneficio, si solo tienes una implementación), por lo tanto entenderlo es más complicado.
  4. Como la cantidad de código es mayor, hay mayor posibilidad de bugs. 
  5. Un cambio trivial puede significar realizar cambios a todas las capas, debido a las abstracciones con fugas.
Aún conociendo esas desventajas y haber tenido que mantener proyectos de este tipo, donde incluso he visto que se agregaran abstracciones para obtener la fecha y hora del sistema. Aun así cuándo estoy por iniciar un proyecto nuevo, tengo esa sensación de dejar "puro" el dominio y las implementaciones concretas declararlas en otro proyecto. Aún sabiendo que no vale la pena, como que se antoja dejarme llevar en ese viaje creando abstracción sobre abstracción.

A veces siento que he logrado separarlo en capas, con moderación, limitando mis abstracciones. Es decir sin llegar al extremo de tener puras interfaces en el dominio. Pero casi siempre tengo que recordar que "No voy a necesitar otra implementación", pensar en YAGNI y el principio KISS. Recordar que siempre puedo refactorizar si se llega a ocupar. el refactoring es fácil porque el código es poco.  

Siempre es más fácil agregar una capa después, que darte cuenta que no la ocupabas y tratar de quitarla. Limitemos nuestras abstracciones.

viernes, junio 02, 2017

QA no debe encontrar errores.


En equipos de desarrollo, además de las personas que programan, también hay personas que realizan las pruebas a los releases o entregas que realizan los programadores. Es el equipo de QA. Este equipo (como su nombre lo dice "Quality Assurance") se asegura de que el producto entregado por el equipo de desarrollo esté libre de errores o bugs.

Un "malentendido" que a veces veo en algunos equipos es: que creemos que las personas de QA están para probar nuestro código por nosotros. Que están ahí para revisar si el cambio que hicimos, lo hicimos bien. A veces nos da flojera y sentimos que no ocupamos correr el programa y revisar si lo que hicimos está bien. Solo cambiamos el código y lo enviamos a QA para que lo prueben ellos.

Es un "malentendido" porque QA no está para eso, QA no está para que nosotros los programadores hagamos cosas bien. Eso lo tenemos que hacer habiendo equipo de QA o no. Es responsabilidad de cada persona revisar que el trabajo que hizo se haya hecho bien, de manera profesional. Sin embargo, me ha tocado ver que llegan a ser ridículos algunos de los bugs que encuentra el equipo de QA. Cosas que si nosotros como programadores le hubiera dado una revisada lo hubiéramos visto. Nos debería de dar vergüenza que QA encuentre errores, no debería ser común. Evitemos esa actitud de que no nos importa cuantos bugs se encuentren.

Como programadores, debemos tener claro que la responsabilidad de que nuestro trabajo esté bien hecho no es responsabilidad del equipo de QA, es nuestra. El equipo de QA está ahí solo como una Safety-Net, una red de protección por si acaso fallamos, no es para que seamos flojos y entreguemos trabajo mediocre.

Robert C. Martin (aka Uncle Bob) habla un poco de eso en su presentación sobre profesionalismo. Les recomiendo que (si no la han visto) la miren.

miércoles, abril 05, 2017

Consultas y comandos

La mayoría de las aplicaciones en las que trabajo siguen un patrón. Son aplicaciones web que tienen consultas y comandos, ya sea acciones con los métodos HTTP GET o POST. Viene siendo el viejo y conocido patrón CQRS. No inició directamente con el patrón en mente; pero cuando el controlador empieza a tener mucho código en una acción, ahí es donde suena como buena idea introducir un comando o un consulta.



Imagina que estás desarrollando una aplicación para capturar ordenes de trabajo, la aplicación es solo un ejemplo por lo que las reglas serán básicas. Los requerimientos pueden ser los siguientes:
  1. Capturar orden de trabajo
  2. Consultar orden de trabajo
  3. Cambiar el estatus de la orden
  4. Marcar como pagada la orden
  5. Consultar ordenes de trabajo pendientes
Puedes ver que la mayoría son consultas o comandos; pero no inicies el desarrollo de la aplicación usando el patron por todos lados, deja que sea el código el que te diga cuando se necesita introducir una nueva abstracción. Al principio agregarías un OrdersController que use algo como EntityFramework con acciones para cada uno de los requerimientos. Y veras si el código se ve fácil de seguir.

Probablemente te pedirán que al momento de capturar una orden no solo se guarde en la db, sino que también hay que enviar correos, agregar un registro en algún log, realizar ciertas validaciones, etcetera. Si metes todo ese código en el action del controller será difícil seguir el código. Ahí es donde abstraer la creación de la orden en un comando tiene sentido. Lo que puedes hacer es agregar una clase "CreateOrderCommand" que seguramente tendría un método Execute que recibe como parámetro un objeto del tipo CreateOrderModel con toda la información necesaria para crear una orden. Este método puede regresar un objeto del tipo CommandResult que es un objeto con una lista de errores y un objeto con el resultado del comando (en este caso, puede ser una nueva orden). De este modo es fácil ver y modificar todo lo que se necesita para crear una orden en un solo lugar, sin tener que ver detalles de HTTP o del framework MVC. Es sencillo ver qué es lo que necesita el comando para funcionar correctamente.

Lo mismo puede pasar para las consultas, si la consulta es compleja será buena idea encapsularla dentro de un objeto Query que tenga propiedades con los posibles parámetros para la consulta y un método Execute o Find que regrese el resultado de la consulta.

Seguir este patrón también me ha servido cuando no conozco o no tengo control sobre la base de datos del sistema. Puedo ir armando los comandos y consultas que regresan valores fijos de prueba y construir la aplicación aunque aún no tenga acceso a la DB o aun no sepa de donde obtener los datos. Una vez que sé de donde consultar o qué actualizar puedo simplemente cambiar la clase consulta y comando indicado.

Seguir este patron cumple mejor con el principio de responsabilidad única, en lugar de tener una clase gigante "Repository" que hace todas la consultas y todos los comandos, tengo una clase comando o consulta para cada característica de la aplicación.

viernes, marzo 03, 2017

Código hediondo

Hay ocasiones en que el código huele mal, es a lo que se le llama code smell. El termino que encontré en español es "código hediondo". No es código que tenga un error obvio, el código que huele mal no necesariamente está mal; pero debes darle una revisada y quizás reescribirlo  porque generalmente cuando hay mal olor significa que algo se está "echando a perder".

Cuando veas código que huele mal... sí, el olor del código se ve, incluso se puede detectar mientras se escucha al código... bueno, decía que sí ves código que huele mal, cámbialo en el momento, no lo dejes para después porque si trabajas mucho tiempo con código que huele mal, puedes acostumbrarte al olor y después no darte cuenta de que tu código apesta.



Algunos de los malos olores en el código son:

Código Duplicado
El código duplicado no es en sí un error. El problema es que no ayuda al mantenimiento del código. Hace que sea fácil cometer errores en el futuro, además de que te llevará más tiempo modificarlo. ¿Te ha tocado hacer un cambio en un programa y tener que ir a muchos partes del código a hacer el mismo cambio? No solo te tardaste más, también existe la posibilidad de que hayas olvidado cambiarlo en algún otro lugar y por lo tanto has introducido un  error.

Para prevenir el código duplicado, lo que puedes hacer es que cuando necesites que se ejecuten instrucciones en varios lugares, en lugar de copiar y pegar, mejor corta y pega. Corta la parte que se repite, pégala en un nuevo método, lo que cambia lo defines como parámetros y mandas llamar (o ejecutas) ese método donde lo necesites.

Método muy largo
El problema con los métodos largos es que es difícil leer que es todo lo que hace. Se complica poder entenderlo y por lo tanto lograr notar a simple vista como puedes afectar la funcionalidad del método al introducir un cambio.

Si el método hace muchas cosas es mejor llamar a otros métodos que hagan una parte chica cada uno. Por ejemplo: si tienes un método que genera un archivo con mucha información (como la factura electrónica). En lugar de tener todo el código en el mismo método, puedes dividirlo en métodos que escriben cada parte del objeto al archivo (un método para escribir los datos del emisor,  receptor, otro para productos, etc.).

Función con muchos parámetros
Este es un mal olor que se va dando con el tiempo, empiezas con uno o dos parámetros y todo se ve bien, luego agregas funcionalidad, necesitas más información  y le vas agregando más y más parámetros y a veces algunos de esos son opcionales. Al final puedes terminar con un método (o función dependiendo como le llame el lenguaje) que recibe muchos parámetros. No es un error; pero puede hacer más difícil entender el código.

Lo que puedes hacer es que cuando empieza a crecer el número de parámetros, en lugar de recibir muchos parámetros, recibir uno solo, un objeto o estructura con atributos (o propiedades) para cada posible valor. Algo como lo que hace jQuery (por ejemplo) con la función ajax, en lugar de recibir muchos parámetros, recibe un solo objeto con atributos para cada opción esperada.

Magic Strings
No solo aplica para las strings, también para los números. Las magic strings son valores literales que aparecen en el código. Por ejemplo cuando en ASP.NET tienes algo como [Authorize(Role = "Administartor")] si te fijas escribí mal el nombre del rol Administrator y no me voy a dar cuenta hasta que vea que todos los usuarios pueden acceder a ese recurso (no solo los que tengan el rol administrador). Con los números el problema no es que lo escribamos mal, sino que no sabemos qué es, si tenemos algo como if order.status = 2 then  es difícil saber qué significa ese 2 por lo tanto si quiero modificar el código debo tener cuidado.

El uso de constantes para los strings y el de enums en los enteros ayuda a prevenir este feo olor. Usa cosas como [Authorize(Role = Role.Administrator)] porque así si lo escribes mal puedes darte cuenta en tiempo de compilación. Tener cosas como if order.status = OrderStatus.InProgress then hace que sea fácil de saber que está pasando en el código.

Complejidad innecesaria 
Es como cuando usas una bazuca para matar una mosca. La complejidad innecesaria hace que el código sea más difícil de seguir, de entender y de modificar. El desarrollo se vuelve más lento y sin ningún beneficio. Este olor puede ser difícil de detectar, más por uno mismo. Es como la persona que se pone mucho perfume pero no se da cuenta porque siempre se pone y ya se acostumbro. No es que huela feo; pero no es agradable el perfume en exceso.

Algunos proyectos son más complejos que otros; pero no debes empezar de lo complejo a lo simple, sino al revés (para seguir con la metáfora, no te puedes ir quitando perfume). A veces sí ocupas dividir tu proyecto en varias capas; pero ve agregándolas cuando sientas que lo necesitas. No empieces agregando capas solo porque sí, después es más difícil quitarlas.

Estos son algunos de los olores que identifico, hay más; pero hasta aquí la dejamos por hoy. Mantén tú código oliendo bien, evita el código hediondo.



lunes, febrero 13, 2017

Cohesión



La cohesión (en programación) se refiere a que tan bien están relacionados entre sí los elementos de un módulo. En el desarrollo orientado a objetos podría decirse que es el grado de relación que existe entre los métodos y variables de una clase. 

Conocer la cohesión te puede ayudar a saber si la clase cumple o no con el principio de responsabilidad única, el cual dice que una clase solo debe tener una razón para cambiar. A veces no se ve a simple vista si el diseño cumple con este principio. Midiendo la cohesion podría ayudarte a distinguir si realmente los métodos hacen cosas relacionadas entre sí.

He visto que hay más de una forma de medir la cohesión de una clase, hay herramientas que pueden auditar el código y decirte como está la cohesión en el proyecto. No he tenido oportunidad de jugar con esas herramientas, la verdad es que esta métrica no la aplico seguido; pero una forma sencilla de medirla es creando un diagrama donde a cada operación de la clase la representas con un rectángulo y cada variable como un circulo (o rectángulo con bordes redondeados). Después conectas los elementos relacionados con una línea. Una vez que se hacen todas la conexiones agrupas los elementos que tienen relación entre sí.

Si solo te sale un grupo entonces hay una alta cohesión y la clase tiene una sola responsabilidad. Si salen varios grupos entonces tiene una baja cohesión, significa que la clase tiene más de una responsabilidad  y quizás sea buena idea dividirla en otras clases, según los grupos resultantes en el diagrama.

Esto va a depender de lo que buscas con la clase, hay ocasiones en que la clase solo la quieres para tener datos relacionados entre sí, como una clase de tipo dirección sin operaciones, solo propiedades para cada parte del dato. Ahí tienes una baja cohesión; pero quizás quieras dejarlo todo en una sola clase. Esto dependerá de tu diseño, la métrica solo te da información, a ti te toca decidir que hacer con ella.

Haz un ejemplo, supón que estás trabajando en una aplicación que generará una factura electrónica, entonces creas una clase Factura con las siguientes operaciones y variables (omitiendo cosas porque esto es solo un ejemplo):

Ya que tienes las operaciones y variables dibuja unas flechas con las relaciones y reacomodas los elementos para que se vean mejor las relaciones:
Viendo las relaciones puedes identificar 4 grupos, eso te dice que la clase Factura tiene baja cohesión y que puede dividirse en varias clases. Puedes ver, también, que la clase tiene varias responsabilidades.

Separando las responsabilidades de la clase factura y buscando una alta cohesión puedes quedar con un diseño de 4 clases donde antes tenias solo una. Cada una con una única responsabilidad y "una sola razón para cambiar". 
Al final el objetivo es que el código sea fácil de entender y de mantener por ti o por alguien más. La meta no es lograr una alta cohesión, la meta es lograr un mejor diseño. Si después de separar en muchas clases, algo te dice que hubiera sido mejor dejar todo en una sola, no dudes mucho en hacer el cambio.  





jueves, febrero 02, 2017

Todo comienza con la escritura

Estaba escuchando el podcast de seanwes, un episodio donde comentaba (como muchas otras veces) que todo comienza con la escritura. Ya había escuchado esa opinión de Sean, de hecho él tiene un curso y toda la cosa sobre el tema. Cuando escuchaba esa frase, pensaba que eso aplicaba solamente para el content marketing; pero pensando un poco más me di cuenta que también puede aplicarse al desarrollo de software.

"Todo comienza con la escritura". Al pensar como aplica esa frase al desarrollo de software, recordé que como programador lo que me gusta es escribir código. No me gusta escribir palabras sobre lo que va a hacer mi programa, no me gusta realmente escribir documentación; pero... 

También recuerdo que en los proyectos donde he podido avanzar más rápido y sin estrés es cuando me entregan los requerimientos por escrito y bien explicados. Cuando la persona que describe el problema se tomó la molestia de escribir claramente el objetivo del proyecto. Me ha tocado estar en proyectos donde no hablo directamente con el cliente, donde mi trabajo es solo implementar una solución propuesta por el arquitecto, en esas ocasiones ha sido fácil llegar al resultado cuando el diseño está bien documentado. Cuando no tengo que estar en las juntas donde se habla de como sería bueno que funcionaran las cosas en lugar de definirlas por escrito.



Parte de la motivación diaria que me ayuda para no distraerme es tener tareas bien definidas, por eso creo que es bueno definir tareas antes de ponerse a programar... con esto me doy cuenta que realmente todo empieza con la escritura, también en el desarrollo de software. Se inicia con la definición de la idea, del objetivo y con la definición de tareas. Si tenemos el habito de escribir nuestras ideas, no nos dará flojera definir por escrito lo que vamos a realizar. De ese modo cuando tengamos definido lo que haremos podemos abrir el editor y solo preocuparnos por el código, seguir el flujo sin detenernos por falta de información.

Es claro que el escenario ideal no es muy común, por lo general no hay tiempo para definir todo a detalle e incluso cuando lo hay no tiene mucho sentido ya que seguramente los detalles de requerimientos cambiarán. Pero no por eso debemos dejar de definir el proyecto con escritura antes de iniciar, las especificaciones pueden cambiar y el habito de escribir nos va a ayudar a no postergar la actualización de la definición. Como todo, entre más practiquemos definir los proyectos con palabras más sencillo se nos hará. Será fácil que llegue una persona nueva al equipo y se ponga al corriente con lo que es el proyecto.