01-Entornos de Desarrollo - Unidad 4 - Optimizacion y Documentacion

ENTORNOS DE DESARROLLO
UNIDAD 4: Optimización y documentación

Contenidos
 Control de versiones. Subversión. Cliente tortoise. Servidor Visual SVN

 Control de versiones en ECLIPSE
 Etiquetas de documentación. Documentación de lases con Javadoc
 Refactoriazación
Introducción
El objetivo de este capítulo es aprender a manejar herramientas de control de

versiones, herramientas para documentar los programas y herramientas de
refactorización.
Introducción
 Cuando estamos desarrollando software, el código fuente está cambiando

continuamente, bien por el propio desarrollo o por el mantenimiento que
hacemos sobre él.
 El control de versiones surge de la necesidad de mantener y llevar control del
código que vamos programando, conservando sus distintos estados.
 Cuando trabajamos en equipo, si no disponemos de una herramienta de
control de versiones, puede ocurrir que se sobrescriban archivos que habían
sido modificados por otros componentes del equipo destruyendo su trabajo.
 En un proyecto se trabaja en dos ramas al mismo tiempo, en la rama de
desarrollo en la que se añaden nuevas funcionalidades, y en la rama de
producción (versiones finalizadas disponibles para los usuarios finales) ,
corrigiendo fallos (bugs) que se hayan detetado.
Control de versiones
 Se puede definir el control de versiones como la capacidad de recordar todos

los cambios que se realizan tanto en la estructura de directorios como en el
contenido de los archivos.
 Es útil cuando se desea recuperar un documento, una carpeta o un proyecto
en un momento concreto de su desarrollo.
 Cuando un proyecto es realizado por un grupo de personas nos permite saber
qué cambios se hacen , quién los hace y cuándo se realizan.
 Las primeras herramientas de control de versiones aparecieron en los años 70.

 En los primeros sistemas solo una persona podía estar modificando un mismo
código a la vez, lo que suponía retrasos en los equipos de trabajo.
 Los sistemas de control de versiones se pueden clasificar:
 Sistemas centralizados.
 Sistemas distribuidos.
Sistemas centralizados.
 En estos sistemas hay un servidor que aloja el repositorio (lugar donde se
almacenan todas las versiones de un proyecto). Es el único lugar donde está
todo el código.
 Los programadores tienen en local solo los archivos sobre los que están
trabajando.
 El programador se conecta con el servidor para enviar los cambios realizados.
 Ejemplos: Subversión, CVS, …
Sistemas distribuidos.
 Cada programador tiene en su máquina una copia del repositorio completo.
 Al estar en local, no necesito internet ni ninguna red para poder enviar
cambios al sistema de control de versiones.
 El repositorio se puede compartir con otras personas.
 Ejemplo: Git, Bazaar, Mercurial,
Control de versiones. Terminología
 Repositorio. Lugar donde se almacenan todas las versiones de un proyecto (los

datos y los cambios) . Puede ser un sistema de archivos en un disco duro, un banco
de datos, … Cada proyecto debe tener su propio repositorio.
 Revisión o versión. Es una versión concreta de los datos almacenados. Algunos
sistemas las identifican con un número contador.
 Etiquetar o rotular (tag). Cuando se crea una versión concreta en un momento
determinado del desarrollo de un proyecto se le pone una etiqueta, de forma que se
pueda localizar y recuperar en cualquier momento. Las etiquetas permiten
identificar de forma fácil revisiones importantes de un proyecto.
 Tronco(trunk). Es el tronco o la línea principal de desarrollo de un proyecto.
 Rama o ramificar (branch). Las ramas son copias de archivos, carpetas o
proyectos. Cuando se crea una rama se crea una bifurcación del proyecto y se crean
dos líneas de desarrollo.
 Desplegar (Checkout). Crear una copia de trabajo del proyecto del repositorio en
el equipo local. Por defecto se obtiene la última versión, aunque también se puede
indicar una versión concreta. Con el checkout se vincula la carpeta de trabajo con
el repositorio.
 Confirmar (commit o check-in). Se realiza commit cuando se confirman los cambios
realizados en local para integrarlos al repositorio.
 Exportación (export). Similar al checkout pero en esta ocasión no vincula la copia
con el repositorio (no incluye los metadatos del control de versiones).
 Importación (import). Es la subida de carpetas y archivos del equipo local al
