• Author / Uploaded
• Oscar J. Sanchez Zevallos

• Categories
• .NET Framework
• Microsoft Visual Studio
• Java (lenguaje de programación)
• Control de versiones
• Objeto (informática)

Citation preview

Informaci´ on de contacto

Cualquier sugerencia, consulta, cr´ıtica o correcci´on por favor comun´ıquenlo entrando en: www.MarcosMeli.com.ar O directamente envi´andome un mail a: [email protected]

Gracias por tomarse el tiempo de hojear esta Tesis, tiene mucho esfuerzo de mi parte y trata de ser un panorama lo m´as completo posible de las posibilidades de utilizar el .NET framework acompa˜ nado del desarrollo ´agil y de las herramientas que lo soportan. Es muy probable que haya una nueva versi´on de esta tesis en mi p´agina, alg´ un art´ıculo nuevo o links a lugares relacionados o que completan la informaci´on.

Version de esta Tesis: 1.0

i

´Indice general

Informaci´ on de contacto

I

Resumen

1

1. Introducci´ on 1.1. Por qu´e T´ecnicas y Herramientas ? . . . . . . . . . . . . . . . . . . . . . ´ ? . . . . . . . . . . . . . . . . . 1.2. Por qu´e Metodolog´ıas de Desarrollo Agil 1.3. Por qu´e la Plataforma .NET ? . . . . . . . . . . . . . . . . . . . . . . . .

4 4 6 9

´ 2. T´ ecnicas de Desarrollo Agil para .NET 2.1. Programaci´on en Capas . . . . . . . . . . . . . . 2.2. Control de Versiones y Programaci´on Concurrente 2.3. Refactoring . . . . . . . . . . . . . . . . . . . . . 2.4. Desarrollo Dirigido por el Testing . . . . . . . . . 2.5. Generaci´on de Documentaci´on a Partir del C´odigo 2.6. Integraci´on Continua . . . . . . . . . . . . . . . . 2.7. Armar una Librer´ıa de C´odigo y Controles . . . . 2.8. Seguimiento de Proyectos . . . . . . . . . . . . . 2.9. Crear Componentes y Controles Personalizados . 2.10. Convenciones de Nombres y Estilo . . . . . . . . . 2.11. Manejo y Reporte Autom´atico de Errores . . . . .

. . . . . . . . . . .

´ 3. Herramientas de Desarrollo Agil para .NET 3.1. Generaci´on Semi-Autom´atica de C´odigo . . . . . . 3.2. Control de Versiones y Programaci´on Concurrente . 3.3. Refactoring . . . . . . . . . . . . . . . . . . . . . . 3.4. Testing de Aplicaciones . . . . . . . . . . . . . . . . 3.5. Generaci´on Semi-autom´atica de Documentaci´on . . 3.6. Compilaci´on e Integraci´on Autom´atica . . . . . . . 3.7. Almacenar Nuestra Librer´ıa de C´odigo y Controles 3.8. Seguimiento de Proyectos . . . . . . . . . . . . . . 3.9. Revisi´on y An´alisis de C´odigo . . . . . . . . . . . .

ii

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . .

12 13 15 19 24 26 28 30 32 33 36 43

. . . . . . . . .

47 48 52 55 59 65 67 71 74 77

iii

3.10. Profilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Check Lists de los Temas Tratados 4.1. Control de C´odigo Fuente . . . . . 4.2. Refactoring . . . . . . . . . . . . . 4.3. Testing . . . . . . . . . . . . . . . . 4.4. Documentaci´on . . . . . . . . . . . 4.5. Compilaci´on e Integraci´on . . . . . 4.6. Generaci´on de C´odigo . . . . . . . 4.7. Convenciones . . . . . . . . . . . . 4.8. Generales . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

80 83 83 84 84 85 85 86 86 87

5. Conclusiones 88 ´ 5.1. Otros Temas de Inter´es sobre Desarrollo Agil . . . . . . . . . . . . . . . . 90 A. Reflexiones Sobre el Desarrollo de Software A.1. Systemantics (Fallos en los Sistemas Complejos) . . . . . . . . A.2. Buen Software: Programaci´on o Gerenciamiento de Personas ? A.3. Mantenibilidad: Problema o Bendici´on ? . . . . . . . . . . . . A.4. Desarrollo Web: La Soluci´on Ideal o una Opci´on m´as ? . . . . A.5. N´ umeros y Estad´ısticas para Reflexionar . . . . . . . . . . . . A.6. Qu´e Significa ser un ’Mejor Desarrollador’ ? . . . . . . . . . . ´ B. Recursos Utiles B.1. Repositorios de Componentes y C´odigo . ´ B.2. Informaci´on sobre Desarrollo Agil . . . . B.3. Direcciones de las Herramientas Tratadas B.4. Contenido del CD Complementario . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

. . . .

. . . . . .

91 91 92 93 93 94 95

. . . .

97 97 98 99 101

Agradecimientos

102

Bibliograf´ıa

103

Resumen

En esta Tesis se analizar´an las diferentes t´ ecnicas de desarrollo ´ agil que permiten generar aplicaciones de manera r´apida y confiable, aprovechando al m´aximo las u ´ltimas herramientas y el nuevo enfoque de la programaci´on que se introdujo en las u ´ltimas versiones de Java y que alcanz´o su grado m´aximo con .NET. El an´alisis realizado se centra principalmente en la automatizaci´on de la mayor´ıa de las tareas del desarrollo y sobre todo en la importancia de generar c´odigo a trav´es de plantillas editables. Las t´ ecnicas abarcadas que cuentan con mayor popularidad son: • Desarrollo en Capas. • Refactoring. • Documentaci´on embebida o generada a partir del c´odigo. • Desarrollo Dirigido por el Testing. • Integraci´on Continua. • Seguimiento de Proyectos. En cuanto a herramientas, analizaremos las que apuntan a facilitar las tareas de: • Generar c´odigo de las capas de Datos y Negocios. • Hacer Refactoring. • Generar Documentaci´on. • Controlar las versiones de un sistema. • Programar entre 2 o m´as personas sobre el mismo c´odigo. • Ejecutar Casos de Test. • Compilar, Integrar y Distribuir el Sistema. • Analizar Problemas en el C´odigo.

1

2

Vale la pena aclarar que hay muchos libros escritos sobre cada uno de estos temas, en esta tesis simplemente se tratar´a de dar una introducci´on para familiarizar al lector con los mismos y brindar referencias sobre donde se puede encontrar mayor informaci´on. El objetivo principal es brindar los conocimientos para que el lector pueda armar su propio marco de desarrollo ´agil sobre .NET. El marco del que hablamos tendr´a que cumplir con las siguientes caracter´ı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´ıa conveniente que no lo tengamos que repetir para cada sistema que hagamos, por ello, ´este ser´a el tema principal en nuestra l´ı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 aplicaci´on de acceso a datos sin tener idea de ADO.NET ni 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 aplicaci´on no deber´ıan cambiar su comportamiento en absoluto. N´otese que en las u ´ltimas condiciones decimos Muy Automatizado o Muy Ortogonal 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 c´odigo solo, sino, de que 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 c´odigo que no podemos entender ni modificar.2 De la ortogonalidad lo que se busca es que ante un cambio haya que modificar la menor cantidad de c´odigo posible, porque eso de no cambiar nada en la pr´actica no existe. La mayor´ıa de las herramientas tratadas pertenec´ıan al mundo Java y fueron portadas a .Net en los u ´ltimos a˜ nos. Casi todas son iniciativas Open-Source por lo que se pueden utilizar libremente y adem´as contamos con el c´odigo fuente, para realizar cambios o agregar funcionalidad, incluso podemos envi´arselas a los creadores para que las incluyan las modificaciones en las pr´oximas versiones. 1

S´olo necesitamos conocer estos temas si vamos a cambiar las plantillas pero si s´olo generamos c´odigo no es necesario saber nada de eso. 2 De hecho todos los intentos de derivar el c´odigo Autom´aticamente a partir de una especificaci´on han fallado porque eran demasiado ambiciosos pretendiendo que los humanos participemos solo en la definici´on del problema y dejemos el resto para las m´aquinas.

3

Veamos como se estructura la tesis y a donde ir en caso de necesitar algo en particular: Comenzaremos explicando el porqu´e del T´ıtulo de la Tesis. (P´ag. 4) Pasaremos luego a las T´ ecnicas para cubrir el marco te´orico del desarrollo ´agil e introducirnos en el mundo de la programaci´on moderna. (P´ag. 12) Seguiremos con un an´alisis de las Herramientas que llevan esos conceptos a la pr´actica, porque sin ellas las t´ecnicas ser´ıan dif´ıciles de implementar y nadie las usar´ıa. (P´ag. 47) Luego daremos una lista de Check Lists con consejos y buenas pr´acticas para no tener problemas al aplicar estos conocimientos. (P´ag. 83) Extraeremos una Conclusi´ on de la informaci´on presentada teniendo en cuenta el presente y futuro de la programaci´on. (P´ag. 88) Adem´as reflexionaremos sobre temas relacionados con el desarrollo del software para tratar de comprender la Crisis en la que se encuentra y de la que parece que ser´a muy dif´ıcil salir ... si es que existe una salida. (P´ag. 91) ´ Finalmente daremos una lista muy completa de Recursos Utiles con informaci´on sobre donde encontrar mas material, donde recurrir en caso de necesitar c´odigo o controles gratuitos y las direcciones de cada una de las herramientas tratadas. (P´ag. 97)

Cap´ıtulo 1 Introducci´ on 1.1.

Por qu´ e T´ ecnicas y Herramientas ?

Cada d´ıa la brecha que existe entre la teor´ıa y la pr´actica aumenta considerablemente, las tendencias comerciales nacen, se establecen y cambian cada cinco a˜ nos o menos. Ejemplos claros de ello son: Fox Pro, Delphi, Visual Basic, Java, etc. La teor´ıa en cambio no puede seguir ese ritmo de actualizaci´on por varias razones, pero sobre todo, porque nada le conforma de esas nuevas tecnolog´ıas y, literalmente, le 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 acad´emico. 5. No podemos controlar lo que no podemos medir. 6. La Inteligencia Artificial resolver´a los problemas por nosotros. y cuando entramos en el mundo de la pr´actica descubrimos: 1. Windows es el sistema m´as usado y el que marca los nuevos est´andares. 2. VB6 es f´acil de entender y es el m´as usado en los desarrollos administrativos. 3. SQL Server, Oracle, MySQL no guardan sus bases en XML y son los m´as populares. 4. .NET marc´o un antes y un despu´es en la historia de la programaci´on. 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 pr´actico con la Inteligencia Artificial. 4

´ CAP´ITULO 1. INTRODUCCION

5

Por ello en esta tesis se analizar´an ambos mundos. ´ m´as destacadas y Del lado de la teor´ıa analizaremos las T´ecnicas de Desarrollo Agil u ´tiles, incluiremos una descripci´on general de cada una, su origen y donde es conveniente usarla. Del lado de la pr´actica estudiaremos las Herramientas desarrolladas para .NET que dan soporte a las t´ecnicas vistas, incluiremos las principales caracter´ısticas de las mismas, donde encontrarlas y en qu´e escala utilizarlas. En este enfoque paralelo no mostraremos todas las T´ecnicas y Herramientas pero al final de la Tesis propondremos un listado con otras posibilidades, citando las fuentes donde encontrar informaci´on adicional.

´ CAP´ITULO 1. INTRODUCCION

1.2.

6

´ Por qu´ e Metodolog´ıas de Desarrollo Agil ?

La mayor´ıa de nosotros somos conscientes que la computaci´on en s´ı y sobre todo el mundo de la programaci´on cambia a una velocidad realmente vertiginosa. Pero algo m´as radical es lo que ocurri´o en la programaci´on que lo podemos definir como una revoluci´ on. Hoy en d´ıa con los requerimientos que tienen los grandes sistemas (distribuidos, 24 Hs. online, acceso Web, etc.) es casi imposible hacer algo individualmente ya que se requieren de conocimientos en much´ısimas ´areas. Gracias a Internet los desarrolladores encontraron una peque˜ na soluci´on, comenzaron a compartir sus conocimientos, experiencias y a ayudarse entre si, reduciendo la cantidad de informaci´on a procesar. Las Listas de Correo y los sitios que son s´olo repositorios de tutoriales o trozos de c´odigo fuente (snippets) son el lugar perfecto para visitar cuando se nos presentan problemas con los que no nos hemos encontrado antes, pero que, seguramente, alguna otra persona ya ha enfrentado y solucionado. Esto afect´o mucho la forma de programar que algunos denominaron Programaci´ on Basada en Componentes, pero no es s´olo eso, la revoluci´ on de la que hablamos va mucho mas all´a. Lo que se quiere destacar es la cantidad de interacciones con las que deben conviven los sistemas actuales y el grado de confianza que se tiene en terceras partes, que nos guste o no, son m´as que necesarias porque como dijimos no podemos hacer todo nosotros. Antes un programador se preocupaba por chequear su c´odigo o actualizar su compilador y no mucho m´as. En cambio, hoy d´ıa, un programador debe verificar compatibilidades de todo tipo, que van desde versiones de sistema operativo, hasta la placa de video de la m´aquina donde se va a correr el sistema, pasando por supuesto por los famosos Services Packs (que gracias a Microsoft se convirtieron en palabra corriente) que no son mas que un fiel reflejo 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 planificaciones y la calidad esperada, que queda para nosotros). Con esto en juego se empieza a notar que el tiempo nunca alcanza con los m´etodos 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 documentaci´on, testing, planificaci´on, gastos en recursos, etc. Lo hacemos para tener la consciencia tranquila y sentir que est´a todo bajo control. Pero a medida que el proyecto avanza se va dejando de lado la documentaci´on porque sino no se puede llegar a tiempo, se va demorando la planificaci´on progresivamente y 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 planificaci´on original.

´ CAP´ITULO 1. INTRODUCCION

7

