Hace unas semanas, llegaron los envíos de Amazon, entre ellos, “The Pragmatic Programmer”, llegaron unas semanas antes de clases, empecé a leerlo aunque aún no lo he terminado, recuerdo cuando leí un artículo de “los libros míticos sobre programación que todo desarrollador debe leer“, la descripción del libro llamó mucho mi atención: “El objetivo es ayudarte en el difícil camino de aprendiz a artesano del bello arte que es la programación”, a pesar de esto no le había dado tanta relevancia cuando se mencionó la palabra “arte”, justo para esto, en clases de Software Engineering, se mencionó el tema de “The Software Craftsmanship” (La artesanía de software).
Empecé a investigar sobre el “Software Craftsmanship”, es un enfoque diferente para el desarrollo de software, el cual da énfasis a las habilidades de codificación de los desarrolladores, no como en el enfoque tradicional, por esto es que busca cambiarlo.
Es cierto que ya es por así decirlo un paradigma para los muggles (personas normales) 😛 e incluso para los mismos desarrolladores verse como profesionales rigurosamente matemáticos en un enfoque de ingeniería (como por ahí dicen que son de pensamiento cuadrado). Como leía en la descripción del libro de “Software Craftsmanship”, que los desarrolladores de software no necesitan verse a sí mismos como parte de la tradición de la ingeniería y que una metáfora diferente sería lo más indicado. La artesanía de software incluso tiene su “Manifesto for Software Craftsmanship”, el cual es reconocido en muchos lugares del mundo y ha sido firmado ya por muchas personas que están de acuerdo con lo que aquí se sigue y ellos intentan promoverlo y difundirlo, en este manifiesto se indican cuatros puntos clave a los cuales se les da mucha valoración:
- “No sólo el software que funciona, sino también el software bien hecho”, no todo lo que se desarrolle por el simple hecho de que funcione significa que este bien, un ejemplo de esto es el hard code, muchos desarrolladores lo usan en ocasiones por falta de tiempo o por no saber cómo hacerlo de otra manera, lo ideal no es solo que funcione si no que esté basado en las buenas prácticas de programación, en el libro “Don’t make me think”, nos dice que al cliente (que muchas veces no tiene experiencia en lo que es software) no se le debe hacer pensar, sino que tiene que encontrar a la aplicación lo más funcional posible (encontrando todo lo que va a resolver sus necesidades fácilmente).
- “No sólo responder al cambio, sino también añadir valor de forma continuada”, nosotros debemos ser conscientes de que el cambio es ya algo inevitable y más bien verlo desde un punto de vista positivo, que mejoraremos lo que estamos desarrollando, es importante que aparte de saber convivir con el cambio, pensemos en que más podemos agregar, siempre es importante darle un plus a nuestro desarrollo.
- “No sólo los individuos y las interacciones, sino también una comunidad de profesionales”, es importante el trabajo en equipo (no el de grupo, ya que muchas veces en un grupo no hay un objetivo en común y todos trabajan buscando sus propios beneficios), si hay errores es bueno reconocerlos para mejorar uno mismo (seguir aprendiendo) y también el equipo mejora porque ya sabrá como enfrentar situaciones posteriores, funcionando como una comunidad en armonía.
- “No sólo la colaboración con el cliente, sino también las asociaciones productivas”, en todo proyecto de software es muy importante que el cliente al dar sus requerimientos trabaje en conjunto con el desarrollador, pero también es importante que se trabaje como una asociación en la que ambos trabajen buscando ser más productivos y mejorar el proyecto que se está desarrollando.
El Software Craftsmanship ve a la formación de un programador como un proceso progresivo del desarrollo de sus habilidades y la adquisición de nuevos conocimientos; la artesanía de software como su mismo nombre lo dice, ve al desarrollo más como un arte y no tanto como una ciencia exacta, ya que valora a la práctica como la mejor forma de aprender y considera como un bello arte (really true) a la programación :D.
🙂 que chevere 🙂
LikeLike
Yo estoy en medio de dar un curso de software libre desde el punto de vista de las comunidades, pero no solo en parte teórica sino también en parte de ingeniería. Me estoy basando en estos libros que compilan la arquitectura de muchos proyectos libres. Arquitecture of Open Source Software es un libro que me ha dado mucho con que apoyarme con la arquitectura del software, y como se ensambla bajo las metodologías de software libre. Sin embargo, también me ha abierto ciertas dudas sobre como puede transmitirse estas lecciones y como llegar a estos resultados.
Creo que pasa algo similar con la artesanía del software ya que habla de lecciones aprendidas. Los autores literarios usualmente son desilusionados de sus obras antiguas de la misma forma que los programadores regresan a ver código de hace algunos años para mofarse de lo ignorante que eran. Eso es, bien un proceso de aprendizaje que se necesita resolver.
Del lado del software libre leí un libro que toca mucho de estos efectos tanto de arquitectura como de artesanía como partes de la cultura unix. Un libro que escribió Eric Raymond llamado The Art of Unix Programming. Donde dice:
LikeLike
Interesante artículo, por cierto cuando termines de leer el libro me lo envías para leerlo, jeje. Lei tu artículo en la revista Hackers & Developers, muy buen trabajo, soy fan de python desde mi segundo año de la carrera cuando me interese por el trabajo con Blender y los scripts. Para ayudar a la divulgación de la revista, se publicó un artículo en el sitio de la comunidad de software libre de Cuba, http://humanos.uci.cu/2012/11/hackers-developers-hd/
LikeLike
Buen artículo, muy claro.
Como aporte, puedo decir que uno puede leer mucha teoría en Internet acerca de que es, o sus manifiestos, pero recomiendo leer “Clean Code – A Handbook of Agile Software Craftsmanship” de Robert C. Martin ya que tiene ejemplos concreto de que hacer y que no hacer, con ejemplos de código/diseño para ser un verdadero “artesano” de software.
LikeLike
buen blog 🙂
LikeLike
Acabo de enterarme que existía algo como esto, o sea formalizado en un manifesto. Ahora ya tengo un documento para justificar mis broncas ante las chapucerías de los colegas que se empeñan a nombrar a sus variables lolo, pepe o chucha, o aquellos para los cuales refactorización es una mala palabra. Aunque pensándolo bien, lo mas seguro es que tampoco lo lean. Ja, peor para ellos, lo bueno es que son pocos, y (en mi radio de acción) se están extiguiendo.
Muchas gracias por el heads-up.
Happy coding Milale, y saludos desde Cuba!
LikeLike