Desarrollo Agil Con

Informacion de contacto

Cualquier sugerencia, consulta, crıtica o correccion por favor comunıquenlo entrando en:

www.MarcosMeli.com.ar

O directamente enviandome 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 mas completo posible de las posibilidades de utilizar el

.NET framework acompanado del desarrollo agil y de las herramientas que lo soportan.

Es muy probable que haya una nueva version de esta tesis en mi pagina, algun artıculo

nuevo o links a lugares relacionados o que completan la informacion.

Version de esta Tesis: 1.0

i

www.MarcosMeli.com.ar

Indice general

Informacion de contacto I

Resumen 1

1. Introduccion 4

1.1. Por que Tecnicas y Herramientas ? . . . . . . . . . . . . . . . . . . . . . 4

1.2. Por que Metodologıas de Desarrollo Agil ? . . . . . . . . . . . . . . . . . 6

1.3. Por que la Plataforma .NET ? . . . . . . . . . . . . . . . . . . . . . . . . 9

2. Tecnicas de Desarrollo Agil para .NET 12

2.1. Programacion en Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2. Control de Versiones y Programacion Concurrente . . . . . . . . . . . . . 15

2.3. Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4. Desarrollo Dirigido por el Testing . . . . . . . . . . . . . . . . . . . . . . 24

2.5. Generacion de Documentacion a Partir del Codigo . . . . . . . . . . . . . 26

2.6. Integracion Continua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.7. Armar una Librerıa de Codigo y Controles . . . . . . . . . . . . . . . . . 30

2.8. Seguimiento de Proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.9. Crear Componentes y Controles Personalizados . . . . . . . . . . . . . . 33

2.10. Convenciones de Nombres y Estilo . . . . . . . . . . . . . . . . . . . . . . 36

2.11. Manejo y Reporte Automatico de Errores . . . . . . . . . . . . . . . . . . 43

3. Herramientas de Desarrollo Agil para .NET 47

3.1. Generacion Semi-Automatica de Codigo . . . . . . . . . . . . . . . . . . 48

3.2. Control de Versiones y Programacion Concurrente . . . . . . . . . . . . . 52

3.3. Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.4. Testing de Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.5. Generacion Semi-automatica de Documentacion . . . . . . . . . . . . . . 65

3.6. Compilacion e Integracion Automatica . . . . . . . . . . . . . . . . . . . 67

3.7. Almacenar Nuestra Librerıa de Codigo y Controles . . . . . . . . . . . . 71

3.8. Seguimiento de Proyectos . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.9. Revision y Analisis de Codigo . . . . . . . . . . . . . . . . . . . . . . . . 77

ii

iii

3.10. Profilers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4. Check Lists de los Temas Tratados 83

4.1. Control de Codigo Fuente . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.2. Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.3. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.4. Documentacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.5. Compilacion e Integracion . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.6. Generacion de Codigo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.7. Convenciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.8. Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5. Conclusiones 88

5.1. Otros Temas de Interes sobre Desarrollo Agil . . . . . . . . . . . . . . . . 90

A. Reflexiones Sobre el Desarrollo de Software 91

A.1. Systemantics (Fallos en los Sistemas Complejos) . . . . . . . . . . . . . . 91

A.2. Buen Software: Programacion o Gerenciamiento de Personas ? . . . . . . 92

A.3. Mantenibilidad: Problema o Bendicion ? . . . . . . . . . . . . . . . . . . 93

A.4. Desarrollo Web: La Solucion Ideal o una Opcion mas ? . . . . . . . . . . 93

A.5. Numeros y Estadısticas para Reflexionar . . . . . . . . . . . . . . . . . . 94

A.6. Que Significa ser un ’Mejor Desarrollador’ ? . . . . . . . . . . . . . . . . 95

B. Recursos Utiles 97

B.1. Repositorios de Componentes y Codigo . . . . . . . . . . . . . . . . . . . 97

B.2. Informacion sobre Desarrollo Agil . . . . . . . . . . . . . . . . . . . . . . 98

B.3. Direcciones de las Herramientas Tratadas . . . . . . . . . . . . . . . . . . 99

B.4. Contenido del CD Complementario . . . . . . . . . . . . . . . . . . . . . 101

Agradecimientos 102

Bibliografıa 103

Resumen

En esta Tesis se analizaran las diferentes tecnicas de desarrollo agil que permiten

generar aplicaciones de manera rapida y confiable, aprovechando al maximo las ultimas

herramientas y el nuevo enfoque de la programacion que se introdujo en las ultimas

versiones de Java y que alcanzo su grado maximo con .NET.

El analisis realizado se centra principalmente en la automatizacion de la mayorıa de

las tareas del desarrollo y sobre todo en la importancia de generar codigo a traves de

plantillas editables.

Las tecnicas abarcadas que cuentan con mayor popularidad son:

• Desarrollo en Capas.

• Refactoring.

• Documentacion embebida o generada a partir del codigo.

• Desarrollo Dirigido por el Testing.

• Integracion Continua.

• Seguimiento de Proyectos.

En cuanto a herramientas, analizaremos las que apuntan a facilitar las tareas de:

• Generar codigo de las capas de Datos y Negocios.

• Hacer Refactoring.

• Generar Documentacion.

• Controlar las versiones de un sistema.

• Programar entre 2 o mas personas sobre el mismo codigo.

• Ejecutar Casos de Test.

• Compilar, Integrar y Distribuir el Sistema.

• Analizar Problemas en el Codigo.

1

2

Vale la pena aclarar que hay muchos libros escritos sobre cada uno de estos temas,

en esta tesis simplemente se tratara de dar una introduccion para familiarizar al lector

con los mismos y brindar referencias sobre donde se puede encontrar mayor informacion.

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 tendra 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 sera el tema principal en nuestra lınea de pensamiento.

Muy Automatizado

Como dijimos al principio la tesis habla de automatizar procesos y uti-

lizar herramientas que hagan cosas por nosotros, pues bien, mostraremos

como hacerlo y aunque parezca exagerado, veremos que podemos desar-

rollar una aplicacion 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 aplicacion no deberıan cambiar su comportamiento en absoluto.

Notese que en las ultimas condiciones decimos Muy Automatizado o Muy Or-

togonal y no Automatizado u Ortogonal esto no es una simple casualidad sino que se

quiere destacar que no estamos hablando que se genere todo el codigo 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 codigo 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 codigo posible, porque eso de no cambiar nada en la practica no

existe.

La mayorıa de las herramientas tratadas pertenecıan al mundo Java y fueron portadas

a .Net en los ultimos anos. Casi todas son iniciativas Open-Source por lo que se pueden

utilizar libremente y ademas contamos con el codigo fuente, para realizar cambios o

agregar funcionalidad, incluso podemos enviarselas a los creadores para que las incluyan

las modificaciones en las proximas versiones.

1 Solo necesitamos conocer estos temas si vamos a cambiar las plantillas pero si solo generamoscodigo no es necesario saber nada de eso.

2 De hecho todos los intentos de derivar el codigo Automaticamente a partir de una especificacionhan fallado porque eran demasiado ambiciosos pretendiendo que los humanos participemos solo en ladefinicion del problema y dejemos el resto para las maquinas.

3

Veamos como se estructura la tesis y a donde ir en caso de necesitar algo en particular:

Comenzaremos explicando el porque del Tıtulo de la Tesis. (Pag. 4)

Pasaremos luego a las Tecnicas para cubrir el marco teorico del desarrollo agil e intro-

ducirnos en el mundo de la programacion moderna. (Pag. 12)

Seguiremos con un analisis de las Herramientas que llevan esos conceptos a la practica,

porque sin ellas las tecnicas serıan difıciles de implementar y nadie las usarıa. (Pag. 47)

Luego daremos una lista de Check Lists con consejos y buenas practicas para no tener

problemas al aplicar estos conocimientos. (Pag. 83)

Extraeremos una Conclusion de la informacion presentada teniendo en cuenta el pre-

sente y futuro de la programacion. (Pag. 88)

Ademas 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 sera muy

difıcil salir ... si es que existe una salida. (Pag. 91)

Finalmente daremos una lista muy completa de Recursos Utiles con informacion sobre

donde encontrar mas material, donde recurrir en caso de necesitar codigo o controles

gratuitos y las direcciones de cada una de las herramientas tratadas. (Pag. 97)

Capıtulo 1

Introduccion

1.1. Por que Tecnicas y Herramientas ?

Cada dıa la brecha que existe entre la teorıa y la practica aumenta considerablemente,

las tendencias comerciales nacen, se establecen y cambian cada cinco anos 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 actualizacion 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 academico.

5. No podemos controlar lo que no podemos medir.

6. La Inteligencia Artificial resolvera los problemas por nosotros.

y cuando entramos en el mundo de la practica descubrimos:

1. Windows es el sistema mas usado y el que marca los nuevos estandares.

2. VB6 es facil de entender y es el mas usado en los desarrollos administrativos.

3. SQL Server, Oracle, MySQL no guardan sus bases en XML y son los mas populares.

4. .NET marco un antes y un despues en la historia de la programacion.

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 practico con la Inteligencia Artificial.

4

CAPITULO 1. INTRODUCCION 5

Por ello en esta tesis se analizaran ambos mundos.

Del lado de la teorıa analizaremos las Tecnicas de Desarrollo Agil mas destacadas y

utiles, incluiremos una descripcion general de cada una, su origen y donde es conveniente

usarla.

Del lado de la practica estudiaremos las Herramientas desarrolladas para .NET que

dan soporte a las tecnicas vistas, incluiremos las principales caracterısticas de las mismas,

donde encontrarlas y en que escala utilizarlas.

En este enfoque paralelo no mostraremos todas las Tecnicas y Herramientas pero

al final de la Tesis propondremos un listado con otras posibilidades, citando las fuentes

donde encontrar informacion adicional.


1.2. Por que Metodologıas de Desarrollo Agil ?

La mayorıa de nosotros somos conscientes que la computacion en sı y sobre todo el

mundo de la programacion cambia a una velocidad realmente vertiginosa.

Pero algo mas radical es lo que ocurrio en la programacion que lo podemos definir

como una revolucion.

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 pequena solucion, comenzaron

a compartir sus conocimientos, experiencias y a ayudarse entre si, reduciendo la

cantidad de informacion a procesar.

Las Listas de Correo y los sitios que son solo repositorios de tutoriales o trozos

de codigo 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 afecto mucho la forma de programar que algunos denominaron Programacion

Basada en Componentes, pero no es solo eso, la revolucion de la que hablamos va

mucho mas alla. 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 mas que necesarias porque como dijimos no podemos

hacer todo nosotros.

Antes un programador se preocupaba por chequear su codigo o actualizar su com-

pilador y no mucho mas. En cambio, hoy dıa, un programador debe verificar compat-

ibilidades de todo tipo, que van desde versiones de sistema operativo, hasta la placa

de video de la maquina 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 metodos

tradicionales ya que piden demasiado a los desarrolladores.

Cuando se comienza un nuevo proyecto se hace demagogia de todo lo que se hara

con respecto a documentacion, testing, planificacion, gastos en recursos, etc. Lo hacemos

para tener la consciencia tranquila y sentir que esta todo bajo control.

Pero a medida que el proyecto avanza se va dejando de lado la documentacion porque

sino no se puede llegar a tiempo, se va demorando la planificacion 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 planificacion original.


Finalmente se omite el testing por completo. La documentacion y planificacion 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 ademas de no tener nada actualizado, no se sabe en

que estado esta 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 este casi completo.

El proyecto se vuelve incontrolable, peor aun que en aquellos dıas de la programacion

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 programacion del prueba

y error, el hago algo y veo si es lo que quieren, termino esta parte y agarro otra. Todas

esas pequenas 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 computacion 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

planificacion de pequenas 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 esta cada parte del sistema y hacer

pequenos ajustes al alcance o a la planificacion si no llegamos en el tiempo prometido.

Si bien es cierto que no hay una planificacion sobre el proyecto completo como

supuestamente tenemos con las metodologıas tradicionales, logramos una mayor sen-

sacion de avance ya que las metas estan mas cerca y son mas visibles.

Como consecuencia todos ganan:


• Los programadores se sienten mucho mas utiles ya que terminaron con lo que

prometieron, lo ven funcionando y sobre todo no se frustran porque estan fuera

de la planificacion. De esta forma rindan mas porque notan que las cosas se estan

completando razonablemente bien y no se los esta presionando constantemente

para que terminen algo.

• El jefe de proyecto tiene semanalmente cosas nuevas del sistema para mostrar

a los gerentes o clientes. Pudiendo ademas identificar errores de interpretacion

asegurandose que todo marcha como ellos quieren.

• Los gerentes o clientes perciben que se estan haciendo cosas y que el proyecto

avanza a paso firme, evitando la ansiedad (o hasta angustia) que generan otras

