La vergüenza de la ingeniería del software

01-06-2009 Luis Artola

Hace tiempo que uso en mis proyectos, de forma más o menos informal, las pruebas unitarias y funcionales. No lo uso en todo tipo de proyectos (si, por ejemplo, estoy creando una personalización de wordpress con una serie de funcionales, no pruebo unitariamente un plugin de wordpress com phpUnit), pero si que trato de apoyarme tanto en phpUnit como en Selenium para tratar de asegurarme de entregar funcionalidades lo más robustas y libres de error posible.

El momento de mayor vergüenza como profesional suele ser, cuando entrego una nueva funcionalidad y no soy capaz de asegurarle al cliente de que funciona en todos los casos o, peor aún, cuando entrego una nueva funcionalidad que me ha hecho cambiar código anterior, y ha hecho que cosas que ya funcionaban correctamente hayan dejado de hacerlo.

Como profesionales de un sector que todavía inmaduro, buscamos una manera de denominarnos que nos dé cierto caché y que, a poder ser, eleve nuestros ingresos por encima del mileurismo. Por eso se oye habla de “ingenieros del software”, “arquitectos de información”, etc.. Soñamos con encontrar una manera que nos acerque a los sueldos de un “ingeniero” o de un “arquitecto”… a veces es patético.

El caso es que yo estoy harto. Por eso he decidido apostar muy fuerte por la Integración continua. Resumiéndolo muchísimo: la integración continua trata de ejecutar “continuamente” una serie de pruebas y métricas sobre el código para que cada vez que publiques nuevas funcionalidades puedas asegurarte, aunque sea mínimamente, de que tu código se encuentra probado sin que esas pruebas te eleven enormemente el coste de desarrollo.

Hace un tiempo hable con David y nos hemos propuesto crear un servidor de integración contínua en PHP (basándonos en phpUnderControl y herramientas varias) que transforme la forma en que entregamos funcionalidades al cliente y eleve un poco nuestra moral como programdores.  :-D

Hago una llamada también a todos aquellos que hablen sobre integración contínua en PHP en sus blogs/páginas (google-ando he visto que son unos cuantos) para que me escriban un comentario en éste post y nos pongamos en conversación porque también vamos a montar una pequeña comunidad alrededor de éstas tecnologías.

Tendréis noticias.  :-D

Etiquetas:
, , ,