repositorio.
 Actualizar (update). Se realiza una actualización cuando se desea integrar los
cambios realizados en el repositorio en la copia de trabajo local (se actualiza a la
última versión).
 Fusión (merge). Una fusión consiste en unir los cambios realizados sobre uno
o varios archivos en una única revisión. Se suele realizar cuando hay varias
líneas de desarrollo separadas en ramas y en alguna etapa se necesitan
fusionar los cambios hechos entre ramas.
 Conflicto. Ocurre cuando dos usuarios crean una copia local (Checkout) de la
misma versión de un archivo, uno de ellos realiza cambios y envía los cambios
(commit) al repositorio y el otro no actualiza (update) estos cambios y realiza
cambios sobre el archivo e intenta enviar luego sus cambios al repositorio. Se
produce el conflicto y el sistema no es capaza de fusionar los cambios.
 Resolver conflicto. La actuación del usuario para atender un conflicto entre
diferentes cambios al mismo documento.
Para trabajar en proyectos utilizando un sistema de control de versiones, se

realizan los siguientes pasos:
 Se crea una copia en local de la información del repositorio con checkout.
 Se realizan las modificaciones
 Se suben las modificaciones al repositorio con commit.
 Si la copia del usuario ya está vinculada al repositorio, antes de modificar y
realizar cambios tiene que hacer Update, para asegurarse de que los cambios
se realizan sobre la última versión del repositorio.
Control de versiones. Subversión. Ciclo de
vida de subversión
 Subversión es una herramienta multiplataforma de código abierto para el
control de versiones. Usa una base de datos central, el repositorio, que
contiene los archivos cuyas versiones se controlan.
 El repositorio actúa como un servidor de ficheros, con la capacidad de
recordar todos los cambios que se hacen tanto en sus directorios como en sus
ficheros.
 El proyecto debe verse como un árbol que tiene su tronco (trunk) donde está
la línea principal de su desarrollo; que tiene sus ramas (branches) en las que
se añadirán nuevas funciones o se corregirán errores; y que además tiene sus
etiquetas (tags) para marcar situaciones importantes, o versiones finalizadas.
vida de subversión
Estructura de carpetas:
 Trunk: base común para guardar las carpetas del proyecto o trabajo a
controlar. Es donde está la versión básica, la rama de desarrollo principal.
 Tags: es una copia del proyecto, de una carpeta o de un archivo que se hace
con el objetivo de obtener una versión que no se va a modificar. Son copias
del tronco. Aquí se guardarán las versiones cerradas de los proyectos.
 Branches: en las ramas se desarrollan versiones que luego se van a publicar.
Es una copia del trunk, de un proyecto, de una carpeta o de un archivo con la
intención de modificar sobre ella, para conseguir un producto final diferente
al original.
vida de subversión
Ciclo de vida de subversion:
Control de versiones. Cliente TortoiseSVN
TortoiseSVN es un cliente gratuito de código abierto para el sistema de control
de versiones Subversion. Al instalarse aparece integrado en la Shell de Windows.
Una vez instalado el programa y el idioma, pulsamos el botón derecho desde el
escritorio o desde un directorio del sistema de archivos y seleccionamos
TortoiseSVN/Settings. Dentro de general se selecciona el idioma.
Una vez instalada la herramienta veamos cómo crear un repositorio privado en el
propio PC y controlar los archivos y documentos almacenados en ese repositorio.
1. Creamos una carpeta en el disco duro, la seleccionamos y, desde el menú
contextual, se elige TortoiseSVN
2. Pulsamos en Crear un repositorio aquí
3. Pulsamos en Crear estructura de carpetas
4. Pulsamos en Navegador de repositorios
Operaciones con TortoiseSVN
Podremos seleccionar las operaciones desde el navegador de repositorios o desde
el menú contextual.
Algunas de las operaciones que podremos realizar son:
 Subir archivos y carpetas al repositorio (Añadir archivo y Añadir carpeta)
 Crear, renombrar o eliminar carpetas y archivos.
 Realizar copias de trabajo vinculadas al repositorio con Obtener (checkout)
 Realizar copias sin vincular con Exportar
 Con Mostrar el registro de revisiones se mostrarán todas las operaciones
realizadas
 Con Gráfico de revisiones se visualizará un gráfico de la situación