formas de trabajar donde solo se les muestran las cosas cuando estan listas (lo que

siempre lleva mas 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 construccion 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 ...


1.3. Por que la Plataforma .NET ?

Para estudiar la aplicacion de las metodologıas agiles debemos encontrar una platafor-

ma de desarrollo moderna que cumpla con las siguientes condiciones:

• Tenga soporte para Programacion 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 ultimas tecnicas de desarrollo agil y existan herramientas

implementadas para hacerlo.

• Sea factible implementar patrones de diseno.

• Sea Multi-Plataforma.

• Sea lo mas economico posible, incluso gratuito.

Las dos grandes opciones que cumplen estas condiciones son, sin lugar a dudas,

Java2EE y .NET Framework.

La inclinacion hacia el segundo esta dada por el impulso que Microsoft le da a .NET

ya que esta dispuesto a convertirlo en la decision 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 decision son:

• La velocidad de crecimiento y maduracion 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 estandarizacion de C# y el CLI (common lenguaje infrastructure) permitio

proyectos como Sharp Develop, un IDE muy completo, similar al Visual Studio

.NET pero de codigo abierto.

• Relacionado con el CLI se desarrollo 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

adhesion e interes comercial llegara a un estado de madurez muy pronto)

• .Net presenta un soporte mas que transparente para integrarse con el resto de

las herramientas de Microsoft y que la mayorıa de las empresas tienen instaladas,

como:


• 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 ademas ineficientes.1

• A SUN pareciera que no le queda mucho ya que parece dar todo el tiempo mano-

tazos de ahogado, regalando cosas y demas. Esta razon es muy importante porque

en un futuro SUN puede dejar de existir, pero que deje de existir Microsoft... es

dudoso no ??

• La diferencia mas notable es cual es el motor detras de cada unos de estos grandes.

• Por un lado esta Java que surge como un lenguaje revolucionario,

orientado a objetos, portable, multi-plataforma, etc. Fue el coneji-

to de indias y se tomo un buen tiempo para crecer pero por varias