21 Comentarios

  • 1. Pelos  |  junio 1st, 2009 at 9:24 am

    He visto que en otro post citabas a Fabien Potencier, creador de symfony. Quizas te interese saber que esta trabajando en algo del estilo. Por ahora toda la información sobre el proyecto la ha dado mediante su twitter http://twitter.com/fabpot Se espera que lo libere en unos pocos meses, y por ahora existe una demo en http://ci.symfony-project.org Lo que mas gracia me hace es uno de sus tweets: “quiero popularizar el uso de test haciendolo facil de cojones” (traducción libre)

    La verdad es que es un tema que me interesa mucho, porque no tengo ni idea, y se que no me vendria nada mal realizar tests.

  • 2. josepzin  |  junio 1st, 2009 at 11:18 am

    Por empezar no tengo idea qué es eso de “integración continua”… me tocará investigar un poco.

  • 3. Chefwww  |  junio 1st, 2009 at 11:44 am

    Me he instalado el phpUndercontrol y todas las herramientas suplementarias. Tiene muy buena pinta. Pero tengo algunas dudas a ver si me las puedes resolver.

    1) Como se hace para crear un proyecto nuevo.
    2) Lo podría crear en la carpeta de los proyectos php /var/www/html por ejemplo?
    3) Se puede usar sin csv? Es decir si yo modifico el script de php directamente, el phpundercontrol lo detecta?

    Realmente si hicieses un entrada explicando los pasos básicos me sería de gran utilidad. De momento voy mirando la documentación a ver si saco algo en claro.

    Un saludo y excelente blog!

  • 4. Luis Artola  |  junio 1st, 2009 at 11:54 am

    tranquilos chicos.. pronto empezarán los post con introducciones y tutoriales.. no soy una máquina… :-D :-D

    Un saludote!

  • 5. blaxter  |  junio 1st, 2009 at 1:23 pm

    ¿para qué reinventar la rueda?. Tienes sistemas de integración continua en cantidad, y de calidad. Lo de menos es eso, lo importante es que en cada proyecto hagas todos tus test, ahí es donde hay que invertir trabajo. Por poder te puedes hacer un sistema de integración continua con cron.

    Yo uso bitten por su integración con trac, pero tienes muchos otros como Hudson o CruiseControl. El lenguaje en el que esté implementado no importa, no sé qué manía tiene la gente con decir “integración continua para XXXX”.

  • 6. Ale Muñoz  |  junio 1st, 2009 at 2:15 pm

    +1 para CruiseControl (sobre todo porque veo que phpUnderControl en realidad es un módulo para CruiseControl)

    Si queréis mirar algo más ligero (aunque menos probado), Integrity tiene pinta de ser bellamente hackeable: http://integrityapp.com/

    Ah, y coincido 100% con #4, reinventar la rueda no tiene sentido y el lenguaje de tu sistema de integración continua debería ser irrelevante. Los muchachos de Integrity te dicen:

    “as long as your build process can be run from an unix-y environment and it returns a zero status code for success and non-zero for failure, then integrity works for you”

    Y eso : )

  • 7. Luis Artola  |  junio 1st, 2009 at 3:55 pm

    Me apunto todo lo que me comentáis!! (sabía yo que publicar éste post iba a traer réditos rápidos… :-D )

    No pensamos reinventar la rueda… sino utilizar las herramientas que ya existen intentando mejorar su integración y generando tutoriales y documentación decente en castellano…

    graciasi por esos links!

  • 8. Joserra  |  junio 1st, 2009 at 8:43 pm

    Jjeje, los javeros lo tenemos algo más facil. En ello estamos!
    Si te interesa, hace poco creamos un grupo de TDD (no enfocado a ningún lenguaje particular) en castellano: http://groups.google.com/group/tddev-sp

    Salu2

  • 9. Luis Artola  |  junio 2nd, 2009 at 6:51 am

    Hola Joserra!

    soy parte de ese grupo y del de metodologías ágiles… :-D

  • 10. freddy  |  junio 3rd, 2009 at 3:28 am

    Personalmente creo que los desarrolladores web estamos bastante desvalorizados y gran parte de la culpa la tenemos nosotros.
    Cuantas veces me he encontrado con desarrolladores web que son simples coders, que lo único que hacen es copy/paste y carecen de inovación, no tienen idea de patterns, buenas practicas, metodologias, manejo de requerimientos, documentación, uml, etc.
    Aún no esta en la conciencia gral, que la complejidad que poseen ciertos desarrollos web, dejan de ser simples paginas para ser productos de software con todo lo que ello involucra.

  • 11. 3wstudio» Links del&hellip  |  junio 3rd, 2009 at 12:59 pm

    [...] La verguenza de la ingenieria en software [...]

  • 12. phproll  |  junio 3rd, 2009 at 9:16 pm

    bueno para nadie es un secreto que php no es lo idea para este tipo de cosas, ni para asegurar calidad, ni para seguridad.

    para todo lo demas python.

    python es el unico lenguaje que vale para la web, lo demas es basura y juguetes

  • 13. Luis Artola  |  junio 3rd, 2009 at 11:12 pm

    ¡Eso es! ¡Qué coño! Con python todo es seguro y de calidad! XDD

  • 14. Tipos de pruebas automati&hellip  |  junio 5th, 2009 at 8:27 am

    [...] el otro día sobre la necesidad de utilizar un servidor de integración contínua en el desarrollo de una aplicación, para poder entregar software con cierta garantía de calidad. Un servidor de integración continua [...]

  • 15. blaxter  |  junio 5th, 2009 at 12:41 pm

    don’t feed the troll

  • 16. Integración continua en &hellip  |  junio 24th, 2009 at 8:25 am

    [...] Un servidor de integración continua es algo mucho más sencillo de lo que parece. Básicamente sólo se dedica a ejecutar un proceso periódicamente (cada cierto tiempo, o cada commit del repositorio) que automatiza el proceso de construcción del software (build). Para entendernos, uno podría programar un script de terminal que llamara al framework de pruebas unitarias, y al generador de la documentación y a los analizadores de métricas de código, etc… y que se ejecutara cada cierto tiempo mediante el cron, y con eso estaría haciendo integración continua. Siendo esto así, el servidor de integración continua es independiente del lenguaje en el que esté escrito el software que está integrando (todo esto ya lo comentaba Blaxter en un post anterior de este blog). [...]

  • 17. Críticas a la ingenierí&hellip  |  julio 21st, 2009 at 10:55 am

    [...] Yo también creo que muchas veces se utilizan las palabras “Ingeniería del software” de forma patética… [...]

  • 18. » Interredes DevBlo&hellip  |  enero 2nd, 2010 at 4:49 am

    [...] http://www.programania.net/desarrollo-agil/la-verguenza-de-la-ingenieria-del-software/ [...]

  • 19. aydim dagam  |  marzo 22nd, 2010 at 10:31 am

    Un post muy interesante.
    yo soy desarrollador. aunque vengo de la rama del diseño. y digamos que ‘las cosas más informáticas’ se me atragantan más.
    estoy empezando con symfony y control de versiones. eso sí, con Git, aunque nada se dice de Git por estos lares. espero que no sea difícil utilizar CI con git (y PHP of course). Ahora voy a por la pruebas unitarias, phpunit y selenium me ha parecido lo más interesante, además lo usará symfony.
    en fin, que eso de crear una comunidad que defienda los derechos de los desarrolladores y para que no seamos tratados como jodidos becarios me parece muy interesante. dónde hay que firmar?… xDD

  • 20. NerKinet » Archivo &hellip  |  mayo 26th, 2010 at 8:00 am

    [...] pero es que el estado actual del desarrollo de software produce muchos momentos de vergüenza (http://www.programania.net/desarrollo-agil/la-verguenza-de-la-ingenieria-del-software/). El día que el desarrollador sea capaz de asegurar que el desarrollo de nuevas funcionalidades no [...]

  • 21. Lo que los gurús nunca t&hellip  |  junio 17th, 2010 at 9:37 am

    [...] A principios de año comencé un nuevo proyecto de migración de una extensa intranet. Un proyecto que me va a llevar todo un año y, por supuesto, una buena oportunidad para aplicar todo lo que he ido leyendo sobre métodos ágiles (y superar la vergüenza del desarrollo de software). [...]

Comenta el articulo:

Requerido

Requerido,