seleccionada
Operaciones con TortoiseSVN
El proceso de trabajo consistirá en hacer Checkout para obtener una copia de
trabajo en una carpeta local, realizar cambios en esa carpeta local y confirmar
los cambios COMMIT (SVN Confirmar) para subirlos al repositorio.
Siempre antes de realizar cambios es aconsejable actualizar con lo que hay en el
repositorio.
Obteniendo información del estado del repositorio
Mientras se trabaja con la copia de trabajo es necesario saber qué archivos se
han cambiado, añadido, borrado, renombrado, o incluso qué archivos han sido
cambiados y confirmados por los demás.
Para ello aparecerán unos iconos superpuestos que dan información del estado en
Subversion de los archivos y carpetas.
Esta configuración se puede cambiar desde TortoiseSVN/Configuración/Iconos
Sobrepuestos
Obteniendo información del estado del repositorio
Resolver conflictos
Una vez que se hayan realizado los cambios en la carpeta de trabajo se subirán al
repositorio con la opción SVN Confirmar.
Si al confirmar se producen conflictos es porque alguien realizó cambios en el
mismo fichero y lo subió al repositorio antes que nosotros. TortoiseSVN avisará de
que la operación ha fallado y no subirá los cambios. Aconseja que se actualice a
la copia del repositorio o que se cancele la operación.
Si se elige la opción de actualizar, se creará una copia de cada archivo en la
carpeta de trabajo y el archivo pasará al estado En conflicto. Para resolver el
conflicto se seleccionará Resolver del menú TortoiseSVN.
Creación de etiquetas con Tortoise
Para crear una etiqueta, nos posicionamos en la carpeta o archivos del
repositorio local de trabajo que queramos etiquetar, y hacemos clic con el botón
derecho. Después seleccionamos Rama/etiqueta del menú TortoiseSVN.
En la ventana que aparece se indica el origen y el destino de la etiqueta a crear y
sobre qué elementos se crea la etiqueta.
Antes de crear una etiqueta hay que crear en el repositorio una carpeta en tags
para guardar los archivos y que no cuelguen directamente de tags.
Creación de ramas con Tortoise
El proceso de creación de ramas es prácticamente idéntico al de creación de
etiquetas.
Para crear una rama, nos posicionamos en la carpeta o archivos del repositorio
local de trabajo que queramos etiquetar, y hacemos clic con el botón derecho.
Después seleccionamos Rama/etiqueta del menú TortoiseSVN.
En la ventana que aparece se indica el origen y el destino de la rama a crear y
sobre qué elementos se crea la rama.
Antes de crear una rama hay que crear en el repositorio una carpeta en branches
para guardar los archivos y que no cuelguen directamente de branches.
Creación de ramas con Tortoise
Las etiquetas se usan típicamente para crear una copia estática de un proyecto
en una etapa concreta. Trabajar con una revisión etiquetada no es una buena
idea. Si se necesita hacer cambios de una versión etiquetada, la forma correcta
es:
1. Crear una nueva rama desde la etiqueta
2. Hacer los cambios en la rama
3. Crear una nueva etiqueta para esta rama.
Hay que recordar que si se modifica una copia de trabajo creada desde una
rama y se confirman los cambios, los cambios irán a la rama y no al tronco.
Fusionar ramas
Los cambios se realizarán siempre en las ramas y, una vez realizados, los
fusionamos con las copias de trabajo y, desde las copias de trabajo asociadas al
tronco se confirman los cambios a trunk.
La fusión siempre se realiza sobre copias de trabajo
Para fusionar los cambios realizados en una rama creada de una carpeta de
trunk, en la copia de trabajo asociada a trunk, se abre la carpeta sobre la que se
creó la rama y dentro de esa carpeta que se ha modificado en la rama, se abre el
menú TortoiseSVN y se elige Fusionar.
Fusionar ramas
Aparecen dos opciones de fusión:
 Fusionar un rango de revisiones: Este método se elige cuando se ha hecho
una o más revisiones en una rama y se desea recoger los cambios a una rama
diferente o a la carpeta de trabajo. En el campo URL desde se escribirá la
URL completa de la rama que contiene los cambios que se desea cargar en la
copia de trabajo.
 Fusionar dos árboles diferentes: Este método se utiliza cuando se desea