razones no se termino de imponer (entre otras porque: era muy pe-

sado 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 esta .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, Crys-

tal Reports, etc. Por este lado hay muchısimo mas dinero y como

sabemos con el todo se hace rapido 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 estan dispuestas a pagar.

• .Net capturo gran parte de la comunidad Open Source que estaba abocada a la

construccion 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 ejecucion con respecto a requerimientos de hardware de las dos

grandes plataformas favorece a .NET que, al no ser totalmente interpretado, lo

1 Ademas de que Java no tiene soporte nativo para integrarse con estas herramientas usa metodosde acceso como ODBC al que MS no le presta atencion (o se la presta para ver como complicarlo) yque son muy lentos en comparacion con, por ejemplo, ADO.NET

www.SourceForge.net


deja a Java fuera de combate en cuanto a Performance2. Aunque se diga que el

Visual Studio es pesado y el framework tambien, 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 programacion 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 dueno 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 companıa y hacer uso de estos derechos.

Podrıamos escribir muchısimas mas 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 preocupo 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 mas curioso e interesante es que con las versiones 1.0 y 1.1 de .Net se incluyo

solo una parte de lo que estaba planificado serıa el .NET Framework (por cuestiones de

mercado o simplemente de tiempos).

En el 2005 lanzara la version 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 proximos 10

anos o como dice Microsoft los proximos 20.

2 Si buscamos en internet ”J2EE Vs .NET”veremos que la comunidad de Java dice que su plataformaes la mejor pero las razones que dan no son suficientes. Se la agarran con C++ porque si lo usamosen .NET puede haber lacks de memoria o errores inesperados ya que se pueden pasar por encimaa los controles del Framework. Pero Microsoft ni loco harıa el C++ semi-interpretado con una capaintermedia porque perderıa el mercado de los juegos actuales hechos con Visual C++ y DirectX, ya quela performance de estos se vendrıa abajo (o acaso conocen algun juego 3D hecho en Java... a si ?? ycuantos servidores se necesitan para ejecutarlo...)

Capıtulo 2

Tecnicas de Desarrollo Agil para.NET

Como comentamos en la introduccion de esta Tesis, las metodologıas agiles son casi la

unica opcion 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 seccion de la tesis analizaremos desde el punto de vista teorico las distintas

Tecnicas de Desarrollo Agil con las que contamos y que tienen mayor popularidad en la

comunidad de desarrolladores de .NET.

Estas tecnicas son la base fundamental de las herramientas mas 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 practica lo mas fielmente posible.

Aclaremos nuevamente que no haremos un analisis exaustivo de cada tecnica porque

serıa imposible ya que existen muchos libros de cada una, nos conformaremos con una

idea general de la tecnica y como se adapta a .NET, para mayor informacion se puede

consultar el Apendice B (pagina 97) donde hay enlaces a sitios sobre cada tema, la

Bibliografıa o el CD complementario donde encontraran mas material.

12

CAPITULO 2. TECNICAS DE DESARROLLO AGIL PARA .NET 13

2.1. Programacion en Capas

Esta sera la primer tecnica que analicemos ya que es una de las mas antiguas. Se

aplica a cualquier tipo de desarrollo relacionado con bases de datos, principalmente en

sistemas administrativos.

Graficamente un tıpico sistema con arquitectura en capas se ve ası: 1

La idea detras 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 practica cuesta mucho mantener una independencia pura como se plantea en

esta tecnica, pero de todas maneras se simplifica muchısimo el desarrollo cuando uno

encara la solucion 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 automaticamente 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 tecnica se popularizo tanto veamos un ejemplo tıpico:

1 De todas la capas que vemos en el grafico no todas tienen porque estar ni tampoco son las unicasque hay, se podrıa llegar a utilizar la cantidad que queramos, este es solo un ejemplo del caso mas comunen un desarrollo con bases de datos.


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, eliminacion, actualizacion y recuperacion 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 codigo de las capas de negocios que poco tienen que ver

con la decision de cambiar la base y que, si el sistema se diseno con esta filosofıa, no se

le deberıa cambiar nada.

Aunque parece que son todos halagos para el desarrollo en capas, en la practica (como

siempre) surgen cosas que no se pueden manejar fiel al esquema propuesto y perdemos

esa abstraccion tan pura que veıamos en el grafico.

Tengamos en cuenta el siguiente enunciado:

Se necesita que cuando se cambie el precio de algun artıculo se escriba un

registro en la tabla de novedades de precios.

La solucion mas 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 tecnica.

Aunque se rompa con la idea general este tipo de cosas pasan siempre. Estas excep-

ciones son mucho mas faciles 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.

Mas bien se debe escribir un breve documento explicando el porque de la decision y

colocarlo en una carpeta de documentos vitales del sistema (con esa informacion 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 prob-

lema con una arquitectura en capas pero debemos estar preparados para posibles excep-

ciones que deben ser tratadas como tales.

2 En ingles estas operaciones son conocidas con el nombre de CRUD por Create, Retrieve, Update& Delete.


2.2. Control de Versiones y Programacion Concur-rente

Cualquier persona que haya hecho algun sistema para alguien, por mas pequeno que

sea, sabe que la siguiente historia es mas que frecuente:

Uno le entrega una version al cliente y luego continua haciendo cambios para la

proxima entrega. Luego que la terminamos llevamos la nueva version, pero, cuando el

cliente la prueba dice:

”Si si, esta muy bien, pero la pantalla de busqueda de aca

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 version anterior del codigo

fuente y rezamos para que sea la misma que genero 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 busqueda y le agregamos el de la version vieja el otro3.

Volvemos a compilar y se lo llevamos, rezandole 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 mas simple, simplemente le pedimos al Sistema de Control

de Versiones que nos muestre las diferencias en el archivo de la pantalla

de busqueda entre la version 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 programacion es una tarea altamente creativa, cambiante y, como citabamos an-

teriormente, generalmente no es una actividad individual.

Solo cuando se trabaja con un grupo de personas que modifican concurrentemente

el codigo nos damos cuenta que es muy complicado juntar las distintas versiones del

sistema que estan en cada maquina, por mas que se dividan correctamente las tareas,

3 Ojala que tengamos un backup de la ultima version porque el resultado probablemente no sera elesperado

4 Aunque parezca poco probable que sea ası de sencillo veremos que lo es en las proximas hojas


Murphy hara que se necesite cambiar el mismo archivo, en el mismo lugar y las cosas se

volveran, como siempre, mas complicadas de lo previsto.

La forma de trabajo de los sistemas de control de versiones es muy simple:

• Hay un repositorio central con el codigo fuente que mantiene los cambios que se

fueron haciendo a lo largo del tiempo.

• Hay tres operaciones basicas sobre el repositorio que son:

Bajarse una version completa del codigo (CHECKOUT)

Bajarse los ultimos cambios y juntarlos con las nuestros (UPDATE)

Subir nuestros cambios para que los demas puedan verlos (COMMIT)

Graficamente se ve ası

Esquema General de un Sistema de Control de Versiones (CVS)

* Utilizaremos directamente los nombres en ingles para no generar

confusion y porque no hay buenas traducciones de estos termino

Con respecto al orden de las operaciones en el uso basico de un sistema de control

de versiones podemos decir que debemos hacer una unica ves un CHECKOUT.

Luego podemos hacer cambios en el sistema, cuando los finalizamos se hace un UP-

DATE 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.

Graficamente:


Tareas mas 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 dividiesemos

la lınea principal de desarrollo en dos y podemos trabajar en cualquiera de ellas.

El lugar mas comun 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 unica que existe, mientras

tanto los otros miembros del equipo pueden continuar con el desarrollo principal.

Inclusive se pueden volcar los cambios del BRANCH del RELEASE a la lınea prin-

cipal de desarrollo con el comando MERGE.

Resumamos este proceso con un grafico:

Pasos Tıpicos de un Branch en el Desarrollo

Otro comando interesante es el de TAG que se encarga de ponerle un nombre sim-

bolico 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 version independiente ya que se actualizan

individualmente serıa una locura tener que anotar todas para despues 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 facil hacer control de versiones ya que Microsoft

no utiliza mas archivos binarios para guardar los proyectos o soluciones. Ahora usa

directamente archivos de texto con sintaxis XML.


Como conclusion 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 codigo 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 justificacion porque se

descubrirıa la verdad facilmente.

Un hecho muy interesante relacionado con la proxima tecnica 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 codigo para ver como evolu-

ciona (lo que no afectara 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 rapidamente, no quedan

muchas cosas a las que tenerle miedo.

Ademas 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 codigo concurrentemente como pasa con Linux. Ası que es buena idea

imitarlos.


2.3. Refactoring

Aunque el nombre no sea muy conocido esta comenzando a escucharse cada vez con

mas frecuencia y va a pasar a ser algo muy comun cuando Microsoft incluya herramientas

que soporten esta tecnica 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 paso de ser un conjunto desor-

denamos de ideas a u ser un texto mas 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 despues se van

cambiando cosas generalmente se tienen mejores resultados.

En la programacion 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 atras y re-pensar todo el problema con la perdida 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 mas que parezca una

perdida de tiempo, a largo plazo nos traera grandes beneficios.

La definicion de refactoring es:

Cambiar ”algo” con el fin de mejorarlo.

En el caso de la programacion ese algo es el codigo, en el diseno son los diagramas y

en el analisis son las especificaciones y la arquitectura.

Un problema con el que se enfrenta hoy en dıa esta tecnica 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 ningun valor comercial. Pero todo buen analista, arquitecto, disenador 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 autorizacion 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 sera nuestra.

Es necesario aclarar que debemos poner en la balanza el costo del cambio y los

beneficios que obtendremos para tomar una decision y no hacer refactoring por deporte,

no porque esto este mal, sino porque nuestros jefes o clientes no estaran muy contentos

y nos quedaremos sin trabajo.


Razones para hacer Refactoring

Las situaciones mas comunes en las que se debe hacer refactoring y que nos daran el

mayor beneficio son:

El Codigo esta duplicado

Esta razon es la que mayor cantidad de problemas nos trae, todo codigo o informa-

cion 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 Diseno”

Una rutina es muy larga

En la programacion 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 metodo con el codigo comentado y se lo debe nombre de manera que

exprese lo mismo que el comentario.

La lista de parametros de una rutina es muy grande

Este es un error muy grave en la programacion orientada a objetos ya que uno

deberıa en estos casos usar un objeto como parametro 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 parametro al metodo y a todas

las llamadas ponerles el parametro extra que quiza no tenga sentido para muchas

de ellas.

Una clase tiene poca cohesion

Si una clase hace demasiadas cosas que no estan relacionadas entre sı, se debe

dividir en varias clases, donde cada una toma un conjunto de responsabilidades

altamente cohesivas.

Los comentarios explican trozos de codigo

Si dentro del cuerpo de una rutina hay comentarios para explicar parte del codigo

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 codigo comentado, gracias a este

refactoring, nuestro sistema se vuelve mas sencillo y auto-documentado.

Una clase esta en el medio entre otras y no hace nada

Si la mayorıa de los metodos de una clase solo tienen una llamada a un metodo de

otra, se debe considerar el hecho de eliminarla ya que refleja un error de diseno,

debiendo convertir las llamadas anteriores por llamadas directas a la clase final.


Refactorings mas 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 que contextos.

Reemplazar los numeros magicos por constantes simbolicas

Este es un refactoring tıpico que todos recomiendan utilizar. En .NET en particular,

cuando disenamos controles personalizados y tenemos tamanos, colores, textos por

defecto siempre conviene usar constantes simbolicas y no los valores literalmente.

Renombrar una variable a un nombre mas claro o informativo

Si una variable tiene un nombre poco claro (temp, obj, etc) cambiarlo a uno mas

significativo. Lo mismo se aplica a las constantes, rutinas y clases.

Reemplazar una expresion con una rutina

Cuando una expresion aparece en mas de un lugar o es demasiado complicada, se

debe crear una funcion que la compute y que tenga un nombre significativo.

Mover las expresiones booleanas de mas de 2 o 3 condiciones a una funcion

Toda expresion booleana lo suficientemente complicada compromete la legibilidad

del codigo en zonas tan importantes como los condicionales, la forma simple de

evitarlo es creando una funcion que la compute y ponerle un nombre adecuado.

Devolver los valores de las funciones ni bien se los conozca y no asignarlo a unavariable temporal

Si hacemos esto el codigo se vuelve mas facil de leer y la mantenibilidad futura no

se complica ya que si agregamos codigo debajo sabemos que no se va a ejecutar

si no corresponde ni cambiara el valor del resultado como pasarıa si tenemos una

variable temporal.

Extraer una rutina

Cuando un metodo se vuelve muy largo o complicado debemos extraer parte de su

codigo y formar una nueva rutina con el pasandole los parametros 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 multiples 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 quiza nos

convenga pasar directamente el objeto para facilitar la legibilidad y la extendibili-

dad.


Combinar codigo similar en una superclase

Si dos subclases tienen codigo similar se debe tratar de trasladarlo a la superclase

y evitar la duplicacion.

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 comun en la construccion de un sistema es que una clase crece en re-

sponsabilidades y es conveniente dividirla en dos para facilitar la legibilidad y

mantenibilidad.

Eliminar una clase

Si una clase se queda solo con un par de responsabilidad quiza sea conveniente

embeberla dentro de otra y eliminarla.

Introducir una rutina foranea

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 extension

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 mas coherente sin una rutina, esconderla.

Reemplazar codigos 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

informacion (como ser archivos de configuracion, variables globales, etc), ası nos

abstraemos de estos datos y hacemos que el sistema se vuelva mas flexible con

poco esfuerzo.


Refactoring del Diseno y la Arquitectura

No solo el codigo necesita refactoring, muchas veces cuando nos damos cuenta que

algo no esta del todo bien tratamos de hacer cambios para que funcione.

Pero muchas veces por mas cambios que le hagamos al codigo el problema sigue ahı.

La razon es porque la solucion no esta en cambiar el codigo sino en cambiar el diseno 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 transaccion es posible y la registra generando la respuesta correspondiente,

la misma vuelve al proceso receptor para que la envıe y recien en este momento se le

pasa la siguiente transaccion al servidor.

Si nos ponemos a dar vuelta el codigo del servidor para arriba y para abajo haciendole

refactorings lo mas probable es que no mejore mucho la performance porque el cuello de

botella no esta allı sino en el receptor de transacciones.

El problema radica en que el receptor trabaja de forma secuencial despachando una

transaccion esperando que este lista y luego despachando otra.

La solucion estarıa dada por una arquitectura concurrente donde las transacciones

se despachen simultaneamente pero esto implica un refactoring muy completo a nivel de

arquitectura y diseno ya que hay que re-pensar todo.

Incluimos este ejemplo para mostrar simplemente que si algo no anda bien, o no nos

gusta como quedo, podemos ir mas alla del codigo en busca de una solucion a un nivel

de abstraccion mayor como pueden ser el diseno o la arquitectura del sistema.

Conclusion

Para marcar la importancia de este tema destacamos que tanto Microsoft como Bor-

land brindaran soporte nativo en sus entornos de desarrollo para muchos de los refac-

toring vistos (ver 3.3).

La principal razon de esta decision es porque comprobaron que la comunidad recurrıa

mucho a los complementos comerciales que hacıan solo esto y porque esta comprobado

que mejora la productividad.

Gracias a este cambio solo necesitamos identificar los refactorings a aplicar y dejar

que nuestro IDE haga el trabajo pesado.

Cuando uno comienza a hacer refactoring quiza 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 mas facil de modificar a la que le cambiamos los nombres, la cantidad

de metodos, los parametros, los comentarios, etc.


2.4. Desarrollo Dirigido por el Testing

Siempre que se habla de testing nos dicen que es indispensable probar todo lo que

hacemos porque somos humanos y nos equivocamos.

Que si no hacemos testing es como si el sistema fuera una bomba y no sabemos

cuando va a explotar. Pero no hablan bien de como hacerlo o piden demasiadas cosas

que no hacen mas 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 codigo que esta 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 ...

Esta bien que se insista en el testing porque en todos lados vemos graficos como el

de la figura siguiente que nos muestran, con razon, que no se puede dejar el testing para

lo ultimo porque seguro no va a haber tiempo y porque tendrıamos que corregir cosas

que ya ni recordamos, perdiendo muchısimo tiempo.

En cambio si vamos testeando mientras el sistema avanza nos podremos mantener

en un nivel estable de productividad durante todo el desarrollo.

Productividad relacionada con momento en que se hace el testing

Algo interesante que se ve en la 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.


Aquı se presenta otra ves un tema de burocracia porque los clientes o jefes estan

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 mas 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 codigo.

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 mas adepto que incluso

afirman que es mas sencillo que hacer el testing convencional.

Para encontrar mayor informacion sobre el tema ir a:

http://www.TestDriven.net

Yo creo que debemos encontrar un punto medio, usando tecnicas de testing temprano

que se pueden ejecutar automaticamente. 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 mas 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

insercion, actualizacion y borrado) sobre una base de prueba.

En la seccion 3.4 mostraremos como funciona NUnit, la herramienta mas usada para

crear y ejecutar tests en el mundo de .NET.

http://www.TestDriven.net


2.5. Generacion de Documentacion a Partir del Codi-go

En las metodologıas denominadas pesadas el desarrollo debe estar dirigido por la

documentacion y los argumentos que presentan para hacerlo parecen buenos, pero, co-

mo siempre, en la practica se convierten en desventajas por la perdida de tiempo que

implica la actualizacion5 y porque se termina haciendo un trabajo doble al mantener

paralelamente esta informacion y el codigo.

Por ejemplo en los desarrollos administrativos con bases de datos lo recomendado es

hacer un diccionario de datos (D.D.) con todas las entidades del sistema y luego crear

la tabla.

Si hay cambios en esta ultima debemos cambiar tambien los DD, pero si documen-

tamos las tablas con los lugares que tienen reservado para esto los motores de bases de

datos, la meta-data puede utilizarse despues para extraer las descripciones y generar

automaticamente el diccionario de datos e inclusive los diagramas de relacion.

La contestacion obvia podrıa ser que pasa si queremos agregar informacion al D.D.

y no lo podemos hacer en las descripciones de los campos y las tablas, nuestra respues-

ta deberıa ser que esa informacion seguramente es mas importante que el D.D. en si,

entonces se deberıa llevar aparte y no embebido con esta informacion 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 comun es tener la estructura de las entidades y las relaciones y luego si hay

info adicional, que serıa una excepcion, se deberıa documentar aparte.

Volviendo a al tema central de esta seccion podemos decir que con el codigo para

algo muy parecido, tener un documento de Word con 500 paginas con la definicion de

las clases, sus metodos, sus responsabilidades, la relacion entre las mismas, etc. es algo

totalmente anti-productivo no tiene sentido colocar allı ese conocimiento es mejor

embeberlo en el codigo o sacarlo automaticamente y generar algo en un formato mas

ameno para encontrar lo que buscamos.

Cuando Microsoft desarrollo las librerıas de .NET se encontro con este problema de

mantenibilidad de la informacion de las clases, metodos, eventos y propiedades y diseno

una nueva forma de documentacion embebida en el codigo con formato XML, gracias

a esto posibilito la inclusion de meta-data sobre los parametros, valores de resultado,

ejemplos, etc.

Un formato muy comun para la documentacion durante el desarrollo es el CHM de

Microsoft que nos permite navegar sobre un arbol con el mismo esquema del codigo y

ver la informacion relacionada con cada elemento del mismo.

5 Inclusive si la documentacion esta desactualizada puede ser hasta peligrosa porque puede llevar adecisiones o pensamientos equivocados.


Esta opcion solo 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 codigo 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 docu-

mentacion en XML y que el mismo compilador de C# es el que se encarga de extraer

esta informacion a un archivo con el mismo nombre que el ensamblado pero con exten-

sion XML. Finalmente fue un paso mas alla permitiendo que el IntelliSense del Visual

Studio extraiga informacion de estos archivos con lo que nuestra documentacion no solo

se extrae sino que ademas se integra automaticamente al VS.NET.

El paso que resta es darle a esa meta-data un formato mas legible que XML 6 y ası

completar el cırculo de la documentacion semi-automatica. Existen muchas herramientas

para hacerlo, la mas popular es NDoc y sera la que analizaremos en la seccion 3.5 (pag.

65).

6 Aunque uno de los objetivos cuando se creo XML era que sea legible por humanos no conozcomucha gente que necesite hacerlo y los que lo hacen tal vez prefieran un hermoso archivo de texto planosin tags.


2.6. Integracion Continua

Integracion Continua (Continuos Integration) no es simplemente una tecnica 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

modulos del sistema.

Anteriormente los equipos trabajaban casi independientemente, disenaban y pro-

gramaban sus modulos, cuando los tenıan listos los testeaban para ver como se com-

portaban 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 atras.

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 Integracion Continua va mas alla, utiliza las tecnicas vistas como: control de

codigo fuente, generacion automatica de documentacion, ejecucion automatica de casos

de test, etc. para cumplir con su cometido.

Los pasos del proceso ideal de integracion continua que se desarrollan automatica-

mente son:

• Revisar el Sistema de Control de Versiones para ver si hay cambios

• Si los hay, extraer la ultima version y ponerle un Tag antes de hacer nada (ej:

PRE_0_7_6).

• Actualizar la version del Sistema (ej: de 0.7.5 a 0.7.6)

• Compilar todos los modulos del sistema.

• Ejecutar los casos de test como se explico en la seccion 2.4

• Si algo salio mal hasta el momento informar por mail o de alguna manera al

encargado y abortar.

• Generar la documentacion automatica.

• Hacer un nuevo Tag en el sistema de control de versiones (ej: POST_0_7_6).

• Generar una nueva instalacion del sistema.

• Copiar o distribuir los archivos donde corresponda.


• Generar un reporte sobre la compilacion e integracion.

• Enviar por mail ese reporte a los miembros que corresponda.

Graficamente el proceso se ve ası:

Para mayor informacion sobre esta tecnica 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 encontraran white papers sobre

estos temas.

Si alguna ves tuvimos que entregar sucesivas versiones de una misma aplicacion

sabemos lo difıcil que se hace recordar todos los cambios que debemos hacer para que

funcione en el ambiente de produccion.

Se deben cambiar las Bases de Datos, la ubicacion de los archivos ya que seguramente

estabamos usando algunos de prueba, compilar los controles en modo Release, cambiarle

el numero de version, etc, etc.

Si usamos integracion continua solo debemos indicarle al sistema que usemos los

pasos que debe realizar para tener una nueva version lista para poner en produccion y

automaticamente la tendremos con un reporte de los resultados intermedios.

http://ccnet.thoughtworks.com

www.thoughtworks.com


2.7. Armar una Librerıa de Codigo y Controles

Una de las principales reglas del desarrollo agil es no hacer nada que ya este he-

cho7 por eso estudiaremos como y donde buscar codigo o controles que resuelvan cosas

por nosotros, luego clasificarlos y guardarlos, para encontrarlos rapidamente cuando los

volvamos a necesitar.

Antes esta era una tarea complicada ya que no habıa disponibilidad de codigo, pero

hoy dıa con Internet no hay mas excusas, cada ves es mayor la cantidad de sitios que se

dedican solo a hostear codigo 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 publicacion. Los visitantes pueden

votar y el sitio premia a los que publicaron los artıculos mas populares.

• Cuentan con opciones avanzadas de busqueda lo que facilita enormemente buscar

lo que queramos, inclusive el codigo mas escurridizo.

• Generalmente permiten descargar el codigo fuente con los binarios y una expli-

cacion 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 mas completo

y cuidado de todos. Para una lista completa buscar en el Apendice B.

Lo que ocurre si uno frecuenta estos sitios es que hay tanta informacion que la mayorıa

parece util pero quiza no sirva para nuestro desarrollo, pero como un en un futuro nos

podrıa servir hacemos lo siguiente:

Bajamos el codigo o los archivos, los guardamos en algun lugar del disco y, tal como

dijo Murphy, permaneceran a mano siempre, pero cuando los necesitemos para algun

proyecto sera imposible encontrarlos.

El problema radica en que no tenemos meta-data de esos archivos, son solo un nombre

dentro de algun directorio y nada mas. Necesitamos alguna clasificacion, descripcion,

imagen de como se ven, etc.

Lo mas comun es armar una jerarquıa de directorios para clasificar esta informacion,

pero a medida que agregamos cosas descubrimos que hay temas ambiguos que son difıciles

de clasificar. Ası vuelve aparecer el problema de la busqueda.

Una buena practica es almacenar ese codigo en una librerıa, ordenada por categorıas

y con la informacion de contexto necesaria para facilitar futuras busquedas.

7 Siempre que este hecho bien...


Para que esta tecnica de resultado debemos utilizar una herramienta adecuada para

guardar esta informacion, 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 seccion 3.7 mostramos la herramienta definitiva y gratuita para almacenar

nuestros snippets.


2.8. Seguimiento de Proyectos

Al comenzar cada proyecto, como todo parece sencillo, creemos que las cosas que hay

que hacer o cualquier otra anotacion 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 impor-

tantes y no se sabe que tareas estas pendientes, cuales listas ni la importancia de cada

una.

La solucion a estos problemas es hacer un seguimiento del proyecto (Project Tracking)

en un lugar centralizado.

El problema esta en hacer que este seguimiento sea sencillo y no una perdida de

tiempo ya que es simplemente un soporte para saber en que estado esta el sistema.

Veremos en el capıtulo de las herramientas cuales son las alternativas y lo sencillo

que es usarlas.

La intencion 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 maximo nivel y esperar que el

resultado sea bueno

Se debe comenzar de a poco, mejorando lo que hacemos, incluir lentamente

las nuevas tecnicas, aprender sus alcances y consecuencias y luego avanzar

a otro nivel

El problema de querer controlar todo al maximo detalle es que es totalmente cansador

y lleva realmente mas trabajo que hacer muchas de las cosas que se estan monitoreando.


2.9. Crear Componentes y Controles Personalizados

Desde los comienzos de la Programacion Visual los desarrolladores mas avanzados

creaban controles personalizados para agregar a sus sistemas y para no tener que ree-

scribir el mismo codigo varias veces o simplemente para poder agregar funcionalidad

facilmente en un futuro.

Era un grupo muy reducido de programadores ya que no era una tarea sencilla, la

documentacion era escasa y el soporte tecnico mınimo.

El salto mas grande en el desarrollo de componentes lo dio Borland cuando decidio

liberar el codigo fuente de su VCL (Visual Class Library) e incluirlo en la instalacion

de Delphi y C++ Builder. A partir de allı y gracias a la abundante documentacion

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 atras, trato 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 version 6 de Visual Basic la creacion se simplifico

un poco, pero otras tareas como testear, distribuir y reusar el control seguıan siendo

complicadas.

Con la aparicion de .NET todo cambio, ahora la polıtica de Microsoft fue brindar

un completo soporte para crear controles y componentes y realmente lo logro. Hoy dıa

cualquier programador en 5’ puede hacer un control que herede de TextBox y deje que

se ingresen solo numeros.

Ademas la documentacion del SDK de .NET es excelente y la instalacion de nuestros

controles es simplemente referenciar una dll y listo. Luego cuando se compila el programa

cliente automaticamente 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 facilmente. Generalmente se

define una interfaz con el nuevo comportamiento y hacemos que la implementen nuestros

controles (se define una interfaz para poder manejar controles heterogeneos de una misma

manera)

Algo muy comun en todas las aplicaciones es la validacion 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 estan en estado de error o no) ası que atacaremos el problema permitiendo

que los controles recuerden si estan 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 termino todo el tema de registrar dll y todo eso, aunque parecıa solo una promesa mas deMicrosoft, realmente funciona, todas las instalaciones son Copiar, Pegar y listo


(*) El prefijo cp indica que son propiedades de un control personalizado y per-

miten encontrar estas propiedades rapidamente desde el editor de codigo (para mayor

informacion ver la seccion 2.10 de Convenciones).

Luego hacemos que nuestro TextBox la implemente y finalmente para usarlo solo

necesitamos hacer la siguiente validacion en el formulario donde se encuentra el control:

De esta manera se puede resolver algo muy tedioso que es la validacion de los datos

ingresados por los usuarios. Al haberlo hecho de esta forma tan generica hasta podrıamos

tener una clase que verifique si hay errores en un dado formulario y los muestre. El codigo

serıa:


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 esta 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 practico 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 codigo (siempre que este bien escrito) de algun control hecho

por otra persona con mas conocimientos.

La mejor opcion es entrar a www.CodeProject.com en busca de excelentes con-

troles para .NET y ademas de descargar el codigo es interesante guardar las paginas que

los presentan, porque generalmente tienen una explicacion de como funciona el control

y de como se usa.

La otra opcion es ejecutar el Reflector (explicado en la pagina 77) y desensamblar el

codigo de algun control del .NET framework como el TreeView para ver como hace uso

de las opciones graficas y de los eventos.

www.CodeProject.com


2.10. Convenciones de Nombres y Estilo

Cuando trabajamos solos es importante tener al menos algunas convenciones para

que nuestro codigo sea mas mantenible y estructurado.

Pero cuando se trabaja en equipo es imprescindible tener varias convenciones si quer-

emos 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 despues de usarlas algun tiempo.

Entre sus usos encontramos reglas para nombrar Clases, variables, archivos de datos,

archivos de codigo, directorios, formularios, recursos compartidos, tablas, formato de

documentos, diagramas, etc.

Como ası tambien 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

terminos que seran usados mas adelante:

PascalCase

Lleva todas las palabras que componen un nombre: en minusculas, concatenadas

y con la primer letra en mayusculas de cada una.

Como en: CapaDatos - ExceptionHelper - ContextoSeguridad

CamelCase

Es igual que el anterior pero con la primer letra en minusculas.

Como en: capaDatos - exceptionHelper - contextoSeguridad

Prefijos de los elementos mas comunes de .NET

Namespaces

En Pascal Case, sin underscores. Generalmente se como raız:

NombreEmpresa.NombreTecnologia

Si no tenemos un nombre de companıa al menos debemos ponerles nuestras iniciales

para poder agrupar todo lo que hagamos y encontrarlo facilmente.

Recordar que los acronimos de tres o mas letras van en pascal case como en Xmly en mayusculas cuando tienen 1 o 2 como en IO .

Assemblies

Si el assembly contiene un unico namespace o si agrupa varios pero con un names-

pace raız en comun, nombrar el assembly igual que ese namespace.


Clases y Estructuras

En Pascal Case, sin underscores, ”C” ni ”cls”.

Si la clase empieza con ”I” la segunda letra debe estar en Minusculas sino se con-

fundirı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.

Coleccion 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 excepcion.

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 Enumal final del nombre del enumerado.

Poner solo el Nombre y si sin flags ponerlo en plural.

Como en DayOfWeek, EditModes .

Funciones y Metodos

En Pascal Case, sin underscores, con excepcion de los manejadores de eventos.

Tratar de evitar abreviaturas.

Las funciones y metodos deben diferir en algo mas que la capitalizacion para no

tener problemas si se lo usa desde VB.NET o algun lenguaje Case-Insensitive.

Propiedades y Variables Publicas

En Pascal Case, sin underscores. Tratar de evitar abreviaturas.


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 .

Parametros

En Camel Case. Tratar de evitar abreviaturas. Es posible usar si el parametro tiene

el mismo nombre que una variable privada o protegida de la clase el prefijo p

Como en pDatos , pValorInicial .

Lo interesante de la ultima regla es que dentro del cuerpo de la rutina encontramos

asignaciones del estilo:

mDatos = pDatos

Identificando claramente que se esta asignando un parametro 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 mas 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 comun es Res.

Como aclaracion general podemos decir que se deben evitar, siempre que sea posible, las

abreviaturas ya que complican la lectura del codigo.

El problema esta en que cuando uno se olvida que significa, cada vez que lee el codigo

debe detenerse a pensar que querıa decir. En cambio si escribimos los nombres completos

la lectura es rapida y objetiva.

Un test muy interesante que propone el equipo de .NET de Microsoft es el GoogleTest, que consiste en escribir el nombre abreviado de la variable en el cuadro de busqueda

del buscador. Si como resultado nos dice: Usted quiso decir ... 2el nombre completo

significa que podemos usar la abreviatura, de otra forma no.

Controles

Un lugar donde todos usan prefijos para denominar a los objetos es en los controles

es en la programacion visual.

Una vez que uno comienza a utilizarlos los recuerda facilmente ya que son muy

intuitivos y, junto con el ”Intellisense”, facilitan la codificacion y lectura del codigo.

La siguiente tabla muestra las convenciones mas utilizadas:


Control Prefijo Ejemplo

Modulo mod modInicialFormulario frm frm PrincipalButton cmd cmdAceptarTextBox txt txt ApellidoCheckBox chk chk HabilitadoRadioButton rad rad MasculinoGroupBox grp grp OpcionesPictureBox pic pic FotoListBox lst lst UsuariosListView lvw lvw ArchivosCheckedListBox clst clst OpcionesComboBox cbo cbo LocalidadTreeView tvw lst UsuariosDateTimePicker dtp dtp FechaAltaToolBar tlb tlb PrincipalMenuItem mnu mnuArchivoLabel lbl lbl NombreImageList img img IconosDataGrid grd grd PedidosProgressBar pbar pbar ProcesadosRichTextBox rtf rtf DocumentoSplitter spl spl Lateral

Objetos de Acceso a Datos

Cuando utilizamos objetos de acceso a datos es conveniente que tengamos algunos

prefijos para que el codigo se vuelva mas legible.

La siguiente tabla muestra algunas recomendaciones:

Objeto Prefijo Ejemplo

DataSet ds ds LocalidadesDataRow dr dr LocalidadOleDbConnection o SqlConnection conn conn ServidorDBOleDbCommand o SqlCommand cmd cmdUpdateOleDbDataAdapter o SqlDataAdapter da daClientesOleDbDataReader o SqlDataReader rdr rdr ClientesCrystal Report rpt rpt Atículos


Convenciones para los Mensajes del Sistema

Un problema que viene desde le comienzo de la programacion 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 ortograficos, agregarles cosas,

etc.

Cuando se quisieron traducir los programas entre diferentes idiomas la cosa empeoro

bastante y las grandes empresas, entre ellas Microsoft, tuvieron que buscar una solucion

inmediata porque ademas del costo de cambiar todas las cadenas, se corrıa el riesgo

que el traductor cambiase algo mas del codigo y el programa generado podrıa contener

errores difıciles de detectar ya que solo 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 ademas 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

mas de un idioma.

La solucion aparecio del lado de los denominados archivos de recursos que vendrıa

a ser informacion simbolica incrustada dentro del programa.

De esta forma no se usa el mensaje en sı, sino que se lo referencia con una constante

simbolica, 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 formaran parte del sistema de manejo

de errores.

En primer lugar definiremos un enumerado cuyos valores vendrıan a ser como las

constantes simbolicas de los archivos de recursos:


Luego definamos la clase ErrorInfo que va a contener todas las cadenas con los

mensajes y la informacion adicional:

Ademas del Tipo de Error y el Mensaje tenemos una bandera que indica si el error

deberıa reportarse por mail como explicaremos en la seccion 2.11.

En la lınea 11 vemos que esta opcion esta habilitada por defecto pero se podrıa

cambiar para cada tipo de mensaje.

En la lınea 12 vemos que se invoca el metodo CargarDatos con un tipo de mensaje

Msg y con parametros opcionales que pasan al arreglo Args :

El metodo es mucho mas largo ya que contiene los mensajes de error, pero como

dijimos todas las cadenas estan 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 practico a esta idea definiremos una clase Mensaje con el metodo:


Este metodo se sobrecargo para que pueda recibir el tipo de mensaje o solo un string,

la idea es que todo lo que signifique mostrar mensajes al usuario pase por aquı, inclusive

si es simplemente un MessageBox.

Hay ademas un arreglo de Object que se usa para pasar informacion 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 definicion de las constantes cuando colocamos el paren-

tesis luego del nombre del metodo en el editor de codigo del Visual Studio nos aparecen

todas las constantes definidas facilitando enormemente la codificacion.


2.11. Manejo y Reporte Automatico 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 ami-

gable 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 asignacion del

TextBox a nuestra variable entera, nos aparece el error:

Cualquier usuario que recibe este mensaje seguramente se asustara, lo cerrara e ira

a hacerse unos mates sin decir nada por miedo a haber hecho algun lıo.

Afortunadamente existe una forma de capturar estos errores y presentar un mensaje

mas ameno (esta estrategia se extrajo de www.CodeProject.com).


Agregando las lıneas marcadas (de la 13 a la 15) y el metodo de las lıneas 6,

7 y 8, cualquier error sea cual fuere el tipo del mismo pasara el control al metodo

ManejoDelError donde podremos mostrar un mensaje mas amigable.

Si no utilizamos esta forma de atrapar errores podrıamos poner un TRY-CATCHen

nuestro metodo Main . Pero, o sorpresa, en ciertas ocasiones aparece la misma pantalla

del principio. La explicacion es que el TRY-CATCHsolo 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 CATCHdel Main sino directamente al runtime de .NET.

Esto muestra porque la solucion propuesta es una de las pocas que tenemos.

Pero demos un paso mas, 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 informacion de contexto requerida para identificar porque ocurrio determinado

error.

La propuesta es reportar el error por mail sin que el usuario se entere. Aunque parezca

complicado, mostraremos parte del codigo que es muy sencillo y en el CD complementario

pueden encontrar todo el codigo.

Primero creamos un HTML en nuestro proyecto y lo incluimos como recurso de la

solucion, el mismo tendra variables encerradas con el sımbolo $ de la forma $MensajeDeError$ .

Cuando ocurre un error debemos cargar la pagina que se logra leyendo el archivo

de recurso como un string para obtener el codigo HTML original, luego reemplazar las

variables en el template con los datos reales para lo que usamos el metodo Replace de

la clase String .

Vale aclarar que esta no es la forma mas eficiente porque se recorre el HTML nveces y se crean n string del tamano del cuerpo del mensaje (donde n es la cantidad de

variables), se deberıa hacer un parsing mas sofisticado e ir reemplazando las variables a


medida que las encontramos, pero a los efectos del ejemplo sera suficiente con la forma

Add hoc.

Para el envio de mails usamos una clase wrapper de la clase System.Web.Mail.MailMessagede la librerıa de .NET, el codigo 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 codigo


Este metodo devuelve un objeto Bitmap, si queremos guardarlo en el disco este serıa

el codigo a usar:9

El mail que recibimos tiene la forma, charan charan:

9 Es increıble la facilidad al manejar imagenes sobre .NET, maneja los formatos mas conocidos y losaccede a traves de la clase generica Image para abstraerse del que estamos usando.

Capıtulo 3

Herramientas de Desarrollo Agilpara .NET

Las Tecnicas de Desarrollo Agil vistas para .NET, y todas las tecnicas en general, no

tienen el impacto deseado si las tareas que proponen se tienen que hacer manualmente,

por ello veremos en esta seccion las herramientas que dan soporte a estas tecnicas y las

llevan un poco mas alla para maximizar la productividad.

No daremos una descripcion detallada de cada una sino que nos limitaremos a mostrar

la funcionalidad basica de cada una, fomentando al lector a probarlas y a seguir la

documentacion que las acompanan y que son muy graficas y completas.

La mayorıa de las herramientas son gratuitas y su codigo fuente esta disponible en

internet. Es una tarea interesante investigar el codigo y tratar de hacer cambios para

agregar funcionalidad y ver que ocurre, porque la mejor de aprender algo en el mundo

de la computacion es probando y teniendo mucha paciencia.

En el Apendice B (Pag. 97) estan los enlaces a los sitios de cada herramienta tratada

y de muchas otras otras.

En el CD complementario se encuentran el codigo fuente y el ejecutable de cada una

en las versiones disponibles a Abril de 2005.

47

CAPITULO 3. HERRAMIENTAS DE DESARROLLO AGIL PARA .NET 48

3.1. Generacion Semi-Automatica de Codigo

Por experiencia personal creo que existe una sola forma de tener exito con la gen-

eracion de codigo de forma automatica y es a traves de plantillas editables.

Los programas que funcionan como una caja negra que uno les da la definicion 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 agre-

gar funcionalidad y no entendamos nada del codigo generado los problemas compensaran

a aparecer, mas aun, cuando cambie el esquema de la Base de datos y queramos regenerar

el codigo se pisaran los cambios (si es que logramos concretarlos).

Por estas razones la herramienta ideal para generar codigo 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 codigo para asignarle a variables

var1, var2, var3, ..., un valor de caracter consecutivo debemos escribir la plantilla:

Todo lo que esta entre <%y %>se ejecuta en CodeSmith porque es parte del codigo

de la plantilla, lo que esta fuera de estos sımbolos se copia literalmente al resultado.

El sımbolo <%=indica que se evaluara la expresion que esta a su derecha y se escribira

el resultado en la salida.

Al ejecutarlo obtenemos:

Este ejemplo no tiene mucho sentido pero si utilizamos la funcionalidad de CodeSmith

de manejar el esquema de las bases de datos podemos definir:


Hay algunas instrucciones un poco raras pero veamos que significan:

• En la lınea 2 le decimos a CodeSmith que nuestra plantilla tiene una propiedad y

que la misma es de tipo TableSchema lo que indica que representa una tabla de

alguna fuente de datos.

• En la lınea 3 se importa el Assembly que contiene la definicion de los tipos rela-

cionados con las fuentes de datos.

• De la lınea 7 a la 9 lo que hacemos es poner el nombre de la columna, un As y

finalmente el tipo de la columna pero en VB.NET.

• En la lınea 13 se oculta la funcion GetVBVariableName que lo unico que hace

es devolver el tipo de una columna pero en VB.NET.

Si lo abrimos y utilizamos por ejemplo la tabla Titles de la base de datos Northwind

que viene con el Sql Server el resultado es:


Ya tenemos hecha gran parte de la plantilla que resuelve el mapeo relacional porque

podemos generar con un click la estructura de una tabla, es realmente facil, no ??

Veamos ahora como serıa una plantilla para generar codigo de acceso a datos a traves

de un DataReader de .NET.

La filosofıa es mas o menos la misma, lo importante es el ciclo For que abarca de la

lınea 19 a la 22 , allı se hace la asignacion de la columna correspondiente de la tabla a

la variable de la estructura que cumple la funcion de representar el mapeo relacional.

Para el ejemplo usamos directamente una instruccion SELECTen el codigo, esto no

es lo mas recomendable, generalmente se debe generar un stored procedure para cada

metodo basico (Fetch , FetchAll , Insert , Update , Delete ) para evitar problemas

de mantenibilidad y de seguridad.

El resultado de correr esta plantilla contra una tabla de Localidades se puede ver en

la siguiente pagina.

Los pasos siguientes serıa hacer una plantilla para generar los stored procedures

de los que hablamos con algun prefijo en particular para distinguirlos de los que no

son son generados automaticamente, por ejemplo podemos usar pga por Procedimiento

Generado Automaticamente y pgu para los Procedimientos Generados por los Usuarios.

Los que comienzan con pga nunca deberıan tocarse ya que si se vuelven a generar se

perderıan los cambios y nadie se darıa cuenta.


Finalmente podrıamos crear una plantilla para las entidades de negocios de una

arquitectura en capas con operaciones de edicion y de control de estados como propone

Rockford Lhotka en su libro Expert One-on-One Visual Basic .NET Business Objects

[Lho03].

Quiza la forma en la que este explicado allı no sea del todo practica por la utilizacion

de WebServices y algunas opciones de DataBinding un tanto complejas pero se pueden

tomar como moldes para hacer nuestras propias plantillas.

Como conclusion podemos decir que cada vez existen mas proyectos para hacer mapeo

relacional a traves de plantillas. Algunos son tan completos que la complejidad para

entenderlos es altısima y nos lleva mucho tiempo.

Lo recomendable es buscar alguno sencillo o extender las plantillas aquı propuestas

y a medida que entendemos la idea ir escalando hacia un framework mas completo.

Personalmente he usado las plantillas incluso para generar el codigo detras de las

pantallas de ABM que son generalmente muy parecidas y creanme que uno ahora mucho

tiempo y comete menos errores. La ventaja principal es que las asignaciones de las

propiedades de las estructuras a los controles y viceversa, las declaracion, los tıtulos de

las columnas, todo es generado por las plantillas, evitandonos el Copy and Paste que

siempre trae problemas.


3.2. Control de Versiones y Programacion Concur-rente

CVS (Concurrent Versioning System)

El Sistema para control de versiones y programacion concurrente mas utilizado es el

CVS.

Todos los proyectos relacionado con Linux tienen sus repositorios de codigo en CVS,

ya que el mismo deriva de un antiguo sistema de control de versiones denominado RSH

que surgio paralelamente con Unix.

Los proyectos open source hosteados en la pagina www.SourceForge.net, ellos

citados en esta tesis, tambien usan este sistema para que los programadores puedan

acceder concurrentemente al codigo y para tener un historial de los cambios.

El cliente de CVS mas conocido y facil de usar es el TortoiseCVS:

El mismo se integra totalmente con el Explorador de Windows, agregando opciones

al menu contextual de cada archivo o directorio.

Pasos para crear un repositorio y poner un proyecto bajo control del CVS:

1. Hacer click con el boton derecho sobre la carpeta que deseamos agregar, abrir el

submenu CVS y seleccionar Make New Module... y completar los datos que nos

solicite.

www.SourceForge.net


2. Hacer click con el boton derecho sobre la carpeta y seleccionar CVS Add Contents...

3. Hacer click con el boton derecho sobre la carpeta y seleccionar CVS Commit...

4. Observar que en el Explorador de Windows nos muestra las versiones de cada archivo

y los iconos que indican si estan modificados o no...


SVN (Sub-Version)

Subversion nacio para ser el reemplazante natural del CVS y para cubrir algunas de

sus principales falencias, entre ellas:1

• Soporte transaccional para los commits y updates.

• Posibilidad de Renombrar Directorios y Archivos.

• Agregar Meta-data a los archivos.

• Permitir manejar diferencias en archivos binarios, guardando solo los cambios y no

todo el archivo como en el CVS.

• Manejo eficiente de los Branch y Tags (en CVS eran proporcionales al tamano del

proyecto).

El proyecto tiene una velocidad de maduracion asombrosa y cada vez tiene mas

adeptos. El cliente de SVN mas conocido y facil de usar es:

Los pasos para crear un repositorio son similares a los mostrados en para CVS. Si

el lector desea entrar en mas detalles se recomienda leer la ayuda que acompana el

programa que es muy grafica y completa.

WinMerge

Este no es una herramienta de control de versiones pero es un complemento de estas

ya que se encarga de mostrar las diferencias entre dos versiones de un archivo.

Ademas permite que lo utilicemos para resolver conflictos cuando dos programadores

cambian al mismo tiempo la misma lınea de codigo. Como nos muestra las diferencias

lado a lado es sencillo encontrar el problema y solucionarlo.

1 En el CD complementario hay una comparacion exhaustiva entre estos dos sistemas.


3.3. Refactoring

ReSharper

Este es el programa de refactoring mas popular en el mundo de .NET, mas especial-

mente para los adeptos a C#.

Los refactoring mas comunes se pueden hacer con un solo click

Pero ademas cuenta con otras opciones como busqueda rapida en archivos y clases,

mejora el Intellisense del VS.NET, tiene templates de codigo, genera asignaciones au-

tomaticamente.

La mejor caracterıstica para los desarrolladores de C# es que hace un analisis en

tiempo real del codigo y nos muestra junto a la barra de desplazamiento los lugares con

errores o warnings, marcandolos con diferentes colores. Algo similar viene integrado en

Visual Studio para VB.NET, sin embargo para saber si tenemos errores en codigo escrito

en C# debemos compilar todo el proyecto. Por ello si usamos el ReSharper todo esto

pasa a ser un recuerdo y vemos como aumenta nuestra productividad.

Esta es una de esas herramientas que cuando las instalamos y vemos como nos sim-

plifica todo no podemos dejar de usar.

En el CD complementario se encuentra un version de demostracion o se puede bajar

de la pagina oficial la ultima version.

CodeSmart

La palabra mayor en cuanto a add-ins para VS.NET, sobre todo para los que venimos

del mundo de Visual Basic, es Code Smart.

La ultima version para .NET de este complemento, la 2005, es completısima y nos

permite aumentar nuestra productividad porque automatiza las tareas mas tediosas.

Este programa se integra perfectamente con el Visual Studio .NET agregando fun-

cionalidad en los menus contextuales y un nuevo menu principal.


Como se ve en la figura cuenta con gran cantidad de opciones:

Este add-in es indispensable si pasamos muchas horas programando con Visual Stu-

dio, en el CD complementario encontraran una version de demostracion o directamente

pueden bajar la ultima de la pagina oficial. Cuando termina el perıodo de prueba sim-

plemente se deshabilitan algunas funciones pero las otras siguen funcionando bien.

Entre las mejores caracterısticas tenemos:

• Corrige las faltas ortograficas dentro de los strings (podemos bajarnos el diccionario

en castellano de la pagina)

• Cuenta con el Code Flow Explorer que genera un arbol de llamadas entre metodos

haciendo un analisis del codigo fuente.

• Extiende las funciones de Busqueda y Reemplazo del Visual Studio.

• Genera la documentacion XML para VB.NET.

• Formatea el estilo del codigo a nuestro gusto.

• Genera Estadısticas del codigo contando cantidad de lıneas de codigo, de comen-

tario, en blanco, etc.

• Ordena los Miembros de una clase en el orden indicado.


• Inserta codigo al principio o al final de los metodos que cumplen con determinada

caracterıstica.

• Cuenta con Snippets de Codigo que se pueden compartir con el resto del equipo.

• Fuerza a que se utilicen las convenciones para nombrar controles o variables.

• Es totalmente configurable.

Soporte en Visual Studio 2005

Visual Studio 2005 incluira soporte integrado para hacer los refactoring mas comunes

entre ellos los tratados en la seccion 2.3 (pag. 19).

Un listado no exhaustivo de los soportados incluye:

• Rename

• Extract Method

• Encapsulate Field

• Extract Interface

• Promote Local Variable to Parameter

• Remove Parameters

• Reorder Parameters

En el sitio oficial del Visual Studio nos indican las nuevas caracterısticas que tendra

este entorno y muestran un ejemplo de lo facil que sera hacer refactoring de ahora en

adelante:


Soporte en Delphi 2005

Siguiendo la misma lınea que Microsoft, Borland incluyo en Delphi 2005 una gran

cantidad de herramientas para hacer refactoring y mejoro el IDE tratando de recuperar

el mercado perdido por el poco exito de Delphi 8.

Por lo que dicen las crıticas esta vez Borland nos dara un entorno con la calidad a

la que estamos acostumbrados de ellos y no algo improvisado como fue Delphi 8 cuyo

lanzamiento fue apresurado y que para corregirlo ya llego al Service Pack 3.

Refactoring Explorer de Delphi 2005


3.4. Testing de Aplicaciones

NUnit

La herramienta mas popular de testing para .NET es NUnit.

Nacio como la version portada para .NET de la popular herramienta de Java (jUnit),

pero luego, en la version 2, se renovo totalmente para hacer uso de facilidades avanzadas

de .NET como los atributos y la reflexividad.

La idea de esta herramienta es hacer testing de caja negra desde el punto de vista

del cliente de la clase o elemento del sistema a testear.

Inclusive se puede llevar un paso mas alla y utilizarla para implementar Test Driven

Development (como se explico en la seccion 2.4).

Veremos un ejemplo sencillo para mostrar como funciona. Para hacerlo simple el

ejemplo parecera de juguete pero debemos recordar que lo importante son los conceptos

de como usar NUnit y no de para que lo estamos usando.

Primero definamos una clase que herede de la clase Stack del .NET Framework, que

se encuentra en el namespace System.Collections . La misma agregara los metodos:

La descripcion e implementacion de los metodos es:

PopAll()

Quita todos los elementos de la Pila y los devuelve como un arreglo de objetos.

PopRange(n as Integer)

Quita n elementos Pila y los devuelve como un arreglo de objetos.


PushRange(objs as Object())

Agrega los elementos del arreglo objs a la Pila.

Para testear la clase creamos un nuevo proyecto llamado TesisStackTests de

tipo Librerıa de Clases y agregamos la referencia al assembly nunit.framework y al

proyecto donde esta nuestra clase Pila como muestra la figura:

Expliquemos brevemente cuales son los atributos que podemos usar con NUnit:

TestFixture

Indica que la clase contiene Casos de Tests.


Test

Indica que el metodo debe ser tratado como un Test.

SetUp

Indica que el metodo se ejecutara antes de cada Test.

TearDown

Indica que el metodo se ejecutara al finalizar cada Test.

TestFixtureSetUp

Indica que el metodo se ejecutara una vez antes de cualquier Test.

TestFixtureTearDown

Indica que el metodo se ejecutara una vez al finalizar todos los Test.

Ignore

Indica que el Test no se ejecutara y sera ignorado.

ExpectedException

Indica que para que el Test sea exitoso debe generar la excepcion indicada.

Mostremos como serıa el esquema de la clase con los tests:


En mas detalle, el codigo de cada test serıa:


Y ahora la mejor parte, si tenemos instalado el TestDriven.NET para ejecutar los

tests simplemente hacemos dos clicks ...

Finalmente ası muestra el resultado NUnit-Gui:


Soporte en Visual Studio 2005

Visual Studio .NET 2005 incluira un soporte para hacer testing de la misma forma

de la que se lo hace con NUnit.

Microsoft intenta con esto aprovechar los conocimientos de la comunidad de desar-

rolladores que encontro en Nunit una herramienta que siempre buscaron y que facilite

la tarea de testing.

En el mismo IDE se podra navegar por los tests, ignorarlos, etc.


3.5. Generacion Semi-automatica de Documentacion

Como mostramos en la seccion 2.5 es muy difıcil mantener la documentacion man-

ualmente, es necesario utilizar herramientas que a partir del codigo generen diagramas

y documentos sobre el codigo o las tablas del sistema.

La herramienta mas popular para la generacion de documentacion en .NET es NDoc.

Esta utiliza los archivos XML que se crean al compilar una aplicacion en C# y junto con

los assemblies genera la documentacion:

El uso de la herramienta es muy sencillo:

• Ejecutamos el entorno grafico.

• Seleccionamos los assemblies a documentar.

• Seleccionamos el formato de salida.

• Configuramos el estilo de la documentacion.

• Presionamos en compilar documentacion.

Graficamente:


Y el chm que genera nos queda:

Es tan sencillo usar NDoc que no hay mucho mas que explicar simplemente debemos

sentarnos a documentar lo que creemos necesario.

VB.DOC

Un problema grave es que por algun motivo Microsoft no incluyo soporte para doc-

umentacion XML en VB.NET. De todas formas existe una herramienta a la cual le

podemos dar un proyecto de Visual Studio .NET y extraera los comentarios XML del

codigo en Visual Basic.

La herramienta se llama VB.DOC y la podemos encontrar en www.SourceForge.net.

Para usarla basta con darle el proyecto y automaticamente extrae el XML tal como

lo hace el compilador de C# de Microsoft.

Luego de esto no hay mas diferencias ya que NDoc no distingue en que lenguaje esta

escrito lo que documenta, solo necesita un assembly y el XML asociado.

www.SourceForge.net


3.6. Compilacion e Integracion Automatica

Visual Studio .NET es el IDE mas completo y poderoso que desarrollo Microsoft, las

ventajas van desde la variedad de las plantillas de proyectos, la increıble facilidad del

Form Designer hasta las herramientas de integracion con Bases de Datos.

VS.NET provee un excelente entorno para el desarrollador individual, pero trae poco

soporte para equipos de trabajo (al menos en la version 2003), otras falencias incluyen:

• No facilita el desarrollo entre personas en distintos lugares.

• No se puede automatizar la ejecucion de los test.

• No trae soporte para otros sistemas de control de versiones que no sean MS Source

Safe (ya sabemos por que no ??).

• No se puede hacer Integracion y Compilacion centralizada.

Para solucionar la parte de automatizacion de tareas de construccion, control de

versiones, testing y distribucion se desarrollo NAnt.

NAnt

NAnt es un herramienta de generacion automatica totalmente gratuita que vendrıa

a ocupar el lugar del MAKE pero en los tiempos modernos.

Se llama NAnt por Not Ant indicando que no es la herramienta para Java portada

sino algo diferente. Aunque la idea es la misma la forma en la que esta implementa

difiere, ya que las tareas estan escritas en dll´s de .NET y se integran como pluggins.

NAnt es facil de usar, nos podemos trabar un poco al principio pero cuando le

agarramos la mano todo va sobre ruedas.

Cuenta con 4 elementos que se representan con la sintaxis estandar de XML:

Tasks

Son los comandos que le damos a Nant. La mayorıa vienen con NAnt pero se

pueden agregar otras facilmente.

Las tareas pueden representar tareas simples sobre archivos (copy , move o delete ),

comandos avanzados (zip , unzip , mail , cvs ), comandos de .NET (csc , vbc ,

tlbimp ) y otros comandos interesantes (nunit , regex )

Existe tambien el condicional if pero con una sintaxis un poco diferente y foreachpara los loops.

Veamos como es la sintaxis en XML de la tarea copy :

<copy file=”archivo1.cs” tofile=”archivo1.bak”/>


y la de la tarea mail :

<mail from=”[email protected]”[email protected]=”Resultados de la Generación.ar”mailhost=”smtp.nombreempresa.com.ar”

><attachments>

<includes name=” * reporte.txt”/></attachments></mail>

El proyecto NAntContrib (nantcontrib.sourceforge.net) agrega mas tareas a

las que vienen por defecto entre otras: codestats , mkiisdir , deliisdir ,

SQL, etc

Targets

Los targets son colecciones de tareas con nombre. Cuando se invoca un target se

ejecutan las tareas en el orden en las que se encuentran.

Pueden depender a la vez de otros targets, en este caso siempre que se ejecute

un target se ejecutara antes la lista de dependencias. En el siguiente ejemplo se

ejecutara antes clean que prepare :

<target name=”clean”

description=”borra los dirs: bin, src y doc”>

<del dir=”bin”/>

<del dir=”src”/>

<del dir=”doc”/>

</target>

<target name=”prepare” depends=”clean”

description=”crea los dirs: bin, src y doc”>

<mkdir dir=”bin”/>

<mkdir dir=”src”/>

<mkdir dir=”doc”/>

</target>

Si varios targets dependen del mismo este solo se ejecuta una vez.

Properties

Las propiedades vendrıan a ser las variables de un script de NAnt.

nantcontrib.sourceforge.net


La diferencias esta en que le podemos dar un valor solo una vez, a partir de allı

una propiedad es inmutable.

Las propiedades pueden tener un valor por defecto, pueden ser leıdas de un archivo

externo o pasadas como argumento cuando se inicia la ejecucion del script.

Hay un conjunto de propiedades predeterminadas como: nant.version , nant.filename ,

nant.settings.defaulframework .

La forma de definir una propiedad es la siguiente:

<property name=”host.name” value=”NuestraEmpresa.com”/>

Projects

Un proyecto es una coleccion de properties, targets y tasks.

Puede estar en un unico archivo o se puede dividir en varios.

Un ejemplo de la sintaxis de project :

<project name=”miProyecto”>

<property name=”project.author” value=”Marcos Meli”/>

<target name=”clean”>

<del dir=”bin”/>

</target>

<!- etc. ->

...

</project>

Para ejecutar un script de NAnt simplemente usamos la lınea de comando:

nant /f:NuestroScript.build

Si no le damos el nombre del script NAnt seguira los siguientes pasos:

1. Busca en el directorio actual un archivo ”.build”.

2. Si no lo encuentra muestra el error.

3. Si hay solo un archivo ”.build” lo ejecuta.

4. Si hay mas de un archivo ”.build”:

a) Si alguno se llama ”default.build” lo ejecuta.

