Desarrollo Agil Con

Informacin de contacto o
Cualquier sugerencia, consulta, cr tica o correccin por favor comun o quenlo entrando en: www.MarcosMeli.com.ar O directamente envindome un mail a: a marcosdotnet@yahoo.com.ar
Gracias por tomarse el tiempo de hojear esta Tesis, tiene mucho esfuerzo de mi parte y trata de ser un panorama lo ms completo posible de las posibilidades de utilizar el a .NET framework acompaado del desarrollo gil y de las herramientas que lo soportan. n a Es muy probable que haya una nueva versin de esta tesis en mi pgina, algn art o a u culo nuevo o links a lugares relacionados o que completan la informacin. o
Version de esta Tesis: 1.0
Indice general
Informacin de contacto o Resumen 1. Introduccin o 1.1. Por qu Tcnicas y Herramientas ? . . . . . . . . . . . . . . . . . . . . . e e 1.2. Por qu Metodolog de Desarrollo Agil ? . . . . . . . . . . . . . . . . . e as 1.3. Por qu la Plataforma .NET ? . . . . . . . . . . . . . . . . . . . . . . . . e 2. Tcnicas de Desarrollo Agil para .NET e 2.1. Programacin en Capas . . . . . . . . . . . . . . o 2.2. Control de Versiones y Programacin Concurrente o 2.3. Refactoring . . . . . . . . . . . . . . . . . . . . . 2.4. Desarrollo Dirigido por el Testing . . . . . . . . . 2.5. Generacin de Documentacin a Partir del Cdigo o o o 2.6. Integracin Continua . . . . . . . . . . . . . . . . o 2.7. Armar una Librer de Cdigo y Controles . . . . a o 2.8. Seguimiento de Proyectos . . . . . . . . . . . . . 2.9. Crear Componentes y Controles Personalizados . 2.10. Convenciones de Nombres y Estilo . . . . . . . . . 2.11. Manejo y Reporte Automtico de Errores . . . . . a
1 4 4 6 9 12 13 15 19 24 26 28 30 32 33 36 43 47 48 52 55 59 65 67 71 74 77
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
3. Herramientas de Desarrollo Agil para .NET 3.1. Generacin Semi-Automtica de Cdigo . . . . . . o a o 3.2. Control de Versiones y Programacin Concurrente . o 3.3. Refactoring . . . . . . . . . . . . . . . . . . . . . . 3.4. Testing de Aplicaciones . . . . . . . . . . . . . . . . 3.5. Generacin Semi-automtica de Documentacin . . o a o 3.6. Compilacin e Integracin Automtica . . . . . . . o o a 3.7. Almacenar Nuestra Librer de Cdigo y Controles a o 3.8. Seguimiento de Proyectos . . . . . . . . . . . . . . 3.9. Revisin y Anlisis de Cdigo . . . . . . . . . . . . o a o
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
ii
iii
3.10. Prolers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Check Lists de los Temas Tratados 4.1. Control de Cdigo Fuente . . . . . o 4.2. Refactoring . . . . . . . . . . . . . 4.3. Testing . . . . . . . . . . . . . . . . 4.4. Documentacin . . . . . . . . . . . o 4.5. Compilacin e Integracin . . . . . o o 4.6. Generacin de Cdigo . . . . . . . o o 4.7. Convenciones . . . . . . . . . . . . 4.8. Generales . . . . . . . . . . . . . .
80 83 83 84 84 85 85 86 86 87
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
5. Conclusiones 88 5.1. Otros Temas de Inters sobre Desarrollo Agil . . . . . . . . . . . . . . . . 90 e A. Reexiones Sobre el Desarrollo de Software A.1. Systemantics (Fallos en los Sistemas Complejos) . . . . . . . . A.2. Buen Software: Programacin o Gerenciamiento de Personas ? o A.3. Mantenibilidad: Problema o Bendicin ? . . . . . . . . . . . . o A.4. Desarrollo Web: La Solucin Ideal o una Opcin ms ? . . . . o o a A.5. Nmeros y Estad u sticas para Reexionar . . . . . . . . . . . . A.6. Qu Signica ser un Mejor Desarrollador ? . . . . . . . . . . e B. Recursos Utiles B.1. Repositorios de Componentes y Cdigo . o B.2. Informacin sobre Desarrollo Agil . . . . o B.3. Direcciones de las Herramientas Tratadas B.4. Contenido del CD Complementario . . . Agradecimientos Bibliograf a 91 91 92 93 93 94 95 97 97 98 99 101 102 103
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Resumen
En esta Tesis se analizarn las diferentes tcnicas de desarrollo gil que permiten a e a generar aplicaciones de manera rpida y conable, aprovechando al mximo las ultimas a a herramientas y el nuevo enfoque de la programacin que se introdujo en las ultimas o versiones de Java y que alcanz su grado mximo con .NET. o a El anlisis realizado se centra principalmente en la automatizacin de la mayor de a o a las tareas del desarrollo y sobre todo en la importancia de generar cdigo a travs de o e plantillas editables. Las tcnicas abarcadas que cuentan con mayor popularidad son: e Desarrollo en Capas. Refactoring. Documentacin embebida o generada a partir del cdigo. o o Desarrollo Dirigido por el Testing. Integracin Continua. o Seguimiento de Proyectos. En cuanto a herramientas, analizaremos las que apuntan a facilitar las tareas de: Generar cdigo de las capas de Datos y Negocios. o Hacer Refactoring. Generar Documentacin. o Controlar las versiones de un sistema. Programar entre 2 o ms personas sobre el mismo cdigo. a o Ejecutar Casos de Test. Compilar, Integrar y Distribuir el Sistema. Analizar Problemas en el Cdigo. o
Vale la pena aclarar que hay muchos libros escritos sobre cada uno de estos temas, en esta tesis simplemente se tratar de dar una introduccin para familiarizar al lector a o con los mismos y brindar referencias sobre donde se puede encontrar mayor informacin. o El objetivo principal es brindar los conocimientos para que el lector pueda armar su propio marco de desarrollo gil sobre .NET. a El marco del que hablamos tendr que cumplir con las siguientes caracter a sticas: Reusable Si vamos a hacer el esfuerzo de ponernos a analizar cada parte de un sistema para ver como desarrollarla lo mejor posible, ser conveniente a que no lo tengamos que repetir para cada sistema que hagamos, por ello, ste ser el tema principal en nuestra l e a nea de pensamiento. Muy Automatizado Como dijimos al principio la tesis habla de automatizar procesos y utilizar herramientas que hagan cosas por nosotros, pues bien, mostraremos como hacerlo y aunque parezca exagerado, veremos que podemos desarrollar una aplicacin de acceso a datos sin tener idea de ADO.NET ni o de SQL Stored Procedures.1 Muy Ortogonal Es indispensable la ortogonalidad en el sentido que siempre podremos agregar funcionalidad sin afectar el resto del sistema, por ejemplo: si agregamos algo nuevo para optimizar el acceso a datos, los formularios de la aplicacin no deber cambiar su comportamiento en absoluto. o an Ntese que en las ultimas condiciones decimos Muy Automatizado o Muy Oro togonal y no Automatizado u Ortogonal esto no es una simple casualidad sino que se quiere destacar que no estamos hablando que se genere todo el cdigo solo, sino, de que o podamos cambiar la forma de hacerlo y acomodarlo a nuestro gusto, por eso usaremos plantillas editables y no recurriremos a programas que funcione como una caja negra de la que sale cdigo que no podemos entender ni modicar.2 o De la ortogonalidad lo que se busca es que ante un cambio haya que modicar la menor cantidad de cdigo posible, porque eso de no cambiar nada en la prctica no o a existe. La mayor de las herramientas tratadas pertenec al mundo Java y fueron portadas a an a .Net en los ultimos aos. Casi todas son iniciativas Open-Source por lo que se pueden n utilizar libremente y adems contamos con el cdigo fuente, para realizar cambios o a o agregar funcionalidad, incluso podemos envirselas a los creadores para que las incluyan a las modicaciones en las prximas versiones. o
Slo necesitamos conocer estos temas si vamos a cambiar las plantillas pero si slo generamos o o cdigo no es necesario saber nada de eso. o 2 De hecho todos los intentos de derivar el cdigo Automticamente a partir de una especicacin o a o han fallado porque eran demasiado ambiciosos pretendiendo que los humanos participemos solo en la denicin del problema y dejemos el resto para las mquinas. o a
1
Veamos como se estructura la tesis y a donde ir en caso de necesitar algo en particular: Comenzaremos explicando el porqu del T e tulo de la Tesis. (Pg. 4) a Pasaremos luego a las Tcnicas para cubrir el marco terico del desarrollo gil e introe o a ducirnos en el mundo de la programacin moderna. (Pg. 12) o a Seguiremos con un anlisis de las Herramientas que llevan esos conceptos a la prctica, a a porque sin ellas las tcnicas ser dif e an ciles de implementar y nadie las usar (Pg. 47) a. a Luego daremos una lista de Check Lists con consejos y buenas prcticas para no tener a problemas al aplicar estos conocimientos. (Pg. 83) a Extraeremos una Conclusin de la informacin presentada teniendo en cuenta el preo o sente y futuro de la programacin. (Pg. 88) o a Adems reexionaremos sobre temas relacionados con el desarrollo del software para a tratar de comprender la Crisis en la que se encuentra y de la que parece que ser muy a dif salir ... si es que existe una salida. (Pg. 91) cil a Finalmente daremos una lista muy completa de Recursos Utiles con informacin sobre o donde encontrar mas material, donde recurrir en caso de necesitar cdigo o controles o gratuitos y las direcciones de cada una de las herramientas tratadas. (Pg. 97) a
Cap tulo 1 Introduccin o

1.1. Por qu Tcnicas y Herramientas ? e e
Cada d la brecha que existe entre la teor y la prctica aumenta considerablemente, a a a las tendencias comerciales nacen, se establecen y cambian cada cinco aos o menos. n Ejemplos claros de ello son: Fox Pro, Delphi, Visual Basic, Java, etc. La teor en cambio no puede seguir ese ritmo de actualizacin por varias razones, a o pero sobre todo, porque nada le conforma de esas nuevas tecnolog y, literalmente, le as encuentra la quinta pata al gato, sosteniendo frases como: 1. Windows es el peor sistema operativo que existe, anda muy mal. 2. Visual Basic 6 no es un lenguaje serio porque no implementa bien la herencia. 3. Las bases de datos que no almacenan sus datos en XML son malas. 4. Todo lo de Microsoft es comercial y no tiene valor acadmico. e 5. No podemos controlar lo que no podemos medir. 6. La Inteligencia Articial resolver los problemas por nosotros. a y cuando entramos en el mundo de la prctica descubrimos: a 1. Windows es el sistema ms usado y el que marca los nuevos estndares. a a 2. VB6 es fcil de entender y es el ms usado en los desarrollos administrativos. a a 3. SQL Server, Oracle, MySQL no guardan sus bases en XML y son los ms populares. a 4. .NET marc un antes y un despus en la historia de la programacin. o e o 5. Hay muchas cosas que no se pueden medir y los que lo hacen generalmente no aciertan en sus predicciones. 6. Ni siquiera la NASA pudo hacer algo prctico con la Inteligencia Articial. a 4
CAP ITULO 1. INTRODUCCION
Por ello en esta tesis se analizarn ambos mundos. a Del lado de la teor analizaremos las Tcnicas de Desarrollo Agil ms destacadas y a e a utiles, incluiremos una descripcin general de cada una, su origen y donde es conveniente o usarla. Del lado de la prctica estudiaremos las Herramientas desarrolladas para .NET que a dan soporte a las tcnicas vistas, incluiremos las principales caracter e sticas de las mismas, donde encontrarlas y en qu escala utilizarlas. e En este enfoque paralelo no mostraremos todas las Tcnicas y Herramientas pero e al nal de la Tesis propondremos un listado con otras posibilidades, citando las fuentes donde encontrar informacin adicional. o
1.2.
Por qu Metodolog de Desarrollo Agil ? e as
La mayor de nosotros somos conscientes que la computacin en s y sobre todo el a o mundo de la programacin cambia a una velocidad realmente vertiginosa. o Pero algo ms radical es lo que ocurri en la programacin que lo podemos denir a o o como una revolucin. o Hoy en d con los requerimientos que tienen los grandes sistemas (distribuidos, 24 a Hs. online, acceso Web, etc.) es casi imposible hacer algo individualmente ya que se requieren de conocimientos en much simas reas. a Gracias a Internet los desarrolladores encontraron una pequea solucin, comenzaron n o a compartir sus conocimientos, experiencias y a ayudarse entre si, reduciendo la cantidad de informacin a procesar. o Las Listas de Correo y los sitios que son slo repositorios de tutoriales o trozos o de cdigo fuente (snippets) son el lugar perfecto para visitar cuando se nos presentan o problemas con los que no nos hemos encontrado antes, pero que, seguramente, alguna otra persona ya ha enfrentado y solucionado. Esto afect mucho la forma de programar que algunos denominaron Programacin o o Basada en Componentes, pero no es slo eso, la revolucin de la que hablamos va o o mucho mas all. Lo que se quiere destacar es la cantidad de interacciones con las que a deben conviven los sistemas actuales y el grado de conanza que se tiene en terceras partes, que nos guste o no, son ms que necesarias porque como dijimos no podemos a hacer todo nosotros. Antes un programador se preocupaba por chequear su cdigo o actualizar su como pilador y no mucho ms. En cambio, hoy d un programador debe vericar compata a, ibilidades de todo tipo, que van desde versiones de sistema operativo, hasta la placa de video de la mquina donde se va a correr el sistema, pasando por supuesto por los a famosos Services Packs (que gracias a Microsoft se convirtieron en palabra corriente) que no son mas que un el reejo de la complejidad actual de los sistemas (basta con pensar que si un gigante como MS con todos los recursos que posee, no puede cumplir las planicaciones y la calidad esperada, que queda para nosotros). Con esto en juego se empieza a notar que el tiempo nunca alcanza con los mtodos e tradicionales ya que piden demasiado a los desarrolladores. Cuando se comienza un nuevo proyecto se hace demagogia de todo lo que se har a con respecto a documentacin, testing, planicacin, gastos en recursos, etc. Lo hacemos o o para tener la consciencia tranquila y sentir que est todo bajo control. a Pero a medida que el proyecto avanza se va dejando de lado la documentacin porque o sino no se puede llegar a tiempo, se va demorando la planicacin progresivamente y o para que no se note tanto se dejan partes del sistema sin completar y testear para poder pasar a otras tareas y ajustarse aunque sea un poco a la planicacin original. o
Finalmente se omite el testing por completo. La documentacin y planicacin pasan o o a ser un recuerdo y se convierten en un conjunto de archivos u hojas a los que nadie accede. El principal problema es que adems de no tener nada actualizado, no se sabe en a que estado est el sistema, y como se dejaron partes sin terminar o testear nadie puede a asegurar que algo funcione. Esto empeora ya que los usuario no entran en contacto con el sistema hasta que est casi completo. e El proyecto se vuelve incontrolable, peor aun que en aquellos d de la programacin as o en los que no se planicaba nada, se hac algo y a medida que el usuario ped se a a agregaban cosas. Las metodolog giles buscan rescatan esa esencia de la programacin del prueba as a o y error, el hago algo y veo si es lo que quieren, termino esta parte y agarro otra. Todas esas pequeas cosas que marcaban a los programadores de la poca, que muchos tratan n e de desestimar diciendo que eran artesanos y arrebatados en lo que hac an. Yo tengo un pensamiento contrario a ese ya que para m esas personas, programa tras programa, lograron llevar la computacin a lo que es actualmente, sino basta con o preguntarnos si estas personas: Terminaban lo que les ped ? an Sab a lo que se enfrentaban ? an Estaban actualizados con respecto a la tecnolog ? a Solucionaban los problemas de los clientes ? Dejaban a los usuarios contentos ? Eran felices con sus trabajos ? Como yo lo veo, la respuesta a todas estas preguntas es un rotundo Si y hoy en d a no podemos contestar positivamente casi ninguna de ellas. Es para reexionar no ? Las metodolog giles como Extreme Programming (XP) o Scrum fomentan la as a planicacin de pequeas partes del sistema (no del sistema en s la misma se hace o n ), semana a semana, d a d paso a paso. a a, Con esto se logra saber exactamente en que estado est cada parte del sistema y hacer a pequeos ajustes al alcance o a la planicacin si no llegamos en el tiempo prometido. n o Si bien es cierto que no hay una planicacin sobre el proyecto completo como o supuestamente tenemos con las metodolog tradicionales, logramos una mayor senas sacin de avance ya que las metas estn mas cerca y son mas visibles. o a Como consecuencia todos ganan:
Los programadores se sienten mucho ms utiles ya que terminaron con lo que a prometieron, lo ven funcionando y sobre todo no se frustran porque estn fuera a de la planicacin. De esta forma rindan ms porque notan que las cosas se estn o a a completando razonablemente bien y no se los est presionando constantemente a para que terminen algo. El jefe de proyecto tiene semanalmente cosas nuevas del sistema para mostrar a los gerentes o clientes. Pudiendo adems identicar errores de interpretacin a o asegurndose que todo marcha como ellos quieren. a Los gerentes o clientes perciben que se estn haciendo cosas y que el proyecto a avanza a paso rme, evitando la ansiedad (o hasta angustia) que generan otras formas de trabajar donde slo se les muestran las cosas cuando estn listas (lo que o a siempre lleva ms tiempo y dinero de lo previsto). a Como nota nal podemos decir que ninguna metodolog es universal, con esto a reconocemos que el desarrollo gil no es aplicable a ciertos tipos de desarrollo. Por a ejemplo, en el construccin de sistemas embebidos puede ser mejor aplicar alguna otra o forma de trabajo como la estructurada tradicional. De todos modos se puede adaptar el desarrollo gil a la mayor de los sistemas para a a que nos de excelentes resultados y sobre todo... para que podamos dormir tranquilos ...
1.3.
Por qu la Plataforma .NET ? e
Para estudiar la aplicacin de las metodolog giles debemos encontrar una plataforo as a ma de desarrollo moderna que cumpla con las siguientes condiciones: Tenga soporte para Programacin Orientada a Objetos. o Tenga garantizada la continuidad (i.e. debe pertenecer a alguna gran empresa o ser open source). Sea popular (para encontrar componentes y soluciones ya implementadas). Sea posible utilizar las ultimas tcnicas de desarrollo gil y existan herramientas e a implementadas para hacerlo. Sea factible implementar patrones de diseo. n Sea Multi-Plataforma. Sea lo ms econmico posible, incluso gratuito. a o Las dos grandes opciones que cumplen estas condiciones son, sin lugar a dudas, Java2EE y .NET Framework. La inclinacin hacia el segundo est dada por el impulso que Microsoft le da a .NET o a ya que est dispuesto a convertirlo en la decisin indiscutible del futuro (y como sabemos a o cuando MS se encapricha con algo, lo logra, y sino compra a los competidores) Los principales factores que nos llevan a esta decisin son: o La velocidad de crecimiento y maduracin de .NET es realmente exponencial con o respecto a la de Java. La facilidad de aprendizaje y acceso a tutoriales es mucho mayor a la de Java. La estandarizacin de C# y el CLI (common lenguaje infrastructure) permiti o o proyectos como Sharp Develop, un IDE muy completo, similar al Visual Studio .NET pero de cdigo abierto. o Relacionado con el CLI se desarroll el proyecto MONO que permite ejecutar o aplicaciones de .NET en distintas plataformas (Linux, Mac, Windows, etc.) sin necesidad de recompilar, directamente se pasan los mismos ejecutables de Windows al runtime de Mono y listo (se encuentra en un estado productivo y por la gran adhesin e inters comercial llegar a un estado de madurez muy pronto) o e a .Net presenta un soporte ms que transparente para integrarse con el resto de a las herramientas de Microsoft y que la mayor de las empresas tienen instaladas, a como:
10
Active Directory SQL Server 7 y 2000 Oce 2000 en adelante La API de Windows El IIS (Internet Information Server) Java no tiene cosas similares y las herramientas que hay para interactuar con estos sistemas son dif ciles de instalar y adems inecientes.1 a A SUN pareciera que no le queda mucho ya que parece dar todo el tiempo manotazos de ahogado, regalando cosas y dems. Esta razn es muy importante porque a o en un futuro SUN puede dejar de existir, pero que deje de existir Microsoft... es dudoso no ?? La diferencia ms notable es cul es el motor detrs de cada unos de estos grandes. a a a Por un lado est Java que surge como un lenguaje revolucionario, a orientado a objetos, portable, multi-plataforma, etc. Fue el conejito de indias y se tom un buen tiempo para crecer pero por varias o razones no se termin de imponer (entre otras porque: era muy peo sado para las maquinas de la poca, no exist un buen IDE para e a desarrollar, era dif operar con bases de datos, etc.). cil Por otro lado est .NET impulsado por la necesidad de la mayor a a de las empresas que hacen desarrollo administrativo que esperaban nuevas versiones de los queridos: Visual basic, Visual Fox, Crystal Reports, etc. Por este lado hay much simo ms dinero y como a sabemos con l todo se hace rpido y lo mejor posible, sino basta e a comparar el Visual Studio.NET con los IDEs ofrecidos por SUN, que no son malos, pero hay una diferencia en productividad muy grande que las empresas no estn dispuestas a pagar. a .Net captur gran parte de la comunidad Open Source que estaba abocada a la o construccin de herramientas y componentes para Java. Estos se maravillaron con o la similitud de C# y Java, vieron el mayor poder del lenguaje de MS y enseguida comenzaron a portar dichas herramientas que incluso mejoran a sus antecesoras (consultar www.SourceForge.net) La eciencia en ejecucin con respecto a requerimientos de hardware de las dos o grandes plataformas favorece a .NET que, al no ser totalmente interpretado, lo
Adems de que Java no tiene soporte nativo para integrarse con estas herramientas usa mtodos a e de acceso como ODBC al que MS no le presta atencin (o se la presta para ver como complicarlo) y o que son muy lentos en comparacin con, por ejemplo, ADO.NET o
1
11
deja a Java fuera de combate en cuanto a Performance2 . Aunque se diga que el Visual Studio es pesado y el framework tambin, basta ponerlo al lado del de Java e para darnos cuenta que es una joya, el consumo de memoria es mucho menor y por otro lado, comparado con Java, .Net no es en lenguaje de programacin como lo es JAVA, sino que es un Runtime o con librer comunes que permite que varios lenguajes se implementen sobre el sin as problemas, inclusive se podr implementar Java. a La licencia del .NET framework es libre y hay otros runtime de la comunidad open source como MONO, o sea que nunca vamos a tener problemas de monopolio, en cambio el dueo de Java es SUN y podr cuando quisiera comenzar a cobrar por n a el uso de su lenguaje, parecer que esto nunca va a pasar, pero pensemos que si a SUN quiebra la podr comprar otra compa y hacer uso de estos derechos. a na Podr amos escribir much simas ms ventajas pero basta con concluir que Microsoft a realmente sab lo que hac cuando creo .Net. Se encargo de atender lo que los usuarios a a reclamaban, tanto los de VB6 como los de Java y les dio dos lenguajes como ellos siempre quisieron: VB.NET y C#. Para el desarrollo de .NET se preocup por crear un entorno de desarrollo (IDE) o muy completo y con soporte de add-ins y macros (dos caracter sticas que le dan al Visual Studio una potencia inigualable) Lo ms curioso e interesante es que con las versiones 1.0 y 1.1 de .Net se incluy a o slo una parte de lo que estaba planicado ser el .NET Framework (por cuestiones de o a mercado o simplemente de tiempos). En el 2005 lanzar la versin 2.0 de .NET que promete ser el golpe nal y sin dudas a o se va a imponer como la plataforma de desarrollo para, por lo menos, los prximos 10 o aos o como dice Microsoft los prximos 20. n o
Si buscamos en internet J2EE Vs .NETveremos que la comunidad de Java dice que su plataforma es la mejor pero las razones que dan no son sucientes. Se la agarran con C++ porque si lo usamos en .NET puede haber lacks de memoria o errores inesperados ya que se pueden pasar por encima a los controles del Framework. Pero Microsoft ni loco har el C++ semi-interpretado con una capa a intermedia porque perder el mercado de los juegos actuales hechos con Visual C++ y DirectX, ya que a la performance de estos se vendr abajo (o acaso conocen algn juego 3D hecho en Java... a si ?? y a u cuantos servidores se necesitan para ejecutarlo...)
Cap tulo 2 Tcnicas de Desarrollo Agil para e .NET