Finalmente se omite el testing por completo. La documentaci´on y planificaci´on pasan a ser un recuerdo y se convierten en un conjunto de archivos u hojas a los que nadie accede. El principal problema es que adem´as de no tener nada actualizado, no se sabe en que estado est´a el sistema, y como se dejaron partes sin terminar o testear nadie puede asegurar que algo funcione. Esto empeora ya que los usuario no entran en contacto con el sistema hasta que est´e casi completo. El proyecto se vuelve incontrolable, peor aun que en aquellos d´ıas de la programaci´on en los que no se planificaba nada, se hac´ıa algo y a medida que el usuario ped´ıa se agregaban cosas. Las metodolog´ıas ´agiles buscan rescatan esa esencia de la programaci´on del prueba y error, el hago algo y veo si es lo que quieren, termino esta parte y agarro otra. Todas esas peque˜ nas cosas que marcaban a los programadores de la ´epoca, que muchos tratan 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 computaci´on a lo que es actualmente, sino basta con preguntarnos si estas personas: • Terminaban lo que les ped´ıan ? • Sab´ıan a lo que se enfrentaban ? • 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 reflexionar no ? Las metodolog´ıas ´agiles como Extreme Programming (XP) o Scrum fomentan la planificaci´on de peque˜ nas partes del sistema (no del sistema en s´ı), la misma se hace semana a semana, d´ıa a d´ıa, paso a paso. Con esto se logra saber exactamente en que estado est´a cada parte del sistema y hacer peque˜ nos ajustes al alcance o a la planificaci´on si no llegamos en el tiempo prometido. Si bien es cierto que no hay una planificaci´on sobre el proyecto completo como supuestamente tenemos con las metodolog´ıas tradicionales, logramos una mayor sensaci´on de avance ya que las metas est´an mas cerca y son mas visibles. Como consecuencia todos ganan:

´ CAP´ITULO 1. INTRODUCCION

8

• Los programadores se sienten mucho m´as u ´tiles ya que terminaron con lo que prometieron, lo ven funcionando y sobre todo no se frustran porque est´an fuera de la planificaci´on. De esta forma rindan m´as porque notan que las cosas se est´an completando razonablemente bien y no se los est´a presionando constantemente para que terminen algo. • El jefe de proyecto tiene semanalmente cosas nuevas del sistema para mostrar a los gerentes o clientes. Pudiendo adem´as identificar errores de interpretaci´on asegur´andose que todo marcha como ellos quieren. • Los gerentes o clientes perciben que se est´an haciendo cosas y que el proyecto avanza a paso firme, evitando la ansiedad (o hasta angustia) que generan otras formas de trabajar donde s´olo se les muestran las cosas cuando est´an listas (lo que siempre lleva m´as tiempo y dinero de lo previsto). Como nota final podemos decir que ninguna metodolog´ıa es universal, con esto reconocemos que el desarrollo ´agil no es aplicable a ciertos tipos de desarrollo. Por ejemplo, en el construcci´on de sistemas embebidos puede ser mejor aplicar alguna otra forma de trabajo como la estructurada tradicional. De todos modos se puede adaptar el desarrollo ´agil a la mayor´ıa de los sistemas para que nos de excelentes resultados y sobre todo... para que podamos dormir tranquilos ...

´ CAP´ITULO 1. INTRODUCCION

1.3.

9

Por qu´ e la Plataforma .NET ?

Para estudiar la aplicaci´on de las metodolog´ıas ´agiles debemos encontrar una plataforma de desarrollo moderna que cumpla con las siguientes condiciones: • Tenga soporte para Programaci´on Orientada a Objetos. • 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 u ´ltimas t´ecnicas de desarrollo ´agil y existan herramientas implementadas para hacerlo. • Sea factible implementar patrones de dise˜ no. • Sea Multi-Plataforma. • Sea lo m´as econ´omico posible, incluso gratuito. Las dos grandes opciones que cumplen estas condiciones son, sin lugar a dudas, Java2EE y .NET Framework. La inclinaci´on hacia el segundo est´a dada por el impulso que Microsoft le da a .NET ya que est´a dispuesto a convertirlo en la decisi´on indiscutible del futuro (y como sabemos cuando MS se encapricha con algo, lo logra, y sino compra a los competidores) Los principales factores que nos llevan a esta decisi´on son: • La velocidad de crecimiento y maduraci´on de .NET es realmente exponencial con respecto a la de Java. • La facilidad de aprendizaje y acceso a tutoriales es mucho mayor a la de Java. • La estandarizaci´on de C# y el CLI (common lenguaje infrastructure) permiti´o proyectos como Sharp Develop, un IDE muy completo, similar al Visual Studio .NET pero de c´odigo abierto. • Relacionado con el CLI se desarroll´o el proyecto MONO que permite ejecutar 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 adhesi´on e inter´es comercial llegar´a a un estado de madurez muy pronto) • .Net presenta un soporte m´as que transparente para integrarse con el resto de las herramientas de Microsoft y que la mayor´ıa de las empresas tienen instaladas, como:

´ CAP´ITULO 1. INTRODUCCION

10

• Active Directory • SQL Server 7 y 2000 • Office 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 adem´as ineficientes.1 • A SUN pareciera que no le queda mucho ya que parece dar todo el tiempo manotazos de ahogado, regalando cosas y dem´as. Esta raz´on es muy importante porque en un futuro SUN puede dejar de existir, pero que deje de existir Microsoft... es dudoso no ?? • La diferencia m´as notable es cu´al es el motor detr´as de cada unos de estos grandes. • Por un lado est´a Java que surge como un lenguaje revolucionario, orientado a objetos, portable, multi-plataforma, etc. Fue el conejito de indias y se tom´o un buen tiempo para crecer pero por varias razones no se termin´o de imponer (entre otras porque: era muy pesado para las maquinas de la ´epoca, no exist´ıa un buen IDE para desarrollar, era dif´ıcil operar con bases de datos, etc.). • Por otro lado est´a .NET impulsado por la necesidad de la mayor´ı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 m´as dinero y como sabemos con ´el todo se hace r´apido y lo mejor posible, sino basta comparar el Visual Studio.NET con los IDE´s ofrecidos por SUN, que no son malos, pero hay una diferencia en productividad muy grande que las empresas no est´an dispuestas a pagar. • .Net captur´o gran parte de la comunidad Open Source que estaba abocada a la construcci´on de herramientas y componentes para Java. Estos se maravillaron con 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 eficiencia en ejecuci´on con respecto a requerimientos de hardware de las dos grandes plataformas favorece a .NET que, al no ser totalmente interpretado, lo 1

Adem´as de que Java no tiene soporte nativo para integrarse con estas herramientas usa m´etodos de acceso como ODBC al que MS no le presta atenci´on (o se la presta para ver como complicarlo) y que son muy lentos en comparaci´ on con, por ejemplo, ADO.NET

´ CAP´ITULO 1. INTRODUCCION

11

deja a Java fuera de combate en cuanto a Performance2 . Aunque se diga que el Visual Studio es pesado y el framework tambi´en, basta ponerlo al lado del de Java 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 programaci´on como lo es JAVA, sino que es un Runtime con librer´ıas comunes que permite que varios lenguajes se implementen sobre el sin problemas, inclusive se podr´ıa implementar Java. • 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 due˜ no de Java es SUN y podr´ıa cuando quisiera comenzar a cobrar por el uso de su lenguaje, parecer´ıa que esto nunca va a pasar, pero pensemos que si SUN quiebra la podr´ıa comprar otra compa˜ n´ıa y hacer uso de estos derechos. Podr´ıamos escribir much´ısimas m´as ventajas pero basta con concluir que Microsoft realmente sab´ıa lo que hac´ıa cuando creo .Net. Se encargo de atender lo que los usuarios 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´o por crear un entorno de desarrollo (IDE) muy completo y con soporte de add-ins y macros (dos caracter´ısticas que le dan al Visual Studio una potencia inigualable) Lo m´as curioso e interesante es que con las versiones 1.0 y 1.1 de .Net se incluy´o s´olo una parte de lo que estaba planificado ser´ıa el .NET Framework (por cuestiones de mercado o simplemente de tiempos). En el 2005 lanzar´a la versi´on 2.0 de .NET que promete ser el golpe final y sin dudas se va a imponer como la plataforma de desarrollo para, por lo menos, los pr´oximos 10 a˜ nos o como dice Microsoft los pr´oximos 20.

2

Si buscamos en internet ”J2EE Vs .NET”veremos que la comunidad de Java dice que su plataforma es la mejor pero las razones que dan no son suficientes. 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´ıa el C++ semi-interpretado con una capa intermedia porque perder´ıa el mercado de los juegos actuales hechos con Visual C++ y DirectX, ya que la performance de estos se vendr´ıa abajo (o acaso conocen alg´ un juego 3D hecho en Java... a si ?? y cuantos servidores se necesitan para ejecutarlo...)

Cap´ıtulo 2 ´ T´ ecnicas de Desarrollo Agil para .NET Como comentamos en la introducci´on de esta Tesis, las metodolog´ıas ´agiles son casi la u ´nica opci´on hoy en d´ıa para desarrollar proyectos de gran envergadura donde se necesita complir con los tiempos y resultados esperados, pero sobre todo en los contextos donde se necesita algo que realmente funcione. En esta secci´on de la tesis analizaremos desde el punto de vista te´orico las distintas ´ con las que contamos y que tienen mayor popularidad en la T´ecnicas de Desarrollo Agil comunidad de desarrolladores de .NET. Estas t´ecnicas son la base fundamental de las herramientas m´as exitosas para la plataforma de Microsoft. Proveen la escencia del desarrollo ´agil y luego las herramientas que veremos en el cap´ıtulo 3 las llevan a la pr´actica lo m´as fielmente posible. Aclaremos nuevamente que no haremos un an´alisis exaustivo de cada t´ecnica porque ser´ıa imposible ya que existen muchos libros de cada una, nos conformaremos con una idea general de la t´ecnica y como se adapta a .NET, para mayor informaci´on se puede consultar el Ap´endice B (p´agina 97) donde hay enlaces a sitios sobre cada tema, la Bibliograf´ıa o el CD complementario donde encontrar´an m´as material.

12

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

2.1.

13

Programaci´ on en Capas

Esta ser´a la primer t´ecnica que analicemos ya que es una de las m´as antiguas. Se aplica a cualquier tipo de desarrollo relacionado con bases de datos, principalmente en sistemas administrativos. Gr´aficamente un t´ıpico sistema con arquitectura en capas se ve as´ı:

1

La idea detr´as del desarrollo en capas es que cada una de ellas se encargue de una parte del sistema bien determinada y que cualquiera pueda ser cambiada sin que afecte el resto. En la pr´actica cuesta mucho mantener una independencia pura como se plantea en esta t´ecnica, pero de todas maneras se simplifica much´ısimo el desarrollo cuando uno encara la soluci´on de esta manera con partes independientes y ortogonales. La principal ventaja, desde mi punto de vista, es que la mayor parte de las capas de datos y de negocios se pueden generar autom´aticamente mediante plantillas ya que se encargan del mapeo relacional y de traducir los objetos del programa en objetos que la base de datos entienda. Para comprender porque esta t´ecnica se populariz´o tanto veamos un ejemplo t´ıpico: 1