b) Si ninguno se llama ”default.build” muestra un error.


Cruise Control .NET

Es herramienta gratuita que se ubica a un nivel mayor de abstraccion en cuando a

automatizacion que NAnt. Es mas fiel a lo explicado en la seccion 2.6 de Integracion

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 version 0.9, es muy facil de instalar y configurar gracias a la

documentacion que lo acompana que es muy completa.

La caracterıstica mas interesante es que genera reportes de cada paso, ya sean de

compilacion, testing, integracion, validacion, etc.

Los mismos se pueden ver desde una pagina web o se le puede pedir al sistema que

los envie por mail en cada integracion.

Soporte Visual Studio 2005

Lo mas asombroso de lo que sera el nuevo entorno de Microsoft es la integracion

completa de todas las tareas de desarrollo.

Visual Studio 2005 incluira soporte desde el modelado de clases, el testing, la docu-

mentacion hasta la compilacion automatica.

En el Cd complementario se incluye un articulo disponible en la pagina oficial del

VS.NET 2005 que indica las nuevas caracterısticas.

Un diagrama que encontramos allı muestra como esta planteada la integracion:


3.7. Almacenar Nuestra Librerıa de Codigo y Con-troles

Durante anos hubo aplicaciones para guardar snippets de codigo y ordenarlos, la