Como comentamos en la introduccin de esta Tesis, las metodolog giles son casi la o as a unica opcin hoy en d para desarrollar proyectos de gran envergadura donde se necesita o a complir con los tiempos y resultados esperados, pero sobre todo en los contextos donde se necesita algo que realmente funcione. En esta seccin de la tesis analizaremos desde el punto de vista terico las distintas o o con las que contamos y que tienen mayor popularidad en la Tcnicas de Desarrollo Agil e comunidad de desarrolladores de .NET. Estas tcnicas son la base fundamental de las herramientas ms exitosas para la e a plataforma de Microsoft. Proveen la escencia del desarrollo gil y luego las herramientas a que veremos en el cap tulo 3 las llevan a la prctica lo ms elmente posible. a a Aclaremos nuevamente que no haremos un anlisis exaustivo de cada tcnica porque a e ser imposible ya que existen muchos libros de cada una, nos conformaremos con una a idea general de la tcnica y como se adapta a .NET, para mayor informacin se puede e o consultar el Apndice B (pgina 97) donde hay enlaces a sitios sobre cada tema, la e a Bibliograf o el CD complementario donde encontrarn ms material. a a a
12
CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET
13
2.1.
Programacin en Capas o
Esta ser la primer tcnica que analicemos ya que es una de las ms antiguas. Se a e a aplica a cualquier tipo de desarrollo relacionado con bases de datos, principalmente en sistemas administrativos. Grcamente un t a pico sistema con arquitectura en capas se ve as :
1
La idea detrs del desarrollo en capas es que cada una de ellas se encargue de una a parte del sistema bien determinada y que cualquiera pueda ser cambiada sin que afecte el resto. En la prctica cuesta mucho mantener una independencia pura como se plantea en a esta tcnica, pero de todas maneras se simplica much e simo el desarrollo cuando uno encara la solucin de esta manera con partes independientes y ortogonales. o La principal ventaja, desde mi punto de vista, es que la mayor parte de las capas de datos y de negocios se pueden generar automticamente mediante plantillas ya que se a encargan del mapeo relacional y de traducir los objetos del programa en objetos que la base de datos entienda. Para comprender porque esta tcnica se populariz tanto veamos un ejemplo t e o pico:
De todas la capas que vemos en el grco no todas tienen porque estar ni tampoco son las unicas a que hay, se podr llegar a utilizar la cantidad que queramos, este es solo un ejemplo del caso ms comn a a u en un desarrollo con bases de datos.
1
14
Pensemos en la capa de datos, generalmente esta no es la que se encarga de hacer directamente las operaciones sobre la base de Datos sino que se crean stored procedures para las tareas t picas de insertado, eliminacin, actualizacin y recuperacin de datos2 . o o o Por lo tanto si se cambia de motor de base de datos se deber reescribir solamente an los stored procedures. Esto nos evita reescribir el cdigo de las capas de negocios que poco tienen que ver o con la decisin de cambiar la base y que, si el sistema se diseo con esta losof no se o n a, le deber cambiar nada. a Aunque parece que son todos halagos para el desarrollo en capas, en la prctica (como a siempre) surgen cosas que no se pueden manejar el al esquema propuesto y perdemos esa abstraccin tan pura que ve o amos en el grco. a Tengamos en cuenta el siguiente enunciado: Se necesita que cuando se cambie el precio de algn art u culo se escriba un registro en la tabla de novedades de precios. La solucin ms sencilla es crear un Trigger en la Base de datos y as cuando se o a modica un precio en la tabla Precios se genera el registro en la tabla Novedades de Precios. El problema es que al utilizar un trigger estamos realizando una tarea de la capa de negocios directamente en la base de datos lo cual va en contra de esta tcnica. e Aunque se rompa con la idea general este tipo de cosas pasan siempre. Estas excepciones son mucho ms fciles de manejar como tales que tratando de hacerlas encajar a a en el esquema general. Yo opino que lo recomendable es hacerlo con un trigger pero tomarse el trabajo de dejarlo bien documentado y cuando digo documentado no me reero a que debemos redactar un documento formal y colocarlo en la carpeta con los diccionarios de datos. Ms bien se debe escribir un breve documento explicando el porque de la decisin y a o colocarlo en una carpeta de documentos vitales del sistema (con esa informacin que o en caso de olvidarse pode provocar terribles problemas muy dif ciles de detectar). Entonces concluimos que es necesario en los sistemas administrativos encarar el problema con una arquitectura en capas pero debemos estar preparados para posibles excepciones que deben ser tratadas como tales.
En ingls estas operaciones son conocidas con el nombre de CRUD por Create, Retrieve, Update e & Delete.
15
2.2.
Control de Versiones y Programacin Concuro rente
Cualquier persona que haya hecho algn sistema para alguien, por ms pequeo que u a n sea, sabe que la siguiente historia es ms que frecuente: a Uno le entrega una versin al cliente y luego contina haciendo cambios para la o u prxima entrega. Luego que la terminamos llevamos la nueva versin, pero, cuando el o o cliente la prueba dice: Si si, est muy bien, pero la pantalla de b squeda de ac a u a quiero que funcione como la anterior no como sta. e Hay dos mundos posibles al tratar de solucionar este problema: Que no llevemos control de versiones En este caso buscamos en nuestro disco alguna versin anterior del cdigo o o fuente y rezamos para que sea la misma que gener el programa del que o habla el cliente. Luego vemos las diferencias con la version actual archivo por archivo hasta que nos damos cuenta que cambiamos. Finalmente probamos como se comporta el sistema si borramos el archivo de la pantalla de bsqueda y le agregamos el de la versin vieja el otro3 . u o Volvemos a compilar y se lo llevamos, rezndole a San Murphy en el a camino para que no nos maldiga con sus leyes cuando lo probemos con el cliente. Que tengamos alguna herramienta de control de versiones Este caso es ms simple, simplemente le pedimos al Sistema de Control a de Versiones que nos muestre las diferencias en el archivo de la pantalla de bsqueda entre la versin actual y la que le entregamos al cliente, este u o las muestra lado a lado resaltando las diferencias y solo debemos extraer lo que necesitamos4 . La programacin es una tarea altamente creativa, cambiante y, como citbamos ano a teriormente, generalmente no es una actividad individual. Solo cuando se trabaja con un grupo de personas que modican concurrentemente l cdigo nos damos cuenta que es muy complicado juntar las distintas versiones del e o sistema que estn en cada mquina, por ms que se dividan correctamente las tareas, a a a
Ojal que tengamos un backup de la ultima versin porque el resultado probablemente no ser el a o a esperado 4 Aunque parezca poco probable que sea as de sencillo veremos que lo es en las prximas hojas o
3
16
Murphy har que se necesite cambiar el mismo archivo, en el mismo lugar y las cosas se a volvern, como siempre, ms complicadas de lo previsto. a a La forma de trabajo de los sistemas de control de versiones es muy simple: Hay un repositorio central con el cdigo fuente que mantiene los cambios que se o fueron haciendo a lo largo del tiempo. Hay tres operaciones bsicas sobre el repositorio que son: a Bajarse una versin completa del cdigo (CHECKOUT) o o Bajarse los ultimos cambios y juntarlos con las nuestros (UPDATE) Subir nuestros cambios para que los dems puedan verlos (COMMIT) a Grcamente se ve as a
Esquema General de un Sistema de Control de Versiones (CVS) * Utilizaremos directamente los nombres en ingls para no generar e confusin y porque no hay buenas traducciones de estos trmino o e Con respecto al orden de las operaciones en el uso bsico de un sistema de control a de versiones podemos decir que debemos hacer una unica ves un CHECKOUT. Luego podemos hacer cambios en el sistema, cuando los nalizamos se hace un UPDATE para obtener los cambios que pueden haber realizado los otros desarrolladores y seguido un COMMIT para reejar nuestros cambios en el repositorio. El ciclo se repite con estas dos operaciones superpuestas entre los programadores. Grcamente: a
17
Tareas ms comunes sobre el repositorio a Hay comandos avanzados para los cuales los sistemas de control de versiones tienen soporte. Uno de ellos es el BRANCH y cuando realizamos uno es como si dividisemos e la l nea principal de desarrollo en dos y podemos trabajar en cualquiera de ellas. El lugar ms comn donde se utilizan BRANCHS es antes de realizar un RELEASE a u ya que se desea seguir trabajando en nuevas funciones del sistema pero hay ajustes que se deben realizar en el sistema para ponerlo en productivo y que detienen el trabajo, en cambio si hacemos un BRANCH algunos miembros del equipo pueden trabar sobre esta division haciendo UPDATES y COMMITS como si fuese la unica que existe, mientras tanto los otros miembros del equipo pueden continuar con el desarrollo principal. Inclusive se pueden volcar los cambios del BRANCH del RELEASE a la l nea principal de desarrollo con el comando MERGE. Resumamos este proceso con un grco: a
Pasos T picos de un Branch en el Desarrollo Otro comando interesante es el de TAG que se encarga de ponerle un nombre simblico a las versiones de un grupo de archivos. o Supongamos que llegamos a un momento en el desarrollo que deseamos recordar (p.e. antes de un cambio importe, antes de una release, antes de corregir un BUG, etc.). Como cada archivo del proyecto tiene una versin independiente ya que se actualizan o individualmente ser una locura tener que anotar todas para despus poder volver a a e este momento. Es recomendable entonces hacer los TAG bastante seguido ya que es muy simple, no perjudica la escalabilidad del repositorio y nos permite volver a cualquier punto en el tiempo con un par de clicks. Con .NET en particular es muy fcil hacer control de versiones ya que Microsoft a no utiliza ms archivos binarios para guardar los proyectos o soluciones. Ahora usa a directamente archivos de texto con sintaxis XML.
18
Como conclusin podemos decir que el control de versiones es como un gran UNDO o en el desarrollo que nos permite ir y venir entre las versiones del cdigo sin problemas. o Inclusive tenemos una auditor perfecta de los cambios, quien los hizo, cuando, etc., lo a que genera mayor conanza en los miembros del equipo de desarrollo, ya que en caso de encontrar un error no se pueden echar la culpa mutuamente sin justicacin porque se o descubrir la verdad fcilmente. a a Un hecho muy interesante relacionado con la prxima tcnica que veremos, es que o e cuando hay que hacer un cambio importante al que le tenemos un poco de desconanza podemos hacer un BRANCH y ir modicando lentamente el cdigo para ver como evoluo ciona (lo que no afectar a la l a nea de desarrollo principal). Si vemos que los cambios perjudican el sistema o no dan los resultados esperados simplemente los descartamos y seguimos trabajando en el BRANCH principal. Uno de los principios en Extreme Programming es el coraje (no temerle a cambiar partes importantes del sistema si creemos que es necesario). Entonces, como con el control de versiones sabemos que el cambio se puede revertir rpidamente, no quedan a muchas cosas a las que tenerle miedo. Adems toda la comunidad Open Source hizo y hace uso de sistemas de control a de versiones y han tenido excelentes resultados, inclusive con cientos de programadores cambiando el cdigo concurrentemente como pasa con Linux. As que es buena idea o imitarlos.
19
2.3.
Refactoring
Aunque el nombre no sea muy conocido est comenzando a escucharse cada vez con a mas frecuencia y va a pasar a ser algo muy comn cuando Microsoft incluya herramientas u que soporten esta tcnica dentro del Visual Studio .NET 2005. e Expliquemos cual es la idea con un ejemplo de la vida diaria. Cuando redactamos una carta, art culo, libro, etc. no pensamos todo lo que vamos a escribir lo hacemos y listo. Sino que escribimos partes, las reordenamos, revisamos, agregamos y quitamos cosas, etc. (por ejemplo esta tesis pas de ser un conjunto desoro denamos de ideas a u ser un texto ms o menos le a ble) Esto es porque el cerebro humano no esta preparado para crear de un intento algo perfecto (ni tampoco con mucho tiempo :), pero si se empieza por algo y despus se van e cambiando cosas generalmente se tienen mejores resultados. En la programacin esto es mas grave porque si uno planea al detalle todo lo que o va a hacer y se sienta a hacerlo, se da cuenta que hay cosas que no encajan o que no funcionan y se debe volver atrs y re-pensar todo el problema con la prdida de tiempo a e que ello implica. Si por otro lado empezamos sin pensar demasiado, tenemos el problema que a medida que avanzamos nos damos cuenta que hay cosas que podr haberse hecho mejor. De an lo que se trata refactoring es de mejorarlas en ese momento por ms que parezca una a prdida de tiempo, a largo plazo nos traer grandes benecios. e a La denicin de refactoring es: o Cambiar algo con el n de mejorarlo. En el caso de la programacin ese algo es el cdigo, en el diseo son los diagramas y o o n en el anlisis son las especicaciones y la arquitectura. a Un problema con el que se enfrenta hoy en d esta tcnica es que, generalmente, a e no agrega funcionalidad al sistema y tiene un costo asociado al tiempo que se pierde en hacer los cambios. Por eso a los ejecutivos no les interesa que se invierta en refactoring porque como se dice no tiene ningn valor comercial. Pero todo buen analista, arquitecto, diseador o u n programador de sistemas se las debe rebuscar para hacer refactoring si realmente piensa que las cosas no pueden seguir as primero por derecha pidiendo autorizacin para , o hacerlo, pero si recibe una negativa, debe encontrar la forma de cambiarlo lentamente sin decir nada, porque seguramente es mejor que dejarlo as porque cuando algo pase , puede ser tarde para solucionarlo y la culpa ser nuestra. a Es necesario aclarar que debemos poner en la balanza el costo del cambio y los benecios que obtendremos para tomar una decisin y no hacer refactoring por deporte, o no porque esto este mal, sino porque nuestros jefes o clientes no estarn muy contentos a y nos quedaremos sin trabajo.
20
Razones para hacer Refactoring