De todas la capas que vemos en el gr´ afico no todas tienen porque estar ni tampoco son las u ´nicas que hay, se podr´ıa llegar a utilizar la cantidad que queramos, este es solo un ejemplo del caso m´as com´ un en un desarrollo con bases de datos.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

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, eliminaci´on, actualizaci´on y recuperaci´on de datos2 . Por lo tanto si se cambia de motor de base de datos se deber´ıan reescribir solamente los stored procedures. Esto nos evita reescribir el c´odigo de las capas de negocios que poco tienen que ver con la decisi´on de cambiar la base y que, si el sistema se dise˜ no con esta filosof´ıa, no se le deber´ıa cambiar nada. Aunque parece que son todos halagos para el desarrollo en capas, en la pr´actica (como siempre) surgen cosas que no se pueden manejar fiel al esquema propuesto y perdemos esa abstracci´on tan pura que ve´ıamos en el gr´afico. Tengamos en cuenta el siguiente enunciado: Se necesita que cuando se cambie el precio de alg´ un art´ıculo se escriba un registro en la tabla de novedades de precios. La soluci´on m´as sencilla es crear un Trigger en la Base de datos y as´ı cuando se modifica 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 t´ecnica. Aunque se rompa con la idea general este tipo de cosas pasan siempre. Estas excepciones son mucho m´as f´aciles de manejar como tales que tratando de hacerlas encajar 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 refiero a que debemos redactar un documento formal y colocarlo en la carpeta con los diccionarios de datos. M´as bien se debe escribir un breve documento explicando el porque de la decisi´on y colocarlo en una carpeta de documentos vitales del sistema (con esa informaci´on que 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.

2

En ingl´es estas operaciones son conocidas con el nombre de CRUD por Create, Retrieve, Update & Delete.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

2.2.

15

Control de Versiones y Programaci´ on Concurrente

Cualquier persona que haya hecho alg´ un sistema para alguien, por m´as peque˜ no que sea, sabe que la siguiente historia es m´as que frecuente: Uno le entrega una versi´on al cliente y luego contin´ ua haciendo cambios para la pr´oxima entrega. Luego que la terminamos llevamos la nueva versi´on, pero, cuando el cliente la prueba dice: ”Si si, est´ a muy bien, pero la pantalla de b´ usqueda de ac´ a quiero que funcione como la anterior no como ´ esta”. Hay dos mundos posibles al tratar de solucionar este problema: • Que no llevemos control de versiones En este caso buscamos en nuestro disco alguna versi´on anterior del c´odigo fuente y rezamos para que sea la misma que gener´o el programa del que 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 b´ usqueda y le agregamos el de la versi´on vieja el otro3 . Volvemos a compilar y se lo llevamos, rez´andole a San Murphy en el 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 m´as simple, simplemente le pedimos al Sistema de Control de Versiones que nos muestre las diferencias en el archivo de la pantalla de b´ usqueda entre la versi´on actual y la que le entregamos al cliente, este las muestra lado a lado resaltando las diferencias y solo debemos extraer lo que necesitamos4 . La programaci´on es una tarea altamente creativa, cambiante y, como cit´abamos anteriormente, generalmente no es una actividad individual. Solo cuando se trabaja con un grupo de personas que modifican concurrentemente ´el c´odigo nos damos cuenta que es muy complicado juntar las distintas versiones del sistema que est´an en cada m´aquina, por m´as que se dividan correctamente las tareas, 3

Ojal´a que tengamos un backup de la u ´ltima versi´on porque el resultado probablemente no ser´a el esperado 4 Aunque parezca poco probable que sea as´ı de sencillo veremos que lo es en las pr´oximas hojas

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

16

Murphy har´a que se necesite cambiar el mismo archivo, en el mismo lugar y las cosas se volver´an, como siempre, m´as complicadas de lo previsto. La forma de trabajo de los sistemas de control de versiones es muy simple: • Hay un repositorio central con el c´odigo fuente que mantiene los cambios que se fueron haciendo a lo largo del tiempo. • Hay tres operaciones b´asicas sobre el repositorio que son: Bajarse una versi´on completa del c´odigo (CHECKOUT) Bajarse los u ´ltimos cambios y juntarlos con las nuestros (UPDATE) Subir nuestros cambios para que los dem´as puedan verlos (COMMIT) Gr´aficamente se ve as´ı

Esquema General de un Sistema de Control de Versiones (CVS) * Utilizaremos directamente los nombres en ingl´es para no generar confusi´on y porque no hay buenas traducciones de estos t´ermino Con respecto al orden de las operaciones en el uso b´asico de un sistema de control de versiones podemos decir que debemos hacer una u ´nica ves un CHECKOUT. Luego podemos hacer cambios en el sistema, cuando los finalizamos se hace un UPDATE para obtener los cambios que pueden haber realizado los otros desarrolladores y seguido un COMMIT para reflejar nuestros cambios en el repositorio. El ciclo se repite con estas dos operaciones superpuestas entre los programadores. Gr´aficamente:

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

17

Tareas m´ as comunes sobre el repositorio 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 dividi´esemos la l´ınea principal de desarrollo en dos y podemos trabajar en cualquiera de ellas. El lugar m´as com´ un donde se utilizan BRANCHS es antes de realizar un RELEASE 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 u ´nica 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 gr´afico:

Pasos T´ıpicos de un Branch en el Desarrollo Otro comando interesante es el de TAG que se encarga de ponerle un nombre simb´olico a las versiones de un grupo de archivos. 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 versi´on independiente ya que se actualizan individualmente ser´ıa una locura tener que anotar todas para despu´es poder volver a 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 f´acil hacer control de versiones ya que Microsoft no utiliza m´as archivos binarios para guardar los proyectos o soluciones. Ahora usa directamente archivos de texto con sintaxis XML.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

18

Como conclusi´on podemos decir que el control de versiones es como un gran UNDO en el desarrollo que nos permite ir y venir entre las versiones del c´odigo sin problemas. Inclusive tenemos una auditor´ıa perfecta de los cambios, quien los hizo, cuando, etc., lo que genera mayor confianza en los miembros del equipo de desarrollo, ya que en caso de encontrar un error no se pueden echar la culpa mutuamente sin justificaci´on porque se descubrir´ıa la verdad f´acilmente. Un hecho muy interesante relacionado con la pr´oxima t´ecnica que veremos, es que cuando hay que hacer un cambio importante al que le tenemos un poco de desconfianza podemos hacer un BRANCH y ir modificando lentamente el c´odigo para ver como evoluciona (lo que no afectar´a a la l´ı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 r´apidamente, no quedan muchas cosas a las que tenerle miedo. Adem´as toda la comunidad Open Source hizo y hace uso de sistemas de control de versiones y han tenido excelentes resultados, inclusive con cientos de programadores cambiando el c´odigo concurrentemente como pasa con Linux. As´ı que es buena idea imitarlos.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

2.3.

19

Refactoring

Aunque el nombre no sea muy conocido est´a comenzando a escucharse cada vez con mas frecuencia y va a pasar a ser algo muy com´ un cuando Microsoft incluya herramientas que soporten esta t´ecnica dentro del Visual Studio .NET 2005. 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´o de ser un conjunto desordenamos de ideas a u ser un texto m´as o menos le´ı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 despu´es se van cambiando cosas generalmente se tienen mejores resultados. En la programaci´on esto es mas grave porque si uno planea al detalle todo lo que 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 atr´as y re-pensar todo el problema con la p´erdida de tiempo 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´ıan haberse hecho mejor. De lo que se trata refactoring es de mejorarlas en ese momento por m´as que parezca una p´erdida de tiempo, a largo plazo nos traer´a grandes beneficios. La definici´on de refactoring es: Cambiar ”algo” con el fin de mejorarlo. En el caso de la programaci´on ese algo es el c´odigo, en el dise˜ no son los diagramas y en el an´alisis son las especificaciones y la arquitectura. Un problema con el que se enfrenta hoy en d´ıa esta t´ecnica es que, generalmente, 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 ning´ un valor comercial. Pero todo buen analista, arquitecto, dise˜ nador o programador de sistemas se las debe rebuscar para hacer refactoring si realmente piensa que las cosas no pueden seguir as´ı, primero por derecha pidiendo autorizaci´on para 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´a nuestra. Es necesario aclarar que debemos poner en la balanza el costo del cambio y los beneficios que obtendremos para tomar una decisi´on y no hacer refactoring por deporte, no porque esto este mal, sino porque nuestros jefes o clientes no estar´an muy contentos y nos quedaremos sin trabajo.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

20

Razones para hacer Refactoring Las situaciones m´as comunes en las que se debe hacer refactoring y que nos dar´an el mayor beneficio son: El C´ odigo est´ a duplicado Esta raz´on es la que mayor cantidad de problemas nos trae, todo c´odigo o informaci´on duplicada a mediano o largo termino es un dolor de cabeza porque se deben hacer modificaciones en paralelo en todos lados. En el libro de Hunt and Tomas [HT99] lo llaman el principio del ”DRY” (Don´t 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 Dise˜ no” Una rutina es muy larga En la programaci´on orientada a objetos tener rutinas que sean mayores que lo que 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 m´etodo con el c´odigo comentado y se lo debe nombre de manera que exprese lo mismo que el comentario. La lista de par´ ametros de una rutina es muy grande Este es un error muy grave en la programaci´on orientada a objetos ya que uno deber´ıa en estos casos usar un objeto como par´ametro y as´ı en caso de cambiar la cantidad de datos que se necesitan se le puede agregar un campo al objeto. De la otra manera en cambio debemos agregar un par´ametro al m´etodo y a todas las llamadas ponerles el par´ametro extra que quiz´a no tenga sentido para muchas de ellas. Una clase tiene poca cohesi´ on Si una clase hace demasiadas cosas que no est´an relacionadas entre s´ı, se debe dividir en varias clases, donde cada una toma un conjunto de responsabilidades altamente cohesivas. Los comentarios explican trozos de c´ odigo Si dentro del cuerpo de una rutina hay comentarios para explicar parte del c´odigo 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 c´odigo comentado, gracias a este refactoring, nuestro sistema se vuelve m´as sencillo y auto-documentado. Una clase est´ a en el medio entre otras y no hace nada Si la mayor´ıa de los m´etodos de una clase s´olo tienen una llamada a un m´etodo de otra, se debe considerar el hecho de eliminarla ya que refleja un error de dise˜ no, debiendo convertir las llamadas anteriores por llamadas directas a la clase final.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

21

´ Refactorings m´ as Conocidos y Utiles 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´e contextos. Reemplazar los numeros m´ agicos por constantes simb´ olicas Este es un refactoring t´ıpico que todos recomiendan utilizar. En .NET en particular, cuando dise˜ namos controles personalizados y tenemos tama˜ nos, colores, textos por defecto siempre conviene usar constantes simb´olicas y no los valores literalmente. Renombrar una variable a un nombre m´ as claro o informativo Si una variable tiene un nombre poco claro (temp, obj, etc) cambiarlo a uno m´as significativo. Lo mismo se aplica a las constantes, rutinas y clases. Reemplazar una expresi´ on con una rutina Cuando una expresi´on aparece en m´as de un lugar o es demasiado complicada, se debe crear una funci´on que la compute y que tenga un nombre significativo. Mover las expresiones booleanas de m´ as de 2 o 3 condiciones a una funci´ on Toda expresi´on booleana lo suficientemente complicada compromete la legibilidad del c´odigo en zonas tan importantes como los condicionales, la forma simple de evitarlo es creando una funci´on que la compute y ponerle un nombre adecuado. Devolver los valores de las funciones ni bien se los conozca y no asignarlo a una variable temporal Si hacemos esto el c´odigo se vuelve m´as f´acil de leer y la mantenibilidad futura no se complica ya que si agregamos c´odigo debajo sabemos que no se va a ejecutar si no corresponde ni cambiar´a el valor del resultado como pasar´ıa si tenemos una variable temporal. Extraer una rutina Cuando un m´etodo se vuelve muy largo o complicado debemos extraer parte de su c´odigo y formar una nueva rutina con ´el pas´andole los par´ametros que necesite. Convertir una rutina larga en una clase Si una rutina es demasiado larga, muchas veces se la puede convertir en una clase con m´ ultiples rutinas para mejorar la legibilidad. Pasar un objeto completo en lugar de miembros espec´ıficos Si estamos pasando pasando muchos valores de un objeto a una rutina quiz´a nos convenga pasar directamente el objeto para facilitar la legibilidad y la extendibilidad.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

22

Combinar c´ odigo similar en una superclase Si dos subclases tienen c´odigo similar se debe tratar de trasladarlo a la superclase y evitar la duplicaci´on. 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 com´ un en la construcci´on de un sistema es que una clase crece en responsabilidades y es conveniente dividirla en dos para facilitar la legibilidad y mantenibilidad. Eliminar una clase Si una clase se queda s´olo con un par de responsabilidad quiz´a sea conveniente embeberla dentro de otra y eliminarla. Introducir una rutina for´ anea Si un clase necesita una rutina adicional y no podemos modificar la clase para agregarla podemos crear la rutina en la clase cliente. Introducir una clase de extensi´ on Si una clase necesita nuevos miembros y no podemos modificar 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 m´as coherente sin una rutina, esconderla. Reemplazar c´ odigos de error con excepciones o viceversa 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 informaci´on (como ser archivos de configuraci´on, variables globales, etc), as´ı nos abstraemos de estos datos y hacemos que el sistema se vuelva m´as flexible con poco esfuerzo.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

23

Refactoring del Dise˜ no y la Arquitectura No s´olo el c´odigo necesita refactoring, muchas veces cuando nos damos cuenta que algo no est´a del todo bien tratamos de hacer cambios para que funcione. Pero muchas veces por m´as cambios que le hagamos al c´odigo el problema sigue ah´ı. La raz´on es porque la soluci´on no est´a en cambiar el c´odigo sino en cambiar el dise˜ no o 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 verifica si la transacci´on es posible y la registra generando la respuesta correspondiente, la misma vuelve al proceso receptor para que la env´ıe y reci´en en este momento se le pasa la siguiente transacci´on al servidor. Si nos ponemos a dar vuelta el c´odigo del servidor para arriba y para abajo haci´endole refactorings lo m´as probable es que no mejore mucho la performance porque el cuello de botella no est´a all´ı sino en el receptor de transacciones. El problema radica en que el receptor trabaja de forma secuencial despachando una transacci´on esperando que este lista y luego despachando otra. La soluci´on estar´ıa dada por una arquitectura concurrente donde las transacciones se despachen simult´aneamente pero esto implica un refactoring muy completo a nivel de arquitectura y dise˜ no ya que hay que re-pensar todo. Incluimos este ejemplo para mostrar simplemente que si algo no anda bien, o no nos gusta como qued´o, podemos ir m´as all´a del c´odigo en busca de una soluci´on a un nivel de abstracci´on mayor como pueden ser el dise˜ no o la arquitectura del sistema. Conclusi´ on Para marcar la importancia de este tema destacamos que tanto Microsoft como Borland brindar´an soporte nativo en sus entornos de desarrollo para muchos de los refactoring vistos (ver 3.3). La principal raz´on de esta decisi´on es porque comprobaron que la comunidad recurr´ıa mucho a los complementos comerciales que hac´ıan s´olo esto y porque est´a comprobado que mejora la productividad. Gracias a este cambio s´olo necesitamos identificar los refactorings a aplicar y dejar que nuestro IDE haga el trabajo pesado. Cuando uno comienza a hacer refactoring quiz´a no vea las ventajas inmediatamente, 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 m´as f´acil de modificar a la que le cambiamos los nombres, la cantidad de m´etodos, los par´ametros, los comentarios, etc.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

2.4.

24

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 m´as que justificar porque en la vida diaria se hace muy poco y solo al finalizar el sistema. Veamos lo que nos pide la teor´ıa: • Debemos probar el sistema contra todas las entradas posibles. • Debemos calcular la cantidad de c´odigo que est´a cubierta por los tests. • Debemos definir 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´a bien que se insista en el testing porque en todos lados vemos gr´aficos como el de la figura siguiente que nos muestran, con raz´on, que no se puede dejar el testing para lo u ´ltimo 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 figura 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.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

25

Aqu´ı se presenta otra ves un tema de burocracia porque los clientes o jefes est´an 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 planificaciones. Lo m´as avanzado que existe en cuanto a testing es lo propuesto por Kent Beck en su libro Test-Driven Development by Example [Bec03] donde nos indica como hacer p primero los test y luego implementar el c´odigo. Esta idea es una parte fundamental de la filosof´ıa de Extreme Programming. Aunque parezca una idea ambiciosa d´ıa a d´ıa cuenta con m´as adepto que incluso afirman que es m´as sencillo que hacer el testing convencional. Para encontrar mayor informaci´on sobre el tema ir a: http://www.TestDriven.net Yo creo que debemos encontrar un punto medio, usando t´ecnicas de testing temprano que se pueden ejecutar autom´aticamente. El problema si usamos un enfoque de desarrollo 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 m´as conservador pero introduciendo 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´ıa para que se puedan validar otras operaciones (como inserci´on, actualizaci´on y borrado) sobre una base de prueba. En la secci´on 3.4 mostraremos como funciona NUnit, la herramienta m´as usada para crear y ejecutar tests en el mundo de .NET.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

2.5.

26

Generaci´ on de Documentaci´ on a Partir del C´ odigo

En las metodolog´ıas denominadas pesadas el desarrollo debe estar dirigido por la documentaci´on y los argumentos que presentan para hacerlo parecen buenos, pero, como siempre, en la pr´actica se convierten en desventajas por la p´erdida de tiempo que implica la actualizaci´on5 y porque se termina haciendo un trabajo doble al mantener paralelamente esta informaci´on y el c´odigo. 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 u ´ltima debemos cambiar tambi´en los DD, pero si documentamos las tablas con los lugares que tienen reservado para esto los motores de bases de datos, la meta-data puede utilizarse despu´es para extraer las descripciones y generar autom´aticamente el diccionario de datos e inclusive los diagramas de relaci´on. La contestaci´on obvia podr´ıa ser que pasa si queremos agregar informaci´on al D.D. y no lo podemos hacer en las descripciones de los campos y las tablas, nuestra respuesta deber´ıa ser que esa informaci´on seguramente es m´as importante que el D.D. en si, entonces se deber´ıa llevar aparte y no embebido con est´a informaci´on ya que perder´ı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 com´ un es tener la estructura de las entidades y las relaciones y luego si hay info adicional, que ser´ıa una excepci´on, se deber´ıa documentar aparte. Volviendo a al tema central de esta secci´on podemos decir que con el c´odigo para algo muy parecido, tener un documento de Word con 500 p´aginas con la definici´on de las clases, sus m´etodos, sus responsabilidades, la relaci´on entre las mismas, etc. es algo totalmente anti-productivo no tiene sentido colocar all´ı ese conocimiento es mejor embeberlo en el c´odigo o sacarlo autom´aticamente y generar algo en un formato m´as ameno para encontrar lo que buscamos. Cuando Microsoft desarrollo las librer´ıas de .NET se encontr´o con este problema de mantenibilidad de la informaci´on de las clases, m´etodos, eventos y propiedades y dise˜ no una nueva forma de documentaci´on embebida en el c´odigo con formato XML, gracias a esto posibilit´o la inclusi´on de meta-data sobre los par´ametros, valores de resultado, ejemplos, etc. Un formato muy com´ un para la documentaci´on durante el desarrollo es el CHM de Microsoft que nos permite navegar sobre un ´arbol con el mismo esquema del c´odigo y ver la informaci´on relacionada con cada elemento del mismo. 5 Inclusive si la documentaci´ on est´ a desactualizada puede ser hasta peligrosa porque puede llevar a decisiones o pensamientos equivocados.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

27

Esta opci´on s´olo funciona con C# ya que es el lenguaje con el que los ingenieros de MS escribieron las librer´ıas pero ya existen herramientas que lo extienden a VB.NET. Un ejemplo de como se ven los Tags XML en el editor de c´odigo ser´ı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 documentaci´on en XML y que el mismo compilador de C# es el que se encarga de extraer esta informaci´on a un archivo con el mismo nombre que el ensamblado pero con extension XML. Finalmente fue un paso m´as all´a permitiendo que el IntelliSense del Visual Studio extraiga informaci´on de estos archivos con lo que nuestra documentaci´on no solo se extrae sino que adem´as se integra autom´aticamente al VS.NET. El paso que resta es darle a esa meta-data un formato m´as legible que XML 6 y as´ı completar el c´ırculo de la documentaci´on semi-autom´atica. Existen muchas herramientas para hacerlo, la m´as popular es NDoc y ser´a la que analizaremos en la secci´on 3.5 (p´ag. 65).

6

Aunque uno de los objetivos cuando se cre´o XML era que sea legible por humanos no conozco mucha gente que necesite hacerlo y los que lo hacen tal vez prefieran un hermoso archivo de texto plano sin tags.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

2.6.

28

Integraci´ on Continua

Integraci´on Continua (Continuos Integration) no es simplemente una t´ecnica sino una filosof´ıa de desarrollo. 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 verifique su integridad. Esta orientado a grandes desarrollos donde hay varios equipos que hacen diferentes m´odulos del sistema. Anteriormente los equipos trabajaban casi independientemente, dise˜ naban y programaban sus m´odulos, cuando los ten´ıan listos los testeaban para ver como se comportaban y finalmente los trataban de unir creyendo que todo saldr´ıa de maravillas; pero todos sospechamos lo dif´ıcil que es que esto funcione, sobre todo por la complejidad que se presenta si las cosas no encajan y hay que volver todo para atr´as. Continuos Integration ataca a este punto y como lo indica el desarrollo ´agil trata 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 ´exito disminuyen. Pero la Integraci´on Continua va m´as all´a, utiliza las t´ecnicas vistas como: control de c´odigo fuente, generaci´on autom´atica de documentaci´on, ejecuci´on autom´atica de casos de test, etc. para cumplir con su cometido. Los pasos del proceso ideal de integraci´on continua que se desarrollan autom´aticamente son: • Revisar el Sistema de Control de Versiones para ver si hay cambios • Si los hay, extraer la u ´ltima versi´on y ponerle un Tag antes de hacer nada (ej: PRE_0_7_6). • Actualizar la versi´on del Sistema (ej: de 0.7.5 a 0.7.6) • Compilar todos los m´odulos del sistema. • Ejecutar los casos de test como se explico en la secci´on 2.4 • Si algo sali´o mal hasta el momento informar por mail o de alguna manera al encargado y abortar. • Generar la documentaci´on autom´atica. • Hacer un nuevo Tag en el sistema de control de versiones (ej: POST_0_7_6). • Generar una nueva instalaci´on del sistema. • Copiar o distribuir los archivos donde corresponda.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

29

• Generar un reporte sobre la compilaci´on e integraci´on. • Enviar por mail ese reporte a los miembros que corresponda. Gr´aficamente el proceso se ve as´ı:

Para mayor informaci´on sobre esta t´ecnica ver el material en el CD complementario o entrar al sitio de CruiseControl.NET: http://ccnet.thoughtworks.com o directamente en www.thoughtworks.com donde encontrar´an white papers sobre estos temas. Si alguna ves tuvimos que entregar sucesivas versiones de una misma aplicaci´on sabemos lo dif´ıcil que se hace recordar todos los cambios que debemos hacer para que funcione en el ambiente de producci´on. Se deben cambiar las Bases de Datos, la ubicaci´on de los archivos ya que seguramente est´abamos usando algunos de prueba, compilar los controles en modo Release, cambiarle el n´ umero de version, etc, etc. Si usamos integraci´on continua s´olo debemos indicarle al sistema que usemos los pasos que debe realizar para tener una nueva versi´on lista para poner en producci´on y autom´aticamente la tendremos con un reporte de los resultados intermedios.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

2.7.

30

Armar una Librer´ıa de C´ odigo y Controles

Una de las principales reglas del desarrollo ´agil es no hacer nada que ya este hecho por eso estudiaremos como y donde buscar c´odigo o controles que resuelvan cosas por nosotros, luego clasificarlos y guardarlos, para encontrarlos r´apidamente cuando los volvamos a necesitar. 7

Antes esta era una tarea complicada ya que no hab´ıa disponibilidad de c´odigo, pero hoy d´ıa con Internet no hay m´as excusas, cada ves es mayor la cantidad de sitios que se dedican s´olo a hostear c´odigo y controles de manera gratuita. 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 publicaci´on. Los visitantes pueden votar y el sitio premia a los que publicaron los art´ıculos m´as populares. • Cuentan con opciones avanzadas de b´ usqueda lo que facilita enormemente buscar lo que queramos, inclusive el c´odigo m´as escurridizo. • Generalmente permiten descargar el c´odigo fuente con los binarios y una explicaci´on de como instalarlo y usarlo. • 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 m´as completo y cuidado de todos. Para una lista completa buscar en el Ap´ endice B. Lo que ocurre si uno frecuenta estos sitios es que hay tanta informaci´on que la mayor´ıa parece u ´til pero quiz´a no sirva para nuestro desarrollo, pero como un en un futuro nos podr´ıa servir hacemos lo siguiente: Bajamos el c´odigo o los archivos, los guardamos en alg´ un lugar del disco y, tal como dijo Murphy, permanecer´an a mano siempre, pero cuando los necesitemos para alg´ un proyecto ser´a imposible encontrarlos. El problema radica en que no tenemos meta-data de esos archivos, son solo un nombre dentro de alg´ un directorio y nada m´as. Necesitamos alguna clasificaci´on, descripci´on, imagen de como se ven, etc. Lo m´as com´ un es armar una jerarqu´ıa de directorios para clasificar esta informaci´on, pero a medida que agregamos cosas descubrimos que hay temas ambiguos que son dif´ıciles de clasificar. As´ı vuelve aparecer el problema de la b´ usqueda. Una buena pr´actica es almacenar ese c´odigo en una librer´ıa, ordenada por categor´ıas y con la informaci´on de contexto necesaria para facilitar futuras b´ usquedas. 7

Siempre que este hecho bien...

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

31

Para que esta t´ecnica de resultado debemos utilizar una herramienta adecuada para guardar esta informaci´on, debe permitir hacer copias de seguridad de la librer´ıa (ya que es una parte vital de nuestro proyecto) y compartirla con otros miembros del equipo. En la secci´on 3.7 mostramos la herramienta definitiva y gratuita para almacenar nuestros snippets.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

2.8.

32

Seguimiento de Proyectos

Al comenzar cada proyecto, como todo parece sencillo, creemos que las cosas que hay que hacer o cualquier otra anotaci´on a tener en cuenta se puede anotar en cualquier lado 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 est´as pendientes, cuales listas ni la importancia de cada una. La soluci´on a estos problemas es hacer un seguimiento del proyecto (Project Tracking) en un lugar centralizado. El problema est´a en hacer que este seguimiento sea sencillo y no una p´erdida de tiempo ya que es simplemente un soporte para saber en que estado est´a el sistema. Veremos en el cap´ıtulo de las herramientas cuales son las alternativas y lo sencillo que es usarlas. La intenci´on es de al menos tener algo para seguir el proyecto, el desarrollo ´agil nos dice: No se debe pretender comenzar con un equipo sin experiencia en desarrollo agil, aplicar todas las reglas propuestas a su m´ ´ aximo nivel y esperar que el resultado sea bueno Se debe comenzar de a poco, mejorando lo que hacemos, incluir lentamente las nuevas t´ecnicas, aprender sus alcances y consecuencias y luego avanzar a otro nivel El problema de querer controlar todo al m´aximo detalle es que es totalmente cansador y lleva realmente m´as trabajo que hacer muchas de las cosas que se est´an monitoreando.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

2.9.

33

Crear Componentes y Controles Personalizados

Desde los comienzos de la Programaci´on Visual los desarrolladores m´as avanzados creaban controles personalizados para agregar a sus sistemas y para no tener que reescribir el mismo c´odigo varias veces o simplemente para poder agregar funcionalidad f´acilmente en un futuro. Era un grupo muy reducido de programadores ya que no era una tarea sencilla, la documentaci´on era escasa y el soporte t´ecnico m´ınimo. El salto m´as grande en el desarrollo de componentes lo dio Borland cuando decidi´o liberar el c´odigo fuente de su VCL (Visual Class Library) e incluirlo en la instalaci´on de Delphi y C++ Builder. A partir de all´ı y gracias a la abundante documentaci´on muchos desarrolladores de todo el mundo comenzaron a formar comunidades para hacer controles. La mayor´ıa eran totalmente gratuitos y de alt´ısima calidad. Luego de esto Microsoft, para no quedarse atr´as, trat´o de hacer algo parecido con Visual Basic pero el problema era que en este lenguaje no ten´ıa herencia, lo que en Delphi era heredar del componente TextBox y agregar funcionalidad, en Visual Basic era reescribir casi toda la clase. En la versi´on 6 de Visual Basic la creaci´on se simplific´o un poco, pero otras tareas como testear, distribuir y reusar el control segu´ıan siendo complicadas. Con la aparici´on de .NET todo cambi´o, ahora la pol´ıtica de Microsoft fue brindar un completo soporte para crear controles y componentes y realmente lo logr´o. Hoy d´ıa cualquier programador en 5’ puede hacer un control que herede de TextBox y deje que se ingresen s´olo n´ umeros. Adem´as la documentaci´on del SDK de .NET es excelente y la instalaci´on de nuestros controles es simplemente referenciar una dll y listo. Luego cuando se compila el programa cliente autom´aticamente se copia en el directorio del programa8 . Una gran ventaja de contar con controles personalizados es que en cualquier momento del desarrollo podemos agregar funcionalidad a los mismos f´acilmente. Generalmente se define una interfaz con el nuevo comportamiento y hacemos que la implementen nuestros controles (se define una interfaz para poder manejar controles heterog´eneos de una misma manera) Algo muy com´ un en todas las aplicaciones es la validaci´on de la entrada de los 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 est´an en estado de error o no) as´ı que atacaremos el problema permitiendo que los controles recuerden si est´an en estado de error y en caso afirmativo almacenen el mensaje que se le deber´ıa mostrar al usuario. En un principio definamos la interfaz IManejoError: 8

Se termin´ o todo el tema de registrar dll y todo eso, aunque parec´ıa s´olo una promesa m´as de Microsoft, realmente funciona, todas las instalaciones son Copiar, Pegar y listo

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

34

(*) El prefijo cp indica que son propiedades de un control personalizado y permiten encontrar estas propiedades r´apidamente desde el editor de c´odigo (para mayor informaci´on ver la secci´on 2.10 de Convenciones). Luego hacemos que nuestro TextBox la implemente y finalmente para usarlo solo necesitamos hacer la siguiente validaci´on en el formulario donde se encuentra el control:

De esta manera se puede resolver algo muy tedioso que es la validaci´on de los datos ingresados por los usuarios. Al haberlo hecho de esta forma tan gen´erica hasta podr´ıamos tener una clase que verifique si hay errores en un dado formulario y los muestre. El c´odigo ser´ıa:

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

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 identifique claramente donde est´a el problema (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 pr´actico de lo que se puede hacer con los controles personalizados. Hay algunos buenos libros sobre el tema, pero, como siempre digo, la mejor forma de aprender es mirando el c´odigo (siempre que est´e bien escrito) de alg´ un control hecho por otra persona con m´as conocimientos. La mejor opci´on es entrar a www.CodeProject.com en busca de excelentes controles para .NET y adem´as de descargar el c´odigo es interesante guardar las p´aginas que los presentan, porque generalmente tienen una explicaci´on de como funciona el control y de como se usa. La otra opci´on es ejecutar el Reflector (explicado en la p´agina 77) y desensamblar el c´odigo de alg´ un control del .NET framework como el TreeView para ver como hace uso de las opciones gr´aficas y de los eventos.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

2.10.

36

Convenciones de Nombres y Estilo

Cuando trabajamos solos es importante tener al menos algunas convenciones para que nuestro c´odigo sea m´as mantenible y estructurado. 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 despu´es de usarlas alg´ un tiempo. Entre sus usos encontramos reglas para nombrar Clases, variables, archivos de datos, archivos de c´odigo, directorios, formularios, recursos compartidos, tablas, formato de documentos, diagramas, etc. Como as´ı tambi´en pueden ser reglas que indiquen como es cada proceso del desarrollo, 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 t´erminos que ser´an usados m´as adelante: PascalCase Lleva todas las palabras que componen un nombre: en min´ usculas, concatenadas y con la primer letra en may´ usculas de cada una. Como en: CapaDatos - ExceptionHelper - ContextoSeguridad CamelCase Es igual que el anterior pero con la primer letra en min´ usculas. Como en: capaDatos - exceptionHelper - contextoSeguridad

Prefijos de los elementos m´ as comunes de .NET Namespaces En Pascal Case, sin underscores. Generalmente se como ra´ız: NombreEmpresa.NombreTecnologia Si no tenemos un nombre de compa˜ n´ıa al menos debemos ponerles nuestras iniciales para poder agrupar todo lo que hagamos y encontrarlo f´acilmente. Recordar que los acr´onimos de tres o m´as letras van en pascal case como en Xml y en may´ usculas cuando tienen 1 o 2 como en IO. Assemblies Si el assembly contiene un u ´nico namespace o si agrupa varios pero con un namespace ra´ız en com´ un, nombrar el assembly igual que ese namespace.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

37

Clases y Estructuras En Pascal Case, sin underscores, ”C” ni ”cls”. Si la clase empieza con ”I” la segunda letra debe estar en Min´ usculas sino se confundir´ıa con una Interfaz. Las clases no deben tener el mismo nombre que el name space que las contiene. Tratar de usar sustantivos y evitar abreviaturas. Colecci´ on de Clases Agregarle Collection al final del nombre de la clase que agrupa. Como en ArticulosCollection, MenuCollection. Delegates Agregarle Delegate al final del nombre del delegado. Como en CallbackDelegate, AsyncDelegate. Excepciones Agregarle Exception al final del nombre de la excepci´on. Como en SecurityException, CadaDatosException. Atributos Agregarle Attribute al final 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 final del nombre del enumerado. Poner s´olo el Nombre y si sin flags ponerlo en plural. Como en DayOfWeek, EditModes. Funciones y M´ etodos En Pascal Case, sin underscores, con excepci´on de los manejadores de eventos. Tratar de evitar abreviaturas. Las funciones y m´etodos deben diferir en algo m´as que la capitalizaci´on para no tener problemas si se lo usa desde VB.NET o alg´ un lenguaje Case-Insensitive. Propiedades y Variables Publicas En Pascal Case, sin underscores. Tratar de evitar abreviaturas.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

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. Par´ ametros En Camel Case. Tratar de evitar abreviaturas. Es posible usar si el par´ametro tiene el mismo nombre que una variable privada o protegida de la clase el prefijo p Como en pDatos, pValorInicial. Lo interesante de la u ´ltima regla es que dentro del cuerpo de la rutina encontramos asignaciones del estilo: mDatos = pDatos Identificando claramente que se est´a asignando un par´ametro a una variable local 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 m´as significativo. 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 com´ un es Res. Como aclaraci´on general podemos decir que se deben evitar, siempre que sea posible, las abreviaturas ya que complican la lectura del c´odigo. El problema est´a en que cuando uno se olvida que significa, cada vez que lee el c´odigo debe detenerse a pensar que quer´ıa decir. En cambio si escribimos los nombres completos la lectura es r´apida y objetiva. 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 b´ usqueda ¨ del buscador. Si como resultado nos dice: Usted quiso decir ... el nombre completo significa que podemos usar la abreviatura, de otra forma no. 2

Controles Un lugar donde todos usan prefijos para denominar a los objetos es en los controles es en la programaci´on visual. Una vez que uno comienza a utilizarlos los recuerda f´acilmente ya que son muy intuitivos y, junto con el ”Intellisense”, facilitan la codificaci´on y lectura del c´odigo. La siguiente tabla muestra las convenciones m´as utilizadas:

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

Control Modulo Formulario Button TextBox CheckBox RadioButton GroupBox PictureBox ListBox ListView CheckedListBox ComboBox TreeView DateTimePicker ToolBar MenuItem Label ImageList DataGrid ProgressBar RichTextBox Splitter

Prefijo mod frm cmd txt chk rad grp pic lst lvw clst cbo tvw dtp tlb mnu lbl img grd pbar rtf spl

39

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 prefijos para que el c´odigo se vuelva m´as legible. La siguiente tabla muestra algunas recomendaciones: Objeto DataSet DataRow OleDbConnection o SqlConnection OleDbCommand o SqlCommand OleDbDataAdapter o SqlDataAdapter OleDbDataReader o SqlDataReader Crystal Report

Prefijo ds dr conn cmd da rdr rpt

Ejemplo dsLocalidades drLocalidad connServidorDB cmdUpdate daClientes rdrClientes rptAtículos

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

40

Convenciones para los Mensajes del Sistema Un problema que viene desde le comienzo de la programaci´on visual es el tema de 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 ortogr´aficos, agregarles cosas, 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 soluci´on inmediata porque adem´as del costo de cambiar todas las cadenas, se corr´ıa el riesgo que el traductor cambiase algo m´as del c´odigo y el programa generado podr´ıa contener errores dif´ıciles de detectar ya que s´olo se presentan en ciertas versiones y no en otras. El golpe final vino con los services packs, porque cuando se detectaba un error en determinado programa se correg´ıa y adem´as se ten´ıa que corregir en las versiones en otros idiomas ya que el parche no se pod´ıa aplicar a todas porque quedar´ıa mensajes en m´as de un idioma. La soluci´on apareci´o del lado de los denominados archivos de recursos que vendr´ıa a ser informaci´on simb´olica incrustada dentro del programa. De esta forma no se usa el mensaje en s´ı, sino que se lo referencia con una constante simb´olica, ahora si se quiere traducir un programa basta traducir el archivo de recursos 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 definir las clases que formar´an parte del sistema de manejo de errores. En primer lugar definiremos un enumerado cuyos valores vendr´ıan a ser como las constantes simb´olicas de los archivos de recursos:

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

41

Luego definamos la clase ErrorInfo que va a contener todas las cadenas con los mensajes y la informaci´on adicional:

Adem´as del Tipo de Error y el Mensaje tenemos una bandera que indica si el error deber´ıa reportarse por mail como explicaremos en la secci´on 2.11. En la l´ınea 11 vemos que esta opci´on est´a habilitada por defecto pero se podr´ıa cambiar para cada tipo de mensaje. En la l´ınea 12 vemos que se invoca el m´etodo CargarDatos con un tipo de mensaje Msg y con par´ametros opcionales que pasan al arreglo Args:

El m´etodo es mucho m´as largo ya que contiene los mensajes de error, pero como dijimos todas las cadenas est´an all´ı y en caso de querer cambiar algo, buscamos la constante y modificamos el string correspondiente. En la l´ınea 25 de CargarDatos vemos como se podr´ıa evitar que se env´ıe un mail para determinado tipo de error. Para darle un uso pr´actico a esta idea definiremos una clase Mensaje con el m´etodo:

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

42

Este m´etodo se sobrecarg´o para que pueda recibir el tipo de mensaje o s´olo un string, la idea es que todo lo que signifique mostrar mensajes al usuario pase por aqu´ı, inclusive si es simplemente un MessageBox. Hay adem´as un arreglo de Object que se usa para pasar informaci´on extra, por 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 definici´on de las constantes cuando colocamos el par´entesis luego del nombre del m´etodo en el editor de c´odigo del Visual Studio nos aparecen todas las constantes definidas facilitando enormemente la codificaci´on.

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

2.11.

43

Manejo y Reporte Autom´ atico de Errores

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 finales 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 asignaci´on del TextBox a nuestra variable entera, nos aparece el error:

Cualquier usuario que recibe este mensaje seguramente se asustar´a, lo cerrar´a e ir´a a hacerse unos mates sin decir nada por miedo a haber hecho alg´ un l´ıo. Afortunadamente existe una forma de capturar estos errores y presentar un mensaje m´as ameno (est´a estrategia se extrajo de www.CodeProject.com).

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

44

Agregando las l´ıneas marcadas (de la 13 a la 15) y el m´etodo de las l´ıneas 6, 7 y 8, cualquier error sea cual fuere el tipo del mismo pasar´a el control al m´etodo ManejoDelError donde podremos mostrar un mensaje m´as amigable. Si no utilizamos esta forma de atrapar errores podr´ıamos poner un TRY-CATCH en nuestro m´etodo Main. Pero, o sorpresa, en ciertas ocasiones aparece la misma pantalla del principio. La explicaci´on es que el TRY-CATCH s´olo captura las excepciones del 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´e la soluci´on propuesta es una de las pocas que tenemos. Pero demos un paso m´as, un problema frecuente con cualquier sistema es que los usuarios no avisan cuando les aparecen estos errores o aunque avisen no nos pueden brindar la informaci´on de contexto requerida para identificar porque ocurri´o determinado error. La propuesta es reportar el error por mail sin que el usuario se entere. Aunque parezca complicado, mostraremos parte del c´odigo que es muy sencillo y en el CD complementario pueden encontrar todo el c´odigo. Primero creamos un HTML en nuestro proyecto y lo incluimos como recurso de la soluci´on, el mismo tendr´a variables encerradas con el s´ımbolo $ de la forma $MensajeDeError$.

Cuando ocurre un error debemos cargar la p´agina que se logra leyendo el archivo de recurso como un string para obtener el c´odigo HTML original, luego reemplazar las variables en el template con los datos reales para lo que usamos el m´etodo Replace de la clase String. Vale aclarar que esta no es la forma m´as eficiente porque se recorre el HTML n veces y se crean n string del tama˜ no del cuerpo del mensaje (donde n es la cantidad de variables), se deber´ıa hacer un parsing m´as sofisticado e ir reemplazando las variables a

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

45

medida que las encontramos, pero a los efectos del ejemplo ser´a suficiente con la forma Add hoc.

Para el envi´o de mails usamos una clase wrapper de la clase System.Web.Mail.MailMessage de la librer´ıa de .NET, el c´odigo usado ser´ıa:

El broche final ser´ıa agregarle al mail un screenshot que nos muestre la tarea que 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 c´odigo

´ ´ CAP´ITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET

46

Este m´etodo devuelve un objeto Bitmap, si queremos guardarlo en el disco este ser´ıa el c´odigo a usar:9

El mail que recibimos tiene la forma, char´an char´an:

9

Es incre´ıble la facilidad al manejar im´agenes sobre .NET, maneja los formatos m´as conocidos y los accede a trav´es de la clase gen´erica Image para abstraerse del que estamos usando.

Cap´ıtulo 3 ´ Herramientas de Desarrollo Agil para .NET ´ vistas para .NET, y todas las t´ecnicas en general, no Las T´ecnicas de Desarrollo Agil tienen el impacto deseado si las tareas que proponen se tienen que hacer manualmente, por ello veremos en esta secci´on las herramientas que dan soporte a estas t´ecnicas y las llevan un poco m´as all´a para maximizar la productividad. No daremos una descripci´on detallada de cada una sino que nos limitaremos a mostrar la funcionalidad b´asica de cada una, fomentando al lector a probarlas y a seguir la documentaci´on que las acompa˜ nan y que son muy gr´aficas y completas. La mayor´ıa de las herramientas son gratuitas y su c´odigo fuente est´a disponible en internet. Es una tarea interesante investigar el c´odigo y tratar de hacer cambios para agregar funcionalidad y ver que ocurre, porque la mejor de aprender algo en el mundo de la computaci´on es probando y teniendo mucha paciencia. En el Ap´endice B (P´ag. 97) est´an los enlaces a los sitios de cada herramienta tratada y de muchas otras otras. En el CD complementario se encuentran el c´odigo fuente y el ejecutable de cada una en las versiones disponibles a Abril de 2005.

47

´ CAP´ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET

3.1.

48

Generaci´ on Semi-Autom´ atica de C´ odigo

Por experiencia personal creo que existe una sola forma de tener ´exito con la generaci´on de c´odigo de forma autom´atica y es a trav´es de plantillas editables. Los programas que funcionan como una caja negra que uno les da la definici´on de la base de datos y generan clases para el acceso a datos sin que se pueda modificar 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 c´odigo generado los problemas compensar´an a aparecer, m´as aun, cuando cambie el esquema de la Base de datos y queramos regenerar el c´odigo se pisar´an los cambios (si es que logramos concretarlos). Por estas razones la herramienta ideal para generar c´odigo en .NET con plantillas se llama CodeSmith, es gratuita y muy usada. La herramienta es sencilla de utilizar basta definir un archivo con la plantilla y correrlo en el programa por ejemplo si queremos generar c´odigo para asignarle a variables var1, var2, var3, ..., un valor de car´acter consecutivo debemos escribir la plantilla:

Todo lo que est´a entre se ejecuta en CodeSmith porque es parte del c´odigo de la plantilla, lo que est´a fuera de estos s´ımbolos se copia literalmente al resultado. El s´ımbolo 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´a los siguientes pasos: 1. Busca en el directorio actual un archivo ”.build”. 2. Si no lo encuentra muestra el error. 3. Si hay s´olo un archivo ”.build” lo ejecuta. 4. Si hay m´as de un archivo ”.build”: a) Si alguno se llama ”default.build” lo ejecuta. b) Si ninguno se llama ”default.build” muestra un error.

´ CAP´ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET

70

Cruise Control .NET Es herramienta gratuita que se ubica a un nivel mayor de abstracci´on en cuando a automatizaci´on que NAnt. Es m´as fiel a lo explicado en la secci´on 2.6 de Integraci´on 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 versi´on 0.9, es muy f´acil de instalar y configurar gracias a la documentaci´on que lo acompa˜ na que es muy completa. La caracter´ıstica m´as interesante es que genera reportes de cada paso, ya sean de compilaci´on, testing, integraci´on, validaci´on, etc. Los mismos se pueden ver desde una p´agina web o se le puede pedir al sistema que los envi´e por mail en cada integraci´on.

Soporte Visual Studio 2005 Lo m´as asombroso de lo que ser´a el nuevo entorno de Microsoft es la integraci´on completa de todas las tareas de desarrollo. Visual Studio 2005 incluir´a soporte desde el modelado de clases, el testing, la documentaci´on hasta la compilaci´on autom´atica. En el Cd complementario se incluye un articulo disponible en la p´agina oficial del VS.NET 2005 que indica las nuevas caracter´ısticas. Un diagrama que encontramos all´ı muestra como est´a planteada la integraci´on:

´ CAP´ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET

3.7.

71

Almacenar Nuestra Librer´ıa de C´ odigo y Controles

Durante a˜ nos hubo aplicaciones para guardar snippets de c´odigo y ordenarlos, la mayor´ıa comerciales, pero para .NET existe un programa que a todos estos los deja kil´ometros atr´as y se trata de Code Library for .NET de Fish.NET. El programa es chino y parece ser que muestra que el fuerte de los chinos, como todos dicen, est´a en perfeccionar las cosas no en inventarlas, porque este programa es la perfecta uni´on de todas las ideas buenas para almacenar c´odigo e informaci´on que existen. Sinceramente cuesta mucho explicar todo lo que hace lo mejor es probarlo y darnos cuenta que est´a hecho para nosotros. Adem´as de completo tiene un muy c´omoda y usable interfaz de usuario como se muestra en la figura:

Pantalla principal del CodeLib Algunas de las caracter´ısticas son: • Permite almacenar el c´odigo en varias bases de datos y hasta con distintos formatos 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.

´ CAP´ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET

72

• Guarda las descripciones, c´odigo, archivos adjuntos e im´agenes dentro de la base as´ı que para llevarlo a otro lado es extremadamente f´acil. • Compacta las Bases de Datos y hace Backups autom´aticos de las mismas. • Podemos editar la descripci´on de cualquier item con el editor embebido. • Podemos bajar p´aginas Web con el download manager y guardarlas como parte de alg´ un item. • Se pueden bajar del mismo sitio 4 bases de datos con c´odigo, muy completas, para 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 a´ un m´as c´omodo el trabajo ya que aparecen los snippets como una ventana m´as en el IDE. • las posibilidades de B´ usqueda son muy Avanzadas. • 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

´ CAP´ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET

73

Men´ us Contextuales Este es un perfecto ejemplo de como deben ser los programas. Est´an cuidados todos los detalles y maximizada la funcionalidad. Una verdadera joya.

´ CAP´ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET

3.8.

74

Seguimiento de Proyectos

Seg´ un lo explicado en la t´ecnica de la secci´on 2.8 el seguimiento se debe hacer de una manera autom´atica, accesible y que permita compartirla entre los miembros del desarrollo. Las dos excelentes alternativas que nos ofrece el mundo open source son:

eGroupWare Caracter´ısticas Generales: • Es el m´as conocido. • Es uno de los 10 con mayor actividad de SourceForge. • Es agradable y muy f´acil de usar • Excelente manejo de calendarios (ver imagen) • Totalmente modular es muy sencillo poner y sacar partes • Existen gran cantidad de m´odulos desarrollados que abarcan desde subsistemas de 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 b´asicas como el seguimiento de Bugs.

´ CAP´ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET

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 m´as recomendable para proyectos de desarrollo pero cuenta 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 f´acilmente.

´ CAP´ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET

76

Excel Si estos sistemas nos parecen complicados por su manejo o instalaci´on al menos podemos utilizar el Excel que aunque no sea muy respetado en el mundo acad´emico es tan general que lo podemos adaptar para solucionar muchos problemas y el seguimiento de proyectos es uno de ellos. La idea es definir hojas (ya sea por m´odulos o importancia) con las distintas actividades 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 f´ormulas par a facilitar las tareas. El u ´ltimo paso ser´ıa incluir programaci´on a trav´es de Visual Basic para formar nuestro propio sistema de Project Tracking. Suena interesante no ?

´ CAP´ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET

3.9.

77

Revisi´ on y An´ alisis de C´ odigo

Reflector Todo lo bueno que trae .NET seguro que se paga por otro lado, uno de ellos es la protecci´on o privacidad del c´odigo. Al igual que pasa en otros lenguajes interpretados, como Java, es muy f´acil desensamblar una dll o un exe de .NET es tan sencillo como bajarse el Reflector de la p´agina oficial de Lutz Roeder, levantar el assembly y elegir el m´etodo o propiedad a desensamblar.

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 c´odigo es algo que fue contemplado por Microsoft desde el comienzo. Para tratar de reducir el problema incluy´o junto con el VS.NET un ofuscador de c´odigo para que las empresas puedan proteger la propiedad intelectual de sus programas. Algo m´as interesante es que MS no protegi´o las librer´ıas b´asicas del framework, dejando las puertas abiertas para que los desarrolladores extraigan informaci´on sobre buenas pr´acticas o vean como se implementan los controles base de los WinForms.

´ CAP´ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET

78

Microsoft FxCop Si pensamos que programamos bien ... basta con darle nuestro c´odigo a este programa de Microsoft para decepcionarnos. El programa analiza los assemblies que le damos utilizando instrospecci´on y verifica 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´ıas del .NET Framework. 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 Secci´on 3.4 nos muestra:

Pantalla Principal del FxCop

´ CAP´ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET

79

En total encontr´o 675 posibles problemas. Es tal vez muy exigente por defecto pero lo podemos cambiar si vamos a la solapa de reglas y desactiva las que no nos parecen convenientes.

Solapa de Selecci´ on de Reglas Tambi´en podemos hacer doble click sobre cualquiera de los errores para ver una descripci´on detallada del mismo, a que regla pertenece y la raz´on de porque se lo considera un error o posible error.

Pantalla con el Detalle de un Error

´ CAP´ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET

3.10.

80

Profilers

Entre las herramientas avanzadas que un programador deber´ıa conocer se encuentran los profilers. Los lenguajes actuales como trabajan en un nivel de abstracci´on muy alto nos llevan a escribir c´odigo muy ineficiente y dif´ıcil de escalar. Si sumamos esto a que las maquinas actuales tienen una velocidad incre´ıble cuando desarrollamos el sistema y lo probamos todo anda de maravillas pero basta que el sistema est´e en producci´on para que nos demos cuenta que cuando se conectan varias personas o se hacen algunas cosas a la vez, el sistema parece una tortuga... Este es un escenario aun m´as com´ un en .NET que tiene un alt´ısimo nivel de abstracci´on a la hora de programar, esto se traduce en muchas capas intermedias de software, por lo tanto una instrucci´on en .NET pueden ser cientos de miles en el sistema operativo y en el procesador. Para controlar el uso de estos recursos (memoria y CPU) nacieron los profilers que hacen un seguimiento l´ınea por l´ınea, m´etodo por m´etodo y clase por clase, para que podamos encontrar el lugar exacto con problemas de performance.

CLR Profiler Este es un excelente profiler gratuito que ofrece Microsoft y hasta contamos con el c´odigo fuente. Esta orientado principalmente a ser un memory profiler y hace su tarea realmente bien. En el CD complementario se incluye el manual de este programa que nos indica en que contexto usarlo y c´omo hacerlo. 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.

´ CAP´ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET

81

NProf NProf es un profiler de tiempo de ejecuci´on, es opensource y se encuentra cerca de su versi´on 1.0. Tiene una gran cantidad de opciones pero no es muy gr´afico (al menos por ahora) cuesta encontrar indicios de rendimiento bajo. Nos muestra cuantas veces se ejecuto cada m´etodo del c´odigo que estamos analizando. Se integra perfectamente con el Visual Studio.NET y podemos ejecutarlo directamente desde all´ı. En el CD complementario se encuentran los ejecutables y el c´odigo fuente de este programa.

Compuware DevPartner Studio Sin lugar a dudas el mejor de todos los profilers. Cuenta con an´alisis est´atico de c´odigo, profiling de alocaci´on, profiling de tiempo de ejecuci´on, captura todos los errores y nos muestra donde ocurrieron, permite hacer profiling de aplicaciones distribuidas y mucho m´as. Es muy funcional y totalmente gr´afico. Muestra en tiempo real la memoria alocada, cuales son los elementos con mayor cantidad de instancias, cuando se ejecuta el GC, etc. Mostremos a continuaci´on un gr´afico del profiler de memoria en tiempo real:

´ CAP´ITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET

82

Lo bueno es que Compuware ofrece una versi´on Community Edition que se encuentra 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 profiler pero que tiene una funci´on muy similar es NPerf. Esta herramienta provee un framework para hacer tests comparativos y mostrar los resultados. La idea es que escribamos el c´odigo para hacer la misma cosa de diferentes formas y el framework ejecutar´a estos m´etodos tantas veces como le digamos, para diferentes tama˜ nos de muestra y luego representar´a los promedios de los tiempos resultantes. En la figura mostramos una comparaci´on entre el m´etodo Contains de las diferentes colecciones que provee .NET.

Cap´ıtulo 4 Check Lists de los Temas Tratados En este Ap´endice se incluyen consejos y buenas pr´acticas a tener en cuenta cuando utilicemos alguna de las t´ecnicas o herramientas propuestas en esta Tesis. Si las tenemos en cuenta es m´as sencillo llegar al resultado esperado y nos evitar´a encontrarnos con sorpresas desagradables.

4.1.

Control de C´ odigo Fuente

X Usar un sistema de control de c´odigo fuente para proteger el c´odigo y llevar un historial irrefutable de los cambios. X Evaluar antes de comenzar las diferentes alternativas y seleccionar la que mejor se adapte al proyecto. X Aprender a usar los comandos avanzados de Tag, Branch y Merge. X Poner todos los elementos del desarrollo bajo control de versiones, inclusive la documentaci´on. X Documentar los cambios cuando se hace un Commit para que el historial sea m´as entendible. X Hacer Tags frecuentemente, sobre todo antes de cambios importantes o en puntos a los que podemos necesitar volver. X Tratar de usar el sistema control de c´odigo fuente junto con un sistema para Project Tracking (aunque sea usar convenciones para los Tags). X Crear un Branch siempre que hagamos una entrega del sistema. Si nos piden alg´ un cambio ser´a m´as sencillo de realizar si nos manejamos de esta forma.

83

CAP´ITULO 4. CHECK LISTS DE LOS TEMAS TRATADOS

4.2.

84

Refactoring

X No dejar las cosas que no est´an del todo bien hasta que se revelen contra nosotros, tratar de cambiarlas antes. X Si encontramos una negativa al pedir autorizaci´on para hacer refactoring, y nos parece necesario hacerlo, debemos encontrar la forma de hacerlo de todos modos. X Tratar de hacer peque˜ nos refactorings y de a uno a la vez. X Hacer una lista de los pasos que lleva cada refactoring y marcarlos a medida que avanzamos. X Asegurarse que los cambios introducidos mejoran la calidad del sistema y no la empeoran. X Llevar una lista de los cambios que quisi´eramos hacerle a cualquier parte del sistema para no olvidarlos y para recurrir a ella cuando buscamos que mejorar. X Pensar cuidadosamente que hacer si el refactoring es muy complicado o afecta a una parte cr´ıtica del sistema. X Hacer un Branch en el sistema de control de versiones si el refactoring es grande o nos va a llevar m´as de un d´ıa. X Testear al finalizar 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 atr´as.

4.3.

Testing

X Escribir tests de unidad (unit-tests) para la mayor parte del c´odigo que podamos. X Escribir los test a medida que avanzamos. No dejarlos para un ma˜ nana que nunca llegar´a. X Asegurarse que el nuevo c´odigo pasa todos los test de regresi´on antes agregarlo al sistema de control de c´odigo fuente. X Usar una herramienta como NUnit para hacer del testing un proceso sencillo y repetible. X Los Tests tambi´en deben estar bajo el sistema de control de versiones. X Hacer Refactoring, en lo posible, cuando se tenga una bater´ıa de tests para poder validar lo que cambiamos.

CAP´ITULO 4. CHECK LISTS DE LOS TEMAS TRATADOS

4.4.

85

Documentaci´ on

X Usar el ”Vea Tambi´en” para navegar f´acilmente por la informaci´on relacionada. X Usar Tablas de Contenidos, Indices, B´ usqueda e Links para que sea m´as sencillo localizar la informaci´on. X La mayor´ıa de los temas de ayuda deben ser cortos y focalizados. X Utilizar gr´aficos, no s´olo texto (respetar la regla: ”una imagen vale m´as que mil palabras”). X Proveer una manera para que los usuarios puedan darnos feedback f´acilmente (ya sea a trav´es de un mail o guardando informaci´on en un archivo y analizarla luego). X Imprimir las partes m´as usadas de la documentaci´on para facilitar la lectura. X Procurar que la ayuda sea sensitiva al contexto y orientada a la tarea que se est´a realizando. X Cuando se est´a documentando algo pensar en c´omo se va a actualizar la documentaci´on cuando las cosas cambien.

4.5.

Compilaci´ on e Integraci´ on

X Usar una herramienta de compilaci´on e integraci´on continua como (como NAnt o Cruise Control.Net) para hacer de este proceso algo simple y repetible. X Evaluar varias herramientas de generaci´on y quedarse con la que mejor se adapte al proyecto y al bolsillo. X Integrar la aplicaci´on de forma regular (generando adem´as la documentaci´on y ejecutando los casos de Test). Muchos recomiendan que diariamente es lo ideal. X Hacer backups de las salidas producidas en la generaci´on diaria (no olvidar la DB). X La integraci´on no es s´olo de los m´odulos del sistema sino que abarca todos los artefactos que componen el desarrollo como: las bases de datos, documentaci´on, tests, instalaciones, backups, etc. X Tratar de hacer integraciones continuas para asegurar que el sistema sigue estable y los conflictos se detectan a tiempo.

CAP´ITULO 4. CHECK LISTS DE LOS TEMAS TRATADOS

4.6.

86

Generaci´ on de C´ odigo

La generaci´on de C´odigo es una herramienta desestimada por la mayor´ıa de los desarrolladores y en esta tesis mostramos lo u ´til que es, pero en caso de decidirse a usarlo tener en cuenta: X Cuando nos encontramos con una gran cantidad de tareas repetitivas al escribir c´odigo considerar usar una herramienta que genere ese c´odigo. X Evaluar varias herramientas de generaci´on de c´odigo hasta encontrar la que mejor encaje en nuestro proyecto (aqu´ı se mostr´o CodeSmith que es gratuito y f´acil de usar, pero hay otras alternativas muy completas). X Utilizar las herramientas de control de versiones sobre las entradas de los generadores y no sobre las salidas de los mismos. X Analizar sinceramente cu´anto tiempo ahorramos si escribimos directamente la soluci´on y cu´anto si hacemos una plantilla para generar el c´odigo. X Pensar como hacer si se debe escalar a una herramienta m´as completa.

4.7.

Convenciones

X Buscar en internet convenciones espec´ıficas para el lenguaje utilizado y seleccionar alguna. X En la p´agina msdn de Microsoft podemos encontrar muchas convenciones en lo referido a .NET inclusive las mismas que uso el equipo del framework. X Tener al menos algunas convenciones bien documentadas. X Asegurarse de que los miembros del equipo conocen bien las convenciones y la raz´on de por qu´e se usan. X Tomarse el tiempo para discutir las convenciones analizando los distintos puntos de vista. X Fomentar a los miembros del equipo de desarrollo a proponer otras convenciones o a mejorar las existentes. X Probar el FxCop para detectar autom´aticamente los problemas de nombres y prestar atenci´on a las justificaciones de porque est´a mal lo que hacemos.

CAP´ITULO 4. CHECK LISTS DE LOS TEMAS TRATADOS

4.8.

87

Generales

Por u ´ltimo citaremos algunos consejos recopilados de distintos libros, de internet o de la filosof´ıa misma del desarrollo ´agil. Es bueno tenerlos siempre en mente: X Tratar las excepciones como tales y no tratar de que todo encaje en nuestro esquema general. X Desconfiar de cualquier parte del sistema porque todo puede fallar inclusive la instrucci´on m´as absurda. X No prometer cuanto tardaremos en hacer algo que nunca hicimos o no entendemos del todo porque caeremos presos de nuestras palabras. X Dise˜ nar las clases pensando en su uso, hacer un croquis con las l´ıneas que usar´ıa el cliente de la clase y no agregar funcionalidad porque s´ı. X No creer en las propagandas de las nuevas tecnolog´ıas hasta no entrar en contacto con ellas y comprobar que son realmente buenas. X Nunca usar la u ´ltima tecnolog´ıa disponible, usar la ante u ´ltima y monitorear como evoluciona la u ´ltima para estar en tema y no sorprendernos cuando se convierta en un est´andar. X Debemos comprender que ninguna metodolog´ıa es universal. Usar el sentido com´ un para extraer lo mejor de cada una, tomar partes de otras y por u ´ltimo quedarse con las t´ecnicas que dieron resultado (si no sirven simplemente descartarlas).

Cap´ıtulo 5 Conclusiones Luego de este gran paseo, aunque resumido, por el mundo de la teor´ıa y la pr´actica del desarrollo ´agil espero que hayan podido comprender un poco m´as lo imperioso que 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 a˜ nos como la programaci´on en cascada, documentaci´on excesiva, el sobredise˜ no, la poca comunicaci´on, el escaso feedback, el ”do it yourself”, etc . Cada vez m´as personas est´an de acuerdo con esto. Las grandes empresas est´an cambiando sus pautas de desarrollo por metodolog´ıas m´as livianas. inclusive Microsoft sac´o los siguientes libros referidos a desarrollo ´agil: X Extreme Programming Adventures in C#. [Sch04] X Test-Driven Development in .NET. [NV04] X Agile Project Management with Scrum. [Jef04] El futuro de la programaci´on para la mayor´ıa est´a m´as que claro y se resume en una palabra: .NET. Los que no est´an de acuerdo es porque no han desarrollado sobre esta plataforma, inclusive los mismos desarrolladores de Java reconocen las grandes virtudes de .NET. Para poder aprovecharlo al m´aximo no podemos dejar pasar por alto la cantidad de herramientas, c´odigo y ayuda que nos brinda internet y que son totalmente gratuitas. Creo que el secreto est´a en ver c´omo desarrollan aplicaciones otras personas con m´as experiencia y tomarlo como base para comenzar nuestros proyectos. Luego investigar c´omo mejorar estas ideas y adaptarlas para que sean ´optimas para nuestra forma de trabajo. Finalmente automatizar con plantillas de c´odigo todo lo que se pueda1 y el tiempo 1

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

88

CAP´ITULO 5. CONCLUSIONES

89

que ahorramos al no escribir nosotros todo el c´odigo lo podamos invertir aprendiendo m´as, mejorando el sistema o haciendo refactoring de las plantillas existentes para documentarlas, extenderlas, etc. Los que en alg´ un momento se imaginaron un mundo con componentes de todo tipo y al alcance de la mano, de f´acil integraci´on, interacci´on entre diferentes lenguajes, 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 com´ un de ejecuci´on que siempre se necesito, que con CORBA no tuvo ´exito, pero que Microsoft logr´o con su framework. Sigo insistiendo en que la clave est´a en la automatizaci´ on o semi-automatizaci´ on 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 f´acil de automatizar). Steve McConnell escribi´o en su libro ”Code Complete 2da Edici´on” [McC04] que hay dos tipos de buenos programadores, para distinguirlo basta con darles una tarea de 5 Hs. y ver como se comportan: X Uno se sienta, piensa el problema, lo diagrama y lo implementa durante las 5 Hs. X 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 soluci´on. 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 m´as gen´erico como que el importador tenga meta-datos sobre el formato del archivo a leer y la tabla en donde insertarlo. La decisi´on como siempre depende del contexto; si estamos seguros que lo vamos a usar una vez para importar los datos de un u ´nico archivo quiz´a la opci´on ad hoc sea la mejor, en cambio si tenemos varios archivos con diferentes formatos y logramos hacer 2

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 float donde deber´ıa decir int y adem´as del 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´a y si aparece alg´ un error se 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 insert´ andolo en una tabla determinada