mayorıa comerciales, pero para .NET existe un programa que a todos estos los deja

kilometros atras 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, esta en perfeccionar las cosas no en inventarlas, porque este programa es

la perfecta union de todas las ideas buenas para almacenar codigo e informacion que

existen.

Sinceramente cuesta mucho explicar todo lo que hace lo mejor es probarlo y darnos

cuenta que esta hecho para nosotros.

Ademas de completo tiene un muy comoda y usable interfaz de usuario como se

muestra en la figura:

Pantalla principal del CodeLib

Algunas de las caracterısticas son:

• Permite almacenar el codigo 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.


• Guarda las descripciones, codigo, archivos adjuntos e imagenes dentro de la base

ası que para llevarlo a otro lado es extremadamente facil.

• Compacta las Bases de Datos y hace Backups automaticos de las mismas.

• Podemos editar la descripcion de cualquier item con el editor embebido.

• Podemos bajar paginas Web con el download manager y guardarlas como parte de

algun item.

• Se pueden bajar del mismo sitio 4 bases de datos con codigo, 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 aun mas comodo el

trabajo ya que aparecen los snippets como una ventana mas en el IDE.

• las posibilidades de Busqueda 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 desar-

rollo.

Los screenshots muestran claramente la abundancia de funcionalidad:

Barra de Herramientas


Menus Contextuales

Este es un perfecto ejemplo de como deben ser los programas. Estan cuidados todos

los detalles y maximizada la funcionalidad. Una verdadera joya.


3.8. Seguimiento de Proyectos

Segun lo explicado en la tecnica de la seccion 2.8 el seguimiento se debe hacer de

una manera automatica, 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 mas conocido.

• Es uno de los 10 con mayor actividad de SourceForge.

• Es agradable y muy facil de usar

• Excelente manejo de calendarios (ver imagen)

• Totalmente modular es muy sencillo poner y sacar partes

• Existen gran cantidad de modulos 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 basicas como el seguimiento de Bugs.


Los calendarios son perfectos y nos permiten cambiar de granularidad (diaria, sem-

anal, mensual y anual) con un solo click.

DotProject

Esta otra alternativa es mas 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 facilmente.


Excel

Si estos sistemas nos parecen complicados por su manejo o instalacion al menos

podemos utilizar el Excel que aunque no sea muy respetado en el mundo academico 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 modulos o importancia) con las distintas activi-

dades y completar el porcentaje que se lleva completados de cada una de ellas o algo

similar.

Con el tiempo ir viendo que mas necesitamos y hacer macros o formulas par a facilitar

las tareas.

El ultimo paso serıa incluir programacion a traves de Visual Basic para formar nuestro

propio sistema de Project Tracking. Suena interesante no ?


3.9. Revision y Analisis de Codigo

Reflector

Todo lo bueno que trae .NET seguro que se paga por otro lado, uno de ellos es la

proteccion o privacidad del codigo.

Al igual que pasa en otros lenguajes interpretados, como Java, es muy facil desensam-

blar una dll o un exe de .NET es tan sencillo como bajarse el Reflector de la pagina oficial

de Lutz Roeder, levantar el assembly y elegir el metodo 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 codigo es algo que fue contemplado por

Microsoft desde el comienzo. Para tratar de reducir el problema incluyo junto con el

VS.NET un ofuscador de codigo para que las empresas puedan proteger la propiedad

intelectual de sus programas.

Algo mas interesante es que MS no protegio las librerıas basicas del framework,