Las situaciones ms comunes en las que se debe hacer refactoring y que nos darn el a a mayor benecio son: El Cdigo est duplicado o a Esta razn es la que mayor cantidad de problemas nos trae, todo cdigo o informao o cin duplicada a mediano o largo termino es un dolor de cabeza porque se deben o hacer modicaciones en paralelo en todos lados. En el libro de Hunt and Tomas [HT99] lo llaman el principio del DRY (Dont Repeat Yourself) y sostienen que es un error muy grave dejar que esto pase. Parnas lo resume claramente: Copiar y Pegar es un error de Diseo n Una rutina es muy larga En la programacin orientada a objetos tener rutinas que sean mayores que lo que o entra en una pantalla es realmente poco necesario. Martin Fowler nos dice que si una rutina es larga y tiene comentarios entonces se debe crear un mtodo con el cdigo comentado y se lo debe nombre de manera que e o exprese lo mismo que el comentario. La lista de parmetros de una rutina es muy grande a Este es un error muy grave en la programacin orientada a objetos ya que uno o deber en estos casos usar un objeto como parmetro y as en caso de cambiar la a a cantidad de datos que se necesitan se le puede agregar un campo al objeto. De la otra manera en cambio debemos agregar un parmetro al mtodo y a todas a e las llamadas ponerles el parmetro extra que quiz no tenga sentido para muchas a a de ellas. Una clase tiene poca cohesin o Si una clase hace demasiadas cosas que no estn relacionadas entre s se debe a , dividir en varias clases, donde cada una toma un conjunto de responsabilidades altamente cohesivas. Los comentarios explican trozos de cdigo o Si dentro del cuerpo de una rutina hay comentarios para explicar parte del cdigo o de la misma, se debe agregar una nueva rutina que reciba el nombre a partir del comentario y que tenga de cuerpo el trozo de cdigo comentado, gracias a este o refactoring, nuestro sistema se vuelve ms sencillo y auto-documentado. a Una clase est en el medio entre otras y no hace nada a Si la mayor de los mtodos de una clase slo tienen una llamada a un mtodo de a e o e otra, se debe considerar el hecho de eliminarla ya que reeja un error de diseo, n debiendo convertir las llamadas anteriores por llamadas directas a la clase nal.
21
Refactorings ms Conocidos y Utiles a

Describamos brevemente algunos de los refactorings tratados en profundidad en el libro de Fowler [Fow99] y en el de Wake [Wak03], invitando al lector a consultarlos en busca de ejemplos y consejos sobre la forma de aplicarlos y en qu contextos. e Reemplazar los numeros mgicos por constantes simblicas a o Este es un refactoring t pico que todos recomiendan utilizar. En .NET en particular, cuando diseamos controles personalizados y tenemos tamaos, colores, textos por n n defecto siempre conviene usar constantes simblicas y no los valores literalmente. o Renombrar una variable a un nombre ms claro o informativo a Si una variable tiene un nombre poco claro (temp, obj, etc) cambiarlo a uno ms a signicativo. Lo mismo se aplica a las constantes, rutinas y clases. Reemplazar una expresin con una rutina o Cuando una expresin aparece en ms de un lugar o es demasiado complicada, se o a debe crear una funcin que la compute y que tenga un nombre signicativo. o Mover las expresiones booleanas de ms de 2 o 3 condiciones a una funcin a o Toda expresin booleana lo sucientemente complicada compromete la legibilidad o del cdigo en zonas tan importantes como los condicionales, la forma simple de o evitarlo es creando una funcin que la compute y ponerle un nombre adecuado. o Devolver los valores de las funciones ni bien se los conozca y no asignarlo a una variable temporal Si hacemos esto el cdigo se vuelve ms fcil de leer y la mantenibilidad futura no o a a se complica ya que si agregamos cdigo debajo sabemos que no se va a ejecutar o si no corresponde ni cambiar el valor del resultado como pasar si tenemos una a a variable temporal. Extraer una rutina Cuando un mtodo se vuelve muy largo o complicado debemos extraer parte de su e cdigo y formar una nueva rutina con l pasndole los parmetros que necesite. o e a a Convertir una rutina larga en una clase Si una rutina es demasiado larga, muchas veces se la puede convertir en una clase con mltiples rutinas para mejorar la legibilidad. u Pasar un objeto completo en lugar de miembros espec cos Si estamos pasando pasando muchos valores de un objeto a una rutina quiz nos a convenga pasar directamente el objeto para facilitar la legibilidad y la extendibilidad.
22
Combinar cdigo similar en una superclase o Si dos subclases tienen cdigo similar se debe tratar de trasladarlo a la superclase o y evitar la duplicacin. o Mover una rutina a otra clase Copiar el cuerpo de la rutina a la nueva clase y reemplazar el cuerpo de la original por una llamada a la nueva. Ir cambiando las llamadas progresivamente hasta poder eliminar la vieja rutina por completo. Convertir una clase en dos Algo muy comn en la construccin de un sistema es que una clase crece en reu o sponsabilidades y es conveniente dividirla en dos para facilitar la legibilidad y mantenibilidad. Eliminar una clase Si una clase se queda slo con un par de responsabilidad quiz sea conveniente o a embeberla dentro de otra y eliminarla. Introducir una rutina fornea a Si un clase necesita una rutina adicional y no podemos modicar la clase para agregarla podemos crear la rutina en la clase cliente. Introducir una clase de extensin o Si una clase necesita nuevos miembros y no podemos modicar la clase, podemos crear una nueva clase que combine la clase original con la nueva funcionalidad. Esconder las rutinas que no deben usarse fuera de la clase Si la interface de una clase es ms coherente sin una rutina, esconderla. a Reemplazar cdigos de error con excepciones o viceversa o Dependiendo de la estrategia de manejo de errores asegurar de usar el esquema adecuado. Proveer factory methods en lugar de constructores Usar un factory method cuando se necesita crear objetos dependiendo de cierta informacin (como ser archivos de conguracin, variables globales, etc), as nos o o abstraemos de estos datos y hacemos que el sistema se vuelva ms exible con a poco esfuerzo.
23
Refactoring del Dise o y la Arquitectura n

No slo el cdigo necesita refactoring, muchas veces cuando nos damos cuenta que o o algo no est del todo bien tratamos de hacer cambios para que funcione. a Pero muchas veces por ms cambios que le hagamos al cdigo el problema sigue ah a o . La razn es porque la solucin no est en cambiar el cdigo sino en cambiar el diseo o o o a o n la arquitectura. Si estamos desarrollando un sistema de manejo de transacciones online podemos descubrir que las mismas salen por time-out cuando hay mucha carga en el servidor. Si la arquitectura del sistema es como una especie de pipeline con un receptor de transacciones que las coloca en una cola, se les pasa de a una al proceso servidor que verica si la transaccin es posible y la registra generando la respuesta correspondiente, o la misma vuelve al proceso receptor para que la env y recin en este momento se le e e pasa la siguiente transaccin al servidor. o Si nos ponemos a dar vuelta el cdigo del servidor para arriba y para abajo hacindole o e refactorings lo ms probable es que no mejore mucho la performance porque el cuello de a botella no est all sino en el receptor de transacciones. a El problema radica en que el receptor trabaja de forma secuencial despachando una transaccin esperando que este lista y luego despachando otra. o La solucin estar dada por una arquitectura concurrente donde las transacciones o a se despachen simultneamente pero esto implica un refactoring muy completo a nivel de a arquitectura y diseo ya que hay que re-pensar todo. n Incluimos este ejemplo para mostrar simplemente que si algo no anda bien, o no nos gusta como qued, podemos ir ms all del cdigo en busca de una solucin a un nivel o a a o o de abstraccin mayor como pueden ser el diseo o la arquitectura del sistema. o n Conclusin o Para marcar la importancia de este tema destacamos que tanto Microsoft como Borland brindarn soporte nativo en sus entornos de desarrollo para muchos de los refaca toring vistos (ver 3.3). La principal razn de esta decisin es porque comprobaron que la comunidad recurr o o a mucho a los complementos comerciales que hac slo esto y porque est comprobado an o a que mejora la productividad. Gracias a este cambio slo necesitamos identicar los refactorings a aplicar y dejar o que nuestro IDE haga el trabajo pesado. Cuando uno comienza a hacer refactoring quiz no vea las ventajas inmediatamente, a pero si lo comenzamos a usar en un proyecto mediano y luego de un tiempo descubrimos que tenemos que cambiar algo en una clase a la que le hicimos refactoring y a otra que no, veremos que es ms fcil de modicar a la que le cambiamos los nombres, la cantidad a a de mtodos, los parmetros, los comentarios, etc. e a
24
2.4.
Desarrollo Dirigido por el Testing
Siempre que se habla de testing nos dicen que es indispensable probar todo lo que hacemos porque somos humanos y nos equivocamos. Que si no hacemos testing es como si el sistema fuera una bomba y no sabemos cuando va a explotar. Pero no hablan bien de como hacerlo o piden demasiadas cosas que no hacen ms que justicar porque en la vida diaria se hace muy poco y solo al a nalizar el sistema. Veamos lo que nos pide la teor a: Debemos probar el sistema contra todas las entradas posibles. Debemos calcular la cantidad de cdigo que est cubierta por los tests. o a Debemos denir formalmente los casos de test para que queden documentados. Debemos correr los casos de test ante cada cambio en el sistema. ... y la lista sigue ... Est bien que se insista en el testing porque en todos lados vemos grcos como el a a de la gura siguiente que nos muestran, con razn, que no se puede dejar el testing para o lo ultimo porque seguro no va a haber tiempo y porque tendr amos que corregir cosas que ya ni recordamos, perdiendo much simo tiempo. En cambio si vamos testeando mientras el sistema avanza nos podremos mantener en un nivel estable de productividad durante todo el desarrollo.
Productividad relacionada con momento en que se hace el testing Algo interesante que se ve en la gura es que el caso que se hace testing durante todo el desarrollo es que tiene una menor productividad inicial, pero provee losmejores resultados a largo plazo.
25
Aqu se presenta otra ves un tema de burocracia porque los clientes o jefes estn a interesados por la productividad actual y no del futuro por eso los programadores no tienen tiempo para testear porque nunca llegan a cumplir con las benditas planicaciones. Lo ms avanzado que existe en cuanto a testing es lo propuesto por Kent Beck en a su libro Test-Driven Development by Example [Bec03] donde nos indica como hacer p primero los test y luego implementar el cdigo. o Esta idea es una parte fundamental de la losof de Extreme Programming. a Aunque parezca una idea ambiciosa d a d cuenta con ms adepto que incluso a a a arman que es ms sencillo que hacer el testing convencional. a Para encontrar mayor informacin sobre el tema ir a: o http://www.TestDriven.net Yo creo que debemos encontrar un punto medio, usando tcnicas de testing temprano e que se pueden ejecutar automticamente. El problema si usamos un enfoque de desarrollo a dirigido por el testing cuesta mucho que todos los miembros del equipo entiendan la idea y apunten hacia el mismo lado. Por eso usando algo ms conservador pero introduciendo a el testing gradualmente obtendremos mejores resultados. Cuando el testing se debe hacer a un sistema que trabaja con Bases de Datos la cosa se complica bastante. Una idea interesante es que, para empezar, hagamos una bater a de tests que simplemente validen que existan determinados registros o que no se quiebran determinadas reglas. Luego ir extendiendo esa bater para que se puedan validar otras operaciones (como a insercin, actualizacin y borrado) sobre una base de prueba. o o En la seccin 3.4 mostraremos como funciona NUnit, la herramienta ms usada para o a crear y ejecutar tests en el mundo de .NET.
26
2.5.
Generacin de Documentacin a Partir del Cdio o o go
En las metodolog denominadas pesadas el desarrollo debe estar dirigido por la as documentacin y los argumentos que presentan para hacerlo parecen buenos, pero, coo mo siempre, en la prctica se convierten en desventajas por la prdida de tiempo que a e 5 implica la actualizacin y porque se termina haciendo un trabajo doble al mantener o paralelamente esta informacin y el cdigo. o o Por ejemplo en los desarrollos administrativos con bases de datos lo recomendado es hacer un diccionario de datos (D.D.) con todas las entidades del sistema y luego crear la tabla. Si hay cambios en esta ultima debemos cambiar tambin los DD, pero si documen e tamos las tablas con los lugares que tienen reservado para esto los motores de bases de datos, la meta-data puede utilizarse despus para extraer las descripciones y generar e automticamente el diccionario de datos e inclusive los diagramas de relacin. a o La contestacin obvia podr ser que pasa si queremos agregar informacin al D.D. o a o y no lo podemos hacer en las descripciones de los campos y las tablas, nuestra respuesta deber ser que esa informacin seguramente es ms importante que el D.D. en si, a o a entonces se deber llevar aparte y no embebido con est informacin ya que perder a a o a relevancia. La idea siempre es tratar de manejar las excepciones como tales y no porque algo no encaja en nuestra idea central concluimos que la idea no sirve. El caso comn es tener la estructura de las entidades y las relaciones y luego si hay u info adicional, que ser una excepcin, se deber documentar aparte. a o a Volviendo a al tema central de esta seccin podemos decir que con el cdigo para o o algo muy parecido, tener un documento de Word con 500 pginas con la denicin de a o las clases, sus mtodos, sus responsabilidades, la relacin entre las mismas, etc. es algo e o totalmente anti-productivo no tiene sentido colocar all ese conocimiento es mejor embeberlo en el cdigo o sacarlo automticamente y generar algo en un formato ms o a a ameno para encontrar lo que buscamos. Cuando Microsoft desarrollo las librer de .NET se encontr con este problema de as o mantenibilidad de la informacin de las clases, mtodos, eventos y propiedades y diseo o e n una nueva forma de documentacin embebida en el cdigo con formato XML, gracias o o a esto posibilit la inclusin de meta-data sobre los parmetros, valores de resultado, o o a ejemplos, etc. Un formato muy comn para la documentacin durante el desarrollo es el CHM de u o Microsoft que nos permite navegar sobre un rbol con el mismo esquema del cdigo y a o ver la informacin relacionada con cada elemento del mismo. o
5 Inclusive si la documentacin est desactualizada puede ser hasta peligrosa porque puede llevar a o a decisiones o pensamientos equivocados.
27
Esta opcin slo funciona con C# ya que es el lenguaje con el que los ingenieros de o o MS escribieron las librer pero ya existen herramientas que lo extienden a VB.NET. as Un ejemplo de como se ven los Tags XML en el editor de cdigo ser o a:
La idea no es propia de Microsoft, para Java existe la herramienta JavaDoc, para C++ se utiliza DoxyGen y la lista sigue. Lo que realmente es un cambio es la documentacin en XML y que el mismo compilador de C# es el que se encarga de extraer o esta informacin a un archivo con el mismo nombre que el ensamblado pero con exteno sion XML. Finalmente fue un paso ms all permitiendo que el IntelliSense del Visual a a Studio extraiga informacin de estos archivos con lo que nuestra documentacin no solo o o se extrae sino que adems se integra automticamente al VS.NET. a a El paso que resta es darle a esa meta-data un formato ms legible que XML 6 y as a completar el c rculo de la documentacin semi-automtica. Existen muchas herramientas o a para hacerlo, la ms popular es NDoc y ser la que analizaremos en la seccin 3.5 (pg. a a o a 65).
Aunque uno de los objetivos cuando se cre XML era que sea legible por humanos no conozco o mucha gente que necesite hacerlo y los que lo hacen tal vez preeran un hermoso archivo de texto plano sin tags.
28
2.6.
Integracin Continua o
Integracin Continua (Continuos Integration) no es simplemente una tcnica sino o e una losof de desarrollo. a La idea es que con la mayor frecuencia posible (al menos una vez por semana e idealmente cada vez que hay cambios) se vuelva a generar todo el sistema y se verique su integridad. Esta orientado a grandes desarrollos donde hay varios equipos que hacen diferentes mdulos del sistema. o Anteriormente los equipos trabajaban casi independientemente, diseaban y pron gramaban sus mdulos, cuando los ten listos los testeaban para ver como se como an portaban y nalmente los trataban de unir creyendo que todo saldr de maravillas; a pero todos sospechamos lo dif que es que esto funcione, sobre todo por la complejidad cil que se presenta si las cosas no encajan y hay que volver todo para atrs. a Continuos Integration ataca a este punto y como lo indica el desarrollo gil trata a de que tengamos el sistema ensamblado lo antes posible durante el desarrollo, porque si pasa demasiado tiempo, los riesgos del proyecto aumentan y las probabilidades de xito e disminuyen. Pero la Integracin Continua va ms all, utiliza las tcnicas vistas como: control de o a a e cdigo fuente, generacin automtica de documentacin, ejecucin automtica de casos o o a o o a de test, etc. para cumplir con su cometido. Los pasos del proceso ideal de integracin continua que se desarrollan automticao a mente son: Revisar el Sistema de Control de Versiones para ver si hay cambios Si los hay, extraer la ultima versin y ponerle un Tag antes de hacer nada (ej: o PRE_0_7_6). Actualizar la versin del Sistema (ej: de 0.7.5 a 0.7.6) o Compilar todos los mdulos del sistema. o Ejecutar los casos de test como se explico en la seccin 2.4 o Si algo sali mal hasta el momento informar por mail o de alguna manera al o encargado y abortar. Generar la documentacin automtica. o a Hacer un nuevo Tag en el sistema de control de versiones (ej: POST_0_7_6). Generar una nueva instalacin del sistema. o Copiar o distribuir los archivos donde corresponda.
29
Generar un reporte sobre la compilacin e integracin. o o Enviar por mail ese reporte a los miembros que corresponda. Grcamente el proceso se ve as a :
Para mayor informacin sobre esta tcnica ver el material en el CD complementario o e o entrar al sitio de CruiseControl.NET: http://ccnet.thoughtworks.com o directamente en www.thoughtworks.com donde encontrarn white papers sobre a estos temas. Si alguna ves tuvimos que entregar sucesivas versiones de una misma aplicacin o sabemos lo dif que se hace recordar todos los cambios que debemos hacer para que cil funcione en el ambiente de produccin. o Se deben cambiar las Bases de Datos, la ubicacin de los archivos ya que seguramente o estbamos usando algunos de prueba, compilar los controles en modo Release, cambiarle a el nmero de version, etc, etc. u Si usamos integracin continua slo debemos indicarle al sistema que usemos los o o pasos que debe realizar para tener una nueva versin lista para poner en produccin y o o automticamente la tendremos con un reporte de los resultados intermedios. a
30
2.7.
7
Armar una Librer de Cdigo y Controles a o
Una de las principales reglas del desarrollo gil es no hacer nada que ya este hea cho por eso estudiaremos como y donde buscar cdigo o controles que resuelvan cosas o por nosotros, luego clasicarlos y guardarlos, para encontrarlos rpidamente cuando los a volvamos a necesitar. Antes esta era una tarea complicada ya que no hab disponibilidad de cdigo, pero a o hoy d con Internet no hay ms excusas, cada ves es mayor la cantidad de sitios que se a a dedican slo a hostear cdigo y controles de manera gratuita. o o Entre las principales ventajas de estos sitios encontramos: Tienen secciones bien ordenadas por lenguaje y categor a. Llevan un control de la popularidad de cada publicacin. Los visitantes pueden o votar y el sitio premia a los que publicaron los art culos ms populares. a Cuentan con opciones avanzadas de bsqueda lo que facilita enormemente buscar u lo que queramos, inclusive el cdigo ms escurridizo. o a Generalmente permiten descargar el cdigo fuente con los binarios y una explio cacin de como instalarlo y usarlo. o Tienen con newsletters con el resumen de las mejores publicaciones de la semana. Mi sitio preferido de este estilo es www.codeproject.com que es el ms completo a y cuidado de todos. Para una lista completa buscar en el Apndice B. e Lo que ocurre si uno frecuenta estos sitios es que hay tanta informacin que la mayor o a parece util pero quiz no sirva para nuestro desarrollo, pero como un en un futuro nos a podr servir hacemos lo siguiente: a Bajamos el cdigo o los archivos, los guardamos en algn lugar del disco y, tal como o u dijo Murphy, permanecern a mano siempre, pero cuando los necesitemos para algn a u proyecto ser imposible encontrarlos. a El problema radica en que no tenemos meta-data de esos archivos, son solo un nombre dentro de algn directorio y nada ms. Necesitamos alguna clasicacin, descripcin, u a o o imagen de como se ven, etc. Lo ms comn es armar una jerarqu de directorios para clasicar esta informacin, a u a o pero a medida que agregamos cosas descubrimos que hay temas ambiguos que son dif ciles de clasicar. As vuelve aparecer el problema de la bsqueda. u Una buena prctica es almacenar ese cdigo en una librer ordenada por categor a o a, as y con la informacin de contexto necesaria para facilitar futuras bsquedas. o u
7
Siempre que este hecho bien...
31
Para que esta tcnica de resultado debemos utilizar una herramienta adecuada para e guardar esta informacin, debe permitir hacer copias de seguridad de la librer (ya que o a es una parte vital de nuestro proyecto) y compartirla con otros miembros del equipo. En la seccin 3.7 mostramos la herramienta denitiva y gratuita para almacenar o nuestros snippets.
32
2.8.
Seguimiento de Proyectos
Al comenzar cada proyecto, como todo parece sencillo, creemos que las cosas que hay que hacer o cualquier otra anotacin a tener en cuenta se puede anotar en cualquier lado o que nosotros lo encontraremos. A medida que el tiempo pasa y el sistema crece se comienzan a olvidar cosas importantes y no se sabe que tareas ests pendientes, cuales listas ni la importancia de cada a una. La solucin a estos problemas es hacer un seguimiento del proyecto (Project Tracking) o en un lugar centralizado. El problema est en hacer que este seguimiento sea sencillo y no una prdida de a e tiempo ya que es simplemente un soporte para saber en que estado est el sistema. a Veremos en el cap tulo de las herramientas cuales son las alternativas y lo sencillo que es usarlas. La intencin es de al menos tener algo para seguir el proyecto, el desarrollo gil nos o a dice: No se debe pretender comenzar con un equipo sin experiencia en desarrollo a gil, aplicar todas las reglas propuestas a su mximo nivel y esperar que el a resultado sea bueno Se debe comenzar de a poco, mejorando lo que hacemos, incluir lentamente las nuevas tcnicas, aprender sus alcances y consecuencias y luego avanzar e a otro nivel El problema de querer controlar todo al mximo detalle es que es totalmente cansador a y lleva realmente ms trabajo que hacer muchas de las cosas que se estn monitoreando. a a
33
2.9.
Crear Componentes y Controles Personalizados
Desde los comienzos de la Programacin Visual los desarrolladores ms avanzados o a creaban controles personalizados para agregar a sus sistemas y para no tener que reescribir el mismo cdigo varias veces o simplemente para poder agregar funcionalidad o fcilmente en un futuro. a Era un grupo muy reducido de programadores ya que no era una tarea sencilla, la documentacin era escasa y el soporte tcnico m o e nimo. El salto ms grande en el desarrollo de componentes lo dio Borland cuando decidi a o liberar el cdigo fuente de su VCL (Visual Class Library) e incluirlo en la instalacin o o de Delphi y C++ Builder. A partir de all y gracias a la abundante documentacin o muchos desarrolladores de todo el mundo comenzaron a formar comunidades para hacer controles. La mayor eran totalmente gratuitos y de alt a sima calidad. Luego de esto Microsoft, para no quedarse atrs, trat de hacer algo parecido con a o Visual Basic pero el problema era que en este lenguaje no ten herencia, lo que en a Delphi era heredar del componente TextBox y agregar funcionalidad, en Visual Basic era reescribir casi toda la clase. En la versin 6 de Visual Basic la creacin se simplic o o o un poco, pero otras tareas como testear, distribuir y reusar el control segu siendo an complicadas. Con la aparicin de .NET todo cambi, ahora la pol o o tica de Microsoft fue brindar un completo soporte para crear controles y componentes y realmente lo logr. Hoy d o a cualquier programador en 5 puede hacer un control que herede de TextBox y deje que se ingresen slo nmeros. o u Adems la documentacin del SDK de .NET es excelente y la instalacin de nuestros a o o controles es simplemente referenciar una dll y listo. Luego cuando se compila el programa cliente automticamente se copia en el directorio del programa8 . a Una gran ventaja de contar con controles personalizados es que en cualquier momento del desarrollo podemos agregar funcionalidad a los mismos fcilmente. Generalmente se a dene una interfaz con el nuevo comportamiento y hacemos que la implementen nuestros controles (se dene una interfaz para poder manejar controles heterogneos de una misma e manera) Algo muy comn en todas las aplicaciones es la validacin de la entrada de los u o usuarios. Mostraremos como hacer para que se automatizar esta tarea. El problema del manejo de errores es que los controles son stateless (no pueden recordar si estn en estado de error o no) as que atacaremos el problema permitiendo a que los controles recuerden si estn en estado de error y en caso armativo almacenen a el mensaje que se le deber mostrar al usuario. a En un principio denamos la interfaz IManejoError:
Se termin todo el tema de registrar dll y todo eso, aunque parec slo una promesa ms de o a o a Microsoft, realmente funciona, todas las instalaciones son Copiar, Pegar y listo
8
34
(*) El prejo cp indica que son propiedades de un control personalizado y permiten encontrar estas propiedades rpidamente desde el editor de cdigo (para mayor a o informacin ver la seccin 2.10 de Convenciones). o o Luego hacemos que nuestro TextBox la implemente y nalmente para usarlo solo necesitamos hacer la siguiente validacin en el formulario donde se encuentra el control: o
De esta manera se puede resolver algo muy tedioso que es la validacin de los datos o ingresados por los usuarios. Al haberlo hecho de esta forma tan genrica hasta podr e amos tener una clase que verique si hay errores en un dado formulario y los muestre. El cdigo o ser a:
35
La pantalla con el resumen de los errores quedar a:
Como otro complemento se puede hacer que el control cuando cambia de estado pinte su borde de color rojo para que el usuario identique claramente donde est el problema a (casi por el mismo precio podr amos mostrar un tooltip con el mensaje de error si el cursor se posiciona sobre el control)
Este es simplemente un ejemplo prctico de lo que se puede hacer con los controles a personalizados. Hay algunos buenos libros sobre el tema, pero, como siempre digo, la mejor forma de aprender es mirando el cdigo (siempre que est bien escrito) de algn control hecho o e u por otra persona con ms conocimientos. a La mejor opcin es entrar a www.CodeProject.com en busca de excelentes cono troles para .NET y adems de descargar el cdigo es interesante guardar las pginas que a o a los presentan, porque generalmente tienen una explicacin de como funciona el control o y de como se usa. La otra opcin es ejecutar el Reector (explicado en la pgina 77) y desensamblar el o a cdigo de algn control del .NET framework como el TreeView para ver como hace uso o u de las opciones grcas y de los eventos. a
36
2.10.
Convenciones de Nombres y Estilo
Cuando trabajamos solos es importante tener al menos algunas convenciones para que nuestro cdigo sea ms mantenible y estructurado. o a Pero cuando se trabaja en equipo es imprescindible tener varias convenciones si queremos que todo llegue a buen puerto y garantizar la mantenibilidad del sistema (incluso nos sirve si cambiamos de personal). Las convenciones se pueden usar para muchas cosas y generalmente se les encuentra el lado bueno despus de usarlas algn tiempo. e u Entre sus usos encontramos reglas para nombrar Clases, variables, archivos de datos, archivos de cdigo, directorios, formularios, recursos compartidos, tablas, formato de o documentos, diagramas, etc. Como as tambin pueden ser reglas que indiquen como es cada proceso del desarrollo, e que documentos se deben crear en cada paso, donde se guardan los archivos, etc. Para .NET analizaremos la rama de las nomenclaturas, pero antes aclararemos dos trminos que sern usados ms adelante: e a a PascalCase Lleva todas las palabras que componen un nombre: en minsculas, concatenadas u y con la primer letra en maysculas de cada una. u Como en: CapaDatos - ExceptionHelper - ContextoSeguridad CamelCase Es igual que el anterior pero con la primer letra en minsculas. u Como en: capaDatos - exceptionHelper - contextoSeguridad
Prejos de los elementos ms comunes de .NET a