fusionar las diferencias de dos ramas distintas en la copia de trabajo.
Si al hacer la fusión aparecen muchos errores o muchos conflictos es posible

volver a la situación anterior seleccionando Revertir del menú TortoiseSVN.
 Instalación configuración y uso de tortoiseSVN 1.8
https://www.youtube.com/watch?v=P73or00mwWA
https://www.youtube.com/watch?v=t2BYUk64IqI
 Guía Tortoise:
https://tortoisesvn.net/docs/nightly/TortoiseSVN_es/tsvn-quick-start.html
Control de versiones. Git
 Git es una herramienta de control de versiones multiplataforma muy
utilizada.
 Fue desarrollada por Linus Torvalds (creador de Linux) en 2005 en código libre
para ayudar al trabajo de mantenimiento del núcleo de Linux.
 Es un sistema distribuido, cada desarrollador tiene su propia copia entera del
repositorio en local, es decir todos los archivos del proyecto.
 Viene instalado en las últimas versiones de Linux y Mac. En Windows hay que
descargarlo e instalarlo de http://git-scm.com
 Documentación https://git-scm.com/documentation
 La forma de trabajar con Git es:
 Cada miembro del equipo de trabajo tiene una copia completa del repositorio
del software que se está desarrollando en local.
 Existe un servidor con repositorio remoto que al que el equipo enviará los
cambios.
 Cada desarrollador podrá enviar los cambios que tiene en local hacia el
repositorio remoto cuando quiera y ese repositorio remoto lo usarán todos los
componentes del equipo para sincronizarse y tener la versión más nueva del
código en cada momento que lo deseen.
Algunos comandos:
 Comprobar la versión instalada: git –-version
 Lista de comando más habituales: git –help
 Configurar las credenciales del desarrollador: git config
 Transformar un directorio en un directorio de trabajo Git: git init
 Registrar en el índice los ficheros nuevos o modificados: git add
 Generar un nuevo commit con lo registrado en el índice: git commit
 Mostrar el estado de los ficheros de un proyecto: git status
 Mostrar diferencias en los ficheros modificados respecto al commit anterior:
git diff.
Control de versiones. Git y GitHub
 Github es el sitio más popular para compartir código y administrar tus
proyectos. Es como una red social en la que se comparte SW.
 Se guardan repositorios remotos en la nube.
 Los repositorios públicos (accesibles por cualquiera) son gratis, y muestran
toda la estructura del proyecto, todas las versiones, quien ha colaborado…. Se
pueden descargar y utilizar sin ningún coste.
 Si se desea tener repositorios privados hay que pagar. Estos se comparten con
los equipos de trabajo o clientes que queramos.
 Una de las mejores tarjetas de visita de las personas que se dedican a la
programación, es el portfolio de proyectos que tenga en su cuenta de GitHub.
Las personas que van a contratar a alguien normalmente miran sus proyectos
en Github.
 Git es la herramienta de control de versiones y GitHub es un hosting de
repositorios Git.
 En GitHub puedes:
 Compartir tus proyectos online.
 Hacer publicidad de tus proyectos.
 Compartir proyectos de forma privada con las personas que desees.
 Otras personas pueden ver el historial de tu proyecto y añadir comentarios o subir
commits para mejorarlo.
 Los repositorios se identifican con una URL por la que cualquier usuario que la
conozca puede acceder a él.
 Algunos proyectos más importantes de software libre del mundo como Linux,
Eclipse, jQuery, etc están en GitHub.
 Algunos ejemplos:
 https://gist.github.com/Juesar/8663416
 https://github.com/ccastromar/animaciones-css
 https://libro.cursohtml5desdecero.com/git_&_github.html
 La función principal de GitHub es compartir repositorios con terceros.
 Los usuarios han de crear una cuenta con lo que adquieren un perfil.
 Las operaciones principales de un usuario registrado son:
 Crear un repositorio remoto para albergar un nuevo proyecto (new repository).
 Copiar un repositorio guardado en GitHub a otra cuenta (fork).
 Importar un repositorio identificado por su URL a GitHub (import repository).
Git en Eclipse
 Eclipse trae de serie un plugin denominado EGit que proporciona una interfaz
bastante completa de las operaciones con Git. Para acceder a ella, hay que ir
a la perspectiva Git (en el menú Window > Open Perspective > Other…, y
entonces seleccionar "Git").
 EGit tiene una completa documentación, a la que se puede acceder yendo a
