andres

Después == Nunca

Como muchos programadores, normalmente soy víctima de una frase… «Cuando tenga tiempo lo corrijo». Desde el inicio de nuestra carrera, nos enseñan una premisa que si bien tiene cierta verdad, nos llena de temor a modificar nuestro código: Si funciona, no lo toques.

Es así como cargamos a nuestras espaldas el miedo a «romper todo». Es algo lógico que cuando estas aprendiendo si tocas algo que funcionaba, deja de hacerlo (No es solo un prejuicio. El desconocimiento del código y no saber que hace lleva a que seamos propensos a cometer errores). Entonces, si esta premisa en cierta parte está bien en ciertos momentos, ¿porque seguimos teniéndola años después?

Podríamos pensar principalmente que el mayor miedo es romper algo que ya funcionaba y recibir alguna llamada de atención. Ciertamente, si el cliente obtiene una falla que impida la operatoria normal, se va a acordar de toda nuestra familia. Pero acaso, ¿No existe un ciclo de pruebas al menos? ¿No deberíamos nosotros mismos hacer pruebas de aceptación antes de entregar los cambios? Creo que tenemos suficiente experiencia para cambiar una estructura compleja por algo mas simple podemos hacerlo. Pero no lo hacemos a pesar de que sabemos que ciertos refactors no romperan nuestro codigo.

Dejemos ese miedo a romper atras. Rompamos, arreglemos, mejoremos, avancemos.

NdeA: Lo más gracioso de todo, es que este articulo comence a escribirlo hace ya 4 meses y nunca lo continué. Es por ello que me pareció importante retomar la escritura del blog a partir de este punto.

andres

El código me molesta

Estas ultimas semanas (o más de un mes, para ser preciso), tuve una tormenta de conocimientos, en donde caía todo rápido e intentaba mantener todo en la mente, claramente sin éxito.

En pos de organizar mi nuevo camino de aprendizaje, me puse a pensar dicho camino. Es decir, como empezar, con que continuar, etc… En definitiva, organizarme. Me encontré que con la lectura del libro «Clean Code: A Handbook of Agile Software Craftsmanship» de Robert C. Martin un nuevo mundo se abría ante mis ojos, una nueva forma de pensar el código: escribir código para programadores, no para computadoras.

Sin ahondar en detalles de lo que contiene el libro (que seguramente sea merecedor de miles de posts), me encontré con el primer paso de este nuevo camino en mi desarrollo profesional. Ese primer paso llegó solo, sin buscarlo, pero con una fuerza abrumadora que me esta ayudando a organizar mi mente. Ese primer paso, esa idea, esa sensación es que todo el código que escribí hace un tiempo me molesta, me incomoda.

¿Que quiero decir con esto? Es la sensación de que algo está mal en el código. Si, hace lo que debería hacer, cumple con los criterios de aceptación, pero aún está mal. ¿Por qué? Porque no puedo leerlo como una narración. No puedo leerlo como si estuviera contándome una historia. Y eso es lo que quiero. Quiero que leer mi código sea como leer un libro (Quienes leyeron el libro saben a que me refiero) y que no haya que hacer ningún esfuerzo para entenderlo.

Creo que esta sensación es fantástica, siento como si tuviera las puertas abiertas a un campo soleado, invitándome a un mundo nuevo en donde todo se ve mas claro.

Es hora de cruzar esa puerta.

andres

Vísteme despacio que estoy apurado

Pensando en como encarar este Post, se me vino a la mente la frase que ahora lo titula. Dicha frase fue atribuida a varias figuras de la historia, como puede ser Fernando VII, Napoleon Bonaparte o Carlos III. La realidad es que sea quien fuera el autor, fue adoptada como una frase de uso popular.

Pero, ¿por que la frase? ¿que tiene que ver con la informática? En estos días me fui dando cuenta que la gran mayoría de los puntos necesarios para mi crecimiento profesional, siempre necesito iniciar el camino de aprendizaje con el siguiente principio:

Si querés hacerlo bien, tenes que hacerlo despacio.