Namespaces En Pascal Case, sin underscores. Generalmente se como ra z: NombreEmpresa.NombreTecnologia Si no tenemos un nombre de compa al menos debemos ponerles nuestras iniciales na para poder agrupar todo lo que hagamos y encontrarlo fcilmente. a Recordar que los acrnimos de tres o ms letras van en pascal case como en Xml o a y en maysculas cuando tienen 1 o 2 como en IO. u Assemblies Si el assembly contiene un unico namespace o si agrupa varios pero con un names pace ra en comn, nombrar el assembly igual que ese namespace. z u
37
Clases y Estructuras En Pascal Case, sin underscores, C ni cls. Si la clase empieza con I la segunda letra debe estar en Minsculas sino se conu fundir con una Interfaz. a Las clases no deben tener el mismo nombre que el name space que las contiene. Tratar de usar sustantivos y evitar abreviaturas. Coleccin de Clases o Agregarle Collection al nal del nombre de la clase que agrupa. Como en ArticulosCollection, MenuCollection. Delegates Agregarle Delegate al nal del nombre del delegado. Como en CallbackDelegate, AsyncDelegate. Excepciones Agregarle Exception al nal del nombre de la excepcin. o Como en SecurityException, CadaDatosException. Atributos Agregarle Attribute al nal del nombre del atributo. Como en FormInMenuAttribute, DescriptionAttribute. Interfaces Agregarle I al inicio del nombre de la interfaz. Como en IManejoError, IEnlaceDatos. Enumerados No agregar Enum al nal del nombre del enumerado. Poner slo el Nombre y si sin ags ponerlo en plural. o Como en DayOfWeek, EditModes. Funciones y Mtodos e En Pascal Case, sin underscores, con excepcin de los manejadores de eventos. o Tratar de evitar abreviaturas. Las funciones y mtodos deben diferir en algo ms que la capitalizacin para no e a o tener problemas si se lo usa desde VB.NET o algn lenguaje Case-Insensitive. u Propiedades y Variables Publicas En Pascal Case, sin underscores. Tratar de evitar abreviaturas.
38
Variables privadas de la clase En Camel Case, sin underscores, comenzando con una m. Indicar siempre Protected o Private, no usar Dim. Como en mDatos, mValorInical. Parmetros a En Camel Case. Tratar de evitar abreviaturas. Es posible usar si el parmetro tiene a el mismo nombre que una variable privada o protegida de la clase el prejo p Como en pDatos, pValorInicial. Lo interesante de la ultima regla es que dentro del cuerpo de la rutina encontramos asignaciones del estilo: mDatos = pDatos Identicando claramente que se est asignando un parmetro a una variable local a a y no necesitamos subir o bajar para ver que son. Variables dentro de los procedimientos En Camel Case. Sin nada en particular pero evitando usar nombre como tempo, obj, etc. buscar algo un poco ms signicativo. a Variables dentro de las funciones Igual que en los procedimientos, pero usando siempre el mismo nombre para la variable que mantiene el valor a devolver. Un nombre comn es Res. u Como aclaracin general podemos decir que se deben evitar, siempre que sea posible, las o abreviaturas ya que complican la lectura del cdigo. o El problema est en que cuando uno se olvida que signica, cada vez que lee el cdigo a o debe detenerse a pensar que quer decir. En cambio si escribimos los nombres completos a la lectura es rpida y objetiva. a Un test muy interesante que propone el equipo de .NET de Microsoft es el Google Test, que consiste en escribir el nombre abreviado de la variable en el cuadro de bsqueda u del buscador. Si como resultado nos dice: Usted quiso decir ... el nombre completo signica que podemos usar la abreviatura, de otra forma no.
Controles
Un lugar donde todos usan prejos para denominar a los objetos es en los controles es en la programacin visual. o Una vez que uno comienza a utilizarlos los recuerda fcilmente ya que son muy a intuitivos y, junto con el Intellisense, facilitan la codicacin y lectura del cdigo. o o La siguiente tabla muestra las convenciones ms utilizadas: a
39
Control Modulo Formulario Button TextBox CheckBox RadioButton GroupBox PictureBox ListBox ListView CheckedListBox ComboBox TreeView DateTimePicker ToolBar MenuItem Label ImageList DataGrid ProgressBar RichTextBox Splitter
Prejo mod frm cmd txt chk rad grp pic lst lvw clst cbo tvw dtp tlb mnu lbl img grd pbar rtf spl
Ejemplo modInicial frmPrincipal cmdAceptar txtApellido chkHabilitado radMasculino grpOpciones picFoto lstUsuarios lvwArchivos clstOpciones cboLocalidad lstUsuarios dtpFechaAlta tlbPrincipal mnuArchivo lblNombre imgIconos grdPedidos pbarProcesados rtfDocumento splLateral
Objetos de Acceso a Datos

Cuando utilizamos objetos de acceso a datos es conveniente que tengamos algunos prejos para que el cdigo se vuelva ms legible. o a La siguiente tabla muestra algunas recomendaciones: Objeto DataSet DataRow OleDbConnection o SqlConnection OleDbCommand o SqlCommand OleDbDataAdapter o SqlDataAdapter OleDbDataReader o SqlDataReader Crystal Report Prejo ds dr conn cmd da rdr rpt Ejemplo dsLocalidades drLocalidad connServidorDB cmdUpdate daClientes rdrClientes rptAtculos
40
Convenciones para los Mensajes del Sistema