Help > Help Contents, y seleccionando el nodo "EGit Documentation" en el
listado de contenidos.
 Guía: https://wiki.eclipse.org/Es:EGit/Es:User_Guide
 Tutorial: subir proyecto eclipse a GitHub:
https://www.youtube.com/watch?v=8EVG7RmrP-o
Alta en GitHub
 Accedemos a https://github.com
 Para crear una cuenta nueva hay que pulsar el enlace Sign in que nos permite
acceder a GitHub si ya tenemos una cuenta creada o crear una nueva.
 Un asistente nos ayudará en la creación de la cuenta.
Crear un repositorio vacío en GitHub
https://www.youtube.com/watch?v=ZFExu_kqeeo
Ejemplos: Descargar contenido de un repositorio a máquina local.
http://gudh.github.io/ihover/dist/index.html
https://blueimp.github.io/Gallery/
Documentación
Por documentación se entiende el texto escrito que acompaña a los proyectos de
cualquier tipo, en nuestro caso de software.
Podemos distinguir los siguientes tipos de documentación:
 Documentación de las especificaciones.
 Documentación del diseño.
 Documentación del código fuente.
 Documentación de usuario final.
Documentación
 Documentación de las especificaciones: nos asegura que tanto el
desarrollador como el cliente tienen la misma idea sobre las funcionalidades
del sistema. Las especificaciones deben describir la siguiente documentación:
 Introducción. En ella se definen los fines y objetivos del SW.
 Descripción de la información. Se realiza un descripción más detallada del
problema incluyendo el HW y SW necesario.
 Descripción funcional. Descripción de cada función requerida por el sistema,
incluyendo diagramas.
 Descripción del comportamiento. Comportamiento del SW ante sucesos internos y
externos
 Criterios de validación. Documentación sobre límites de rendimiento, clases de
pruebas, respuesta esperada del SW, consideraciones especiales
Documentación
 Documentación del diseño: en la fase de diseño se decide la estructura de
datos a utilizar, la forma en que se van a implementar, el contenido de las
clases, sus métodos y atributos… También se deciden las funciones, sus datos
de entrada y salida, …
Documentación
 Documentación del código fuente: durante la fase de implementación es
necesario comentar convenientemente cada una de las partes que tiene el
programa.
 Estos comentarios se incluyen en el código fuente con el objeto de clarificar y
explicar cada elemento del programa, se deben comentar las clases , los
métodos, las variables y en definitiva todo elemento que se considere
importante.
 Documentar el código fuente es necesario para explicar claramente lo que
hace el programa, de esta manera TODO el equipo de desarrollo sabrá lo
que se está haciendo y por qué. De esta forma es mucho más fácil:
 Reparar errores: todos los programas tienen errores y descubrirlos sólo es cuestión
de tiempo y de que el programa tenga éxito y se utilice frecuentemente.
 Añadir nuevas funcionalidades: todos los programas sufren modificaciones a lo
largo de su vida, al menos los que tienen éxito.
Documentación
 Documentación de usuario final: es la documentación que se entrega al
usuario tanto especializado como no especializado. Se describe cómo utilizar
las aplicaciones del proyecto
Documentación
Documentación del código fuente
 Para documentar proyectos existen muchas herramientas, normalmente cada
lenguaje dispone de su propia herramienta como:
 PHPDoc y phpDocumentator para php,
 Javadoc para Java o
 JSDoc, el Java doc para JavaScript.
 En esta unidad nos ocuparemos de Javadoc, para documentar programas
Java.
Documentación
Uso de JavaDoc en Eclipse
 JavaDoc es una utilidad para extraer y generar documentación directamente
del código en formato HTML.
 Para que la documentación sea útil debemos escribir los comentarios del
código de acuerdo a las recomendaciones de Javadoc. La documentación y el
código se van a incluir dentro del mismo fichero.
Documentación
Los comentarios, son anotaciones en el código que el compilador ignora pero son
muy útiles para los programadores.
Existen en los lenguajes de programación desde el principio. Desde hace mucho
tiempo se observó que en realidad los comentarios se usaban para dos propósitos
diferentes:
 Para explicar el propósito de sentencias o grupos de sentencias:
 Comentarios de línea: comienzan con los caracteres “//” y terminan con la línea.
 Comentarios tipo C: comienzan con los caracteres “/*”, y terminan con los
caracteres “*/”. Pueden agrupar varias líneas.
 Comentarios explicando qué hace una "pieza" cerrada de código.
 Comentarios de documentación Javadoc: estos comentarios se colocan entre los