Hace días vengo consultando con colegas sobre como crecer en profesionalismo sin tener un entorno que te obligue a hacerlo. Es muy fácil aprender buenas prácticas cuando tenes un buen profesor. Pero, ¿cómo lo haces cuando querés encararlo sólo?

Lo primero que me encontré es que, contrario a lo que normalmente las empresas piden, no parece ser tan importante interiorizarte tanto en una tecnología sino en las bases del desarrollo de software: Ideas, pensamientos y prácticas que van mas allá de una tecnología en particular. Me topé, solo para citar un ejemplo, con la idea de «Clean Code», el arte de escribir código de fácil interpretación. O como lo nombran de manera aún mas rica en un curso de Pluralsight: «Clean Code: Writing Code for Humans«. Mas allá de los principios que allí mencionan, me encontré con la afirmación de algo que venia pensando hace semanas: Para avanzar en un nivel más profundo de profesionalismo, hay que pensar más antes de ejecutar, lo cual implica detenerse a analizar y tomar la decisión correcta. (Contrario a lo que muchas veces se fomenta que es sentarse y escribir código hasta que funcione)

Luego de unos 12 años en la industria, conozco muchas de mis fortalezas y debilidades, y una de las fortalezas que siempre destaco es mi capacidad de adaptación: No importa el trabajo al que me esté dedicando, puedo tomar el toro por las astas y llevar mi tarea a buen puerto. Pero no es la forma de hacerlo. Si bien muchas veces la situación lo amerita, no es el contexto ideal en el ciclo de vida de un producto. Este vicio disfrazado de virtud genera trabajo de mala calidad, que luego puede resultar inmantenible. Y lamentablemente uno lo aprende por la fuerza.

Es por ello es que el primer principio que considero que debemos seguir para crecer, es ir más lento. La historia nos muestra que luego nunca tenemos tiempo para mejorar lo que por apuro no lo hicimos bien desde el principio. Es por ello que debemos frenar, pensar y recién en última instancia ejecutar.

Asi que… vamos despacio…

Referencias:

  • https://siempreconectado.es/origen-visteme-despacio-que-tengo-prisa%C2%B4/
  • Imagen: https://pixabay.com/en/napoleon-napoleon-bonaparte-33073/
  • https://app.pluralsight.com/library/courses/writing-clean-code-humans/
andres

Nunca dejes de Desafiarte

Durante esta última semana tuve la tarea de crear una API sencilla. Funcionalmente no era nada del otro mundo, hasta podríamos decir que era trivial. El desafío era que no podía utilizar .NET, plataforma en la que trabajo desde hace unos 7 u 8 años.

