Buscar este blog

lunes, 16 de abril de 2012

Programador vs Desarrollador

    Desde hace unos días he estado pensando en el uso de las palabras programador y desarrollador, y es por ello que me he decidido a escribir mi visión personal sobre ellas.

       Últimamente veo que, dentro de la informática, se utilizan indistintamente ambos términos cuando se quiere hacer referencia a personas que, como yo, trabajan realizando aplicaciones. Si nos vamos al diccionario, veremos que, siendo puristas, sería más correcto hacer en ese caso referencia a un programador que a un desarrollador. Pero es tanto lo que se ha devaluado la palabra programador que a mi personalmente no me gusta, y me explico.

        Por mi experiencia he visto que hay demasiadas personas que se leen un par de manuales de programación o empiezan a hacer una práctica en una clase, y ya están "programando", y más de uno en esa situación te dirá "soy programador" (no creo ser la única que se ha encontrado con uno de estos casos, ante alguien que se ha aprendido tres tags de html y saca como conclusión que es "programador web"). En nuestro ámbito la palabra programador está haciendo referencia únicamente a una persona que escribe código, sin más adjetivos ni requisitos. Que esto se ha extendido mucho, que hay mucho intrusismo en nuestra profesión, que la culpa de este intrusismo la tenemos nosotros... creo que todo eso daría para una entrada a parte (o varias entradas, siendo sincera), pero el hecho es que esto ocurre, y que personas que no te sabrían decir la diferencia entre poner <p/> o <br> se autodenominan programadores.

        Según el DRAE programar en su acepción informática es "Elaborar programas para la resolución de problemas mediante ordenadores", definición en nada opuesta al hecho único de escribir código. Yo leo esto y pienso, “¿realmente es esto lo que mis compañeros y yo hacemos?”. Y siendo sincera, mi respuesta es “NO”.... no sólo eso. Es una definición demasiado simple: elaborar un programa para resolver un problema lo puede hacer el del par de manuales y los tres tags. Entonces, ¿cual es la diferencia? Pues que nuestro trabajo tiene algo más: tiene un análisis, tiene un diseño, tiene una optimización, tiene pruebas, tiene darle mil y una vueltas al problema para buscar la mejor solución, tiene el seguimiento de una o varias metodologías, … y por supuesto también tiene escribir código. Y la palabra desarrollador define muchísimo mejor la unión de todos estos requisitos que la palabra programador.

         Desde que escuchas la palabra desarrollar te viene a la mente un proceso, una serie de pasos conscientes, un análisis de la situación,... Es algo más complejo y a la vez más ordenado, con un proceso de razonamiento y la necesidad de un conocimiento previo. Por decirlo de alguna forma, dentro de la informática, quien desarrolla una aplicación también la programa, pero no todo el que programa desarrolla.
        
         Es por esto que, sí, si me dicen que soy programadora, siendo “purista”, no puedo ofenderme, que esto es una visión personal pero, por favor, llámame desarrolladora :)


lunes, 2 de abril de 2012