delimitadores /**...*/ agrupan varias líneas y cada línea irá precedida por un *, y lo
más importante es que estos deben colocarse antes de la declaración de una clase,
un campo, un método o un constructor.
Documentación
 Dentro de estos delimitadores se podrá escribir etiquetas HTML. Los
comentarios Javadoc están formados por dos partes: una descripción, seguida
de un bloque de tags.
 El programa de generación de documentación “JavaDoc” ignorará toda la
información de un fichero de código excepto la que se encuentre entre los
delimitadores /** …*/
Documentación
 Ejemplo de documentación:
descripción
tags
Documentación
Ejemplo:
Documentación
Uso de JavaDoc en Eclipse. Etiquetas
Se pueden usar tags (etiquetas) para documentar ciertos aspectos concretos
como la versión de la clase, el autor, los parámetros utilizados o los valores
devueltos. Las etiquetas de Javadoc van precedidas por @. Las más usadas son:
ETIQUETA DESCRIPCIÓN
@autor Autor de la clase. Sólo para las clases.
@version Versión de la clase. Sólo para las clases.
@see Referencia a otra clase. Ej. @see cadena
@param Descripción de parámetro. Una etiqueta por cada parámetro
@return Descripción de lo que devuelve. Sólo si no es void
@throws Descripción de la excepción que puede propagar
@deprecated Marca el método como obsoleto.
@since Indica el nº de versión desde la que existe el método.
Etiquetas definidas en JavaDoc: https://en.wikipedia.org/wiki/Javadoc

Documentación
Uso de JavaDoc en Eclipse. Generar la documentación
 La mayor parte de los IDE que implementan Java, como Eclipse o Netbeans,
incluyen un botón o un enlace para configurar y ejecutar Javadoc.
 Generan páginas HTML de documentación a partir de los comentarios JavaDoc
incluidos en el código fuente.
 En la documentación que se genera, se incluye una hoja de estilos que se
puede modificar.
 También hay algunos sitios en los que te puedes descargar plantillas
personalizadas
http://java-white-box.blogspot.com/2012/08/javadoc-como-personalizar-el-
html.html
Documentación
Desde Eclipse, seleccionado el proyecto, se abre el menú Project y se elige la
opción Generate Javadoc:
 En Javadoc command se tiene que indicar dónde se encuentra el archivo
ejecutable de Javadoc. Se pulsa el botón Configure para buscarlo dentro de la
carpeta donde se encuentra instalado el JDK, dentro de la carpeta bin.
 En los cuadros inferiores se elegirá el proyecto y las clases a documentar.
 Se seleccionará la visibilidad de los elementos a documentar. Con Private se
documentarán todos los miembros públicos, privados y protegidos.
 Se indica la carpeta de destino donde se almacenará el código HTML.
 Pulsando Next se nos pedirá el título del documento HTML y se eligen las
opciones. Como mínimo se selecciona la barra de navegación y el índice.
 Tutorial para generar documentación con Javadoc:
https://www.javierrguez.com/generar-javadoc-con-eclipse/
Documentación
Actividades:
 Realiza las actividades A.4.1 y A.4.2 de la plataforma para probar la
herramienta javaDoc.
 Realiza y entrega las actividades A.4.3 y A.4.4
Refactorización
Es una técnica de ingeniería de software que permite la optimización de código
realizando cambios en su estructura interna sin que esto suponga alteraciones en
su comportamiento externo.
¿Qué hace la refactorización?

 Limpia el código, mejorando la consistencia y la claridad.
 Mantiene el código, no añade nuevas funcionalidades ni corrige errores.
 Facilita realizar cambios en el código.
 Previene la permanencia de las malas prácticas en el código (code smells)
Refactorización
Cuando refactorizar. Malas prácticas (Malos olores,bad smells)
 Código duplicado
 Métodos muy largos
 Clases muy grandes
 Lista de parámetros extensa
 Cambio divergente: una clase es frecuentemente modificada por diversos motivos,
normalmente no relacionados entre sí. A lo mejor conviene eliminar la clase.
 Cirugía a tiro pistola: Cuando después de un cambio en una determinada clase, se deben