dejando las puertas abiertas para que los desarrolladores extraigan informacion sobre

buenas practicas o vean como se implementan los controles base de los WinForms.


Microsoft FxCop

Si pensamos que programamos bien ... basta con darle nuestro codigo a este programa

de Microsoft para decepcionarnos.

El programa analiza los assemblies que le damos utilizando instrospeccion 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 Seccion 3.4 nos muestra:

Pantalla Principal del FxCop


En total encontro 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 Seleccion de Reglas

Tambien podemos hacer doble click sobre cualquiera de los errores para ver una de-

scripcion detallada del mismo, a que regla pertenece y la razon de porque se lo considera

un error o posible error.

Pantalla con el Detalle de un Error


3.10. Profilers

Entre las herramientas avanzadas que un programador deberıa conocer se encuentran

los profilers.

Los lenguajes actuales como trabajan en un nivel de abstraccion muy alto nos llevan

a escribir codigo 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

este en produccion 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 mas comun en .NET que tiene un altısimo nivel de abstrac-

cion a la hora de programar, esto se traduce en muchas capas intermedias de software,

por lo tanto una instruccion 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, metodo por metodo 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

codigo 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 como 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.


NProf

NProf es un profiler de tiempo de ejecucion, es opensource y se encuentra cerca de

su version 1.0.

Tiene una gran cantidad de opciones pero no es muy grafico (al menos por ahora)

cuesta encontrar indicios de rendimiento bajo.

Nos muestra cuantas veces se ejecuto cada metodo del codigo que estamos analizando.

Se integra perfectamente con el Visual Studio.NET y podemos ejecutarlo directa-

mente desde allı.

En el CD complementario se encuentran los ejecutables y el codigo fuente de este

programa.

Compuware DevPartner Studio

Sin lugar a dudas el mejor de todos los profilers.

Cuenta con analisis estatico de codigo, profiling de alocacion, profiling de tiempo

de ejecucion, captura todos los errores y nos muestra donde ocurrieron, permite hacer

profiling de aplicaciones distribuidas y mucho mas.

Es muy funcional y totalmente grafico. Muestra en tiempo real la memoria alocada,

cuales son los elementos con mayor cantidad de instancias, cuando se ejecuta el GC, etc.

Mostremos a continuacion un grafico del profiler de memoria en tiempo real:


Lo bueno es que Compuware ofrece una version 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 funcion muy similar es NPerf.

Esta herramienta provee un framework para hacer tests comparativos y mostrar los

resultados. La idea es que escribamos el codigo para hacer la misma cosa de diferentes

formas y el framework ejecutara estos metodos tantas veces como le digamos, para difer-

entes tamanos de muestra y luego representara los promedios de los tiempos resultantes.

En la figura mostramos una comparacion entre el metodo Contains de las diferentes

colecciones que provee .NET.

Capıtulo 4

Check Lists de los Temas Tratados

En este Apendice se incluyen consejos y buenas practicas a tener en cuenta cuando

utilicemos alguna de las tecnicas o herramientas propuestas en esta Tesis.

Si las tenemos en cuenta es mas sencillo llegar al resultado esperado y nos evitara

encontrarnos con sorpresas desagradables.

4.1. Control de Codigo Fuente

X Usar un sistema de control de codigo fuente para proteger el codigo 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

documentacion.

X Documentar los cambios cuando se hace un Commit para que el historial sea mas

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 codigo 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 algun

cambio sera mas sencillo de realizar si nos manejamos de esta forma.

83

CAPITULO 4. CHECK LISTS DE LOS TEMAS TRATADOS 84

4.2. Refactoring

X No dejar las cosas que no estan del todo bien hasta que se revelen contra nosotros,

tratar de cambiarlas antes.

X Si encontramos una negativa al pedir autorizacion para hacer refactoring, y nos

parece necesario hacerlo, debemos encontrar la forma de hacerlo de todos modos.

X Tratar de hacer pequenos 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 quisieramos 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 mas 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

atras.

4.3. Testing

X Escribir tests de unidad (unit-tests) para la mayor parte del codigo que podamos.

X Escribir los test a medida que avanzamos. No dejarlos para un manana que nunca

llegara.

X Asegurarse que el nuevo codigo pasa todos los test de regresion antes agregarlo al

sistema de control de codigo fuente.

X Usar una herramienta como NUnit para hacer del testing un proceso sencillo y

repetible.

X Los Tests tambien 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.


4.4. Documentacion

X Usar el ”Vea Tambien” para navegar facilmente por la informacion relacionada.

X Usar Tablas de Contenidos, Indices, Busqueda e Links para que sea mas sencillo

localizar la informacion.

X La mayorıa de los temas de ayuda deben ser cortos y focalizados.

X Utilizar graficos, no solo texto (respetar la regla: ”una imagen vale mas que mil

palabras”).

X Proveer una manera para que los usuarios puedan darnos feedback facilmente (ya

sea a traves de un mail o guardando informacion en un archivo y analizarla luego).

X Imprimir las partes mas usadas de la documentacion para facilitar la lectura.

X Procurar que la ayuda sea sensitiva al contexto y orientada a la tarea que se esta

realizando.

X Cuando se esta documentando algo pensar en como se va a actualizar la docu-

mentacion cuando las cosas cambien.

4.5. Compilacion e Integracion

X Usar una herramienta de compilacion e integracion continua como (como NAnt o

Cruise Control.Net) para hacer de este proceso algo simple y repetible.

X Evaluar varias herramientas de generacion y quedarse con la que mejor se adapte

al proyecto y al bolsillo.

X Integrar la aplicacion de forma regular (generando ademas la documentacion y

ejecutando los casos de Test). Muchos recomiendan que diariamente es lo ideal.

X Hacer backups de las salidas producidas en la generacion diaria (no olvidar la DB).

X La integracion no es solo de los modulos del sistema sino que abarca todos los

artefactos que componen el desarrollo como: las bases de datos, documentacion,

tests, instalaciones, backups, etc.

X Tratar de hacer integraciones continuas para asegurar que el sistema sigue estable

y los conflictos se detectan a tiempo.


4.6. Generacion de Codigo

La generacion de Codigo es una herramienta desestimada por la mayorıa de los de-

sarrolladores y en esta tesis mostramos lo util 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

codigo considerar usar una herramienta que genere ese codigo.

X Evaluar varias herramientas de generacion de codigo hasta encontrar la que mejor

encaje en nuestro proyecto (aquı se mostro CodeSmith que es gratuito y facil de

usar, pero hay otras alternativas muy completas).

X Utilizar las herramientas de control de versiones sobre las entradas de los gener-

adores y no sobre las salidas de los mismos.

X Analizar sinceramente cuanto tiempo ahorramos si escribimos directamente la solu-

cion y cuanto si hacemos una plantilla para generar el codigo.

X Pensar como hacer si se debe escalar a una herramienta mas completa.

4.7. Convenciones

X Buscar en internet convenciones especıficas para el lenguaje utilizado y seleccionar

alguna.

X En la pagina 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

razon de por que 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 automaticamente los problemas de nombres y

prestar atencion a las justificaciones de porque esta mal lo que hacemos.


4.8. Generales

Por ultimo 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 esque-

ma general.

X Desconfiar de cualquier parte del sistema porque todo puede fallar inclusive la

instruccion mas absurda.

X No prometer cuanto tardaremos en hacer algo que nunca hicimos o no entendemos

del todo porque caeremos presos de nuestras palabras.

X Disenar 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 ultima tecnologıa disponible, usar la ante ultima y monitorear como

evoluciona la ultima para estar en tema y no sorprendernos cuando se convierta

en un estandar.

X Debemos comprender que ninguna metodologıa es universal. Usar el sentido comun

para extraer lo mejor de cada una, tomar partes de otras y por ultimo quedarse

con las tecnicas 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 practica

del desarrollo agil espero que hayan podido comprender un poco mas 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 anos como la pro-

gramacion en cascada, documentacion excesiva, el sobrediseno, la poca comunicacion, el

escaso feedback, el ”do it yourself”, etc .

Cada vez mas personas estan de acuerdo con esto. Las grandes empresas estan cam-

biando sus pautas de desarrollo por metodologıas mas livianas.

inclusive Microsoft saco 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 programacion para la mayorıa esta mas que claro y se resume en una

palabra: .NET. Los que no estan 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 maximo no podemos dejar pasar por alto la cantidad de

herramientas, codigo y ayuda que nos brinda internet y que son totalmente gratuitas.

Creo que el secreto esta en ver como desarrollan aplicaciones otras personas con mas

experiencia y tomarlo como base para comenzar nuestros proyectos. Luego investigar

como mejorar estas ideas y adaptarlas para que sean optimas para nuestra forma de

trabajo.

Finalmente automatizar con plantillas de codigo 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 quevalen la pena porque se hacen seguido o cambian constantemente

88

CAPITULO 5. CONCLUSIONES 89

que ahorramos al no escribir nosotros todo el codigo lo podamos invertir aprendien-

do mas, mejorando el sistema o haciendo refactoring de las plantillas existentes para

documentarlas, extenderlas, etc.

Los que en algun momento se imaginaron un mundo con componentes de todo tipo

y al alcance de la mano, de facil integracion, interaccion 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 comun

de ejecucion que siempre se necesito, que con CORBA no tuvo exito, pero que Microsoft

logro con su framework.

Sigo insistiendo en que la clave esta en la automatizacion o semi-automatizacion

de las tareas repetitivas2 o que dependen de otra parte del sistema (como las clases del

mapeo relacional que mostramos en esta tesis que es muy facil de automatizar).

Steve McConnell escribio en su libro ”Code Complete 2da Edicion” [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 solucion.

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 mas generico como que el importador tenga meta-datos sobre el

formato del archivo a leer y la tabla en donde insertarlo.

La decision como siempre depende del contexto; si estamos seguros que lo vamos a

usar una vez para importar los datos de un unico archivo quiza la opcion 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 lashace les pone pocas ganas, luego cuando el sistema falla a nadie se le ocurre que lo que puede andarmal es que en la estructura que mapea con una tabla dice float donde deberıa decir int y ademas deltiempo perdido en realizar la tarea hay que sumar el tiempo que gastamos en encontrar estos erroresque son muy escurridizos. Usando plantillas sabemos que esto no ocurrira y si aparece algun error seregeneran las capas y listo.

3 Cuando decimos Ad hoc nos referimos al hecho de utilizar algo ası como un ReadLine y particionarel String insertandolo en una tabla determinada

CAPITULO 5. CONCLUSIONES 90

algo suficientemente generico 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 creanme

que lo van a necesitar).

Con respecto a .NET tenemos que entender que marco un antes y un despues en el

desarrollo de sistemas y en la forma de programar.

No entender los alcances de esta revolucion nos cerrara 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 Interes sobre Desarrollo Agil

Muchos temas temas de actualidad no fueron cubiertos en esta tesis por cuestiones

de tiempo y espacio.

Es interesante buscar informacion de los siguientes temas ya que pueden ayudar a

nuestra productividad y a nuestra experiencia:

Tecnicas no tratadas

• Abstraccion de Pantallas Comunes con Formularios Heredados.

• Pair Programming.

• Patrones de Diseno.

• Construccion de Tablero de Comandos para el soporte de decisiones.

• Logging y Trace de Aplicaciones.

• Consejos para la Creacion de Interfaces de Usuario. Buscar info en www.JoelOnSoftware.com

Herramientas no tratadas

• Extension del Visual Studio con Macros y Addins.

• Usar Componentes de Correccion Ortografica.

• Creadores de Instalaciones.

www.JoelOnSoftware.com

Apendice A

Reflexiones Sobre el Desarrollo deSoftware

A.1. Systemantics

Aunque el comportamiento de los sistemas complejos esta condicionados por el CAOS

intrınseco en los mismos, hubo personas que investigaron leyes sobre estos comportamien-

tos 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 mas rapido, mas facil 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 instalandolo, configurandolo y nada mas.

Apareceran nuevos problemas con la sola presencia del nuevo sistema. Una

vez instalado, no se ira mas, sino que crecera y lo abarcara todo. Comenzara a

hacer cosas extranas y sorprendentes, fallara de formas que nunca pensamos

que fueran posibles; inclusive se opondra a su funcion original.

Nos distorsionara la perspectiva y nos hara olvidar el objetivo inicial que

tenıa el sistema.

Nos pondra ansiosos y lo forzaremos para que trabaje sea como sea.

Eventualmente dara algun resultado y nos alegraremos creyendo que es lo

que siempre quisimos.1

En este punto llegamos al maximo de la invasion... hemos sido absorbidos

por el sistema... ahora somos gente de sistemas.

1 Aunque lo que terminamos consiguiendo era mas facil y economico hacerlo antes de implementarel 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 esta escrito en el ano 1978 y esta cita tiene hoy mas

vigencia y sentido que en aquella epoca porque los sistemas actuales abarcan todo y son

cada vez mas complejos, convirtiendose en campos minados llenos de bugs, esperando

para explotar.

Las leyes que mas se destacan de las citadas en el libro son:

• Si algo puede salir mal, saldra 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 funcionamien-

to puede que no se detecte por largos perıodos (si es que en algun momento se

detectan).

• Los sistemas pueden fallar en un numero infinito de formas.

• Los sistemas tienden a crecer, y cuando crecen, desplazan todo lo que esta en su

camino.

