Developeando

A veces es bueno escribir más código del necesario para que sea fácil de leer. Para que la persona que le de mantenimiento pueda entender de forma clara y rápida lo que hace el código. Esa persona en el futuro puedes ser tú mismo. Hay otras veces que el código redúndate no ayuda, al contrario es ruido que no dejar ver lo que realmente está pasando. Puede esconder bugs difícil de ver a simple vista. Al escribir código debemos tomar en cuenta que no solo escribimos para la maquina. A la computadora no el importa como escribamos las cosas, para ella es lo mismo el nombre de las variables, el estilo de programación, el lenguaje, paradigma, etc. El código fuente que escribimos debemos pensar que es para las personas que van a leerlo. Escribimos para personas, no para maquinas. Por lo tanto debemos de ser claros con lo que tratamos de expresar en el código. Tampoco es una novela a la que le debemos dar suspenso o drama. Deben ser una serie de instrucciones concretas sin palabras de más

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

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 dar una solución "rápida" al negocio, escribimos código que resuelve el problema de momento; pero que si lo d

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 m

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í, t erminaba 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