Un problema que viene desde le comienzo de la programacin visual es el tema de o donde se almacenan los string con mensajes en general y de error. El problema consiste en que los mensajes se distribuyen por cualquier parte del sistema y es muy dif cil encontrarlos, por ejemplo, para corregir posibles errores ortogrcos, agregarles cosas, a etc. Cuando se quisieron traducir los programas entre diferentes idiomas la cosa empeor o bastante y las grandes empresas, entre ellas Microsoft, tuvieron que buscar una solucin o inmediata porque adems del costo de cambiar todas las cadenas, se corr el riesgo a a que el traductor cambiase algo ms del cdigo y el programa generado podr contener a o a errores dif ciles de detectar ya que slo se presentan en ciertas versiones y no en otras. o El golpe nal vino con los services packs, porque cuando se detectaba un error en determinado programa se correg y adems se ten que corregir en las versiones en a a a otros idiomas ya que el parche no se pod aplicar a todas porque quedar mensajes en a a ms de un idioma. a La solucin apareci del lado de los denominados archivos de recursos que vendr o o a a ser informacin simblica incrustada dentro del programa. o o De esta forma no se usa el mensaje en s sino que se lo referencia con una constante , simblica, ahora si se quiere traducir un programa basta traducir el archivo de recursos o y listo. Lo que proponemos para el manejo de errores es seguir estas convenciones pero adaptarla a nuestras necesidades para luego poder extenderla. Comencemos entonces a denir las clases que formarn parte del sistema de manejo a de errores. En primer lugar deniremos un enumerado cuyos valores vendr a ser como las an constantes simblicas de los archivos de recursos: o
41
Luego denamos la clase ErrorInfo que va a contener todas las cadenas con los mensajes y la informacin adicional: o
Adems del Tipo de Error y el Mensaje tenemos una bandera que indica si el error a deber reportarse por mail como explicaremos en la seccin 2.11. a o En la l nea 11 vemos que esta opcin est habilitada por defecto pero se podr o a a cambiar para cada tipo de mensaje. En la l nea 12 vemos que se invoca el mtodo CargarDatos con un tipo de mensaje e Msg y con parmetros opcionales que pasan al arreglo Args: a
El mtodo es mucho ms largo ya que contiene los mensajes de error, pero como e a dijimos todas las cadenas estn all y en caso de querer cambiar algo, buscamos la a constante y modicamos el string correspondiente. En la l nea 25 de CargarDatos vemos como se podr evitar que se env un mail a e para determinado tipo de error. Para darle un uso prctico a esta idea deniremos una clase Mensaje con el mtodo: a e
42
Este mtodo se sobrecarg para que pueda recibir el tipo de mensaje o slo un string, e o o la idea es que todo lo que signique mostrar mensajes al usuario pase por aqu inclusive , si es simplemente un MessageBox. Hay adems un arreglo de Object que se usa para pasar informacin extra, por a o ejemplo, si el mensaje es de un error inesperado en una pantalla le debemos pasar el nombre de la misma y en el String.Format de la clase ErrorInfo incluirlo con un {0}.
Al usar enumerados para la denicin de las constantes cuando colocamos el parno e tesis luego del nombre del mtodo en el editor de cdigo del Visual Studio nos aparecen e o todas las constantes denidas facilitando enormemente la codicacin. o
43
2.11.
Manejo y Reporte Automtico de Errores a
Un tema a tener en cuenta en cualquier sistema que desarrollemos es como vamos a hacer con el manejo de errores y sobre todo con esos errores inesperados que se presentan cuando los usuarios nales ponen sus manos en el sistema. En .NET los errores no capturados se presentan al usuario de una forma poco amigable y hace que nuestro sistema se vea inestable y parece que no cuidamos los detalles. El t pico ejemplo es cuando le pedimos un dato al usuario con un TextBox y lo que necesitamos es un integer, si el usuario no ingresa nada y hacemos la asignacin del o TextBox a nuestra variable entera, nos aparece el error:
Cualquier usuario que recibe este mensaje seguramente se asustar, lo cerrar e ir a a a a hacerse unos mates sin decir nada por miedo a haber hecho algn l u o. Afortunadamente existe una forma de capturar estos errores y presentar un mensaje ms ameno (est estrategia se extrajo de www.CodeProject.com). a a
44
Agregando las l neas marcadas (de la 13 a la 15) y el mtodo de las l e neas 6, 7 y 8, cualquier error sea cual fuere el tipo del mismo pasar el control al mtodo a e ManejoDelError donde podremos mostrar un mensaje ms amigable. a Si no utilizamos esta forma de atrapar errores podr amos poner un TRY-CATCH en nuestro mtodo Main. Pero, o sorpresa, en ciertas ocasiones aparece la misma pantalla e del principio. La explicacin es que el TRY-CATCH slo captura las excepciones del o o Thread al que pertenece, entonces, si el formulario que genera el error esta en otro Thread no se pasa el control al CATCH del Main sino directamente al runtime de .NET. Esto muestra porqu la solucin propuesta es una de las pocas que tenemos. e o Pero demos un paso ms, un problema frecuente con cualquier sistema es que los a usuarios no avisan cuando les aparecen estos errores o aunque avisen no nos pueden brindar la informacin de contexto requerida para identicar porque ocurri determinado o o error. La propuesta es reportar el error por mail sin que el usuario se entere. Aunque parezca complicado, mostraremos parte del cdigo que es muy sencillo y en el CD complementario o pueden encontrar todo el cdigo. o Primero creamos un HTML en nuestro proyecto y lo incluimos como recurso de la solucin, el mismo tendr variables encerradas con el s o a mbolo $ de la forma $MensajeDeError$.
Cuando ocurre un error debemos cargar la pgina que se logra leyendo el archivo a de recurso como un string para obtener el cdigo HTML original, luego reemplazar las o variables en el template con los datos reales para lo que usamos el mtodo Replace de e la clase String. Vale aclarar que esta no es la forma ms eciente porque se recorre el HTML n a veces y se crean n string del tamao del cuerpo del mensaje (donde n es la cantidad de n variables), se deber hacer un parsing ms sosticado e ir reemplazando las variables a a a
45
medida que las encontramos, pero a los efectos del ejemplo ser suciente con la forma a Add hoc.
Para el envi de mails usamos una clase wrapper de la clase System.Web.Mail.MailMessage o de la librer de .NET, el cdigo usado ser a o a:
El broche nal ser agregarle al mail un screenshot que nos muestre la tarea que a estaba realizando el usuario en el momento del error. Adivinen cuantas l neas se necesitan en .NET para poder hacerlo, ... si si ..., menos de 8 l neas de cdigo o
46
Este mtodo devuelve un objeto Bitmap, si queremos guardarlo en el disco este ser e a 9 el cdigo a usar: o
El mail que recibimos tiene la forma, charn charn: a a
Es incre la facilidad al manejar imgenes sobre .NET, maneja los formatos ms conocidos y los ble a a accede a travs de la clase genrica Image para abstraerse del que estamos usando. e e
Cap tulo 3 Herramientas de Desarrollo Agil para .NET

Las Tcnicas de Desarrollo Agil vistas para .NET, y todas las tcnicas en general, no e e tienen el impacto deseado si las tareas que proponen se tienen que hacer manualmente, por ello veremos en esta seccin las herramientas que dan soporte a estas tcnicas y las o e llevan un poco ms all para maximizar la productividad. a a No daremos una descripcin detallada de cada una sino que nos limitaremos a mostrar o la funcionalidad bsica de cada una, fomentando al lector a probarlas y a seguir la a documentacin que las acompaan y que son muy grcas y completas. o n a La mayor de las herramientas son gratuitas y su cdigo fuente est disponible en a o a internet. Es una tarea interesante investigar el cdigo y tratar de hacer cambios para o agregar funcionalidad y ver que ocurre, porque la mejor de aprender algo en el mundo de la computacin es probando y teniendo mucha paciencia. o En el Apndice B (Pg. 97) estn los enlaces a los sitios de cada herramienta tratada e a a y de muchas otras otras. En el CD complementario se encuentran el cdigo fuente y el ejecutable de cada una o en las versiones disponibles a Abril de 2005.
47
CAP ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET
48
3.1.
Generacin Semi-Automtica de Cdigo o a o
Por experiencia personal creo que existe una sola forma de tener xito con la gene eracin de cdigo de forma automtica y es a travs de plantillas editables. o o a e Los programas que funcionan como una caja negra que uno les da la denicin de o la base de datos y generan clases para el acceso a datos sin que se pueda modicar la forma en la que lo hacen ni agregar funcionalidad, son realmente peligrosos. puede ser que al principio todo parezca ir de maravilla pero cuando necesitemos agregar funcionalidad y no entendamos nada del cdigo generado los problemas compensarn o a a aparecer, ms aun, cuando cambie el esquema de la Base de datos y queramos regenerar a el cdigo se pisarn los cambios (si es que logramos concretarlos). o a Por estas razones la herramienta ideal para generar cdigo en .NET con plantillas se o llama CodeSmith, es gratuita y muy usada. La herramienta es sencilla de utilizar basta denir un archivo con la plantilla y correrlo en el programa por ejemplo si queremos generar cdigo para asignarle a variables o var1, var2, var3, ..., un valor de carcter consecutivo debemos escribir la plantilla: a
Todo lo que est entre <% y %> se ejecuta en CodeSmith porque es parte del cdigo a o de la plantilla, lo que est fuera de estos s a mbolos se copia literalmente al resultado. El s mbolo <%= indica que se evaluara la expresin que est a su derecha y se escribir o a a el resultado en la salida. Al ejecutarlo obtenemos:
Este ejemplo no tiene mucho sentido pero si utilizamos la funcionalidad de CodeSmith de manejar el esquema de las bases de datos podemos denir:
49
Hay algunas instrucciones un poco raras pero veamos que signican: En la l nea 2 le decimos a CodeSmith que nuestra plantilla tiene una propiedad y que la misma es de tipo TableSchema lo que indica que representa una tabla de alguna fuente de datos. En la l nea 3 se importa el Assembly que contiene la denicin de los tipos relao cionados con las fuentes de datos. De la l nea 7 a la 9 lo que hacemos es poner el nombre de la columna, un As y nalmente el tipo de la columna pero en VB.NET. En la l nea 13 se oculta la funcin GetVBVariableName que lo unico que hace o es devolver el tipo de una columna pero en VB.NET. Si lo abrimos y utilizamos por ejemplo la tabla Titles de la base de datos Northwind que viene con el Sql Server el resultado es:
50
Ya tenemos hecha gran parte de la plantilla que resuelve el mapeo relacional porque podemos generar con un click la estructura de una tabla, es realmente fcil, no ?? a Veamos ahora como ser una plantilla para generar cdigo de acceso a datos a travs a o e de un DataReader de .NET.
La losof es ms o menos la misma, lo importante es el ciclo For que abarca de la a a l nea 19 a la 22, all se hace la asignacin de la columna correspondiente de la tabla a o la variable de la estructura que cumple la funcin de representar el mapeo relacional. o Para el ejemplo usamos directamente una instruccin SELECT en el cdigo, esto no o o es lo ms recomendable, generalmente se debe generar un stored procedure para cada a mtodo bsico (Fetch, FetchAll, Insert, Update, Delete) para evitar problemas e a de mantenibilidad y de seguridad. El resultado de correr esta plantilla contra una tabla de Localidades se puede ver en la siguiente pgina. a Los pasos siguientes ser hacer una plantilla para generar los stored procedures a de los que hablamos con algn prejo en particular para distinguirlos de los que no u son son generados automticamente, por ejemplo podemos usar pga por Procedimiento a Generado Automticamente y pgu para los Procedimientos Generados por los Usuarios. a Los que comienzan con pga nunca deber tocarse ya que si se vuelven a generar se an perder los cambios y nadie se dar cuenta. an a
51
Finalmente podr amos crear una plantilla para las entidades de negocios de una arquitectura en capas con operaciones de edicin y de control de estados como propone o Rockford Lhotka en su libro Expert One-on-One Visual Basic .NET Business Objects [Lho03]. Quiz la forma en la que este explicado all no sea del todo prctica por la utilizacin a a o de WebServices y algunas opciones de DataBinding un tanto complejas pero se pueden tomar como moldes para hacer nuestras propias plantillas. Como conclusin podemos decir que cada vez existen ms proyectos para hacer mapeo o a relacional a travs de plantillas. Algunos son tan completos que la complejidad para e entenderlos es alt sima y nos lleva mucho tiempo. Lo recomendable es buscar alguno sencillo o extender las plantillas aqu propuestas y a medida que entendemos la idea ir escalando hacia un framework ms completo. a Personalmente he usado las plantillas incluso para generar el cdigo detrs de las o a pantallas de ABM que son generalmente muy parecidas y cranme que uno ahora mucho e tiempo y comete menos errores. La ventaja principal es que las asignaciones de las propiedades de las estructuras a los controles y viceversa, las declaracin, los t o tulos de las columnas, todo es generado por las plantillas, evitndonos el Copy and Paste que a siempre trae problemas.
52
3.2.
Control de Versiones y Programacin Concuro rente
CVS (Concurrent Versioning System)

El Sistema para control de versiones y programacin concurrente ms utilizado es el o a CVS. Todos los proyectos relacionado con Linux tienen sus repositorios de cdigo en CVS, o ya que el mismo deriva de un antiguo sistema de control de versiones denominado RSH que surgi paralelamente con Unix. o Los proyectos open source hosteados en la pgina www.SourceForge.net, ellos a citados en esta tesis, tambin usan este sistema para que los programadores puedan e acceder concurrentemente al cdigo y para tener un historial de los cambios. o El cliente de CVS ms conocido y fcil de usar es l TortoiseCVS: a a e
El mismo se integra totalmente con el Explorador de Windows, agregando opciones al menu contextual de cada archivo o directorio. Pasos para crear un repositorio y poner un proyecto bajo control del CVS: 1. Hacer click con el botn derecho sobre la carpeta que deseamos agregar, abrir el o submen CVS y seleccionar Make New Module... y completar los datos que nos u solicite.
53
2. Hacer click con el botn derecho sobre la carpeta y seleccionar CVS Add Contents... o
3. Hacer click con el botn derecho sobre la carpeta y seleccionar CVS Commit... o
4. Observar que en el Explorador de Windows nos muestra las versiones de cada archivo y los iconos que indican si estn modicados o no... a
54
SVN (Sub-Version)
Subversion naci para ser el reemplazante natural del CVS y para cubrir algunas de o sus principales falencias, entre ellas:1 Soporte transaccional para los commits y updates. Posibilidad de Renombrar Directorios y Archivos. Agregar Meta-data a los archivos. Permitir manejar diferencias en archivos binarios, guardando slo los cambios y no o todo el archivo como en el CVS. Manejo eciente de los Branch y Tags (en CVS eran proporcionales al tamao del n proyecto). El proyecto tiene una velocidad de maduracin asombrosa y cada vez tiene ms o a adeptos. El cliente de SVN ms conocido y fcil de usar es: a a
Los pasos para crear un repositorio son similares a los mostrados en para CVS. Si el lector desea entrar en ms detalles se recomienda leer la ayuda que acompaa el a n programa que es muy grca y completa. a
WinMerge
Este no es una herramienta de control de versiones pero es un complemento de estas ya que se encarga de mostrar las diferencias entre dos versiones de un archivo. Adems permite que lo utilicemos para resolver conictos cuando dos programadores a cambian al mismo tiempo la misma l nea de cdigo. Como nos muestra las diferencias o lado a lado es sencillo encontrar el problema y solucionarlo.
En el CD complementario hay una comparacin exhaustiva entre estos dos sistemas. o
55
3.3.
Refactoring
ReSharper
Este es el programa de refactoring mas popular en el mundo de .NET, ms especiala mente para los adeptos a C#. Los refactoring ms comunes se pueden hacer con un slo click a o
Pero adems cuenta con otras opciones como bsqueda rpida en archivos y clases, a u a mejora el Intellisense del VS.NET, tiene templates de cdigo, genera asignaciones auo tomticamente. a La mejor caracter stica para los desarrolladores de C# es que hace un anlisis en a tiempo real del cdigo y nos muestra junto a la barra de desplazamiento los lugares con o errores o warnings, marcndolos con diferentes colores. Algo similar viene integrado en a Visual Studio para VB.NET, sin embargo para saber si tenemos errores en cdigo escrito o en C# debemos compilar todo el proyecto. Por ello si usamos el ReSharper todo esto pasa a ser un recuerdo y vemos como aumenta nuestra productividad. Esta es una de esas herramientas que cuando las instalamos y vemos como nos simplica todo no podemos dejar de usar. En el CD complementario se encuentra un version de demostracin o se puede bajar o de la pgina ocial la ultima versin. a o
CodeSmart
La palabra mayor en cuanto a add-ins para VS.NET, sobre todo para los que venimos del mundo de Visual Basic, es Code Smart. La ultima versin para .NET de este complemento, la 2005, es complet o sima y nos permite aumentar nuestra productividad porque automatiza las tareas ms tediosas. a Este programa se integra perfectamente con el Visual Studio .NET agregando funcionalidad en los menus contextuales y un nuevo men principal. u
56
Como se ve en la gura cuenta con gran cantidad de opciones:
Este add-in es indispensable si pasamos muchas horas programando con Visual Studio, en el CD complementario encontrarn una version de demostracin o directamente a o pueden bajar la ultima de la pgina ocial. Cuando termina el per a odo de prueba simplemente se deshabilitan algunas funciones pero las otras siguen funcionando bien. Entre las mejores caracter sticas tenemos: Corrige las faltas ortogrcas dentro de los strings (podemos bajarnos el diccionario a en castellano de la pgina) a Cuenta con el Code Flow Explorer que genera un rbol de llamadas entre mtodos a e haciendo un anlisis del cdigo fuente. a o Extiende las funciones de Bsqueda y Reemplazo del Visual Studio. u Genera la documentacin XML para VB.NET. o Formatea el estilo del cdigo a nuestro gusto. o Genera Estad sticas del cdigo contando cantidad de l o neas de cdigo, de comeno tario, en blanco, etc. Ordena los Miembros de una clase en el orden indicado.
57
Inserta cdigo al principio o al nal de los mtodos que cumplen con determinada o e caracter stica. Cuenta con Snippets de Cdigo que se pueden compartir con el resto del equipo. o Fuerza a que se utilicen las convenciones para nombrar controles o variables. Es totalmente congurable.
Soporte en Visual Studio 2005

Visual Studio 2005 incluir soporte integrado para hacer los refactoring ms comunes a a entre ellos los tratados en la seccin 2.3 (pg. 19). o a Un listado no exhaustivo de los soportados incluye: Rename Extract Method Encapsulate Field Extract Interface Promote Local Variable to Parameter Remove Parameters Reorder Parameters
En el sitio ocial del Visual Studio nos indican las nuevas caracter sticas que tendr a este entorno y muestran un ejemplo de lo fcil que ser hacer refactoring de ahora en a a adelante:
58
Soporte en Delphi 2005

Siguiendo la misma l nea que Microsoft, Borland incluy en Delphi 2005 una gran o cantidad de herramientas para hacer refactoring y mejor el IDE tratando de recuperar o el mercado perdido por el poco xito de Delphi 8. e Por lo que dicen las cr ticas esta vez Borland nos dar un entorno con la calidad a a la que estamos acostumbrados de ellos y no algo improvisado como fue Delphi 8 cuyo lanzamiento fue apresurado y que para corregirlo ya lleg al Service Pack 3. o
Refactoring Explorer de Delphi 2005
59
3.4.
NUnit
Testing de Aplicaciones
La herramienta ms popular de testing para .NET es NUnit. a Naci como la versin portada para .NET de la popular herramienta de Java (jUnit), o o pero luego, en la versin 2, se renov totalmente para hacer uso de facilidades avanzadas o o de .NET como los atributos y la reexividad. La idea de esta herramienta es hacer testing de caja negra desde el punto de vista del cliente de la clase o elemento del sistema a testear. Inclusive se puede llevar un paso mas all y utilizarla para implementar Test Driven a Development (como se explic en la seccin 2.4). o o Veremos un ejemplo sencillo para mostrar como funciona. Para hacerlo simple el ejemplo parecer de juguete pero debemos recordar que lo importante son los conceptos a de cmo usar NUnit y no de para que lo estamos usando. o Primero denamos una clase que herede de la clase Stack del .NET Framework, que se encuentra en el namespace System.Collections. La misma agregar los mtodos: a e
La descripcin e implementacin de los mtodos es: o o e PopAll() Quita todos los elementos de la Pila y los devuelve como un arreglo de objetos.
PopRange(n as Integer) Quita n elementos Pila y los devuelve como un arreglo de objetos.
60
PushRange(objs as Object()) Agrega los elementos del arreglo objs a la Pila.
Para testear la clase creamos un nuevo proyecto llamado TesisStackTests de tipo Librer de Clases y agregamos la referencia al assembly nunit.framework y al a proyecto donde est nuestra clase Pila como muestra la gura: a
Expliquemos brevemente cuales son los atributos que podemos usar con NUnit: TestFixture Indica que la clase contiene Casos de Tests.
61
Test Indica que el mtodo debe ser tratado como un Test. e SetUp Indica que el mtodo se ejecutar antes de cada Test. e a TearDown Indica que el mtodo se ejecutar al nalizar cada Test. e a TestFixtureSetUp Indica que el mtodo se ejecutar una vez antes de cualquier Test. e a TestFixtureTearDown Indica que el mtodo se ejecutar una vez al nalizar todos los Test. e a Ignore Indica que el Test no se ejecutar y ser ignorado. a a ExpectedException Indica que para que el Test sea exitoso debe generar la excepcin indicada. o Mostremos como ser el esquema de la clase con los tests: a
62
En ms detalle, el cdigo de cada test ser a o a:
63
Y ahora la mejor parte, si tenemos instalado el TestDriven.NET para ejecutar los tests simplemente hacemos dos clicks ...
Finalmente as muestra el resultado NUnit-Gui:
64
Soporte en Visual Studio 2005

