Advertencia: Esta información puede contener trazas de términos técnicos de software. Consulte a su equipo técnico o en nuestro glosario* al final del texto 😉
Not only working software,
but also well-crafted softwareNo sólo software que funciona,
sino también software bien diseñado
¿Por qué?
– Por calidad
– Por mantenibilidad
– Por escalabilidad
– Por el valor añadido y continuado
– Por el trabajo en equipo
– Por el servicio al cliente
– Y, sobre todo, porque somos profesionales del software
Aitor, Danel, Jon, Jordi y Xabi, cinco de nuestros desarrolladores Init Services, han pasado el último fin de semana en Softfware Craftsmanship* Pamplona, primer evento alrededor de esta corriente de la artesanía del software en la zona norte.
El objetivo está claro: reforzar nuestra conciencia sobre la importancia del código limpio*, adquirir nuevos recursos y aplicarlos al fin último de nuestros productos tecnológicos: el negocio de nuestros clientes.
Los detalles nos los cuentan ellos de primera mano.
Las 2 charlas que más te han motivado y por qué:
Danel Ceresa
Programación Funcional*, de Raúl Raja:
“Abre tu mente a otra forma de programar, a otra forma de ver los problemas a los que te enfrentas al desarrollar una solución”.
Software economics, de Carlos Buenosvinos.
“Te hace pensar dos veces antes de invertir tu tiempo en algo que por convención se entiende que se trata de una buena práctica. No todo es aplicable y/o rentable”.
Aitor Aldonza
Errores de los que aprender, de Carlos Blé.
“Expuso su experiencia personal de trabajo en equipo e hicimos intervenciones entre todos de los errores más comunes que crean mal ambiente y descoordinación entre los miembros de un proyecto”.
Ciencia o “MAJIA”, de Aitor Alzola.
“Se expuso una problemática muy común en desarrollo software: la estimación previa de un proyecto. Las conclusiones fueron que a día de hoy sigue siendo la parte más subjetiva de un desarrollo y que no acaba de ser exacta a pesar de la experiencia”.
Xabi Sáez de Ocáriz
La kata* de RPG Combat.
“Después del primer día de charlas me di cuenta de que había sido un error no llevar el portátil. Todo el día hablando de construir software te pone los dientes largos. El segundo día surgió esta kata y siempre es un placer hacer pairing* con compañeros como Guillermo Gutierrez. Es muy ilustrativo aprender cómo razona otro, qué soluciones da y por qué. Además me llevé la motivación extra que necesitaba para aprender los shortcuts* de IntelIJ*.
El par de debates que se formaron en torno a “SOLID* es sobreingeniería” y Software Economics de Guillermo Gutiérrez.
“Es importante, a la hora de adoptar una nueva práctica o tecnología, evaluar el retorno de inversión que tiene el equipo/empresa de ello y no hacerlo porque mola o porque sí”.
Jordi Martí
Software Economics. Guillermo Gutiérrez.
“Empezó con 12 minutos de Luis Artola en los que sintetizó de forma magistral la economía del software, sus derivadas y consecuencias: dónde está el coste, el riesgo, por qué desarrollamos de forma iterativa*, por qué los tests* nos ayudan a minimizar dicho coste y riesgo, y cómo el diseño impacta en ello. De esas charlas que ayudan a recuperar el foco y el por qué de las cosas que hacemos.
Katas Parallel-Change*
“Me encantó la charla de refactoring*, basada en la kata de parallel-change, donde hablamos de diferentes estrategias para refactorizar código, y de cómo el IDE* nos ayuda a hacerlo. Impartida por Carlos Blé, una referencia en el mundo del desarrollo, y autor del primer libro de TDD* en español.
Jon E. Eguiluz
Debate coloquio con respecto a Docker
“Varios participantes compartimos experiencias sobre esta herramienta. Pude aprender conceptos muy interesantes y sobre todo saqué varios links para investigar, que espero que nos ayuden mucho en un futuro próximo”.
Katas Parallel-change
“Lo segundo más interesante fueron unas katas que hicimos sobre paralell-change una técnica de refactor muy interesante. Además de descubrir este nuevo concepto para mí, aprendimos cómo usar el IDE para hacer este refactor, de forma rápida y sobretodo segura”.
¿Qué es lo que más valoras de trabajar en base a Software Craftsmanship?
Jon E. Eguiluz
“Lo que más valoro de este filosofía es que se le da importancia tanto al resultado como al proceso de creación. Dicha filosofía exhorta al programador a mejorar su técnica y su destreza para que el resultado sea mejor, más estable, más mantenible y además hecho con más cariño”.
Xabi Sáez de Ocáriz
“La búsqueda de calidad en el producto que construyes, entendiendo por calidad un código que solo haga lo que tiene que hacer para solucionar el problema del cliente, su negocio, y que está abierto a extenderse en un futuro. Un código que sea comprensible por otros desarrolladores o yo mismo en un futuro. Creo que el aprendizaje continuo y la compartición de conocimiento están en el corazón del Craftsmanship”.
Jordi Martí
“Software craftsmanship es sobre estas tres P, en inglés: Profesionalism, Pragmatism y Pride. Debemos ser Profesionales del desarrollo software, lo cual implica trabajar orientados a cliente y sintiendo dicha responsabilidad hacia este. Pragmáticos: ni tomar el camino corto ni el camino largo, equilibrando la mejor solución hoy con la mejor solución para mañana, mientras escribimos código limpio. Y Orgullosos, ya que el desarrollo de software también es nuestro hobby. Eso permite que nuestro trabajo sea disfrutable la mayor parte del tiempo, mientras resolvemos necesidades reales del cliente. Esto nos hace estar orgullosos, de nosotros y de nuestros compañeros”.
Danel Ceresa
“Nos aporta estabilidad en el código que entregamos al cliente”.
Aitor Aldonza
“Valoro la colaboración de mis compañeros en un intento de mejora continua y de aprender de experiencias”.
¿Qué aporta a tus clientes tu paso por Software Craftsmanship Pamplona?
Jordi Martí
“A los clientes les beneficia directamente esta filosofía, porque lleva a una forma profesional de hacer las cosas. Trabajamos para los clientes, no sintiendo los problemas como marrones, sino como retos que debemos afrontar. Vivirlo de esta forma mejora nuestras capacidades y la relación con nuestro cliente, quien ve en nosotros un verdadero apoyo para crecer en el futuro”.
Aitor Aldonza
“Metodologías y experiencias para mejorar el trabajo. En mi caso particular, sobre todo en cuanto a sistemas de testing y su aplicación”.
Danel Ceresa
“Aprovechamiento máximo de nuestras capacidades como desarrolladores y un aumento en la adaptabilidad de las aplicaciones a las necesidades del cliente”.
Jon E. Eguiluz
“Mejorar la técnica y conocer nuevas herramientas favorece principalmente a los clientes y sus productos: en calidad y en ser productos más mantenibles y flexibles a futuros cambios”.
Xabi Sáez de Ocáriz
“Les aporta trabajar con profesionales que tienen en consideración tanto una solución técnica de calidad como una que responde a las necesidades de cada momento. Productos y procesos de construcción que se adaptan a los negocios de nuestros clientes.”.
A nuestros desarrolladores desde luego, asistir a Software Craftsmanship Pamplona, además de herramientas y metodologías, les ha aportado una gran motivación.
¿Pruebas?
Las que hacen cada mañana desde que han vuelto en katas de TDD para empezar bien el día. Ejercicios de testing para que nuestros productos tecnológicos vayan como la seda.
¿Dientes largos?
Entonces seguramente llevas en la sangre Software Craftsmanship Init Services
Glosario
Software Craftsmanship: Movimiento en torno al desarrollo del software que apuesta por la profesionalidad, el pragmatimo y el orgullo
Código limpio: código mantenible, bien diseñado, testado y testable, etc.
Programación funcional: paradigma de programación declarativa basado en el uso de funciones matemáticas.
Kata: proveniente del kárate, práctica sencilla que en base a la repetición permite alcanzar la perfección.
Pairing: o pair programming. Práctica en la que 2 programadores actúan sobre una problemática, aportando varios puntos de vista sobre el código.
Shortcut: Atajo de teclado. Por ejemplo: “Crtl + C” para copiar.
IntelliJ: IDE de referencia al desarrollar en Java.
SOLID: Acrónimo de los cinco primeros principios de la Programación Orientada a Objetos: Principio de responsabilidad única (Single responsability), Abierto/cerrado (Open Closed), sustitución de Liskpov, Segregación de Interfaces e Inversión de Dependencias. Estos 5, centrados en las dependencias entre artefactos de nuestro sistema, se complementan con otros 6 orientados a la modularización y el packaging.
De forma iterativa: frente a las tradicionales metodologías waterfall donde el trabajo se divide en grandes fases de análisis, desarrollo y entrega, trabajar de forma iterativa permite ver resultados tan pronto se tienen y reducir el riesgo final del proyecto.
Tests: generalmente código que se escribe para confirmar que una funcionalidad (implementada a través de otro código) cumple las especificaciones indicadas.
Refactoring: La refactorización es una técnica de la ingeniería de software para reestructurar un código fuente, alterando su estructura interna sin cambiar su comportamiento externo.
IDE: Un entorno de desarrollo integrado o entorno de desarrollo interactivo, en inglés Integrated. Development Environment (IDE), es una aplicación informática que proporciona servicios integrales para facilitarle al desarrollador o programador el desarrollo de software.
TDD: Test driven design: diseño orientado a tests, donde se escribe primero el test para garantizar que el código escrito a posteriori cumple la especificación indicada, y por lo tanto, lo resuelve.