CAP´ITULO 5. CONCLUSIONES

90

algo suficientemente gen´erico habremos solucionado el problema para todas las veces que en el futuro tengamos que importar algo de un archivo de texto a una base (y cr´eanme que lo van a necesitar). Con respecto a .NET tenemos que entender que marc´o un antes y un despu´es en el desarrollo de sistemas y en la forma de programar. No entender los alcances de esta revoluci´on nos cerrar´a muchas puertas en el futuro 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 Inter´ es sobre Desarrollo Agil

Muchos temas temas de actualidad no fueron cubiertos en esta tesis por cuestiones de tiempo y espacio. Es interesante buscar informaci´on de los siguientes temas ya que pueden ayudar a nuestra productividad y a nuestra experiencia: T´ ecnicas no tratadas • Abstracci´on de Pantallas Comunes con Formularios Heredados. • Pair Programming. • Patrones de Dise˜ no. • Construcci´on de Tablero de Comandos para el soporte de decisiones. • Logging y Trace de Aplicaciones. • Consejos para la Creaci´on de Interfaces de Usuario. Buscar info en www.JoelOnSoftware.com Herramientas no tratadas • Extensi´on del Visual Studio con Macros y Addins. • Usar Componentes de Correcci´on Ortogr´afica. • Creadores de Instalaciones.