Visual Studio .NET 2005 incluir un soporte para hacer testing de la misma forma a de la que se lo hace con NUnit. Microsoft intenta con esto aprovechar los conocimientos de la comunidad de desarrolladores que encontr en Nunit una herramienta que siempre buscaron y que facilite o la tarea de testing. En el mismo IDE se podr navegar por los tests, ignorarlos, etc. a
65
3.5.
Generacin Semi-automtica de Documentacin o a o
Como mostramos en la seccin 2.5 es muy dif mantener la documentacin mano cil o ualmente, es necesario utilizar herramientas que a partir del cdigo generen diagramas o y documentos sobre el cdigo o las tablas del sistema. o La herramienta ms popular para la generacin de documentacin en .NET es NDoc. a o o Esta utiliza los archivos XML que se crean al compilar una aplicacin en C# y junto con o los assemblies genera la documentacin: o El uso de la herramienta es muy sencillo: Ejecutamos el entorno grco. a Seleccionamos los assemblies a documentar. Seleccionamos el formato de salida. Conguramos el estilo de la documentacin. o Presionamos en compilar documentacin. o Grcamente: a
66
Y el chm que genera nos queda:
Es tan sencillo usar NDoc que no hay mucho ms que explicar simplemente debemos a sentarnos a documentar lo que creemos necesario.
VB.DOC
Un problema grave es que por algn motivo Microsoft no incluy soporte para docu o umentacin XML en VB.NET. De todas formas existe una herramienta a la cual le o podemos dar un proyecto de Visual Studio .NET y extraer los comentarios XML del a cdigo en Visual Basic. o La herramienta se llama VB.DOC y la podemos encontrar en www.SourceForge.net. Para usarla basta con darle el proyecto y automticamente extrae el XML tal como a lo hace el compilador de C# de Microsoft. Luego de esto no hay ms diferencias ya que NDoc no distingue en que lenguaje esta a escrito lo que documenta, slo necesita un assembly y el XML asociado. o
67
3.6.
Compilacin e Integracin Automtica o o a
Visual Studio .NET es el IDE ms completo y poderoso que desarroll Microsoft, las a o ventajas van desde la variedad de las plantillas de proyectos, la incre ble facilidad del Form Designer hasta las herramientas de integracin con Bases de Datos. o VS.NET provee un excelente entorno para el desarrollador individual, pero trae poco soporte para equipos de trabajo (al menos en la versin 2003), otras falencias incluyen: o No facilita el desarrollo entre personas en distintos lugares. No se puede automatizar la ejecucin de los test. o No trae soporte para otros sistemas de control de versiones que no sean MS Source Safe (ya sabemos por que no ??). No se puede hacer Integracin y Compilacin centralizada. o o Para solucionar la parte de automatizacin de tareas de construccin, control de o o versiones, testing y distribucin se desarrollo NAnt. o
NAnt
NAnt es un herramienta de generacin automtica totalmente gratuita que vendr o a a a ocupar el lugar del MAKE pero en los tiempos modernos. Se llama NAnt por Not Ant indicando que no es la herramienta para Java portada sino algo diferente. Aunque la idea es la misma la forma en la que esta implementa diere, ya que las tareas estn escritas en dlls de .NET y se integran como pluggins. a NAnt es facil de usar, nos podemos trabar un poco al principio pero cuando le agarramos la mano todo va sobre ruedas. Cuenta con 4 elementos que se representan con la sintaxis estndar de XML: a Tasks Son los comandos que le damos a Nant. La mayor vienen con NAnt pero se a pueden agregar otras fcilmente. a Las tareas pueden representar tareas simples sobre archivos (copy, move o delete), comandos avanzados (zip, unzip, mail, cvs), comandos de .NET (csc, vbc, tlbimp) y otros comandos interesantes (nunit, regex) Existe tambin el condicional if pero con una sintaxis un poco diferente y foreach e para los loops. Veamos como es la sintaxis en XML de la tarea copy: <copy file=archivo1.cs tofile=archivo1.bak/>
68
y la de la tarea mail:
<mail from=compilacionauto@nombreempresa.com.ar tolist=sistemas@nombreempresa.com.ar subject=Resultados de la Generacin.ar mailhost=smtp.nombreempresa.com.ar > <attachments> <includes name=*reporte.txt/> </attachments> </mail>
El proyecto NAntContrib (nantcontrib.sourceforge.net) agrega ms tareas a a las que vienen por defecto entre otras: codestats, mkiisdir, deliisdir, SQL, etc Targets Los targets son colecciones de tareas con nombre. Cuando se invoca un target se ejecutan las tareas en el orden en las que se encuentran. Pueden depender a la vez de otros targets, en este caso siempre que se ejecute un target se ejecutar antes la lista de dependencias. En el siguiente ejemplo se a ejecutar antes clean que prepare: a <target name=clean description=borra los dirs: bin, src y doc> <del dir=bin/> <del dir=src/> <del dir=doc/> </target> <target name=prepare depends=clean description=crea los dirs: bin, src y doc> <mkdir dir=bin/> <mkdir dir=src/> <mkdir dir=doc/> </target> Si varios targets dependen del mismo este slo se ejecuta una vez. o Properties Las propiedades vendr a ser las variables de un script de NAnt. an
69
La diferencias est en que le podemos dar un valor slo una vez, a partir de all a o una propiedad es inmutable. Las propiedades pueden tener un valor por defecto, pueden ser le das de un archivo externo o pasadas como argumento cuando se inicia la ejecucin del script. o Hay un conjunto de propiedades predeterminadas como: nant.version, nant.filename, nant.settings.defaulframework. La forma de denir una propiedad es la siguiente: <property name=host.name value=NuestraEmpresa.com/> Projects Un proyecto es una coleccin de properties, targets y tasks. o Puede estar en un unico archivo o se puede dividir en varios. Un ejemplo de la sintaxis de project: <project name=miProyecto> <property name=project.author value=Marcos Meli/> <target name=clean> <del dir=bin/> </target> <!- etc. -> ... </project> Para ejecutar un script de NAnt simplemente usamos la l nea de comando: nant /f:NuestroScript.build Si no le damos el nombre del script NAnt seguir los siguientes pasos: a 1. Busca en el directorio actual un archivo .build. 2. Si no lo encuentra muestra el error. 3. Si hay slo un archivo .build lo ejecuta. o 4. Si hay ms de un archivo .build: a a) Si alguno se llama default.build lo ejecuta. b) Si ninguno se llama default.build muestra un error.
70
Cruise Control .NET

Es herramienta gratuita que se ubica a un nivel mayor de abstraccin en cuando a o automatizacin que NAnt. Es ms el a lo explicado en la seccin 2.6 de Integracin o a o o Continua. Esta herramienta se encarga principalmente de monitorear un sistema de control de versiones y disparar ciertos scripts cuando se detectan cambios (los scripts pueden ser de NAnt). Actualmente va por la versin 0.9, es muy fcil de instalar y congurar gracias a la o a documentacin que lo acompaa que es muy completa. o n La caracter stica ms interesante es que genera reportes de cada paso, ya sean de a compilacin, testing, integracin, validacin, etc. o o o Los mismos se pueden ver desde una pgina web o se le puede pedir al sistema que a los envi por mail en cada integracin. e o
Soporte Visual Studio 2005

Lo ms asombroso de lo que ser el nuevo entorno de Microsoft es la integracin a a o completa de todas las tareas de desarrollo. Visual Studio 2005 incluir soporte desde el modelado de clases, el testing, la docua mentacin hasta la compilacin automtica. o o a En el Cd complementario se incluye un articulo disponible en la pgina ocial del a VS.NET 2005 que indica las nuevas caracter sticas. Un diagrama que encontramos all muestra como est planteada la integracin: a o
71
3.7.
Almacenar Nuestra Librer de Cdigo y Cona o troles
Durante aos hubo aplicaciones para guardar snippets de cdigo y ordenarlos, la n o mayor comerciales, pero para .NET existe un programa que a todos estos los deja a kilmetros atrs y se trata de Code Library for .NET de Fish.NET. o a El programa es chino y parece ser que muestra que el fuerte de los chinos, como todos dicen, est en perfeccionar las cosas no en inventarlas, porque este programa es a la perfecta unin de todas las ideas buenas para almacenar cdigo e informacin que o o o existen. Sinceramente cuesta mucho explicar todo lo que hace lo mejor es probarlo y darnos cuenta que est hecho para nosotros. a Adems de completo tiene un muy cmoda y usable interfaz de usuario como se a o muestra en la gura:
Pantalla principal del CodeLib Algunas de las caracter sticas son: Permite almacenar el cdigo en varias bases de datos y hasta con distintos formatos o entre otros: Access, MSSQL Server, MSDE y MySQL. Permite que varios desarrolladores compartan las bases de datos sobre todo en las versiones de SQL Server y MySQL.
72
Guarda las descripciones, cdigo, archivos adjuntos e imgenes dentro de la base o a as que para llevarlo a otro lado es extremadamente fcil. a Compacta las Bases de Datos y hace Backups automticos de las mismas. a Podemos editar la descripcin de cualquier item con el editor embebido. o Podemos bajar pginas Web con el download manager y guardarlas como parte de a algn item. u Se pueden bajar del mismo sitio 4 bases de datos con cdigo, muy completas, para o los lenguajes: VB6, VB.NET, C# y un compilado con varios lenguajes llamado CodeLib. Permite exportar a XML, HTML, CHM y PDF; e importar datos del disco, de los favoritos, etc. Se puede bajar un plug-in para el Visual Studio para que sea an ms cmodo el u a o trabajo ya que aparecen los snippets como una ventana ms en el IDE. a las posibilidades de Bsqueda son muy Avanzadas. u Es totalmente personalizable, hasta se pueden cambiar los iconos de cada tem. Hay versiones nuevas del programa todo el tiempo y mucha actividad en su desarrollo. Los screenshots muestran claramente la abundancia de funcionalidad:
Barra de Herramientas
73
Mens Contextuales u Este es un perfecto ejemplo de como deben ser los programas. Estn cuidados todos a los detalles y maximizada la funcionalidad. Una verdadera joya.
74
3.8.
Segn lo explicado en la tcnica de la seccin 2.8 el seguimiento se debe hacer de u e o una manera automtica, accesible y que permita compartirla entre los miembros del a desarrollo. Las dos excelentes alternativas que nos ofrece el mundo open source son:
eGroupWare
Caracter sticas Generales: Es el ms conocido. a Es uno de los 10 con mayor actividad de SourceForge. Es agradable y muy fcil de usar a Excelente manejo de calendarios (ver imagen) Totalmente modular es muy sencillo poner y sacar partes Existen gran cantidad de mdulos desarrollados que abarcan desde subsistemas de o chat, interface web de los mails, lectura de feeds RSS, etc, etc. Entre las cosas no del todo positivas esta el tema de que no es orientado para proyectos de desarrollo sino a proyectos en general lo que nos complica a la hora de solucionar cuestiones bsicas como el seguimiento de Bugs. a
75
Los calendarios son perfectos y nos permiten cambiar de granularidad (diaria, semanal, mensual y anual) con un solo click.
DotProject
Esta otra alternativa es ms recomendable para proyectos de desarrollo pero cuenta a con una funcionalidad reducida si lo comparamos con el anterior. De todos modos cuenta con un muy buen subsistema de foros donde podemos agrupar distintos temas para solucionar estos problemas. Otra caracter stica favorable es que permite administrar presupuestos fcilmente. a
76
Excel
Si estos sistemas nos parecen complicados por su manejo o instalacin al menos o podemos utilizar el Excel que aunque no sea muy respetado en el mundo acadmico es e tan general que lo podemos adaptar para solucionar muchos problemas y el seguimiento de proyectos es uno de ellos. La idea es denir hojas (ya sea por mdulos o importancia) con las distintas activio dades y completar el porcentaje que se lleva completados de cada una de ellas o algo similar. Con el tiempo ir viendo que mas necesitamos y hacer macros o frmulas par a facilitar o las tareas. El ultimo paso ser incluir programacin a travs de Visual Basic para formar nuestro a o e propio sistema de Project Tracking. Suena interesante no ?
77
3.9.
Revisin y Anlisis de Cdigo o a o
Reector
Todo lo bueno que trae .NET seguro que se paga por otro lado, uno de ellos es la proteccin o privacidad del cdigo. o o Al igual que pasa en otros lenguajes interpretados, como Java, es muy fcil desensama blar una dll o un exe de .NET es tan sencillo como bajarse el Reector de la pgina ocial a de Lutz Roeder, levantar el assembly y elegir el mtodo o propiedad a desensamblar. e
Esta tan bien hecho que nos permite mostrar el fragmento desensamblado en cualquier lenguaje del Framework ya sea C#, VB.NET o Delphi. Aunque lo que hablamos de la privacidad de cdigo es algo que fue contemplado por o Microsoft desde el comienzo. Para tratar de reducir el problema incluy junto con el o VS.NET un ofuscador de cdigo para que las empresas puedan proteger la propiedad o intelectual de sus programas. Algo ms interesante es que MS no protegi las librer bsicas del framework, a o as a dejando las puertas abiertas para que los desarrolladores extraigan informacin sobre o buenas prcticas o vean como se implementan los controles base de los WinForms. a
78
Microsoft FxCop
Si pensamos que programamos bien ... basta con darle nuestro cdigo a este programa o de Microsoft para decepcionarnos. El programa analiza los assemblies que le damos utilizando instrospeccin y verica o si cumplen con las reglas solicitadas, que por defecto, son muy, pero muy exigentes ya que son las mismas que se siguieron en el desarrollo de las librer del .NET Framework. as Entre las cosas que chequea encontramos: Faltas de ortograf a. Errores de casing. Que no se capturen excepciones en lugares claves. Que no se hagan los dispose de recursos o que se hagan dos veces. Problemas de portabilidad. Much simas cosas mas... El programa es muy intuitivo, al analizar el assembly nunit.core del popular framework de testing tratado en la Seccin 3.4 nos muestra: o
Pantalla Principal del FxCop
79
En total encontr 675 posibles problemas. Es tal vez muy exigente por defecto pero o lo podemos cambiar si vamos a la solapa de reglas y desactiva las que no nos parecen convenientes.
Solapa de Seleccin de Reglas o Tambin podemos hacer doble click sobre cualquiera de los errores para ver una dee scripcin detallada del mismo, a que regla pertenece y la razn de porque se lo considera o o un error o posible error.
Pantalla con el Detalle de un Error
80
3.10.
Prolers
Entre las herramientas avanzadas que un programador deber conocer se encuentran a los prolers. Los lenguajes actuales como trabajan en un nivel de abstraccin muy alto nos llevan o a escribir cdigo muy ineciente y dif de escalar. o cil Si sumamos esto a que las maquinas actuales tienen una velocidad incre cuando ble desarrollamos el sistema y lo probamos todo anda de maravillas pero basta que el sistema est en produccin para que nos demos cuenta que cuando se conectan varias personas e o o se hacen algunas cosas a la vez, el sistema parece una tortuga... Este es un escenario aun ms comn en .NET que tiene un alt a u simo nivel de abstraccin a la hora de programar, esto se traduce en muchas capas intermedias de software, o por lo tanto una instruccin en .NET pueden ser cientos de miles en el sistema operativo o y en el procesador. Para controlar el uso de estos recursos (memoria y CPU) nacieron los prolers que hacen un seguimiento l nea por l nea, mtodo por mtodo y clase por clase, para que e e podamos encontrar el lugar exacto con problemas de performance.
CLR Proler
Este es un excelente proler gratuito que ofrece Microsoft y hasta contamos con el cdigo fuente. Esta orientado principalmente a ser un memory proler y hace su tarea o realmente bien. En el CD complementario se incluye el manual de este programa que nos indica en que contexto usarlo y cmo hacerlo. o Una imagen que muestra el nivel al que analiza la memoria ser a.
Es muy recomendable usarlo sobre todo para entender como utilizar adecuadamente los recursos de una plataforma tan poderosa como .NET.
81
NProf
NProf es un proler de tiempo de ejecucin, es opensource y se encuentra cerca de o su versin 1.0. o Tiene una gran cantidad de opciones pero no es muy grco (al menos por ahora) a cuesta encontrar indicios de rendimiento bajo. Nos muestra cuantas veces se ejecuto cada mtodo del cdigo que estamos analizando. e o Se integra perfectamente con el Visual Studio.NET y podemos ejecutarlo directamente desde all . En el CD complementario se encuentran los ejecutables y el cdigo fuente de este o programa.
Compuware DevPartner Studio

Sin lugar a dudas el mejor de todos los prolers. Cuenta con anlisis esttico de cdigo, proling de alocacin, proling de tiempo a a o o de ejecucin, captura todos los errores y nos muestra donde ocurrieron, permite hacer o proling de aplicaciones distribuidas y mucho ms. a Es muy funcional y totalmente grco. Muestra en tiempo real la memoria alocada, a cuales son los elementos con mayor cantidad de instancias, cuando se ejecuta el GC, etc. Mostremos a continuacin un grco del proler de memoria en tiempo real: o a
82
Lo bueno es que Compuware ofrece una versin Community Edition que se encuentra o reducida pero es gratuita. De todas formas es bastante completa y vale la pena bajarla.
NPerf
Otra herramienta interesante que no puede encuadrarse dentro de los proler pero que tiene una funcin muy similar es NPerf. o Esta herramienta provee un framework para hacer tests comparativos y mostrar los resultados. La idea es que escribamos el cdigo para hacer la misma cosa de diferentes o formas y el framework ejecutar estos mtodos tantas veces como le digamos, para difera e entes tamaos de muestra y luego representar los promedios de los tiempos resultantes. n a En la gura mostramos una comparacin entre el mtodo Contains de las diferentes o e colecciones que provee .NET.
Cap tulo 4 Check Lists de los Temas Tratados