• Cuando los sistemas crecen en complejidad, comienzan a oponerse a la funcion

original que debıan realizar.

• Cuando los sistemas crecen en tamano, pierden funcionalidad basica.

• Mas grande es el sistema, menos las cosas que hace bien.

• Los sistemas independientes duran mas 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: Programacion o Gerenciamien-

to de Personas ?

Aunque en esta Tesis nos concentramos en la construccion 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 programacion se

trata solo un 15% de comunicacion con la computadora y un 85% de comunicacion con

otras personas. Un programador promedio pasa nada mas que un 30% trabajando solo.


Sin embargo encontramos que lo que se necesita es un punto medio, no se puede hacer

un sistema complejo si contamos solo con buenos administradores u gerentes; ni tampoco

se lo puede hacer simplemente con buenos programadores, se necesita algo intermedio,

porque por mas bueno que sean los programadores si los gerentes no les pueden encontrar

la funcion adecuada y motivarlos, la cosa no va.

A.3. Mantenibilidad: Problema o Bendicion ?

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 man-

tenimiento, pero en la practica 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 corazon del

sistema, el cambiar cosas constantemente.

Los sistemas de los bancos, los de las tarjetas de credito, todos ellos estan en constante

mantenimiento y no por eso se los puede considerar malos sistemas...

Tampoco queremos fomentar la idea que el mantenimiento es la salvacion, simple-

mente rescatar esta idea para ser un poco mas conscientes cuando hablamos de manten-

imiento y pensar que no es tan malo despues de todo.

A.4. Desarrollo Web: La Solucion Ideal o una Op-

cion mas ?

Si existiese la moda del desarrollo seguro que estarıa por el lado del Desarrollo Web.

Todo el mundo quiere su pagina 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 solucion o no.

Ademas, como la Ingenierıa del SW anuncia con bombos y platillos que es mas

economico y mas rapido que el desarrollo de aplicaciones de escritorio, les da a los

gerentes el argumento ideal para tomar la decision de encarar los proyectos de la empresa

con Desarrollo Web.

Como todo, el Desarrollo Web no es la mejor solucion para todo, en mi opinion 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,


el problema si el usuario presiona dos veces un boton, 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 mas prudente y efectivo proveer consultas vıa Web y actual-

izacion a traves de aplicaciones de escritorio (por algo SAP y las grandes empresas de

SW administrativo confıan en el modelo cliente-servidor comun y corriente que demostro

ser mas que efectivo durante anos).

A.5. Numeros y Estadısticas para Reflexionar

Actualmente los proyectos son cada vez mas complejos y generalmente menos exi-

tosos, aquı tenemos algunos graficos que nos dan numeros concretos sobre los resultados

de los desarrollos:

Fuente de esta informacion: The Standish Group

Hay ademas numeros interesante que nos abren la mente del esfuerzo requerido para

hacer sistemas colosales como Windows, por ejemplo:

Windows 2000 tiene mas de 50 millones de lıneas de codigo.

SQL Server tiene mas o menos 1.5 millones de lıneas de codigo.

SAP fue desarrollado por 4200 Ingenieros de SW y tiene 37 millones de lıneas de

codigo.

Mostremos ahora cual es el porcentaje de las funciones que realmente se usa en la

mayorıa de los sistemas.


Este grafico indica claramente porque el desarrollo agil fomenta el interactuar con-

stantemente con el cliente para ver que es lo que realmente quiere y no desarrollar

funciones que nunca usara.

A.6. Que 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 mas del universo del software para explorar,

algun nuevo lenguaje que aprender o alguna nueva herramienta para probar.

Es indispensable hacer uso de los recursos de internet para continuar explo-

rando 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 disenando 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 solo 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.


Luego en los proyecto reales si uno no preve los cambios o simplemente no imagina

que podrıa pasar si el usuario toca aquı o alla, apareceran errores por todos lados y el

tiempo perdido en debugging sera 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 opinion

de los demas hacia nosotros despues de esto.

Apendice 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 Codigo

www.SourceForge.net La pagina mas destacada de desarrollo open source que

provee un servicio de hosting gratuito para todo esta co-

munidad. Gran parte de las herramientas Open Source

de esta tesis tienen su centro de desarrollo en los servi-

dores de esta pagina. Si se necesita cualquier programa

Open Source, con codigo y todo conviene empezar bus-

cando por aca.

www.CodeProject.com Indudablemente la pagina mas 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 pagina 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 ultima tecnologıa.

97

www.SourceForge.net

www.CodeProject.com

www.ElGuille.info

APENDICE B. RECURSOS UTILES 98

www.PlanetSourceCode.com Sitio con gran cantidad de codigo fuente y controles pero

como no estan muy editados cuesta un poco mas buscar

la info, pero si buscamos algo difıcil de hacer no im-

porta el lenguaje en que estemos trabajando este es un

excelente lugar para encontrarlo.

www.GotDotNet.com Sitio mantenido por Microsoft donde participan activa-

mente miembros que forman parte del equipo de desar-

rollo 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 pro-

grama que existe, esta hecho por chinos, la pagina tiene

partes en los dos idiomas. Se instala el programa y de-

spues se bajan las bases de datos que contienen el codigo

fuente.

Se pueden crear nuestras propias bases para ordenar el

codigo ya existentes.

B.2. Informacion sobre Desarrollo Agil

www.ExtremeProgramming.com La pagina oficial de esta metodologıa de desarrollo agil,

a primera vista no parece muy completa ni actualizada

pero contiene informacion de altısima calidad y se puede

descargar gran parte del sitio en un solo ZIP.

www.JoelOnSoftware.com La pagina oficial de un guru en el desarrollo de sistemas.

Encontramos grandes consejos y discusiones sobre los

temas mas actuales, en especial se destaca un libro sobre

interfaces de usuario muy sencillo y facil de leer.

OOP Criticism Pagina dedicada a juntar crıticas constructivas de la pro-

gramacion 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 Pagina dedicada a la generacion automatica de codigo,

gran cantidad de articulos y un listado muy completo de

las herramientas ordenadas por lenguaje.

www.PlanetSourceCode.com

www.GotDotNet.com

www.ExtremeProgramming.com

www.JoelOnSoftware.com

www.CodeGeneration.net


www.LarkWare.com Pagina oficial de Mike Gunderloy actualizada diaria-

mente, contine excelente informacion de ultimo momen-

to que se puede descarcar a traves de un RSS. Todos los

dıas hace un resumen de los temas de mayor resonancia

o de nuevas aplicaciones que van apareciende.

www.EggHeadCafe.com Aunque el nombre parezca poco serio esta pagina agrupa

una gran cantidad de desarrolladores cubriendo temas

de .NET, Java y VB6. Cuenta ademas con excelentes

recursos como iconos y enlaces interesantes.

www.TestDriven.com Pagina dedicada a tratar este modo de desarrollo con

mucho material y nos permite bajar presentaciones y

articulos.

www.DevDays.com.ar Pagina oficial de la confenciaria de .NET mas impor-

tante organizada por Microsoft, allı encontraran los

archivos de las presentaciones que cubren algunos de los

temas tratados en esta tesis.

En el CD complementario encontraran un html con muchısimos mas enlaces y con

direcciones de paginas que contienen directorios que se actualizan constantemente.

B.3. Direcciones de las Herramientas Tratadas

Control de Versiones y Programacion 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

www.LarkWare.com

www.EggHeadCafe.com

www.TestDriven.com

www.DevDays.com.ar

http://tortoisecvs.soureforge.net

http://tortoisesvn.tigris.org

http://wincvs.soureforge.net

http://winmerge.soureforge.net

http://www.cvsnt.org

http://www.dotnetrefactoring.com

http://www.jetbrains.com/resharper

http://www.axtools.com

http://nunit.soureforge.net


MBUnit: http://mbunit.soureforge.net

Generacion de Documentacion a Partir del Codigo

NDoc: ndoc.soureforge.net

VB.DOC: vbdoc.soureforge.net

Documentor: www.lutzroeder.com

Generacion e Integracion Continua

NAnt: http://nant.soureforge.net

NAnt Pad: http://www.nantpad.com

CruiseControl.NET: ccnet.thoughtworks.com

Generacion Automatica de Codigo

CodeSmith: http://www.ericjsmith.net/codesmith

Librerias de Codigo 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

Analisis de Codigo

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

http://mbunit.soureforge.net

ndoc.soureforge.net

vbdoc.soureforge.net

www.lutzroeder.com

http://nant.soureforge.net

http://www.nantpad.com

ccnet.thoughtworks.com

http://www.ericjsmith.net/codesmith

http://myweb.hinet.net/home4/s630417/

http://www.egroupware.org

http://www.dotproject.net

http://www.fogcreek.com/FogBugz

http://www.lutzroeder.com

http://www.gotdotnet.com

http://www.microsoft.com

http://www.compuware.com

http://www.dotnetwiki.org


B.4. Contenido del CD Complementario

En el Cd complementario se incluyen todas las herramientas tratadas en esta tesis,

junto con mucha informacion sobre las tecnicas 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 informacion sobre los temas tratados en esta Tesis

y sobre el desarrollo agil en general. Ademas encontraran artıculos de las paginas citada

como: www.CodeProject.com, www.CSharpCorner.com, www.Larkware.com,

www.CodeGeneration.net, etc.

En el directorio Componentes esta el codigo fuente de los Controles y Componentes

mas populares de .NET.

www.CodeProject.com

www.CSharpCorner.com

www.Larkware.com

www.CodeGeneration.net

Agradecimientos

Quiero agradecer sobre todo a mi familia quienes hicieron posible que haya llegado

hasta aquı y que con su motivacion y paciencia hicieron posible que pueda dedicarme a

mi gran vocacion que es la computacion.

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 companeros 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, practicos y charlas que tanto se extranan 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 ensenarlo. Yo com-

probe que es verdad con esta Tesis que me dejo mucho. Por eso quiero agradecer espe-

cialmente al director de la misma el Dr. Manuel Fidel por haberme permitido elegir este

tema y por guiarme durante todo el trabajo. Con su increıble conocimiento y desde su

sencillez me ha ensenado a ver el mundo de la Programacion y de la Computacion en

general de una manera unica. Mucho del contenido de la tesis esta influenciado por sus

geniales ideas y por nuestras entretenidas charlas.

Gracias a la mujer que espero me acompane toda la vida.

Bahıa Blanca Marcos A. Meli

Abril, 2005

102

Bibliografıa

[Bec99] Kent Beck. Extreme Programming Explained. Addison Wesley, 1999. El libro

mas 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. Addison-

Wesley, 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 tambien los ”An-

tiPatterns” 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 Imper-

fect World. APress, 2002. Un libro muy divertido e interesante que muestra

que en la actualidad por mas 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 tecnologı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


[Gun04] Mike Gunderloy. Coder to Developer: Tools and Strategies for Delivering Your

Software. Sybex, 2004. Muy buen libro que nos muestra como pasar de pro-

gramadores a buenos desarrolladores basandose 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 mas conocido sobre

patrones, propone los nombres utilizados en la actualidad y da una clasificacion

muy interesante.

[HT99] Andrew Hunt and David Thomas. The Pragmatic Programmer. From journet-

man 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 utiles. Recomendable para toda persona relacionada

con la programacion.

[HT03] Andrew Hunt and David Thomas. Pragmatic Version Control. Pragmatic

Press, 2003. Pequeno y util libro que nos ensena los conceptos basicos e inter-

medios del control de versiones, muy recomendable.

[HT04] Andrew Hunt and David Thomas. Pragmatic Unit Testing. Pragmatic Press,

2004. Excelente libro que cubre la parte teorica y practica sobre el Testing

Automatico 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 practicos.

[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 practico con la introduccion y justificacion

de las capas de negocios y como se pueden generar automaticamente. Incluye

ademas las plantillas de CodeSmith para hacerlo.

[McC04] Steve McConnell. Code Complete 2ed. MS Press, 2004. El mejor libro sobre

construccion de Software, muy amplio y explica temas desde cuantos comen-

tarios utilizar en nuestros programas que conducta nos dara mejores resultados

en nuestra carrera, una JOYA !!

[Mic] Microsoft. Microsoft Patterns And Practices. MS Press. Este no es un libro

sino una coleccion de libros que publica Microsoft y que son gratuitos. Son

una excelente guia para los que comienzan o estan 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.


[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 Pro-

grammers. APress, 2002. Otro libro de la editorial mas 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. Nue-

vo libro de Microsoft que muestra como administrar proyectos usando esta

metodologıa agil.

[Sha00] Alan Shalloway. Design Patterns Explained. Addison-Wesley, 2000. Un libro

mas bien practico que nos introduce al mundo de los patrones. Nos muestra

como se aplican en la realidad a traves 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 mas que quejas a la metodologıa con un tono muy ironico. Por

ejemplo en un capıtulo dice que no puede ser que el codigo nunca este listo si

usamos XP, y mi respuesta es: NO NUNCA ESTA LISTO siempre le falta algo,

ningun sistema funciona como se esperaba, siempre hay algo que cambiar o sera

que tiene algun 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 agregue aca porque

es interesante ver como se la agarran con cosas que funcionan en la practica

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 mas practica que el libro de Fowler, muestra con ejemplos

y con ejercicios para el lector como darnos cuenta donde hacer refactoring y

donde no.

Desarrollo Agil Con

Documents

Transcript of Desarrollo Agil Con