Programming

Recuerdo llevarme muy bien con un equipo de trabajo en un proyecto con Laravel. En México solemos tener una cultura muy “picante (Pesada)” de hablar y de tratar al “compadrazgo (Amigos)”. Un día común, me acerco a un compañero de trabajo y veo que empezaba a hacer alguna clase de código espagueti, por lo complejo de un requerimiento, por cierto demasiado complejo lo recuerdo, en ese momento yo exclamó: “Mantenlo simple, idiota” Se me quedó viendo de una manera sorprendida y como no, mientras yo intentaba explicarle que existe un concepto que dice literalmente eso, el equipo reía y reía, este mandamiento es el denominado KISS....

Me considero perfeccionista y durante el tiempo que me ha tocado iniciar en varios proyectos, suelo tener dudas cuando me toca elegir cierta tecnología(s) para desarrollar y hacer ese proyecto realidad. Cabe mencionar que en los últimos años han salido múltiples tecnologías que cumplen un mismo fin con diferentes diseños, implementaciones, patrones, lenguajes, etc. Por ejemplo, hace años lo común era utilizar jquery para interactuar con un sitio web, era el rey y nadie lo quitaba de ahí....

Hace un par de proyectos atrás, me tocó refactorizar una aplicación hecha en ionic v3, la versión novedosa (En aquel tiempo) en utilizar un webview para generar una app móvil con angular y typescript al nivel más arriba. Parte del motivo de la refactorización y reconstrucción de algunos componentes, era que algunos no funcionaban como se esperaba, errores básicos por falta de pruebas de parte de las personas que mantenían el proyecto mucho antes de mi equipo....

Conversando con un muy estimado amigo psicólogo de profesión, charlabamos sobre el concepto de “Caja Negra” dentro de la industria de TI, el cual notamos que es un concepto de ambas profesiones: "Es una metáfora para designar aquel elemento estructural de un modelo abstracto sobre el funcionamiento de un sistema que se halla entre la entrada (input) y la salida (output)" Esta cita es sacada directamente de psicología, pero el concepto es similar a lo que es en programación y fácilmente aplicable....

Al desarrollar un microservicio simple en hapijs, me di cuenta que al siempre utilizar async/await casi era obligado en ciertos escenarios utilizar try/catch (Definido así desde arquitectura inicial del proyecto), lo cual no me tenía del todo convencido y recien empezando con Go me di cuenta que no manejan este tipo de excepciones por los siguientes principios. Usar excepciones para errores esperados es una complejidad básicamente innecesaria. Además, mucha gente ha notado que mover el manejo de errores lejos del origen del error hace que las personas no piensen en las rutas de error....