En este Apndice se incluyen consejos y buenas prcticas a tener en cuenta cuando e a utilicemos alguna de las tcnicas o herramientas propuestas en esta Tesis. e Si las tenemos en cuenta es ms sencillo llegar al resultado esperado y nos evitar a a encontrarnos con sorpresas desagradables.
4.1.
Control de Cdigo Fuente o
Usar un sistema de control de cdigo fuente para proteger el cdigo y llevar un o o historial irrefutable de los cambios. Evaluar antes de comenzar las diferentes alternativas y seleccionar la que mejor se adapte al proyecto. Aprender a usar los comandos avanzados de Tag, Branch y Merge. Poner todos los elementos del desarrollo bajo control de versiones, inclusive la documentacin. o Documentar los cambios cuando se hace un Commit para que el historial sea ms a entendible. Hacer Tags frecuentemente, sobre todo antes de cambios importantes o en puntos a los que podemos necesitar volver. Tratar de usar el sistema control de cdigo fuente junto con un sistema para Project o Tracking (aunque sea usar convenciones para los Tags). Crear un Branch siempre que hagamos una entrega del sistema. Si nos piden algn u cambio ser ms sencillo de realizar si nos manejamos de esta forma. a a
83
CAP ITULO 4. CHECK LISTS DE LOS TEMAS TRATADOS
84
4.2.
Refactoring
No dejar las cosas que no estn del todo bien hasta que se revelen contra nosotros, a tratar de cambiarlas antes. Si encontramos una negativa al pedir autorizacin para hacer refactoring, y nos o parece necesario hacerlo, debemos encontrar la forma de hacerlo de todos modos. Tratar de hacer pequeos refactorings y de a uno a la vez. n Hacer una lista de los pasos que lleva cada refactoring y marcarlos a medida que avanzamos. Asegurarse que los cambios introducidos mejoran la calidad del sistema y no la empeoran. Llevar una lista de los cambios que quisiramos hacerle a cualquier parte del sistema e para no olvidarlos y para recurrir a ella cuando buscamos que mejorar. Pensar cuidadosamente que hacer si el refactoring es muy complicado o afecta a una parte cr tica del sistema. Hacer un Branch en el sistema de control de versiones si el refactoring es grande o nos va a llevar ms de un d a a. Testear al nalizar cada refactoring para asegurarnos de no corromper nada en el sistema y, en caso de hacerlo, utilizar el sistema de control de versiones para volver atrs. a
4.3.
Testing
Escribir tests de unidad (unit-tests) para la mayor parte del cdigo que podamos. o Escribir los test a medida que avanzamos. No dejarlos para un ma ana que nunca n llegar. a Asegurarse que el nuevo cdigo pasa todos los test de regresin antes agregarlo al o o sistema de control de cdigo fuente. o Usar una herramienta como NUnit para hacer del testing un proceso sencillo y repetible. Los Tests tambin deben estar bajo el sistema de control de versiones. e Hacer Refactoring, en lo posible, cuando se tenga una bater de tests para poder a validar lo que cambiamos.
85
4.4.
Documentacin o
Usar el Vea Tambin para navegar fcilmente por la informacin relacionada. e a o Usar Tablas de Contenidos, Indices, Bsqueda e Links para que sea ms sencillo u a localizar la informacin. o La mayor de los temas de ayuda deben ser cortos y focalizados. a Utilizar grcos, no slo texto (respetar la regla: una imagen vale ms que mil a o a palabras). Proveer una manera para que los usuarios puedan darnos feedback fcilmente (ya a sea a travs de un mail o guardando informacin en un archivo y analizarla luego). e o Imprimir las partes ms usadas de la documentacin para facilitar la lectura. a o Procurar que la ayuda sea sensitiva al contexto y orientada a la tarea que se est a realizando. Cuando se est documentando algo pensar en cmo se va a actualizar la docua o mentacin cuando las cosas cambien. o
4.5.
Compilacin e Integracin o o
Usar una herramienta de compilacin e integracin continua como (como NAnt o o o Cruise Control.Net) para hacer de este proceso algo simple y repetible. Evaluar varias herramientas de generacin y quedarse con la que mejor se adapte o al proyecto y al bolsillo. Integrar la aplicacin de forma regular (generando adems la documentacin y o a o ejecutando los casos de Test). Muchos recomiendan que diariamente es lo ideal. Hacer backups de las salidas producidas en la generacin diaria (no olvidar la DB). o La integracin no es slo de los mdulos del sistema sino que abarca todos los o o o artefactos que componen el desarrollo como: las bases de datos, documentacin, o tests, instalaciones, backups, etc. Tratar de hacer integraciones continuas para asegurar que el sistema sigue estable y los conictos se detectan a tiempo.
86
4.6.
Generacin de Cdigo o o
La generacin de Cdigo es una herramienta desestimada por la mayor de los deo o a sarrolladores y en esta tesis mostramos lo util que es, pero en caso de decidirse a usarlo tener en cuenta: Cuando nos encontramos con una gran cantidad de tareas repetitivas al escribir cdigo considerar usar una herramienta que genere ese cdigo. o o Evaluar varias herramientas de generacin de cdigo hasta encontrar la que mejor o o encaje en nuestro proyecto (aqu se mostr CodeSmith que es gratuito y fcil de o a usar, pero hay otras alternativas muy completas). Utilizar las herramientas de control de versiones sobre las entradas de los generadores y no sobre las salidas de los mismos. Analizar sinceramente cunto tiempo ahorramos si escribimos directamente la solua cin y cunto si hacemos una plantilla para generar el cdigo. o a o Pensar como hacer si se debe escalar a una herramienta ms completa. a
4.7.
Convenciones
Buscar en internet convenciones espec cas para el lenguaje utilizado y seleccionar alguna. En la pgina msdn de Microsoft podemos encontrar muchas convenciones en lo a referido a .NET inclusive las mismas que uso el equipo del framework. Tener al menos algunas convenciones bien documentadas. Asegurarse de que los miembros del equipo conocen bien las convenciones y la razn de por qu se usan. o e Tomarse el tiempo para discutir las convenciones analizando los distintos puntos de vista. Fomentar a los miembros del equipo de desarrollo a proponer otras convenciones o a mejorar las existentes. Probar el FxCop para detectar automticamente los problemas de nombres y a prestar atencin a las justicaciones de porque est mal lo que hacemos. o a
87
4.8.
Generales
Por ultimo citaremos algunos consejos recopilados de distintos libros, de internet o de la losof misma del desarrollo gil. a a Es bueno tenerlos siempre en mente: Tratar las excepciones como tales y no tratar de que todo encaje en nuestro esquema general. Desconar de cualquier parte del sistema porque todo puede fallar inclusive la instruccin ms absurda. o a No prometer cuanto tardaremos en hacer algo que nunca hicimos o no entendemos del todo porque caeremos presos de nuestras palabras. Disear las clases pensando en su uso, hacer un croquis con las l n neas que usar a el cliente de la clase y no agregar funcionalidad porque s . No creer en las propagandas de las nuevas tecnolog hasta no entrar en contacto as con ellas y comprobar que son realmente buenas. Nunca usar la ultima tecnolog disponible, usar la ante ultima y monitorear como a evoluciona la ultima para estar en tema y no sorprendernos cuando se convierta en un estndar. a Debemos comprender que ninguna metodolog es universal. Usar el sentido comn a u para extraer lo mejor de cada una, tomar partes de otras y por ultimo quedarse con las tcnicas que dieron resultado (si no sirven simplemente descartarlas). e
Cap tulo 5 Conclusiones

Luego de este gran paseo, aunque resumido, por el mundo de la teor y la prctica a a del desarrollo gil espero que hayan podido comprender un poco ms lo imperioso que a a se hace sincerarse con uno mismo y durante el desarrollo darle importancia a las cosas que realmente lo merecen y no a otras que quedaron obsoletas hace aos como la pron gramacin en cascada, documentacin excesiva, el sobrediseo, la poca comunicacin, el o o n o escaso feedback, el do it yourself, etc . Cada vez ms personas estn de acuerdo con esto. Las grandes empresas estn cama a a biando sus pautas de desarrollo por metodolog ms livianas. as a inclusive Microsoft sac los siguientes libros referidos a desarrollo gil: o a Extreme Programming Adventures in C#. [Sch04] Test-Driven Development in .NET. [NV04] Agile Project Management with Scrum. [Jef04] El futuro de la programacin para la mayor est ms que claro y se resume en una o a a a palabra: .NET. Los que no estn de acuerdo es porque no han desarrollado sobre esta a plataforma, inclusive los mismos desarrolladores de Java reconocen las grandes virtudes de .NET. Para poder aprovecharlo al mximo no podemos dejar pasar por alto la cantidad de a herramientas, cdigo y ayuda que nos brinda internet y que son totalmente gratuitas. o Creo que el secreto est en ver cmo desarrollan aplicaciones otras personas con ms a o a experiencia y tomarlo como base para comenzar nuestros proyectos. Luego investigar cmo mejorar estas ideas y adaptarlas para que sean ptimas para nuestra forma de o o trabajo. Finalmente automatizar con plantillas de cdigo todo lo que se pueda1 y el tiempo o
Cuando decimos todo lo que se pueda no hay que tomarlo tan literalmente, sino las cosas que valen la pena porque se hacen seguido o cambian constantemente
1
88
CAP ITULO 5. CONCLUSIONES
89
que ahorramos al no escribir nosotros todo el cdigo lo podamos invertir aprendieno do ms, mejorando el sistema o haciendo refactoring de las plantillas existentes para a documentarlas, extenderlas, etc. Los que en algn momento se imaginaron un mundo con componentes de todo tipo u y al alcance de la mano, de fcil integracin, interaccin entre diferentes lenguajes, a o o encuentran sus deseos materializados en .NET, ya que hay componentes de todo tipo. Pero lo importante es que pueden estar escritos en cualquier lenguaje, desde C++ hasta VB.NET, desde COBOL a SmallTalk porque .NET provee una plataforma comn u de ejecucin que siempre se necesito, que con CORBA no tuvo xito, pero que Microsoft o e logr con su framework. o Sigo insistiendo en que la clave est en la automatizacin o semi-automatizacin a o o 2 de las tareas repetitivas o que dependen de otra parte del sistema (como las clases del mapeo relacional que mostramos en esta tesis que es muy fcil de automatizar). a Steve McConnell escribi en su libro Code Complete 2da Edicin [McC04] que hay o o dos tipos de buenos programadores, para distinguirlo basta con darles una tarea de 5 Hs. y ver como se comportan: Uno se sienta, piensa el problema, lo diagrama y lo implementa durante las 5 Hs. El otro toma el problema, lo analiza, piensa como automatizarlo y durante 4 horas y 45 minutos genera una herramienta que haga el trabajo, luego la ejecuta para que en los 15 minutos restantes genere la solucin. o Yo opino que es mejor lo segundo pero no hay que dejar que el fanatismo nos consuma. Necesitamos, como en todas las cosas de la vida, criterio para poder distinguir cuando conviene hacer una cosa o la otra y no seguir siempre la misma l nea. Por ejemplo si tenemos que hacer un importador de datos de un archivo separado por comas (CSV) a una tabla en la base de datos debemos ponderar el hacer un importador ad hoc3 o hacer algo ms genrico como que el importador tenga meta-datos sobre el a e formato del archivo a leer y la tabla en donde insertarlo. La decisin como siempre depende del contexto; si estamos seguros que lo vamos a o usar una vez para importar los datos de un unico archivo quiz la opcin ad hoc sea la a o mejor, en cambio si tenemos varios archivos con diferentes formatos y logramos hacer
Las tareas repetitivas son tan sencillas y cansadoras que nadie tiene ganas de hacerlas y el que las hace les pone pocas ganas, luego cuando el sistema falla a nadie se le ocurre que lo que puede andar mal es que en la estructura que mapea con una tabla dice oat donde deber decir int y adems del a a tiempo perdido en realizar la tarea hay que sumar el tiempo que gastamos en encontrar estos errores que son muy escurridizos. Usando plantillas sabemos que esto no ocurrir y si aparece algn error se a u regeneran las capas y listo. 3 Cuando decimos Ad hoc nos referimos al hecho de utilizar algo as como un ReadLine y particionar el String insertndolo en una tabla determinada a
2
CAP ITULO 5. CONCLUSIONES
90
algo sucientemente genrico habremos solucionado el problema para todas las veces que e en el futuro tengamos que importar algo de un archivo de texto a una base (y cranme e que lo van a necesitar). Con respecto a .NET tenemos que entender que marc un antes y un despus en el o e desarrollo de sistemas y en la forma de programar. No entender los alcances de esta revolucin nos cerrar muchas puertas en el futuro o a ya que inclusive gigantes como Borland, SAP y la comunidad Open Source se alinearon con Microsoft para acelerar y facilitar el cambio.
5.1.
Otros Temas de Inters sobre Desarrollo Agil e
Muchos temas temas de actualidad no fueron cubiertos en esta tesis por cuestiones de tiempo y espacio. Es interesante buscar informacin de los siguientes temas ya que pueden ayudar a o nuestra productividad y a nuestra experiencia: Tcnicas no tratadas e Abstraccin de Pantallas Comunes con Formularios Heredados. o Pair Programming. Patrones de Diseo. n Construccin de Tablero de Comandos para el soporte de decisiones. o Logging y Trace de Aplicaciones. Consejos para la Creacin de Interfaces de Usuario. Buscar info en www.JoelOnSoftware.com o Herramientas no tratadas Extensin del Visual Studio con Macros y Addins. o Usar Componentes de Correccin Ortogrca. o a Creadores de Instalaciones.
Apndice A e Reexiones Sobre el Desarrollo de Software

A.1. Systemantics
Aunque el comportamiento de los sistemas complejos est condicionados por el CAOS a intr nseco en los mismos, hubo personas que investigaron leyes sobre estos comportamientos y le pusieron el nombre de Systemantics. El primer libro sobre el tema es de John Gall (ver [Gal78]). Analicemos un extracto muy interesante del mismo: Los sistemas de computadora nos seducen porque prometen hacer el trabajo duro ms rpido, mas fcil y mejor de lo que podr a a a amos hacerlo nosotros. Pero si instalamos un sistema, es muy probable que encontremos que nuestro tiempo y esfuerzo se va instalndolo, congurndolo y nada ms. a a a Aparecern nuevos problemas con la sola presencia del nuevo sistema. Una a vez instalado, no se ira ms, sino que crecer y lo abarcar todo. Comenzar a a a a a hacer cosas extraas y sorprendentes, fallar de formas que nunca pensamos n a que fueran posibles; inclusive se opondr a su funcin original. a o Nos distorsionar la perspectiva y nos har olvidar el objetivo inicial que a a ten el sistema. a Nos pondr ansiosos y lo forzaremos para que trabaje sea como sea. a Eventualmente dar algn resultado y nos alegraremos creyendo que es lo a u 1 que siempre quisimos. En este punto llegamos al mximo de la invasin... hemos sido absorbidos a o por el sistema... ahora somos gente de sistemas.
Aunque lo que terminamos consiguiendo era mas fcil y econmico hacerlo antes de implementar a o el sistema, no importa, porque nadie recuerda como era antes.
1
91
APENDICE A. REFLEXIONES SOBRE EL DESARROLLO DE SOFTWARE
92
Lo mas interesante es que el libro est escrito en el ao 1978 y esta cita tiene hoy mas a n vigencia y sentido que en aquella poca porque los sistemas actuales abarcan todo y son e cada vez ms complejos, convirtindose en campos minados llenos de bugs, esperando a e para explotar.
Las leyes que ms se destacan de las citadas en el libro son: a Si algo puede salir mal, saldr mal. (ley de Murphys) a Los sistemas en general trabajan mal o directamente no lo hacen. Los sistemas complicados rara vez exceden el 5 % de eciencia. En los sistemas complejos, el mal funcionamiento o incluso la falta de funcionamiento puede que no se detecte por largos per odos (si es que en algn momento se u detectan). Los sistemas pueden fallar en un nmero innito de formas. u Los sistemas tienden a crecer, y cuando crecen, desplazan todo lo que est en su a camino. Cuando los sistemas crecen en complejidad, comienzan a oponerse a la funcin o original que deb realizar. an Cuando los sistemas crecen en tamao, pierden funcionalidad bsica. n a Ms grande es el sistema, menos las cosas que hace bien. a Los sistemas independientes duran ms y funcionan mejor. a Los sistemas complejos presentan comportamientos complejos e imprevisibles. Los sistemas colosales fomentan a que se produzcan errores colosales.
A.2.
Buen Software: Programacin o Gerenciamieno to de Personas ?
Aunque en esta Tesis nos concentramos en la construccin de sistemas no debemos o olvidar que el desarrollo en general no es una actividad individual y aunque lo fuera al menos debemos negociar con nuestro cliente. En el libro Code Complete de McConnell [McC04] nos dice que la programacin se o trata slo un 15 % de comunicacin con la computadora y un 85 % de comunicacin con o o o otras personas. Un programador promedio pasa nada ms que un 30 % trabajando solo. a
93
Sin embargo encontramos que lo que se necesita es un punto medio, no se puede hacer un sistema complejo si contamos slo con buenos administradores u gerentes; ni tampoco o se lo puede hacer simplemente con buenos programadores, se necesita algo intermedio, porque por ms bueno que sean los programadores si los gerentes no les pueden encontrar a la funcin adecuada y motivarlos, la cosa no va. o
A.3.
Mantenibilidad: Problema o Bendicin ? o
En la teor escuchamos constantemente que los buenos sistemas se identican por a su bajo mantenimiento. Luego se deduce que el objetivo para tener un buen sistema es evitar o reducir el mantenimiento, pero en la prctica esto no tiene el menor sentido, porque los requerimientos a cambian y si no hay mantenimiento entonces como cambiamos la funcionalidad. Un buen ejemplo es por ejemplo una empresa con varias sucursales y que abre nuevas cada cierto tiempo. El sistema de esa empresa vive en mantenimiento, es el corazn del o sistema, el cambiar cosas constantemente. Los sistemas de los bancos, los de las tarjetas de crdito, todos ellos estn en constante e a mantenimiento y no por eso se los puede considerar malos sistemas... Tampoco queremos fomentar la idea que el mantenimiento es la salvacin, simpleo mente rescatar esta idea para ser un poco ms conscientes cuando hablamos de mantena imiento y pensar que no es tan malo despus de todo. e
A.4.
Desarrollo Web: La Solucin Ideal o una Opo cin ms ? o a
Si existiese la moda del desarrollo seguro que estar por el lado del Desarrollo Web. a Todo el mundo quiere su pgina web, toda empresa que se precie tiene que tener a su Intranet, los Bancos deben poder operar por Internet, etc. Pero muchas veces no se analiza si es la mejor solucin o no. o Adems, como la Ingenier del SW anuncia con bombos y platillos que es ms a a a econmico y ms rpido que el desarrollo de aplicaciones de escritorio, les da a los o a a gerentes el argumento ideal para tomar la decisin de encarar los proyectos de la empresa o con Desarrollo Web. Como todo, el Desarrollo Web no es la mejor solucin para todo, en mi opinin es o o ideal para una Intranet para realizar consultas e informes y no para actualizar datos. Desarrollar un sistema para hacer ABMs en un entorno web, aunque parezca sencillo, presenta cientos de complicaciones: lo dif de mantener el estado, el manejo de errores, cil
94
el problema si el usuario presiona dos veces un botn, problemas de compatibilidades o entre navegadores, problemas de seguridad, etc. No estoy en contra del Desarrollo Web, sino de que se haga por deporte sin analizar riesgos y consecuencias; es ms prudente y efectivo proveer consultas v Web y actuala a izacin a travs de aplicaciones de escritorio (por algo SAP y las grandes empresas de o e SW administrativo conf en el modelo cliente-servidor comn y corriente que demostr an u o ser ms que efectivo durante aos). a n
A.5.
N meros y Estad u sticas para Reexionar
Actualmente los proyectos son cada vez ms complejos y generalmente menos exia tosos, aqu tenemos algunos grcos que nos dan nmeros concretos sobre los resultados a u de los desarrollos:
Fuente de esta informacin: The Standish Group o Hay adems nmeros interesante que nos abren la mente del esfuerzo requerido para a u hacer sistemas colosales como Windows, por ejemplo: Windows 2000 tiene ms de 50 millones de l a neas de cdigo. o SQL Server tiene mas o menos 1.5 millones de l neas de cdigo. o SAP fue desarrollado por 4200 Ingenieros de SW y tiene 37 millones de l neas de cdigo. o Mostremos ahora cual es el porcentaje de las funciones que realmente se usa en la mayor de los sistemas. a
95
Este grco indica claramente porqu el desarrollo gil fomenta el interactuar cona e a stantemente con el cliente para ver que es lo que realmente quiere y no desarrollar funciones que nunca usar. a
A.6.
Qu Signica ser un Mejor Desarrollador ? e
Hay una sola cosa que distingue los buenos desarrolladores del resto y es su actitud para seguir aprendiendo. Los buenos desarrolladores no dejan de aprender. Siempre hay una parte ms del universo del software para explorar, a algn nuevo lenguaje que aprender o alguna nueva herramienta para probar. u Es indispensable hacer uso de los recursos de internet para continuar explorando y aprendiendo. Mike Gunderloy, en Coder to Developer [Gun04] Yo coincido totalmente con Gunderloy pero agregar que un buen desarrollador es a aquel que se adelanta a los problemas. El que cuando esta diseando o programando n algo se imagina las cosas que pueden pasar y que podr poner en peligro el sistema o an llegar complicarlo. La analog perfecta esta dada por el juego de ajedrez. En ste cuando empezamos a e a jugar no pensamos demasiado los movimientos y slo vemos uno o dos hacia adelante, o a medida que nuestro conocimiento avanza vamos proyectando varias jugadas hacia adelante previendo lo que puede ocurrir. En el software pasa algo parecido: Cuando uno empieza a programar lo hace para resolver problemas puntuales y no piensa que pasar si algo cambia o como afectar eso a lo que ya hicimos. a a
96
Luego en los proyecto reales si uno no prev los cambios o simplemente no imagina e que podr pasar si el usuario toca aqu o all, aparecern errores por todos lados y el a a a tiempo perdido en debugging ser excesivo. Lo que nos deja muy mal parados y como a dice el dicho: Hazte fama y chate a dormir, o sea, nos va a costar cambiar la opinin e o de los dems hacia nosotros despus de esto. a e
Apndice B e Recursos Utiles