Ap´ endice A Reflexiones Sobre el Desarrollo de Software A.1.

Systemantics

Aunque el comportamiento de los sistemas complejos est´a condicionados por el CAOS 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 m´as r´apido, mas f´acil y mejor de lo que podr´ıamos hacerlo nosotros. Pero si instalamos un sistema, es muy probable que encontremos que nuestro tiempo y esfuerzo se va instal´andolo, configur´ andolo y nada m´ as. Aparecer´an nuevos problemas con la sola presencia del nuevo sistema. Una vez instalado, no se ira m´as, sino que crecer´ a y lo abarcar´ a todo. Comenzar´ aa hacer cosas extra˜ nas y sorprendentes, fallar´ a de formas que nunca pensamos que fueran posibles; inclusive se opondr´ a a su funci´ on original. Nos distorsionar´a la perspectiva y nos har´ a olvidar el objetivo inicial que ten´ıa el sistema. Nos pondr´a ansiosos y lo forzaremos para que trabaje sea como sea. Eventualmente dar´a alg´ un resultado y nos alegraremos creyendo que es lo 1 que siempre quisimos. En este punto llegamos al m´aximo de la invasi´ on... hemos sido absorbidos por el sistema... ahora somos gente de sistemas. 1

Aunque lo que terminamos consiguiendo era mas f´acil y econ´omico hacerlo antes de implementar el sistema, no importa, porque nadie recuerda como era antes.