Concordion

     Para estrenar este blog con algo más profesional que los agradecimientos, me gustaría hablar de Concordion (http://www.concordion.org).
     Concordion es una gran herramienta para la automatización de especificaciones activas, de gran utilidad en desarrollos ágiles como Scrum, TDD o BDD. Es más, puede ser realmente útil a la hora de unificar estas tres tecnologías (que ya de por sí se llevan bastante bien, pero una ayudita extra siempre es buena).
     A grandes rasgos, a través de Concordion escribimos en formato html qué es lo que tiene que realizar nuestra aplicación y, con ayuda de tests JUnit (es decir, podemos incluir tanto test unitarios como tests Selenium), comprobamos si estas especificaciones se cumplen, dándonos como resultado un archivo de salida en html en el que se muestran en rojo las especificaciones que no han pasado el test y en verde las que si han pasado (para una explicación más clara del uso de Concordion podemos recurrir a su tutorial, en español, sencillo y realmente claro).
    ¿Qué es lo que más me gusta de Concordion, y lo que me ha llevado a escribir esta entrada? Pues los siguientes puntos:

  • Facilidad de uso en general, y de implantación en sistemas que ya tienen implementados los tests. La forma de definir las especificaciones es realmente sencilla e intuitiva, y el comenzar a usar las herramientas propias de Concordion no tiene por qué llevar más de 10 minutos.
  • Facilidad de integración con Spring. Tengo que admitir que cuando hice la primera prueba me quedé pensando "si, vale, muy sencillo, pero ahora cuando quiera utilizar la inyección de Spring, y correr los test con el JUnit de Spring, vendrá lo simpático". ¡Nada más lejos de la realidad! Cambiar un test hecho completamente con Spring para que use Concordion puede tardar... ¿5 minutos sin estresarse? Simplemente cambias el test original para que reciba los parámetros de Concordion y devuelva el dato que quieres que devuelva, y haces un test que procese el test de Concordion, y ¡ya está! Es así de sencillo (un ejemplo de la implementación se puede encontrar aquí, y sí, el test de procesamiento con Concordion son sólo tres líneas).
  • Facilidad de uso con Scrum, TDD y BDD. Por lo menos para mi imaginarme el ciclo de vida de una funcionalidad con estas metodologías usando Concordion me resulta simplemente evidente, y una forma de facilitar a los analistas / consultores el definir la funcionalidad de forma que cuando llegue al desarrollador sea entendible y que, cuando el desarrollador entregue la implementación, el consultor pueda ver fácilmente si se cumplen sus especificaciones. Tal como lo veo:
  1. El consultor definiría las historias de usuario indicando qué condiciones de entrada se tienen que cumplir y qué salidas se esperan, siguiendo las recomendaciones de Concordion, por ejemplo, "Si el usuario no es de rol X, no podrá obtener la lista de productor". Si tiene conocimientos suficientes como para especificarlo directamente en un documento html, mejor que mejor.
  2. El desarrollador definirá el fichero html que comprueba esta prueba en Concordion (bien creándolo desde 0 si no se lo entrega el consultor, o modificándolo para usar los tags específicos).
  3. Se crean los tests que comprueban si se cumplen las especificaciones que ha indicado el consultor.
  4. Se implementan los métodos necesarios para que se pasen los test y se refactoriza.
  5. Una vez probada la implementación, se lanzan los test Concordion, generando el reporte html que se pasará al consultor donde se indica que las especificaciones que ha solicitado se cumplen en la aplicación.
          No sólo se facilita la comunicación entre consultor y desarrollador, sino que se obtiene un documento que especifica que se obtienen los resultados esperados, todo dentro de metodologías ágiles que no sólo no nos harán perder el tiempo en pesada documentación, sino que facilitará ver como se va incrementando la funcionalidad de las aplicaciones.

Agradecimientos

Como primera entrada me gustaría dar las gracias a una serie de personas que han tenido mucho que ver en el nacimiento de este blog, cuyo nombre es "Renacimiento de una informática", porque me he decidido a crearlo tras darme cuenta de que desde hace un tiempo había entrado en un conformismo y, quizá en cierta forma apatía profesional, que realmente no iba conmigo, ni por forma de ser, ni por el hecho de que me encanta mi trabajo y me encanta conocer, investigar y probar cosas nuevas, y al darme cuenta de ello he podido reaccionar cuando aún era posible, y volver a ilusionarme con mi profesión:

  • Por una parte, quiero agradecer a Jose Luis Rodriguez, a David Bonilla y a Atlassian, por la reciente oferta que han sacado, en la cual van a contratar a 15 programadores en Europa. A Jose Luis por pasarme el link (seguramente por mi misma, tal mi apatía, no me hubiera enterado), a David por la tremenda y perfecta difusión que ha hecho y a Atlassian por sacar esa oferta. Aunque me haya quedado en el camino del proceso de selección, lo cierto es que en vez de ser una decepción por no pasar, el hecho de animarme a enviar el curriculum y atreverme a intentar un cambio tan radical me ha hecho despertar, volver a informarme, a investigar,.. (y a tomar clases de inglés, que buena falta me hacen, y que desde luego no pienso dejar :) ). 
  • Por otra parte, para mi la más importante, gracias a Ramón (mi pareja) por, al decirle "estoy pensando en enviar un curriculum para un trabajo en la otra punta del planeta donde hablan un idioma que no conoces" su respuesta fuera un rotundo "adelante, tienes todo mi apoyo", y a mi familia por responder a la misma cuestión con un directo "cuenta con que te iríamos a visitar seguro".
  • Todo esto ha hecho que haya vuelto a buscar nuevas y mejores formas de hacer las cosas, y realizar nuevas propuestas en mi actual trabajo, y en este aspecto también quiero agradecerle a Domingo que no sólo no me coartara en estas ganas, sino que escuchara mis propuestas, me animara a seguir con ellas y se mostrara tan ilusionado con ellas como yo lo estaba.
  • Y un agradecimiento algo más ... "raro", a Steve Jobs, pues todo esto además ha coincidido con que me estuviera leyendo su biografía, y en cierto modo me ha ayudado a contagiarme de las ganas de hacer cosas diferentes y especiales que él siempre tuvo.