Estás en: Cristalab > Artículos > Introducción a la Programación Extrema
Introducción a la Programación Extrema
Por: _CONEJO +
27 de Agosto del 2007
Programación Extrema ¿Pero qué demonios es eso? La desconocidaProgramación Extrema es una metodología de programación que, en muchos casos, hace las cosas bastante más sencillas.
Nos enfrentamos a un nuevo proyecto y lo primero que hacemos es sacar lápiz, papel y pasar unas cuantas horas diseñando la estructura del proyecto, definiendo las relaciones internas y la interfaz de las diferentes clases y métodos. Después empezamos a programar propiamente dicho y en último lugar, y con menor importancia, finalmente testeamos nuestra aplicación. En teoría, y en teoría funciona el comunismo; pero sólo en teoría, este esquema es perfecto : Planificar, Construir y Buscar Errores (que no debería de haber ninguno). Pero si alguna vez lo has usado, sabrás que se cae por su propio peso en la mayoría de casos. Piensa en aquel momento que descubriste un error y tuviste que revisar cientos de líneas de código para taparlo, y la solución era un gran parche para no tocar el resto de tu super-código. O aquel en el que pasaste horas y horas definiendo métodos de clases que al final no llegaste a usar, porque en la práctica te saltaste toda esa teoría aburrida y en vez de unos setters decidiste hacer públicas las variables y modificarlas "a pelo".
Ahí es donde interviene la programación extrema, haciendo el proceso más práctico que teórico. La programación extrema (a partir de ahora XP - eXtreme Programming - para facilitar las cosas) es perfecta para proyectos pequeños y medianos, pero es aún mejor para grandes proyectos o de alto riesgo.
¿En qué se diferencia entonces la XP de otras metodologías? En la XP, la importancia de los test (para encontrar errores) y la experiencia del cliente (feedback) adquieren una mayor importancia, haciendo que se trabaje en ciclos de menor tiempo. Tranquilos que lo explicaremos todo.
A tomar por culo toda la teoría La teoría está muy bien, pero es eso, "teoría". Sólo hay que ver que se inventaron los atributos public para las variables en lenguajes orientados a objetos, cuando "en teoría" todas deberían de ser privadas y controladas mediante setters y getters. Eso no significa que no piensen antes de empezar un proyecto. Es bueno (y necesario) hacer un mínimo esquema de cómo deben de ser las cosas y funcionar el sistema, pero no pasar horas y horas de organización (todo dependerá del tamaño del proyecto). Recuerda que poca organización es mala, pero en exceso también.
Los tests antes que el programa La XP llevada al extremo implica que se escriban los test (debug tests) antes que la propia aplicación. Esto tampoco es estrictamente necesario, pero sin embargo hay "Tests Units Frameworks" que son una serie de tests pre-fabricados para aplicar directamente a tu aplicación. ¿Por qué?¿Por qué son tan importantes? Cuando se programa de la forma old-school, uno deja para el final el testear su aplicación y encontrar errores. Esto significa que se le da una menor importante porque "en teoŕia" el programa no debería de fallar, aunque la realidad sea otra. Además suele ocurrir que al encontrar un fallo se aplica un parche que sólo ensucia el código y que ni siquiera se integra bien con el código. Sed sinceros, ¿cuántos de vosotros ha creado variables y métodos especiales para solucionar un fallo, cuando podría haber utilizado parte de los recursos a existentes?¿Y después nos olvidamos de esas variables, sin borrarlas ni nada?
Testeando nuestra aplicación desde el primer momento, nos aseguramos de que el código escrito hasta entonces es correcto y no estropea lo anterior. La programación orintada a objetos facilita esta tarea, ya que los objetos tienen una "interfaz" y deben responder ante ciertos "estímulos". Así por ejemplo, en un caso práctico, podríamos escribir los métodos vacíos de una clase, dentro de cada método escribir solamente el código necesario para que imprima por pantalla un mensaje que diga que se llegó a tal método o a tal otro. Y después, poco a poco, ir escribiendo el resto del código.
Haz compartimentos estanco Si todo tu programa es una gran bola de código inentendible, cuando haya un agujero te entrará agua y te hundirás en la balsa. Si por el contrario tu barquichuelo está hecho a base de compartimentos estancos y uno está agujereado, seguirás a flote porque el resto no se inundará. Hacer pequeños trozos independientes de un programa es casi una obligación de nuestros tiempos y una de las bases de la XP. Tanto si trabajas en solitario como en un grupo, las ventajas son infinitas. Si trabajas en grupo, cada uno de tus compañeros puede trabajar en un apartado diferente del programa ahorrando tiempo de desarrollo, además al ser "independientes" si falla un "módulo" del programa, sólo se necesita reparar ese módulo, el código estará localizado en un grupo de archivos menor y se solucionará con mayor rapidez. Haz módulos según necesites.
Consulta con el cliente El feedback es importante, y la XP lo potencia al máximo. Si el programador idea una forma de ir desde A hasta C pasando por B, el cliente o el usuario encontrará la forma de ir directamente de A a C generando errores por el camino. A cada poco se suelta una beta para testeo, con la información resultante de los testeadores se hace una "pequeña" release. Pequeños cambios implican pequeños errores que se solucionan en menor tiempo. Esto va acorde con el de hacer pequeños módulos en el programa, y se van probando los módulos uno a uno según su desarrollo.
En grandes proyectos y de riesgo, utiliza la XP ¿Tienes un gran proyecto?¿Algo nuevo para tu equipo de desarrollo?¿Para la industria del software?¡La XP es para tí! La XP proporciona un camino fácil para alcanzar metas simples a corto plazo que formen parte de un proyecto a mayor escala. Con la XP puedes establecer mejores roadmaps (planes de desarrollo y tiempos de entrega) tener un mejor control sobre el producto porque a cada paso que des tendrás un producto funcional, no tan completo como el proyectado, pero funcional.
Conclusiones La XP está ahí afuera. Es un recurso útil y al igual que muchos de los patrones de programación (MVC, Singleton, ...) posiblemente estés usando ya parte de la XP en tus proyectos a diario, pero nunca viene mal conocer algunos consejos extra para hacernos más ágiles en el desarrollo de software.
Llevo toda la vida haciendo programación de esa y pensé que ir hacia la planificación extrema era evolucionar y mejorar... He fallado en la vida de nuevo Por:MorphX
No soy programador, pero muy interesante el articulo!
Esta bien explicado y suena muy logico todo......para algo me servira!
Gracias conejo!
Cada dia aprendiendo más. Por:pabletein_blog
Lindo artículo. De todas formas, tras varios años de intentar hacer "grandes proyectos" por mi mismo me di cuenta que no hay nada mas valioso que un aliado, asi que ahora la mayoria de los proyectos los embarco junto a otra gente. Y siempre usamos XP sin saberlo Por:Señor Nacho_blog
No es un buen método cuando tienes un cliente voluble. Por:DaHouseCat_blog
Siempre he considerado a XP util cuando tienes un cliente necio, de hecho para eso se construyo para cambios durante la fase de desarrollo es una metodologia que se adapta muy bien, pero para mi la mejor opcion siempre ha sido FDD(feature driven development)
Saludos! Muy buen articulo _Conejo Por:Prozac_blog
Y pensar que siempre creí que lo estaba haciendo mal
Hola, soy desarrollador al igual que muchos de ustedes, y actualmente trabajo con metodologia a la opuesta de la XP (no la conosco al 100%) , esta se llama CMMI , yo pienso que el convinar las dos traeria mas veneficos por que: 1.- Por si sola la XP, deja muchos procesos sin documentacion, ya que si es cierto que mucho proceso entorpece y quita tiempo, pero entre mas vigilado este el proceso y documentado, la empresa sabra a todo momento como va realmente el avance del proyecto, y no llegara a preguntarle al programador: ¿como vas?? --- Jefe. ¿Pues ahi la llevo, ya casi termino?--PROGramador. Ese casi no le dice nada a un lider de proyecto o aun Gerente. Bueno espero entiendan m diferencia de opinion y pues como dije, no estoy encontra, si que si se combinara con otra metodologia estaria mejor. Saludos Por:Francisco ROberto_blog
sin saberlo y asi tambien trabajo yo, Por:clydde_blog
Es verdad lo de la documentacion, pero bue se podran documentar los test no??
Saludos. Por:rodrigo.art_blog
pues me pasa igual, sin saber que existia el XP, asi he trabajado
Excelente artículo _conejo. Todos nosotros como desarrolladores siempre hemos tratado de implementar un flujo y una metodología ágil, versátil y fluida. Nos ahorra demasiado tiempo así como reducir los costos del proyecto y los recursos técnicos empleados.
Y pues si, efectivamente, muchos de nosotros hacemos uso de esa metodología a diario son darnos cuenta. En cuanto a otras metodologías puedo reiterar que es como a cada quién le acomode y según optimice sus tiempos. Tal vez no todos desarrollan de la misma manera por la sencilla razón que tal vez otros hallan más fácil (mas no más practico) método para sus proyectos.
Por:glsmaster
manolo_blog :
dejense de XP y pasense a ubuntu.
Creo suponer que leyo completo el Articulo.
Muy buen Articulo Conejo, me parece que llevo ya tiempo utilizando esta metodologia sin saberlo y pensar que segun yo utlilizaba la de prueba y error . Por:flashreloco
"yo ya la usaba"Como todo en la vida siempre usamos un poco de esto o de aquello. Quien más quien menos ha utilizado algunos patrones de diseño sin saberlo al igual que la XP. Sin embargo la XP no es que compiles y pruebes TÚ muchas veces, si no que sea (primeramente) los tests y luego el cliente (o en su defecto un equipo de testers) e ir cumpliendo objetivos poco a poco. Un buen ejemplo de esto pueden ser algunas distribuciones Linux, que salen cada 6 meses (es poco tiempo para un sistema operativo) en el que se van introduciendo mejoras de forma gradual (no como en windows por ejemplo).
Personalmente la única vez que intentaron enseñarme algo de programación de forma oficial (en cursos) era Java y decidí no asistir. Mucha gente (sobre todo ahora) empieza con Java, que para aprender POO está muy bien, pero es un lenguaje harto aburrido y repetitivo, demasiado teórico de "creo tal clase con tal interface que hereda de tal otra"... Hey, primero veamos realmente qué necesitamos y vayamos poco a poco.
Grandes proyectos Gato, la XP sigue siendo perfecta para grandes proyectos. Tienes un proyecto de grandes proporciones, es novedoso para tu equipo de trabajo e incluso para la industria del software... ¿Qué usas? ¡¡ La XP !! ¿Por qué? Es sencillo, cumples pequeños objetivos, es más fácil plantearse una serie de objetivos a dos semanas vista cada uno que un gran objetivo a 6 meses de desarrollo. Grandes tiempos de desarollos son malos, al final se pierde mucho tiempo porque al principio dices "ya habrá tiempo", además de que es más dificil de depurar y encontrar errores.
Si construimos una casa, primero ponemos los cimientos, luego las paredes interiores, luego las exteriores y finalmente decoramos. Esto está bien, sea la casa grande o pequeña funciona pero... si la casa es grande, podemos perder demasiado tiempo con los cimientos o perder definitivamente el enfoque del proyecto, si el tiempo se agota tendremos unos cimientos pero no un techo donde cobijarnos. Con la XP primeramente haríamos los cimientos de una habitación, conforme empecemos con sus paredes veremos que necesitamos tirar los cimientos de las habitaciones contiguas y así, ir habitación por habitación, metas creibles y realizables en cortos periodos de tiempo. Si el tiempo se agota siempre podremos capear el temporal del cliente malhumorado y enseñarle "parte".
Cambios en el diseño/estructura Está claro Prozac, si a mitad se decide incluir/excluir una nueva característica, esta es la metodología con la que menos daños sufrirá el proyecto. Además no sólo sirve para eso, si no que si te adentras en "terreno inexplorado" es lo tuyo. Digamos que diseñas un juego, cuando los testers lo prueban dicen "pues estaría bien que hiciese tal cosa" y no sólo en juegos, si no en cualquier programa al cual debas de dar soporte durante un tiempo.
No se documenta Bueno, documentar o no es cosa tuya, si es cierto que no hay una documentación "pre-programación" aunque unos buenos nombres de variables y métodos, así como una documentación posterior facilitaría mucho la tarea de mantenimiento del código. Digamos que NO HAY una planificación muy detallada (pero la debe de haber siempre), pero una documentación es necesaria si se planea mantener el código. @Francisco Roberto : la situación que planteas no es de la XP, es cosa del programador, de hecho, al tener objetivos más pequeños se controla mejor lo que se ha hecho y lo que no. Por:_CONEJO
si sí, realmente ya estamos usándola... hace muuucho tiempo Por:Loon
Se me olvidaba una cosita en el comentario anterior. Con eso de que "JAVA es un lenguaje harto aburrido y repetitivo, demasiado teórico..." ¿estás de broma verdad? Por:dav_blog
dav_blog :
Se me olvidaba una cosita en el comentario anterior. Con eso de que "JAVA es un lenguaje harto aburrido y repetitivo, demasiado teórico..." ¿estás de broma verdad?
Pero lo es ¿Has intentado programar en Actionscript 3 comparado con Java para interfaz gráfico? Es más cómodo y divertido hacerle ingeniería inversa a un script de perl que escribir código de interfaz en Java. Por:Freddie
¿Comparar Actionscript con Java? Java no es sólo para crear interfaces gráficas, de hecho diría que eso es una pequeñísima parte de java. Eso de "cómodo" y "divertido" no tiene nada que ver con una robusta aplicación. Con respecto a usar flash en una aplicación, bueno habrá muchas opiniones pero a mi desde luego me resulta mucho más agradable navegar por una aplicación HTML-Javascript-CSS que por otra con flash. En relación al soporte que te puede dar una empresa para un desarrollo profesional, comparar Macromedia con Sun se me antoja muy parecido a decir que MySQL no tiene nada que envidiarle a Oracle. Por:dav_blog
JAva puede ser aburrido, si quieres programar en flash, por que flash esta orientado a graficos.
No intentes dibujar con un Cañon ni derruir castillos con un pincel...
A buen entendedor, ... Por:Uno de españa_blog
dav_blog :
¿Comparar Actionscript con Java? Java no es sólo para crear interfaces gráficas, de hecho diría que eso es una pequeñísima parte de java.
Claro, pero es el punto del conejo. El conejo no programa para servidor, programa para cliente, por ende, Java le es horrendo y aburrido. Java es perfecto para el lado del servidor.
dav_blog :
En relación al soporte que te puede dar una empresa para un desarrollo profesional, comparar Macromedia con Sun se me antoja muy parecido a decir que MySQL no tiene nada que envidiarle a Oracle.
MySQL tiene poco que envidiarle a Oracle, a excepción de la increible base de usuarios tipo SAP que tiene Oracle, así como el lobby que tiene en las universidades (Hey, como Java).
En conclusión: Es cosa de contexto. Java, como dije, es perfecto para el lado del servidor, pero es aburridorsisimo y las metodologías que se usan del lado del cliente para "hacerlo robusto" se pueden hacer igual en la mayoría de otros lenguajes. Como ejemplo que puse, Actionscript 3. Un gran lenguaje para cliente que copia mucho de Java pero le quita todo lo "tedioso" de sus millones de interfaces y frameworks insufribles (Del lado del cliente). Por:Freddie
Muy bueno Conejo, bueno es poco, esta excelente. Como algunos antes que yo. Ya hacía algo parecido , pero no sabía como llamarle . Ahora si puedo ir por ahi con mi "Hago XP, ¿y ustedes? ". Por:R4f43l
De hecho XP es una metodologia que uno temrina adoptando debido a la falta de tiempo o compromiso, pero viendo un proyecto a gran escala que debe evolucioanr se peude tornar riesgoso no hacer las tareas con cierto tiempo, no llevando todo al EXTREMO !!! Por:RaC_blog
@dav_blog , Java existe y tienes sus usuarios fieles. Y está muy bien, pero como dice Freddie de parte del cliente es insufrible. Te puedo dar mis opiniones personales con la parte que me tocó lidiar o te puedo decir casos reales de java.
La mayor empresa informática de la región "ganó" el concurso para hacer el software de las bibliotecas municipales de toda la comunidad (de hecho, la versión anterior también era suya). Al proyecto, además de unos cuantos millones le dieron un plazo de un año. Empezó a ser desarrollado en Java. Ahora llevan MÁS DE TRES años de desarrollo, la empresa ha tenido que contratar a 3 personas más para este proyecto únicamente y te aseguro que no está ni por asomo acabado o con pinta de acabar. Y no creas que cogieron a unos mandangas que iban por la calle, fueron a buscar a los mejores en el tema.
Por mi parte, cuando recuerdo el mini-ahorcado que hice y la cantidad de código sobrante y repetitivo que había me entran temblores y eso que sólo era uno de los muchos ejercicios que tuve que entregar.
Java es bueno, es rápido en cálculos y con una sintaxis relativamente cómoda, siempre y cuando te dediques a hacer aplicaciones de consola y no interfaces para el usuario. Por:_CONEJO
Proceso unificado de desarrollo de sotware:
Dirigido por casos de uso. Centrado en la arquitectura. Iterativo e incremental. Por:Pitxon_blog
Aclarado el tema. Lo que ocurre es que yo programo java del lado de servidor, y creí que iban por ahí los tiros. En cuanto a cliente solo he programado algún applet y llevas razón en que es bastante dificultoso.
Gracias por las aclaraciones Por:dav_blog
que cheere como clab se torna mas un sitio mas para devs =) Por:carlosczg__blog
La verdad es que a mi me encantaría saber programar, ya no de forma extrema, si no normal. suerte que existe el Dreamweaver, los códigos libres de javascript y Cristalab, porque si no estaría muy jodido. Por:Sisco
Puej que les digo creo que xp es usado por muchos(Por no decir todos) de una o de otra forma solo que considero que tambien tiene su falencias personalmente me gusta mucho esta metodologia pero creo que para proyectos grandes el lado de la documentacion nos es muy confiable que digamos, no nos olvidemos qe el control y respaldo de los procesos es fundamental dentro de un sistema Por:sisweb
a me olvidava felicidades por el articulo ( Por:sisweb
Está chido el artículo _CONEJO, pero explica un poco más sobre como aplicarlo. Suena bastante chido, pero debería tener un lado más práctico. Por:spacecowboy
Para mi esta es la forma más rápida y sencilla de trabajar, lo separas en bloques de código (archivos, modulos, plugins) y usas un sistema de logging adecuado, cuando algún modulo en específico muestra un error, el logging ayudará a explicar el problema y el beta-tester podrá copiar/pegar el error para que entiendas que suceda.
Por otro lado, mientras mejor estructurado esten los modulos, y mejor documentes tu código será más fácil para otros usar tu trabajo, sea un proyecto libre o privado.
Se ha comprobado en muchos proyectos que si está bien estructurado, documentado y mientras más rápido se libere código en microversiones mejor será desarrollado y usado. Ejemplo. Distribuciones de Linux, CMS colectivos como wordpress, Frameworks, etc.
hola muy interesante el articulopero como puedo trabajar xp con programacion orientada a objetos?? te agradezco si me ayudas con tu opinion!!! cualquier contacto mi e-mail es jal185@hotmail.com
saludos alexa Por:jalemos_blog
Interesante el post, muy util, gracias...!!! Por:martin varesio_blog
He estado investigando sobre XP y en realidad lo que hace es llevar a tierra lo que los "humanos programadores" hacemos en el día a día "terminar rápido y bien..." creo que la filosofía es buena "mostrar hasta el cansancio..." tengo experiencia en muchos proyectos en los cuales los clientes cambian diariamente y a veces en lapsos de horas, los requerimientos, así que la XP es como si un arquitecto pudiera empezar por el frente de la casa, se la va a mostrar al cliente y la va a tirar a bajo 100 veces hasta que el cliente quede conforme, de ahí continua con el primer cuarto en un proceso netamente iterativo. Es cierto lo que comenta Francisco ROberto_blog, no está claro que y como documentar, pero bueno en principio depende de lo que quiera docuemtar cada uno, supongo que gestionar recursos y tiempos con un excel y ms project evitaría estar preguntando todo el tiempo... En fin es una metodología muy abierta y depende de la experiencia de cada uno, como implementarla... Sds, desde Uruguay... Por:Marce_blog
muy buen articulo es interesante el articulo Por:juaan_blog
me encantó este artículo,,,fueron buenas las sugerencias Por:Midori
La mayoría de los programadores (o por lo menos, los que yo conozco), evitan el "lapiz y papel"... todos nos largamos (como acá, en mi país, dicen) "a los bifes"... programar.
Les quiero hacer la siguiente pregunta: Yo no soy un experto en informatica y me gustaria que pudieran explicarme esto con manzanitas, si es posible:
Cuando quiero hacer un proyecto en Rup utilizo el lenguaje de modelado uml..
En el caso de Xp que lenguaje de modelado es el adecuado..?
O como yo hago para modelar cada una de las etapas en Xp? Por:Pedro O.-blog
no se si se deben de hacer diagramas de caso de uso, entidad relasion en los proyectos utilizando la metodologia xtream programing(xp). Por:rosa maria mondragon lope
Extremadamente interesante el articulo muy interezante saludos a todos gracias conejo. Por:kinsi-blog
Me encanta el articulo, muy bueno y los comentarios la mayoría acertado, me gustaría contarles mi experiencia en cuanto a la xp.
no soy un desarrollador nato pero siempre toca hacer uno que otro proyecto y por ende siempre debe estar una metodologia que respalde.
Cuando decidi hacer Xp en realidad busque algo que no tenga documentacion pero me estrelle, ya que si necesitas un proyecto firme y que camine de buena mano necesitas documentar las cosas mas relevantes, y la metodologia se presta para ello. Por:wilycab-blog
Hola, un artículo interesante pero para mí la programación extrema es más un paradigma que una metodología.
contestando la duda de Pedro O sobre la pregunta planteada arriba.
Es posible usar UML para el modelado de cualquier sistema, ya que UML es solo una herramienta, esta muy separado de la métodología, puedes mesclar UML con XP sin ningún problema. Los diagramas que uses dependerán de como enfoques tú el análisis.
En lo personal solo prefiero y veo más importante el uso de los diagramas de clases y los diagramas de casos de uso, tal vez los de secuencia si el sistema lo amerita Por:Ditmar-blog
, pero no sabía como llamarle 