91

´ APENDICE A. REFLEXIONES SOBRE EL DESARROLLO DE SOFTWARE

92

Lo mas interesante es que el libro est´a escrito en el a˜ no 1978 y esta cita tiene hoy mas vigencia y sentido que en aquella ´epoca porque los sistemas actuales abarcan todo y son cada vez m´as complejos, convirti´endose en campos minados llenos de bugs, esperando para explotar.

Las leyes que m´ as se destacan de las citadas en el libro son: • Si algo puede salir mal, saldr´a mal. (ley de Murphy’s) • Los sistemas en general trabajan mal o directamente no lo hacen. • Los sistemas complicados rara vez exceden el 5 % de eficiencia. • 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 alg´ un momento se detectan). • Los sistemas pueden fallar en un n´ umero infinito de formas. • Los sistemas tienden a crecer, y cuando crecen, desplazan todo lo que est´a en su camino. • Cuando los sistemas crecen en complejidad, comienzan a oponerse a la funci´on original que deb´ıan realizar. • Cuando los sistemas crecen en tama˜ no, pierden funcionalidad b´asica. • M´as grande es el sistema, menos las cosas que hace bien. • Los sistemas independientes duran m´as y funcionan mejor. • Los sistemas complejos presentan comportamientos complejos e imprevisibles. • Los sistemas colosales fomentan a que se produzcan errores colosales.

