DevOps en Podemos TI (p3)
- Lee más sobre DevOps en Podemos TI (p3)
- Inicie sesión o registrese para enviar comentarios
Un viejo dicho reza "somos lo que comemos"...
Si en un futuro lejano, un ser de otro planeta quisiera conocer nuestro mundo, le bastaría asomarse a nuestra basura.
Con ver cualquier depósito sabría todo sobre la humanidad: qué nos motiva, qué apreciamos, lo que amamos y cómo amamos, en qué creemos, cómo vestimos, en qué nos transportamos, qué nos quita la sed y qué comemos...
Así que también "somos lo que desechamos".
Hace un tiempo, describíamos la arquitectura de los sistemas que desarrollamos en Podemos. Nos enfocamos en describir la misma, una arquitectura de capas, con las clásicas Modelo, API e Interfaz. El post además habla de los límites que debe haber en el código que se coloque en cada uno.
De ese artículo podemos extraer también algunos puntos importantes.
En la última entrada, hice alusión a que el debuggeo de un programa puede ser visto como una especie de juego de detectives, hay un crimen por resolver y pistas que deben llevar al origen de la falla, que luego se deberá resolver.
Resulta que en desarrollo de sistemas, las analogías de juegos abundan. Y un escenario donde también disfruto jugando es mientras sigo una metodología de trabajo en particular a la hora de estar programando.
Debuggear* es todo un arte.
De hecho casi todo en el desarrollo de software y sistemas es un arte. Al menos así lo vemos aquí.
El arte detrás de esto está en la parte creativa, en la parte donde creas algo que al usuario le resulta útil. E implica muchísimas habilidades que caen en el rango de 'artes'. Es un arte poder entender una necesidad y luego plasmarla en un software (empezando por la interfaz y terminando por la arquitectura, o al revés). Es un arte diseñarlo. Es un arte realizarlo.
Y también es un arte depurarlo.