La mayor parte del tiempo la ocupe en investigar la plataforma que iba a utilizar (JAVA) junto a los frameworks disponibles que me permitan llegar al objetivo en el irrisorio tiempo de 1 semana, teniendo que codificar únicamente en mi tiempo libre (Es decir, a lo sumo 2 o 3 horas libres durante cada día de la semana y unas 6 / 7 horas durante el fin de semana.

Entonces, resumimos en:

  • 30 horas disponibles muy fragmentadas
  • Programado en Java, que no lo utilizo hace unos 10 años
  • API REST, que nunca desarrollé en JAVA
  • MARIADB, que no utilizo desde los tiempos que era MySQL
  • Deploy en AWS, en donde ni siquiera tenia cuenta.

Durante algún momento en que mi cerebro estaba ya quemado y empezando a divagar, me tope con esa frase: «Nunca dejes de aprender». Aunque yo la acompañaría de una frase que me inspiro en la decisión de utilizar JAVA y  durante el resto de la semana:

Nunca dejes de desafiarte

(Por cierto… llegué a completar el objetivo)

Photo de Negocios creado por creativeart

andres

Como evitar la inicialización de bases de datos en Entity Framework

Arranco diciendo que hasta el momento Entity Framework no me termina de convencer. Entregar todas las decisiones a un tercero llamado Microsoft no es algo que me deje tranquilo. Me siento mas cómodo con ADO.NET, ya que se tiene control total de las consultas que se ejecutan en la base de datos. No obstante, reconozco los beneficios de Entity Framework. Las migraciones son, por ejemplo, un gran beneficio en arquitectura Multi – Tenant de base de datos, en donde una migración manual puede ser contraproducente. Otro «beneficio» es que uno no está tan pendiente de lo que se termina haciendo en SQL (Lo cual, como mencione, tampoco me resulta tan agradable, pero me parece aceptable en el caso de las sentencias de manipulación de datos).

Por algún  motivo hay veces que es necesario evitar la creación automática de la base de datos. En mi caso estoy con un sistema que es la migración a web de una version desktop muy rudimentaria y un factor importante es el poco tiempo que puedo dedicarle al mismo al ser un desarrollo ad-honorem pero que a la vez tiene sus plazos. Las opciones que encontré son:

  • Activar migrations y cada cambio que hago generar una migración: No me parece óptimo estando en un ambiente de desarrollo, ademas de tener la experiencia de que en otro proyecto cada vez que hacíamos deploy con una migración teníamos problemas que, para complicarlo aún más, eran fallas silenciosas. (Acá es donde en un entorno normal tendría que dedicarle tiempo a investigación, pero no lo tengo)
  • Recrear la base de datos cada vez que haga un cambio en la estructura (lo cual no me parece conveniente ya que sólo es válido para un ambiente no productivo)
  • Desactivar la creación automática, no utilizar Migrations y manejar todo desde un proyecto de base de datos (Opción elegida)

El código es muy sencillo, simplemente hay que asignarle al atributo Database de la clase DbContext de la cual heredamos un objeto del tipo «NullDatabaseInitializer». De esta manera, evitamos que al instanciar el objeto «Context» se quiera correr la inicialización de la base de datos.

Lo importante no es el código, sino el análisis previo:  No nos casemos con las tecnologías y elijamos de cada una la que mejor se adapte a nuestras necesidades. En mi caso uso Entity Framework para tener un desarrollo más ágil, pero le quito la creación de la base de datos y no activo migrations ya que no me genera un beneficio importante.

Buen Codeo

andres

Presentación

Como una copia a Jose Ferrer de revivir sus tiempos de blog tech, se me «ocurrió» (entre comillas porque evidentemente la idea del blog es robada :P) también armar un blog. Muy pronto me encontré con la primera disyuntiva: ¿para que?. Hay muchas opciones posibles: divulgar investigaciones para que otros puedan aprovecharlas, contar el día a día de la vida de un developer (So boring…), promocionar y publicitar desarrollos propios, y una larga lista de etcéteras.

Ahora viene la parte filosófica. No se si es la crisis de los 30, pero me encuentro en este momento en un proceso de cambios personales de todo tipo en pos de mejorar a nivel general ciertos puntos que no me tienen contento. A nivel profesional (lo que a este espacio concierne) me veo en una etapa en donde quiero comenzar a organizar mis conocimientos, pulirlos y emprolijarlos. Si bien tengo bastante experiencia, en muchos temas toco de oído y siguiendo con la analogía, quiero empezar a conocer a fondo la teoría musical. Es por ello que comencé algunos cursos de «Clean Code», a investigar Best Practices, etc. En definitiva, no creer que solo con la experiencia tengo que quedarme quieto, sino que debo volver a los libros para crecer aun mas (Casi que diría que es mi lema el constante crecimiento profesional)

Es por ello que inicio este blog con objetivos acorde a mis cambios:

  1. Documentar temas que sean de mi interés y quiera tener algún registro de ellos
  2. Documentar POCs que en algún momento investigue y no quiera que terminen perdidas en algún disco por ahí (Ya se me rompieron varios)
  3. Organizar algunos proyectos que tengo vivos (o que quisiera tenerlos).
  4. Desarrollar ideas para aplicar a proyectos.
  5. Sentirme libre de publicar OTs relacionadas al desarrollo profesional 🙂

En definitiva, este blog va a ser una especie de «Diario Intimo Profesional». Espero que de paso a alguien le interese lo que publico y no sentirme tan solo entre estas letritas 🙂

Espero poder organizarme y dedicarle tiempo, porque en definitiva, tiempo es lo que a veces nos falta…

  • GIF: gifer.com