A.2.

Buen Software: Programaci´ on o Gerenciamiento de Personas ?

Aunque en esta Tesis nos concentramos en la construcci´on de sistemas no debemos 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 programaci´on se trata s´olo un 15 % de comunicaci´on con la computadora y un 85 % de comunicaci´on con otras personas. Un programador promedio pasa nada m´as que un 30 % trabajando solo.

´ APENDICE A. REFLEXIONES SOBRE EL DESARROLLO DE SOFTWARE

93

Sin embargo encontramos que lo que se necesita es un punto medio, no se puede hacer un sistema complejo si contamos s´olo con buenos administradores u gerentes; ni tampoco se lo puede hacer simplemente con buenos programadores, se necesita algo intermedio, porque por m´as bueno que sean los programadores si los gerentes no les pueden encontrar la funci´on adecuada y motivarlos, la cosa no va.

A.3.

Mantenibilidad: Problema o Bendici´ on ?

En la teor´ıa escuchamos constantemente que los buenos sistemas se identifican por su bajo mantenimiento. Luego se deduce que el objetivo para tener un buen sistema es evitar o reducir el mantenimiento, pero en la pr´actica esto no tiene el menor sentido, porque los requerimientos 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 coraz´on del sistema, el cambiar cosas constantemente. Los sistemas de los bancos, los de las tarjetas de cr´edito, todos ellos est´an en constante mantenimiento y no por eso se los puede considerar malos sistemas... Tampoco queremos fomentar la idea que el mantenimiento es la salvaci´on, simplemente rescatar esta idea para ser un poco m´as conscientes cuando hablamos de mantenimiento y pensar que no es tan malo despu´es de todo.

A.4.

Desarrollo Web: La Soluci´ on Ideal o una Opci´ on m´ as ?