realizar varias modificaciones adicionales en diversos lugares para compatibilizar dicho
cambio.
 Envidia de funcionalidad: Tenemos un método que utiliza más cantidad de elementos de
otra clase que de la suya propia. Se suele resolver el problema pasando el método a la
clase cuyos elementos utiliza más.
 Clase de sólo datos: clases que sólo tienen atributos y métodos gets y sets.
 Legado rechazado: subclases que utilizan solo unas pocas características de sus
superclases. Si las subclases no necesitan todo lo que sus superclases les proveen por
herencia, esto suele indicar que la jerarquía de clases no es correcta como fue pensada.
Refactorización
Refactorización en Eclipse
 Eclipse tiene diversos métodos de refactorizar. Dependiendo de dónde
invoquemos a la refactorización (clase, método o atributo) tendremos un
menú contextual u otro.
 Para refactorizar, se selecciona el elemento (clase, variable, expresión,
bloque de instrucciones, método…), se pulsa el botón derecho del ratón, se
selecciona Refactor y, a continuación, el método de refactorización.
Refactorización
Los métodos más comunes de refactorización son:
 Rename: cambia el nombre de las variables, clases, métodos, paquetes,
directorios… modificando las referencias a ese identificador.
 Move: mueve una clase de un paquete a otro (se actualizan las referencias).
 Extract Constant: convierte un número o cadena literal en una constante.
 Extract local variable: asigna una expresión a variable local.
 Convert Local Variable to Field: convierte una variable local en un atributo
privado de la clase.
 Extract Method: nos permite seleccionar un bloque de código y convertirlo en
un método.
 Change Method Signature: permite cambiar la firma de un método, es decir, el
nombre del método y los parámetros que tiene. Automáticamente se
actualizarán todas las dependencias y llamadas al método dentro del proyecto.
Si al refactorizar se cambia el tipo de dato de retorno del método, aparecerán
errores de compilación, por lo que hay que modificarlo manualmente.
Refactorización
 Inline: nos permite ajustar una referencia a una variable o método con la
línea en la que se utiliza y conseguir así una única línea de código. Cuando se
utiliza, se sustituye la referencia a la variable o método con el valor asignado
a la variable o la aplicación del método, respectivamente.
Ejemplo:
Refactorización
 Member Type to Top Level: convierte una clase anidada en una clase de
nivel superior con su propio archivo de java.
 Extract Interface: Nos permite escoger los métodos de una clase para crear
una Interface.
 Extract Superclass: Permite extraer una superclase. Si la clase ya utilizaba
una superclase, la recién creada pasará a ser su superclase. Se pueden
seleccionar los métodos y atributos que formarán parte de la superclase.
Refactorización
 Eclipse permite ver el histórico de refactorizaciones que se han realizado en
un proyecto.
 Para ello hay que abrir el menú Refactor/History.
 En la ventana que se abre, se pueden ver todos los cambios realizados y su
detalle.
 Si se elige uno de los cambios realizados y se pulsa el botón “Remove” se
borra del histórico.
 También se puede crear un Script con todos los cambios realizados en la
refactorización y guardarlo en un fichero XML (Refactor/Create Script).
 La opción Refactor/Apply Script permite cargar un script de refactorización.

01-Entornos de Desarrollo - Unidad 4 - Optimizacion y Documentacion

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

01-Entornos de Desarrollo - Unidad 4 - Optimizacion y Documentacion

Cargado por

Copyright:

Formatos disponibles

ENTORNOS DE DESARROLLO

UNIDAD 4: Optimización y documentación

 Control de versiones. Subversión. Cliente tortoise. Servidor Visual SVN

El objetivo de este capítulo es aprender a manejar herramientas de control de

 Cuando estamos desarrollando software, el código fuente está cambiando

 Se puede definir el control de versiones como la capacidad de recordar todos

 Las primeras herramientas de control de versiones aparecieron en los años 70.

 Repositorio. Lugar donde se almacenan todas las versiones de un proyecto (los

Para trabajar en proyectos utilizando un sistema de control de versiones, se

Si al hacer la fusión aparecen muchos errores o muchos conflictos es posible

Etiquetas definidas en JavaDoc: https://en.wikipedia.org/wiki/Javadoc

¿Qué hace la refactorización?

También podría gustarte