Por que cuando hay que hacer algo, nada mejor que conseguirlo hecho ... o encontrar algo que lo haga por nosotros Marcos Meli
B.1.
Repositorios de Componentes y Cdigo o

www.SourceForge.net La pgina mas destacada de desarrollo open source que a provee un servicio de hosting gratuito para todo esta comunidad. Gran parte de las herramientas Open Source de esta tesis tienen su centro de desarrollo en los servidores de esta pgina. Si se necesita cualquier programa a Open Source, con cdigo y todo conviene empezar buso cando por ac. a www.CodeProject.com Indudablemente la pgina ms trabajada de desarrollo a a en .NET y otros lenguajes. Contiene gran cantidad de art culos, todos editados, con ranking, en una palabra: excelente. www.ElGuille.info La mejor pgina de habla hispana con art a culos sobre desarrollo con manuales de su autor, con un lenguaje sencillo y entretenido. Guille fue declarado MVP por su aporte a la comunidad de desarrolladores acercandole a los usuarios la ultima tecnolog a.
97
APENDICE B. RECURSOS UTILES
98
www.PlanetSourceCode.com Sitio con gran cantidad de cdigo fuente y controles pero o como no estn muy editados cuesta un poco mas buscar a la info, pero si buscamos algo dif de hacer no imcil porta el lenguaje en que estemos trabajando este es un excelente lugar para encontrarlo. www.GotDotNet.com Sitio mantenido por Microsoft donde participan activamente miembros que forman parte del equipo de desarrollo de .NET y que liberan controles o herramientas que no se pudieron incluir en el Visual Studio y presentan tutoriales. CodeLib Si de manejar snippets hablamos este es el mejor programa que existe, esta hecho por chinos, la pgina tiene a partes en los dos idiomas. Se instala el programa y despus se bajan las bases de datos que contienen el cdigo e o fuente. Se pueden crear nuestras propias bases para ordenar el cdigo ya existentes. o
B.2.
Informacin sobre Desarrollo Agil o
www.ExtremeProgramming.com La pgina ocial de esta metodolog de desarrollo gil, a a a a primera vista no parece muy completa ni actualizada pero contiene informacin de alt o sima calidad y se puede descargar gran parte del sitio en un slo ZIP. o www.JoelOnSoftware.com La pgina ocial de un gur en el desarrollo de sistemas. a u Encontramos grandes consejos y discusiones sobre los temas ms actuales, en especial se destaca un libro sobre a interfaces de usuario muy sencillo y fcil de leer. a OOP Criticism Pgina dedicada a juntar cr a ticas constructivas de la programacin orientada a objetos. Es interesante visitarla o para escuchar la otra campana sobre esta metodolog a de desarrollo y para comprender que caracteristicas de la misma pueden ser peligrosas. www.CodeGeneration.net Pgina dedicada a la generacin automtica de cdigo, a o a o gran cantidad de articulos y un listado muy completo de las herramientas ordenadas por lenguaje.
99
www.LarkWare.com Pgina ocial de Mike Gunderloy actualizada diariaa mente, contine excelente informacin de ultimo momeno to que se puede descarcar a travs de un RSS. Todos los e d hace un resumen de los temas de mayor resonancia as o de nuevas aplicacines que van apareciende. o www.EggHeadCafe.com Aunque el nombre parezca poco serio esta pgina agrupa a una gran cantidad de desarrolladores cubriendo temas de .NET, Java y VB6. Cuenta adems con excelentes a recursos como iconos y enlaces interesantes. www.TestDriven.com Pgina dedicada a tratar este modo de desarrollo con a mucho material y nos permite bajar presentaciones y articulos. www.DevDays.com.ar Pgina ocial de la confenciaria de .NET ms impora a tante organizada por Microsoft, all encontraran los archivos de las presentaciones que cubren algunos de los temas tratados en esta tesis.
En el CD complementario encontrarn un html con much a simos ms enlaces y con a direcciones de pginas que contienen directorios que se actualizan constantemente. a
B.3.
Direcciones de las Herramientas Tratadas

Tortoise CVS: http://tortoisecvs.soureforge.net Tortoise SVN: http://tortoisesvn.tigris.org WinCVS: http://wincvs.soureforge.net WinMerge: http://winmerge.soureforge.net CVS Server: http://www.cvsnt.org
Control de Versiones y Programacin Concurrente o
Refactoring
Refactoring DotNet: http://www.dotnetrefactoring.com ReSharper: http://www.jetbrains.com/resharper Code Smart 2005: http://www.axtools.com
Testing
NUnit: http://nunit.soureforge.net
100
MBUnit: http://mbunit.soureforge.net
Generacin de Documentacin a Partir del Cdigo o o o

NDoc: ndoc.soureforge.net VB.DOC: vbdoc.soureforge.net Documentor: www.lutzroeder.com
Generacin e Integracin Continua o o

NAnt: http://nant.soureforge.net NAnt Pad: http://www.nantpad.com CruiseControl.NET: ccnet.thoughtworks.com
Generacin Automtica de Cdigo o a o

CodeSmith: http://www.ericjsmith.net/codesmith
Librerias de Cdigo y Controles o

CodeLib: http://myweb.hinet.net/home4/s630417/
e-Groupware: http://www.egroupware.org DorProject: http://www.dotproject.net FogBugz: http://www.fogcreek.com/FogBugz
Anlisis de Cdigo a o
Reector: http://www.lutzroeder.com FxCop: http://www.gotdotnet.com
Prolers
CLR Proler: http://www.microsoft.com DevPartner Studio: http://www.compuware.com Nperf : http://www.dotnetwiki.org
101
B.4.
Contenido del CD Complementario
En el Cd complementario se incluyen todas las herramientas tratadas en esta tesis, junto con mucha informacin sobre las tcnicas y sobre el desarrollo gil en general. o e a En el directorio ra se encuentra el ejecutable Presentacin.exe que nos permite z navegar entre los diferentes contenidos del CD.
Para poder correr los ejemplos y utilizar las herramientas se deben instalar: El .NET framework v1.1 El .NET framework v1.1 Service Pack 1 (opcional) Los mismos se encuentran en el directorio Programas\Requeridos. Las Herramientas se encuentran en el directorio Herramientas clasicadas de la misma forma mostrada en la tesis. En el directorio Material hay mucha informacin sobre los temas tratados en esta Tesis o y sobre el desarrollo gil en general. Adems encontrarn art a a a culos de las pginas citada a como: www.CodeProject.com, www.CSharpCorner.com, www.Larkware.com, www.CodeGeneration.net, etc. En el directorio Componentes est el cdigo fuente de los Controles y Componentes a o ms populares de .NET. a
Agradecimientos
Quiero agradecer sobre todo a mi familia quienes hicieron posible que haya llegado hasta aqu y que con su motivacin y paciencia hicieron posible que pueda dedicarme a o mi gran vocacin que es la computacin. o o Por que cuando todo parec negro me iluminaron. a Por que nunca dejaron de estar conmigo. Por que nunca me pidieron nada a cambio. Por que son las mejores personas que conozco. Por que los amo, Gracias.
Gracias a mis amigos y compaeros que pese a todas mis locuras y mi fanatismo n me aguantaron siempre y me dieron fuerzas para terminar esta etapa y seguir adelante. Gracias por las tardes de mate, prcticos y charlas que tanto se extraan cuando uno a n deja de estudiar. Tengo un recuerdo hermoso de cada uno de ustedes porque cada uno es especial para mi. Muchos dicen que la mejor forma de aprender algo es tratar de ensearlo. Yo comn prob que es verdad con esta Tesis que me dej mucho. Por eso quiero agradecer espee o cialmente al director de la misma el Dr. Manuel Fidel por haberme permitido elegir este tema y por guiarme durante todo el trabajo. Con su incre conocimiento y desde su ble sencillez me ha enseado a ver el mundo de la Programacin y de la Computacin en n o o general de una manera unica. Mucho del contenido de la tesis est inuenciado por sus a geniales ideas y por nuestras entretenidas charlas. Gracias a la mujer que espero me acompae toda la vida. n Bah Blanca a Abril, 2005 102 Marcos A. Meli
Bibliograf a
[Bec99] Kent Beck. Extreme Programming Explained. Addison Wesley, 1999. El libro ms popular de Extreme Programming escrito por uno de sus pioneros. Tiene su a fama bien ganada porque es entretenido y nos ayuda a abrir los ojos justicando cada principio de XP. [Bec03] Kent Beck. Test-Driven Development: By Example. Addison-Wesley, 2003. [BF00] Kent Beck and Martin Fowler. Planning Extreme Programming. AddisonWesley, 2000. Este libro explica como estimar los tiempos si usamos XP como metolog de desarrollo, indicandonos como no caer presos de nuestras propias a promesas.
[Bro03] William J. Brown. AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. Wiley And Sons, 2003. Como existen los Patterns (que son consejos sobre la forma de encarar los problemas) existen tambin los Ane tiPatterns que vendr a ser consejos sobre como no encarar o solucionar los an problemas si no queremos terminar mal. [Dun02] Christopher Duncan. The Career Programmer, Guerilla Tactics for an Imperfect World. APress, 2002. Un libro muy divertido e interesante que muestra que en la actualidad por ms buenos que seamos programando no alcanza, que a necesitamos saber defendernos junto con nuestro equipo de desarrollo de los deadlines, cambios en requerimientos, cambios en las tcnolog etc. e as, [Fow99] Martin Fowler. Refactoring: Improving the Design of Existing Code. Addison Wesley, 1999. El libro de cabecera sobre Refactoring, contiene guias paso a paso para hacer cada un y para cada uno da ejemplos en Java. [Gal78] John Gall. Systemantics; how systems work... and especially how they fail. Pocket Books, 1978. El primer libro de Systemantics, un poco anticuado pero con contenido aplicable aun en la actualidad. Robert L. Glass. Facts and Fallacies of Software Engineering. Addison-Wesley, 2002. Este libro describe de manera sencilla y clara 55 hechos a tener en cuenta en nuestros desarrollos y 10 errores muy comunes de la Ingenier del SW. a 103
[Gla02]
104
[Gun04] Mike Gunderloy. Coder to Developer: Tools and Strategies for Delivering Your Software. Sybex, 2004. Muy buen libro que nos muestra como pasar de programadores a buenos desarrolladores basndose en el uso de herramientas tal a como se propone en esta tesis. [GV95] Johnson Gamma, Helm and Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. El libro ms conocido sobre a patrones, propone los nombres utilizados en la actualidad y da una clasicacin o muy interesante. Andrew Hunt and David Thomas. The Pragmatic Programmer. From journetman to master. Addison Wesley, 1999. Sin duda uno de los mejores libros que he le Por lo entretenido, por la profundidad y sencillez de las ideas y porque do. esta plagado de consejos utiles. Recomendable para toda persona relacionada con la programacin. o Andrew Hunt and David Thomas. Pragmatic Version Control. Pragmatic Press, 2003. Pequeo y util libro que nos ensea los conceptos bsicos e intern n a medios del control de versiones, muy recomendable. Andrew Hunt and David Thomas. Pragmatic Unit Testing. Pragmatic Press, 2004. Excelente libro que cubre la parte terica y prctica sobre el Testing o a Automtico de Aplicaciones. Analizando las diferentes formas de hacerlo. a Ron Jeries. Extreme Programming Installed. Addison Wesley, 2000. Libro que analiza Extreme Programming desde el punto de vista de como integrarlo progresivamente a nuestro equipo de desarrollo, lleno de consejos prcticos. a Ron Jeries. Extreme Programming Adventures in C#. MS Press, 2004. Libro que muestra ejemplos de como usar Extreme Programming en el mejor lenguaje de la actualidad.
[HT99]
[HT03]
[HT04]
[Jef00]
[Jef04]
[Lho03] Rockford Lhotka. Expert One-on-One Visual Basic .NET Business Objects. APress, 2003. Un libro totalmente prctico con la introduccin y justicacin a o o de las capas de negocios y como se pueden generar automticamente. Incluye a ademas las plantillas de CodeSmith para hacerlo. [McC04] Steve McConnell. Code Complete 2ed. MS Press, 2004. El mejor libro sobre construccin de Software, muy amplio y explica temas desde cuantos comeno tarios utilizar en nuestros programas que conducta nos dar mejores resultados a en nuestra carrera, una JOYA !! [Mic] Microsoft. Microsoft Patterns And Practices. MS Press. Este no es un libro sino una coleccin de libros que publica Microsoft y que son gratuitos. Son o una excelente guia para los que comienzan o estn en un nivel intermedio a de .NET, hay libros de acceso a datos, patrones, manejo de excepciones, sql server, etc. Los PDF se encuentran en el CD complementario o se pueden bajar directamente desde http://www.microsoft.com/practices.
105
[Nan04] Brian Nantz. Open Source .NET Development. Prentice Hall, 2004. Libro sobre las herramientas gratuitas de .NET. [NV04] James W. Newkirk and Alexei A. Vorontsov. Test-Driven Development in Microsoft .NET. MS Press, 2004. Libro sobre testing de Microsoft donde se muestra esta interesante forma de enfrentar el desarrollo. Complementa el libro de Kent Beck sobre el tema mostrando como aplicar TDD a aplicaciones Web o con acceso a bases de daros. Hank Rainwater. Herding Cats: A Primer for Programmers Who Lead Programmers. APress, 2002. Otro libro de la editorial ms actualizada y profesional a con respecto a .NET y el desarrollo moderno, este en especial trata de como liderar a otros programadores, planicar y hacer buenas relaciones gerenciales. Ken Schwaber. Agile Project Management with Scrum. MS Press, 2004. Nuevo libro de Microsoft que muestra como administrar proyectos usando esta metodolog gil. a a
[Rai02]
[Sch04]
[Sha00] Alan Shalloway. Design Patterns Explained. Addison-Wesley, 2000. Un libro ms bien prctico que nos introduce al mundo de los patrones. Nos muestra a a como se aplican en la realidad a travs de ejemplos y nos advierte en que e contextos no deberiamos usarlos. [SR03] Matt Stephens and Doug Rosenberg. Extreme Programming Refactored: The Case Against XP. APress, 2003. El nombre lo indica se trata de mejorar XP pero no son ms que quejas a la metodolog con un tono muy irnico. Por a a o ejemplo en un cap tulo dice que no puede ser que el cdigo nunca este listo si o usamos XP, y mi respuesta es: NO NUNCA ESTA LISTO siempre le falta algo, ningn sistema funciona como se esperaba, siempre hay algo que cambiar o ser u a que tiene algn ejemplo que indique que no, yo le dir que Windows, Linux, u a Oce, los sistemas administrativos de las empresas, etc. nunca estuvieron listos y con esto queda claro porque no me agrada demasiado, lo agregu ac porque e a es interesante ver como se la agarran con cosas que funcionan en la prctica a como XP.
[Wak00] William C. Wake. Extreme Programming Explored. Addison Wesley, 2000. Otro libro muy completo de extreme programming que complementa los conceptos del libro inicial de XP publicado por Kent Beck. [Wak03] William C. Wake. Refactoring Workbook. Addison Wesley, 2003. Este libro es una gu un poco ms prctica que el libro de Fowler, muestra con ejemplos a a a y con ejercicios para el lector como darnos cuenta donde hacer refactoring y donde no.

Desarrollo Agil Con

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Desarrollo Agil Con

Cargado por

Copyright:

Formatos disponibles

Informacin de contacto o

Version de esta Tesis: 1.0

Cap tulo 1 Introduccin o

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

Por qu Metodolog de Desarrollo Agil ? e as

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

Por qu la Plataforma .NET ? e

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

Cap tulo 2 Tcnicas de Desarrollo Agil para e .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

Control de Versiones y Programacin Concuro rente

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

Razones para hacer Refactoring

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

Refactorings ms Conocidos y Utiles a

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

Refactoring del Dise o y la Arquitectura n

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

Desarrollo Dirigido por el Testing

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

Generacin de Documentacin a Partir del Cdio o o go

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

Armar una Librer de Cdigo y Controles a o

Siempre que este hecho bien...

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

Crear Componentes y Controles Personalizados

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

La pantalla con el resumen de los errores quedar a:

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

Convenciones de Nombres y Estilo

Prejos de los elementos ms comunes de .NET a

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

Objetos de Acceso a Datos

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

Convenciones para los Mensajes del Sistema

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

Manejo y Reporte Automtico de Errores a

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

CAP ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

El mail que recibimos tiene la forma, charn charn: a a

Cap tulo 3 Herramientas de Desarrollo Agil para .NET