Si existiese la moda del desarrollo seguro que estar´ıa por el lado del Desarrollo Web. Todo el mundo quiere su p´agina web, toda empresa que se precie tiene que tener su Intranet, los Bancos deben poder operar por Internet, etc. Pero muchas veces no se analiza si es la mejor soluci´on o no. Adem´as, como la Ingenier´ıa del SW anuncia con bombos y platillos que es m´as econ´omico y m´as r´apido que el desarrollo de aplicaciones de escritorio, les da a los gerentes el argumento ideal para tomar la decisi´on de encarar los proyectos de la empresa con Desarrollo Web. Como todo, el Desarrollo Web no es la mejor soluci´on para todo, en mi opini´on es 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´ıcil de mantener el estado, el manejo de errores,

´ APENDICE A. REFLEXIONES SOBRE EL DESARROLLO DE SOFTWARE

94

el problema si el usuario presiona dos veces un bot´on, problemas de compatibilidades 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 m´as prudente y efectivo proveer consultas v´ıa Web y actualizaci´on a trav´es de aplicaciones de escritorio (por algo SAP y las grandes empresas de SW administrativo conf´ıan en el modelo cliente-servidor com´ un y corriente que demostr´o ser m´as que efectivo durante a˜ nos).

A.5.

N´ umeros y Estad´ısticas para Reflexionar

Actualmente los proyectos son cada vez m´as complejos y generalmente menos exitosos, aqu´ı tenemos algunos gr´aficos que nos dan n´ umeros concretos sobre los resultados de los desarrollos:

Fuente de esta informaci´on: The Standish Group Hay adem´as n´ umeros interesante que nos abren la mente del esfuerzo requerido para hacer sistemas colosales como Windows, por ejemplo: Windows 2000 tiene m´as de 50 millones de l´ıneas de c´odigo. SQL Server tiene mas o menos 1.5 millones de l´ıneas de c´odigo. SAP fue desarrollado por 4200 Ingenieros de SW y tiene 37 millones de l´ıneas de c´odigo. Mostremos ahora cual es el porcentaje de las funciones que realmente se usa en la mayor´ıa de los sistemas.

´ APENDICE A. REFLEXIONES SOBRE EL DESARROLLO DE SOFTWARE

95

Este gr´afico indica claramente porqu´e el desarrollo ´agil fomenta el interactuar constantemente con el cliente para ver que es lo que realmente quiere y no desarrollar funciones que nunca usar´a.

A.6.

Qu´ e Significa ser un ’Mejor Desarrollador’ ?

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 m´ as del universo del software para explorar, alg´ un nuevo lenguaje que aprender o alguna nueva herramienta para probar. 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´ıa que un buen desarrollador es aquel que se adelanta a los problemas. El que cuando esta dise˜ nando o programando algo se imagina las cosas que pueden pasar y que podr´ıan poner en peligro el sistema o llegar complicarlo. La analog´ıa perfecta esta dada por el juego de ajedrez. En ´este cuando empezamos a jugar no pensamos demasiado los movimientos y s´olo vemos uno o dos hacia adelante, 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´ıa si algo cambia o como afectar´ıa eso a lo que ya hicimos.

´ APENDICE A. REFLEXIONES SOBRE EL DESARROLLO DE SOFTWARE

96

Luego en los proyecto reales si uno no prev´e los cambios o simplemente no imagina que podr´ıa pasar si el usuario toca aqu´ı o all´a, aparecer´an errores por todos lados y el tiempo perdido en debugging ser´a excesivo. Lo que nos deja muy mal parados y como dice el dicho: ”Hazte fama y ´echate a dormir”, o sea, nos va a costar cambiar la opini´on de los dem´as hacia nosotros despu´es de esto.

Ap´ endice B ´ 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 C´ odigo www.SourceForge.net La p´agina mas destacada de desarrollo open source que 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 p´agina. Si se necesita cualquier programa Open Source, con c´odigo y todo conviene empezar buscando por ac´a. www.CodeProject.com Indudablemente la p´agina m´as trabajada de desarrollo en .NET y otros lenguajes. Contiene gran cantidad de art´ıculos, todos editados, con ranking, en una palabra: excelente. www.ElGuille.info La mejor p´agina de habla hispana con art´ı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 u ´ltima tecnolog´ıa.

97

´ ´ APENDICE B. RECURSOS UTILES

98

www.PlanetSourceCode.com Sitio con gran cantidad de c´odigo fuente y controles pero como no est´an muy editados cuesta un poco mas buscar la info, pero si buscamos algo dif´ıcil de hacer no importa 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 p´agina tiene partes en los dos idiomas. Se instala el programa y despu´es se bajan las bases de datos que contienen el c´odigo fuente. Se pueden crear nuestras propias bases para ordenar el c´odigo ya existentes.

B.2.

´ Informaci´ on sobre Desarrollo Agil

www.ExtremeProgramming.com La p´agina oficial de esta metodolog´ıa de desarrollo ´agil, a primera vista no parece muy completa ni actualizada pero contiene informaci´on de alt´ısima calidad y se puede descargar gran parte del sitio en un s´olo ZIP. www.JoelOnSoftware.com La p´agina oficial de un gur´ u en el desarrollo de sistemas. Encontramos grandes consejos y discusiones sobre los temas m´as actuales, en especial se destaca un libro sobre interfaces de usuario muy sencillo y f´acil de leer. OOP Criticism P´agina dedicada a juntar cr´ıticas constructivas de la programaci´on orientada a objetos. Es interesante visitarla 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 P´agina dedicada a la generaci´on autom´atica de c´odigo, gran cantidad de articulos y un listado muy completo de las herramientas ordenadas por lenguaje.

´ ´ APENDICE B. RECURSOS UTILES

99

www.LarkWare.com P´agina oficial de Mike Gunderloy actualizada diariamente, contine excelente informaci´on de u ´ltimo momento que se puede descarcar a trav´es de un RSS. Todos los d´ıas hace un resumen de los temas de mayor resonancia o de nuevas aplicaci´ones que van apareciende. www.EggHeadCafe.com Aunque el nombre parezca poco serio esta p´agina agrupa una gran cantidad de desarrolladores cubriendo temas de .NET, Java y VB6. Cuenta adem´as con excelentes recursos como iconos y enlaces interesantes. www.TestDriven.com P´agina dedicada a tratar este modo de desarrollo con mucho material y nos permite bajar presentaciones y articulos. www.DevDays.com.ar

P´agina oficial de la confenciaria de .NET m´as importante organizada por Microsoft, all´ı encontraran los archivos de las presentaciones que cubren algunos de los temas tratados en esta tesis.

En el CD complementario encontrar´an un html con much´ısimos m´as enlaces y con direcciones de p´aginas que contienen directorios que se actualizan constantemente.

B.3.

Direcciones de las Herramientas Tratadas

Control de Versiones y Programaci´ on Concurrente 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

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

´ ´ APENDICE B. RECURSOS UTILES

MBUnit: http://mbunit.soureforge.net

Generaci´ on de Documentaci´ on a Partir del C´ odigo NDoc: ndoc.soureforge.net VB.DOC: vbdoc.soureforge.net Documentor: www.lutzroeder.com

Generaci´ on e Integraci´ on Continua NAnt: http://nant.soureforge.net NAnt Pad: http://www.nantpad.com CruiseControl.NET: ccnet.thoughtworks.com

Generaci´ on Autom´ atica de C´ odigo CodeSmith: http://www.ericjsmith.net/codesmith

Librerias de C´ odigo y Controles CodeLib: http://myweb.hinet.net/home4/s630417/

Seguimiento de Proyectos e-Groupware: http://www.egroupware.org DorProject: http://www.dotproject.net FogBugz: http://www.fogcreek.com/FogBugz

An´ alisis de C´ odigo Reflector: http://www.lutzroeder.com FxCop: http://www.gotdotnet.com

Profilers CLR Profiler: http://www.microsoft.com DevPartner Studio: http://www.compuware.com Nperf : http://www.dotnetwiki.org

100

´ ´ APENDICE B. RECURSOS UTILES

B.4.

101

Contenido del CD Complementario

En el Cd complementario se incluyen todas las herramientas tratadas en esta tesis, junto con mucha informaci´on sobre las t´ecnicas y sobre el desarrollo ´agil en general. En el directorio ra´ız se encuentra el ejecutable Presentación.exe que nos permite 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 clasificadas de la misma forma mostrada en la tesis. En el directorio Material hay mucha informaci´on sobre los temas tratados en esta Tesis y sobre el desarrollo ´agil en general. Adem´as encontrar´an art´ıculos de las p´aginas citada como: www.CodeProject.com, www.CSharpCorner.com, www.Larkware.com, www.CodeGeneration.net, etc. En el directorio Componentes est´a el c´odigo fuente de los Controles y Componentes m´as populares de .NET.

Agradecimientos

Quiero agradecer sobre todo a mi familia quienes hicieron posible que haya llegado hasta aqu´ı y que con su motivaci´on y paciencia hicieron posible que pueda dedicarme a mi gran vocaci´on que es la computaci´on. Por que cuando todo parec´ıa negro me iluminaron. 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 compa˜ neros que pese a todas mis locuras y mi fanatismo me aguantaron siempre y me dieron fuerzas para terminar esta etapa y seguir adelante. Gracias por las tardes de mate, pr´acticos y charlas que tanto se extra˜ nan cuando uno 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 ense˜ narlo. Yo comprob´e que es verdad con esta Tesis que me dej´o mucho. Por eso quiero agradecer especialmente 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´ıble conocimiento y desde su sencillez me ha ense˜ nado a ver el mundo de la Programaci´on y de la Computaci´on en general de una manera u ´nica. Mucho del contenido de la tesis est´a influenciado por sus geniales ideas y por nuestras entretenidas charlas. Gracias a la mujer que espero me acompa˜ ne toda la vida. Bah´ıa Blanca Abril, 2005

Marcos A. Meli

102

Bibliograf´ıa

[Bec99] Kent Beck. Extreme Programming Explained. Addison Wesley, 1999. El libro m´as popular de Extreme Programming escrito por uno de sus pioneros. Tiene su fama bien ganada porque es entretenido y nos ayuda a abrir los ojos justificando 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´ıa de desarrollo, indicandonos como no caer presos de nuestras propias 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 tambi´en los ”AntiPatterns” que vendr´ıan a ser consejos sobre como no encarar o solucionar los 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 m´as buenos que seamos programando no alcanza, que necesitamos saber defendernos junto con nuestro equipo de desarrollo de los deadlines, cambios en requerimientos, cambios en las t´ecnolog´ıas, etc. [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.

[Gla02]

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´ıa del SW. 103

´ ´ APENDICE B. RECURSOS UTILES

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 bas´andose en el uso de herramientas tal 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 m´as conocido sobre patrones, propone los nombres utilizados en la actualidad y da una clasificaci´on muy interesante.

[HT99]

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´ıdo. Por lo entretenido, por la profundidad y sencillez de las ideas y porque esta plagado de consejos u ´tiles. Recomendable para toda persona relacionada con la programaci´on.

[HT03]

Andrew Hunt and David Thomas. Pragmatic Version Control. Pragmatic Press, 2003. Peque˜ no y u ´til libro que nos ense˜ na los conceptos b´asicos e intermedios del control de versiones, muy recomendable.

[HT04]

Andrew Hunt and David Thomas. Pragmatic Unit Testing. Pragmatic Press, 2004. Excelente libro que cubre la parte te´orica y pr´actica sobre el Testing Autom´atico de Aplicaciones. Analizando las diferentes formas de hacerlo.

[Jef00]

Ron Jeffries. 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 pr´acticos.

[Jef04]

Ron Jeffries. Extreme Programming Adventures in C#. MS Press, 2004. Libro que muestra ejemplos de como usar Extreme Programming en el mejor lenguaje de la actualidad.

[Lho03] Rockford Lhotka. Expert One-on-One Visual Basic .NET Business Objects. APress, 2003. Un libro totalmente pr´actico con la introducci´on y justificaci´on de las capas de negocios y como se pueden generar autom´aticamente. Incluye ademas las plantillas de CodeSmith para hacerlo. [McC04] Steve McConnell. Code Complete 2ed. MS Press, 2004. El mejor libro sobre construcci´on de Software, muy amplio y explica temas desde cuantos comentarios utilizar en nuestros programas que conducta nos dar´a mejores resultados en nuestra carrera, una JOYA !! [Mic]

Microsoft. Microsoft Patterns And Practices. MS Press. Este no es un libro sino una colecci´on de libros que publica Microsoft y que son gratuitos. Son una excelente guia para los que comienzan o est´an en un nivel intermedio 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.

´ ´ APENDICE B. RECURSOS UTILES

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.

[Rai02]

Hank Rainwater. Herding Cats: A Primer for Programmers Who Lead Programmers. APress, 2002. Otro libro de la editorial m´as actualizada y profesional con respecto a .NET y el desarrollo moderno, este en especial trata de como liderar a otros programadores, planificar y hacer buenas relaciones gerenciales.

[Sch04]

Ken Schwaber. Agile Project Management with Scrum. MS Press, 2004. Nuevo libro de Microsoft que muestra como administrar proyectos usando esta metodolog´ıa ´agil.

[Sha00] Alan Shalloway. Design Patterns Explained. Addison-Wesley, 2000. Un libro m´as bien pr´actico que nos introduce al mundo de los patrones. Nos muestra como se aplican en la realidad a trav´es de ejemplos y nos advierte en que 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 m´as que quejas a la metodolog´ıa con un tono muy ir´onico. Por ejemplo en un cap´ıtulo dice que no puede ser que el c´odigo nunca este listo si usamos XP, y mi respuesta es: NO NUNCA ESTA LISTO siempre le falta algo, ning´ un sistema funciona como se esperaba, siempre hay algo que cambiar o ser´a que tiene alg´ un ejemplo que indique que no, yo le dir´ıa que Windows, Linux, Office, los sistemas administrativos de las empresas, etc. nunca estuvieron listos y con esto queda claro porque no me agrada demasiado, lo agregu´e ac´a porque es interesante ver como se la agarran con cosas que funcionan en la pr´actica 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´ıa un poco m´as pr´actica que el libro de Fowler, muestra con ejemplos y con ejercicios para el lector como darnos cuenta donde hacer refactoring y donde no.