14. La orientación a objetos “ ¿Si cambian los requisitos? Ah, entonces no me preocupa …” “ (*) El desarrollo iterativo es un enfoque en el que el desarrollo se organiza en una serie de mini-proyectos cortos, de duración fija (p. ej., cuatro semanas) llamados iteraciones. El resultado de cada uno es un sistema que puede ser probado, integrado y ejecutado. (**) Cada iteración incluye sus propias actividades de análisis de requisitos, diseño, implementación y pruebas. (…) El subtítulo de un libro que trata el desarrollo iterativo es Aceptar el cambio [Beck00]. Esta frase evoca una aptitud clave del desarrollo iterativo: en lugar de luchar contra el inevitable cambio que ocurre en el desarrollo de software intentando (normalmente sin éxito) especificar, congelar y ‘firmar’ de manera completa y correcta a partir de un conjunto de requisitos fijos y diseñar antes de implementar, el desarrollo iterativo se basa en una aptitud de aceptación del cambio y la adaptación como motores inevitables y, de hecho, esenciales . Esto no quiere decir que el desarrollo iterativo (y el UP) fomenten un proceso dirigido por ‘una adición de características’ de manera incontrolada y reactiva. El UP llega a un equilibro entre la necesidad – por un lado – de llegar a un acuerdo y estabilizar un conjunto de requisitos, y – por otro lado – la realidad de los requisitos cambiantes, cuando el personal involucrado clarifica su visión o cambia el mercado .” (***) “ UML y patrones” – Craig Larman
(*) Antes de iniciar este slide, hablar del desarrollo en cascada y de su problemática asociada: amplificación de los errores, poca y tardía participación de los usuarios en un proyecto, etc., etc. (**) Símil del desarrollo iterativo con las muñecas rusas (Matrioshkas) (***) Cuando tras días de prototipaje el usuario ve éste y dice que no es lo que esperaba, ¿es para cabrearse o para alegrarse? RE: para alegrarse; el usuario ha clarificado su visión gracias al prototipo y de no ser por éste el desarrollo completo habría implicado seguramente bastante más tiempo
(*) Filosofías: “Los programadores que descansan son más productivos” y “La frescura aporta mejores ideas” El exceso de trabajo es un serio problema en los proyectos (síndrome del quemado o burn-out: http://es.wikipedia.org/wiki/Burn-out) (**) Son fundamentales cuando los programadores cambian de pareja o hacen refactoring del código de otros Se consigue un código con el mismo estilo, homogéneo, legible, así como evitar las clásicas situaciones “esto no puede modificarse hasta que venga Pepito de sus vacaciones; lo lleva él y es el único que sabe cómo funciona…” (***) El mejor diseño es el más simple de todos aquellos que pasen todos los tests Para XP simple significa (por orden de prioridad): El sistema (tanto el código como los tests) deben comunicar todo lo que se deba comunicar El sistema no debe contener código duplicado Debe tener la menor cantidad de clases Debe tener la menor cantidad de métodos
![T x 5 – XP Convenciones usadas y aclaraciones ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)