U. T Optimización y Documentación Refactorización

U. T. 4. - Optimización y Documentación. 4. 1. Refactorización
U.T.4.- Optimización y Documentación Refactorización. Concepto. Limitaciones. Patrones de refactorización más usuales. Analizadores de código. Refactorización y pruebas. Herramientas de ayuda a la refactorización Control de versiones. Estructura de las herramientas de control de versiones. Repositorio. Herramientas de control de versiones Pautas para la documentación. Uso de documentación alternativo Herramientas de refactorización, control de versiones y de generación de documentación del entorno de desarrollo.

4. 1. Refactorización. Concepto. Limitaciones
4.1. Refactorización. Concepto. Limitaciones. Patrones de refactorización más usuales. Analizadores de código. Refactorización y pruebas. Herramientas de ayuda a la refactorización. “La refactorización consiste en realizar una transformación al software preservando su comportamiento, modificando su estructura interna para mejorarlo” (Opdyke, W.). En múltiples ocasiones durante el transcurso de un proyecto de grandes proporciones o de larga duración es frecuente encontrarse con que necesitamos revaluar y modificar código creado anteriormente, o ponerse a trabajar con un proyecto de otra persona, para lo cual antes se deberá estudiar y comprender. A pesar de los comentarios o la documentación del proyecto en cuestión, la refactorización (informalmente llamada limpieza de código) ayuda a tener un código que es más sencillo de comprender, más compacto, más limpio y, por supuesto, más fácil de modificar.

Refactorizar no cambia la funcionalidad del código ni el comportamiento del programa, el programa deberá comportarse de la misma forma antes y después de efectuar las refactorizaciones. Las refactorizaciones son pequeños cambios que hacen que el código sea más visible, flexible, entendible y modificable. No existe ninguna etapa de desarrollo especifica para la refactorización, se puede refactorizar siempre que se quiera ya que la funcionalidad (si lo hemos hecho bien) no va a sufrir cambio alguno. Aunque no exista ninguna etapa para la refactorización, debería ser una tarea recurrente a la hora de codificar o mantener una aplicación. El modo más eficiente de tener un código refactorizado es intercalar la creación de código nuevo con la refactorización de código.

Las tabulaciones son también un excelente recurso para obtener una mayor visibilidad del código, con lo que conseguir que el código sea mas entendible y fácilmente modificable. Aunque la tabulación no sea una técnica o una práctica propia de la refactorización en sí misma, ya que no se modifica código, cumple con al menos parte de los objetivos de la refactorización. Los entornos de desarrollo disponen de herramientas que nos permiten dar formato al código de manera automática. En Netbeans lo hacemos desde el menú «Source» (Fuente) con la opción «Format» (Formato).

PATRONES DE REFACTORIZACIÓN MÁS USUALES
Para refactorizar nuestro código, podemos encontrar útil disponer de una serie de reglas o casos de uso para aplicar en nuestro código, eso es justamente lo que hacen los patrones de refactorización. Aportan una base de modificaciones en el código para sustituir elementos de la manera más apropiada dependiendo de lo que quieras refactorizar y más importante aún, de como lo quieras refactorizar. También tendríamos que tener en cuenta que no siempre se pueden aplicar estos patrones al código sobre el que estamos trabajando, depende en gran medida del lenguaje que estemos utilizando. En este caso concreto estamos hablando de patrones de refactorización para ser aplicados a lenguajes del paradigma de programación orientada a objetos.

1. Extraer Método Tenemos un fragmento de código que puede agruparse. Convertimos el fragmento en un método cuyo nombre explique el propósito del método. Ejemplo: public void imprimirTodo() { imprimirBanner(); //detalles de impresión System.out.println(“nombre: “ + nombre); System.out.println(“cantidad “ + obtenerCargoPendiente()); }

Refactorizamos el código anterior:
public void ImprimirTodo() { imprimirBanner(); imprimirDetalles(obtenerCargoPendiente()); } public void imprimirDetalles(double cargoPendiente) { System.out.println (“nombre: “ + nombre); System.out.println(“cantidad “ + cargoPendiente);

2. Separar Variables Temporales
Tenemos una variable temporal que usamos más de una vez, pero no es una variable de bucle ni una variable temporal de colección. Creamos una variable temporal diferente para cada asignación. Ejemplo: double temp = 2 * (alto + ancho); System.out.println(temp); temp = alto * ancho;

double perimetro = 2 * (alto + ancho); System.out.println(perimetro); double area = alto * ancho; System.out.println(area);

3. Eliminar asignaciones a parámetros
Un parámetro es usado para recibir una asignación. Usamos una variable temporal en su lugar. Ejemplo: int descuento (int entradaValor, int cantidad, int año) { if (entradaValor > 50) entradaValor -= 2; ………. }

int descuento (int entradaValor, int cantidad, int año) { int resultado = entradaValor; if (entradaValor > 50) resultado -= 2; …………………………… }

4. Mover Método Un método es, o será, usado por más características de otra clase que en aquella donde está definido. Crearemos un nuevo método con un cuerpo similar en la clase que se use más. Convertiremos el cuerpo del método antiguo en una delegación simple o lo removeremos por completo.

Ejemplo: public class Proyecto { Persona[] participantes; } public class Persona { int id; boolean participante(Proyecto p) { for(int i=0; i<p.participantes.length; i++) if (p.participantes[i].id == id) return(true); return(false); ……………………………………… if (x.participante(p)) ….…….

Refactorizamos el código
public class Proyecto { Persona[] participantes; boolean participante(Persona x) { for(int i=0; i<participantes.length; i++) if (participantes[i].id == x.id) return(true); return(false); } public class Persona { int id; […] if (p.participante(x)) […]

5. Consolidar fragmentos duplicados en condicionales
El mismo fragmento de código está en todas las ramas de una expresión condicional. Sacamos dicho fragmento fuera de la expresión. Ejemplo: if (esAcuerdoEspecial()) { total = precio * 0.95; enviar(); }else { total = precio * 0.98; }

if (esAcuerdoEspecial()) total = precio * 0.95; else total = precio * 0.98; enviar();

6. Descomponer un Condicional
Tenemos una complicada declaración en el condicional. Extraemos métodos de la condición y del cuerpo del condicional. Ejemplo: if (fecha.antes (EMPIEZA_VERANO) || fecha.despues(FIN_VERANO)) cargo = cantidad * tasaInvierno + cargoServicioInvierno; else cargo = cantidad * tasaVerano;

if (noEsVerano(fecha)) cargo = cargoInvierno(cantidad); else cargo = cargoVerano (cantidad); double cargoInvierno(int cantidad) { return cantidad * tasaInvierno + cargoServicioInvierno; } double cargoVerano(int cantidad) { return cantidad * tasaVerano;

7. Consolidar Expresiones Condicionales
Tenemos una secuencia de condicionales con el mismo resultado. Los combinamos en una sola expresión y lo extraemos. Ejemplo: double cuantiaPorDiscapacidad() { if (antiguedad < 2) return 0; if (mesesDiscapacitado > 12) if (esTiempoParcial) // calculamos la cantidad por discapacidad }

double cuantiaPorDiscapacidad () { if (esNoElegibleParaDiscapacidad()) return 0; // calculamos la cantidad por discapacidad }

8. Reemplazar Condicional por Polimorfismo
Tenemos un condicional que elige diferentes comportamientos dependiendo del tipo de un objeto. Movemos cada caso del condicional en un método sobrecargado en una subclase. Hacemos el método original abstracto.

Ejemplo: double getVelocidad(){ switch (tipo){ case EUROPEA: return getVelocidadBase(); case AFRICANA: return getVelocidadBase() - getFactorCarga() * numeroCocos; case NORUEGO_AZUL: return (esMoteado) ? 0 : getVelocidadBase(voltaje); } throw new RuntimeException(“Debería ser inalcanzable”);

Refactorizamos: La solución es definir una clase «Golondrina», con un método abstracto getVelocidad(). Luego defina la subclases Europea, Africana, Noruego Azul y redefinir ("override") el método getVelocidad() para cada uno de ellos. El switch desaparece.

9. Reemplazar Número Mágico con Constante Simbólica
Tenemos un literal con un significado particular. Creamos una constante, la nombramos significativamente y la sustituimos por el literal. Ejemplo: double energiaPotencial(double masa, double altura) { return masa * altura * 9.81; }

double energiaPotencial(double masa, double altura) { return masa * CONSTANTE_GRAVITACIONAL * altura; } static final double CONSTANTE_GRAVITACIONAL = 9.81;

10. Reemplazar Número Mágico con Método Constante
Tenemos un literal con un significado particular. Creamos un método que nos devuelve el literal, lo nombramos significativamente y lo sustituimos por el literal. Ejemplo: double energiaPotencial(double masa, double altura) { return masa * altura * 9.81; }

double energiaPotencial(double masa, double altura) { return masa * constanteGravitacional() * altura; } public static double constanteGravitacional(){ return 9.81;

11. Reemplazar Datos y Valores por Objetos
Tenemos un atributo que necesita información o comportamiento adicional. Convertimos el atributo en un objeto. Ejemplo:

12. Reemplazar Array con Objeto
Tenemos un array en el que ciertos elementos tienen un significado diferente. Reemplazamos el array con un objeto que tenga un atributo para cada elemento. Ejemplo: String[] fila = new String[3]; fila[0] = “San Martín de la Arena C.D.”; fila[1] = “15”;

Rendimiento fila = new Rendimiento(); fila.setNombre(“San Martín de la Arena C.D.”); fila.setGanados(“1337”);

13. Encapsular Atributo Tenemos un atributo público. Lo convertimos a privado y le creamos métodos de acceso. Ejemplo: public String nombre;

private String nombre; public String getNombre() {return nombre;} public void setNombre(String arg) {nombre = arg;}

14. Encapsular Colección Un método devuelve una colección. Hacemos que devuelva una colección de solo lectura y le facilitamos métodos de adición y eliminación de elementos. Ejemplo:

15. Reemplazar SubClases por Atributos
Tenemos subclases que solo varían en métodos que devuelven información constante. Cambiamos los métodos por atributos de la superclase y eliminamos las subclases. Ejemplo: Refactorizamos

16. Extraer SubClase Una clase tiene propiedades que solo son usadas en determinadas instancias. Creamos una subclase para dicho grupo de propiedades. Ejemplo:

17. Extraer Clase Tenemos una clase que hace el trabajo que debería ser hecho por dos. Creamos una nueva clase y movemos los atributos y métodos relevantes de la vieja a la nueva clase. Ejemplo:

18. Extraer una SuperClase
Hay dos (o más) clases con características similares. Crear una clase base para ellas y mover el comportamiento común a la clase base. Ejemplo:

Refactorizamos

MALOS OLORES Los “malos olores” son una relación de malas prácticas de desarrollo, indicadores de que nuestro código podría necesitar ser refactorizado. No siempre que detectemos un posible “mal olor” es un fallo de diseño en nuestro código y deberemos refactorizarlo, pero nos ayudará saber reconocer los indicadores y valorar si ese indicador es válido y tendremos que refactorizar. Los “malos olores” no son necesariamente un problema en sí mismos, pero nos indican que hay un problema cerca. Varias de las malas prácticas de código reconocidas como antipatrones suelen corresponderse con “malos olores”.

Antipatrones Método largo. Los programas que permanecen más tiempo sin necesitar una mejora son aquellos con métodos cortos, que son más reutilizables y aportan mayor semántica. Clase grande. Clases que hacen demasiado y por lo general con una baja cohesión, siendo muy vulnerables al cambio. Lista de parámetros larga. Los métodos con muchos parámetros elevan el acoplamiento, son difíciles de comprender y cambian con frecuencia. Clase de datos. Clases que solo tienen atributos y métodos tipo get y set. Las clases siempre deben disponer de algún comportamiento no trivial.

Estructuras de agrupación condicional
Estructuras de agrupación condicional. Un case o switch con muchas cláusulas, o muchos ifs anidados, tampoco es una buena idea. Comentarios. Al encontrar un gran comentario, se debería reflexionar sobre por qué algo necesita ser tan explicado y no es autoexplicativo. Los comentarios ocultan muchas veces a otro “mal olor”. Atributo temporal. Objetos que tengan atributos que se usan solo en ciertas circunstancias. Tal código es difícil de comprender, ya que lo esperado es que un objeto use todas sus variables. Generalidad especulativa. Jerarquías con clases sin utilidad actual, pero que se introducen por si en un futuro fuesen necesarias. El resultado son jerarquías difíciles de mantener y comprender, con clases que pudieran no ser nunca de utilidad.

Jerarquías paralelas. Cada vez que se añade una subclase a una jerarquía hay que añadir otra nueva clase en otra jerarquía distinta. Intermediario. Clases cuyo único trabajo es la delegación y ser intermediarias. Legado rechazado. Subclases que usan solo un poco de lo que heredan de la clase padre. Si las clases hijas no necesitan lo que heredan, generalmente será porque la herencia está mal aplicada. Intimidad inadecuada. Clases que tratan con la parte privada de otras. Se debe restringir el acceso al conocimiento interno de una clase. Cadena de mensajes. Un cliente pide algo a un objeto que a su vez lo pide a otro y éste a otro, etc.

Obsesión primitiva. Uso excesivo de tipos primitivos
Obsesión primitiva. Uso excesivo de tipos primitivos. Existen grupos de tipos primitivos (enteros, caracteres, reales, etc.) que deberían modelarse como objetos. Debe eliminarse la reticencia a usar pequeños objetos para pequeñas tareas, como dinero, rangos o números de teléfono que debieran muchas veces ser objetos. Clase perezosa. Una clase que no está haciendo nada o casi nada debería eliminarse. Cambios en cadena. Un cambio en una clase implica cambiar otras muchas. En estas circunstancias es muy difícil afrontar un proceso de cambio.

Envidia de características
Envidia de características. Un método que utiliza más cantidad de cosas de otro objeto que de sí mismo. Duplicación de código. Duplicar, o copiar y pegar, código no es una buena idea. Grupos de datos. Manojos de datos que se arrastran juntos (se ven juntos en los atributos de clases, en parámetros, etc.) debieran situarse en una clase. Tiene beneficios inmediatos como son la reducción de las listas de parámetros y de llamadas a métodos.

REFACTORIZACIÓN Y PRUEBAS
Las pruebas son una parte fundamental en el proceso de refactorización, tenemos que recordar que la piedra angular de la refactorización es no agregar ni modificar la funcionalidad del programa mientras se refactoriza, por lo que la creación de pruebas de código nos permite corroborar si antes y después de una refactorización los resultados son los mismos o si, por el contrario, hemos hecho algo mal a la hora de refactorizar. Es probable que nos encontremos con casos en los que la refactorización necesaria que hay que realizar es tan grande que afecta al diseño del código de manera muy significativa, lo cual nos obligará a modificar las pruebas.

HERRAMIENTAS DE AYUDA A LA REFACTORIZACIÓN.
El uso de herramientas es vital en el desarrollo de la refactorización. Una herramienta de automatización de refactorizaciones permite: Configurar las refactorizaciones de forma sencilla para que se adapten a nuestros requisitos. Mostrar los cambios antes de que estos sucedan. Realizar los cambios de forma automática. Deshacer los cambios si fuera necesario. En Netbeans podemos utilizar los analizadores de código PMD y FindBugs.

PMD PMD es un analizador estático de código que utiliza unos conjuntos de reglas para identificar problemas dentro del software, ya sean posibles bugs, código muerto, duplicado, etc. No forma parte de la instalación estándar de Netbeans, por lo que tendremos que descargarlo desde , haciendo clic en el enlace «Netbeans Plugin». El fichero descargado tiene el nombre « _ _pmd.nbm» (los plugins que descargamos tienen la extensión *.nbm). Para instalarlo iremos al menú «Tools-Plugins».

En el cuadro de diálogo que se abre haremos clic en la ficha «Downloaded», hacemos clic en el botón «Add Plugins» y seleccionamos el fichero que hemos descargado. Hacemos clic en el botón «Install» para que se instale. Cuando termine habrá que reiniciar el entorno para que se apliquen los cambios. Cuando se haya reiniciado Netbeans, vamos al menú «Tools-Options». En el botón «Miscellaneous», vemos que se ha agregado la ficha «PMD».

Para elegir las reglas que se van a utilizar para revisar el código, hacemos clic en el botón «Manage rules». En el lado izquierdo están las reglas disponibles, en el derecho las que se van a usar y en medio los botones para pasar las reglas de una lista a otra.

Haciendo clic en el botón «Manage rulesets», podemos definir reglas personalizadas para revisar el código que tendremos en ficheros «.xml» o «.jar». Para ejecutar las revisión vamos al menú «Tools-Run PMD».

En la figura vemos un ejemplo del resultado
En la figura vemos un ejemplo del resultado. Dentro del código se marca las línea donde se encontró el primer fallo. En la parte baja se listan todos los fallos de diseño que se encuentran.

FindBugs Otra herramienta que podemos usar dentro de Netbeans para buscar posibles defectos de nuestro código es FindBugs. Como herramienta no es tan potente como PMD. Se accede a la misma desde «Source-Inspect». En el cuadro de diálogo elegimos en «Scope» si chequeamos el fichero, el paquete, el proyecto o todos los proyectos abiertos.

En «Configuration» elegimos «FindBugs»
En «Configuration» elegimos «FindBugs». Haciendo clic en el botón «Manage» (figura), elegimos las opciones para la revisión. Marcamos la casilla de selección de las reglas que queramos aplicar. Al seleccionar una, aparece en la derecha una descripción de la misma.

Hacemos clic en «OK» para volver al cuadro de diálogo anterior y, una vez allí, en «Inspect» para que comience la inspección. En la salida, veremos en el lado izquierdo el/los problema/s detectado y, en el derecho, una descripción del mismo.

El menú Refactor Además de las herramientas vistas, disponemos de otras ayudas a la refactorización dentro de Netbeans. Una de ellas la tenemos en las distintas opciones del menú «Refactor», que nos permite aplicar de una forma rápida y segura todos los cambios que refactoricen nuestro código. Renombrar: Cambia el nombre de una clase, variable o método y modifica todo el código del proyecto para referenciar al nuevo nombre. Move: Permite mover métodos o atributos de un paquete o de una clase a otra. Copy: Copia una clase a otro proyecto o paquete. Safely delete: Borrado seguro de una clase, método o atributo.

Inline: reemplaza las referencias a una variable, método, o constante con los valores asignados.
Change method parameters: Permite agregar, eliminar, modificar o cambiar el orden de los parámetros de un método, al igual que su modificador de acceso (private o public). Pull Up: Permite subir un método o campo a otra clase de la cual hereda la clase que contiene al método o campo que deseamos subir. Push Down: Permite bajar una clase anidada, método o campo a otra clase la cual hereda de la clase que contiene a la clase anidada, método o campo que deseamos bajar. Extract Interface: Permite seleccionar cuales métodos públicos no estáticos de una clase o interface, irán a parar a una nueva interface. La clase de la cual fue extraída la interface implementará la nueva interface creada. La interface de la cual fue extraída la interface extenderá la nueva interface.

Extract Superclass: Despliega al programador los métodos y campos que se pueden mover a una superclase. El programador selecciona cuales desea mover y NetBeans creará una nueva clase abstracta que contendrá dichos campos y métodos, también hará que la clase refactorizada la extienda. Use Supertype Where Possible: Despliega al programador todas las clases que extiende la clase actual. El programador seleccionará una, y NetBeans buscará en todo el proyecto referencias a la clase que se quiere refactorizar, si encuentra referencias, determinará si es posible utilizar la superclase seleccionada. Encapsulate Fields: Crea los métodos set y get para acceder a los campos de una clase. ………………………………………….

Veamos ejemplos de uso. Ejemplo: renombrar una clase. Hacemos clic sobre la clase y después en «Refactor-Rename». Ejemplo: renombrar un método. Hacemos clic sobre el método y después en «Refactor-Rename».

Veamos ejemplos de uso. Ejemplo: cambiar los parámetros de un método. Hacemos clic sobre el método y después en «Refactor-Change Method Parameters». -Hacemos clic en el botón «Add» para añadir parámetros al método. -Hacemos clic en el botón de cada tipo para modificarlo. -Desde la lista desplegable «Access» elegimos el tipo de acceso al método.

Veamos ejemplos de uso. Ejemplo: Encapsular campos . Hacemos clic sobre el método y después en «Refactor-Encapsulate Fields». Marcamos los métodos set y get para los campos que queramos.

4.2. Control de versiones. Estructura de las herramientas de control de versiones. Repositorio. Herramientas de control de versiones. Control de versiones Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto software o una configuración del mismo. Los sistemas de control de versiones facilitan la administración de las distintas versiones de cada producto desarrollado, así como las posibles especializaciones realizadas (por ejemplo, para algún cliente específico). El conjunto de información gestionada por el sistema de control de versiones es lo que se conoce con el nombre de repositorio.

Estructura de las herramientas de control de versiones.
Un sistema de control de versiones debe proporcionar: Control del almacenaje de los elementos que deba gestionar (archivos de texto, imágenes, documentación…) Posibilidad de realizar cambios sobre los elementos almacenados (modificaciones parciales, añadir, borrar, renombrar o mover elementos) Registro histórico de las acciones realizadas con cada elemento o conjunto de elementos (normalmente pudiendo volver o extraer un estado anterior del producto) Sería deseable que incluyera además: generación de informes con los cambios introducidos entre dos versiones, informes de estado, marcado con nombre identificativo de la versión de un conjunto de ficheros.

Las ventajas de usar un repositorio son:
Control exacto sobre cuál es la última versión del código, y quién y cuándo la ha cargado. Comparar versiones, viendo cuales han sido los cambios realizados. Regresar atrás (a una versión anterior) cuando lo que hemos desarrollado no nos ha dado los resultados esperados. Crear distintas ramas del proyecto. Si llegado a un punto se hace necesario hacer dos aplicaciones con distintas funcionalidades, pero con cosas en común, se pueden separar en dos ramas.

Conceptos claves sobre repositorios:
Trunk (tronco): la línea principal de desarrollo, donde se llevan a cabo los cambios menos complejos del día a día. Branch (rama): cuando se van a llevar a cabo cambios importantes que romperán la compilación, pruebas, experimentos o intentos de optimización, debe crearse una nueva rama de desarrollo. Esto es un branch: una copia del código o la rama de la que deriva. También puede crearse una rama para una versión terminada, hacer mantenimiento de esta versión sobre esta rama, y continuar el desarrollo de la nueva versión en el trunk. Tag (etiqueta): etiquetas que sirven para identificar un cierto momento en el desarrollo que queremos preservar. Se utilizan habitualmente para marcar cambios de versión (alfas, betas,…) y puntos de interés. Sobre un tag no se puede/no se debe hacer cambio.

Herramientas de control de versiones.
CVS (Concurrent Version System): Desarrollado por GNU se distribuye bajo licencia GPL. Fue muy popular hasta la aparición de Subversion. SVN (Subversion): Hoy es el más popular, fue creado para mejorar CVS, mejorando sobre todo el manejo de archivos binarios. Git: Diseñado por Linus Torvalds, es usado por el desarrollo del kernel de Linux, aunque no alcanza la popularidad de los otros dos. Mercurial: Un gestor de versiones para entornos distribuidos sin necesidad de usar un servidor.

Subversión Subversion es un sistema de control de versiones diseñado específicamente para reemplazar a CVS. Es software libre bajo una licencia de tipo Apache/BSD y se le conoce también como svn por ser el nombre de la herramienta utilizada en la línea de comandos. Una característica importante de Subversion es que, a diferencia de CVS, los archivos versionados no tienen cada uno un número de revisión independiente, en cambio, todo el repositorio tiene un único número de versión que identifica un estado común de todos los archivos del repositorio en un instante determinado. Dispone de acceso a redes para usarlo desde varios ordenadores. Permite deshacer los cambios.

Las ventajas de usar Subversion son:
Modificaciones atómicas. Creación de ramas y etiquetas operación más eficiente que en CVS (Coste constante, y no lineal) Se envían sólo las diferencias en ambas direcciones (en CVS siempre se envían al servidor archivos completos). Maneja eficientemente archivos binarios (a diferencia de CVS) Permite selectivamente el bloqueo de archivos. Integrado en Apache permite utilizar opciones que este servidor provee a la hora de autentificar archivos

¿Cómo usar Subversion? Para crear el servidor donde se alojará el repositorio, necesitamos una herramienta aparte. Por ejemplo, VisualSVN. Para configurar el repositorio local, necesitamos otra herramienta aparte. Por ejemplo, TortoiseSVN. Desde Netbeans, lo que haremos con Subversion es actualizar el proyecto en el que estamos trabajando en el repositorio.

1º) Instalamos el servidor para Subversion.
Para ello accedemos a la página de descarga de VisualSVN y lo descargamos. Cuando finalice la descarga obtendré el archivo «VisualSVN-Server msi», que es el instalador del programa. Lo ejecutamos y vamos pasando ventanas hasta llegar a la de la figura, donde activamos el primer botón de opción que nos instala el servidor.

Elegimos el directorio de instalación y de repositorios o dejamos los que hay por defecto. Si queremos que la comunicación con el repositorio se realice a través de HTTPS seleccionamos la casilla «Use secure connnection ( Seleccionamos el botón de opción «Use subversion autentication» para administrar los usuarios directamente desde el repositorio. Si el puerto que viene por defecto está en uso, lo cambiamos.

Cuando termine la instalación abrimos el programa y creamos el repositorio haciendo clic con el botón derecho del ratón sobre el icono «Repositories».

Veremos el cuadro de diálogo de la figura donde escribiremos un nombre para el repositorio.
El acceso al repositorio tiene que ser autentificado, por lo que crearemos un usuario.

En el cuadro de diálogo escribimos nombre y contraseña para el mismo
Veremos en la carpeta «Users» el usuario que hemos creado.

2º) Instalamos el cliente TortoiseSVN para configurar el repositorio local.
Accedemos a la página de la descarga y elegimos la versión en función de nuestro sistema operativo (32 o 64 bits). Tras completar la descarga tendremos el fichero «TortoiseSVN win32-svn msi» que es el instalador del programa. Lo instalamos con las opciones por defecto. Configuración del repositorio con TortoiseSVN Después de haber instalado creamos la carpeta en nuestro equipo para el repositorio local y, con el cliente de «TortoiseSVN», hacemos clic con en el botón derecho del ratón sobre «SVN Checkout».

En el cuadro de diálogo que se abre debemos de indicar al programa de donde bajará las fuentes y debemos de poner la URL en donde hemos configurado nuestro repositorio. Nos solicitará el nombre de usuario y contraseña para acceder al servidor del repositorio.

3º) Creamos el proyecto NetBeans en el repositorio local.
Ahora escribiríamos el código de nuestro proyecto y después los subiríamos al repositorio.

Para subir los cambios a nuestro proyecto, podemos usar Commit para que suba el proyecto al repositorio.

Elegimos la carpeta en el repositorio.
Veremos el cuadro de diálogo de la figura donde elegimos la URL del repositorio, escribimos el nombre de usuario y la contraseña. Elegimos la carpeta en el repositorio.

Elegimos los ficheros a importar al repositorio.

Veremos el cuadro de diálogo de la figura donde haremos clic en el botón Commit.
Podemos ver en el servidor los ficheros que se han subido.

Importar un proyecto usando TortoiseSVN
Nos movemos por el explorador de Windows hasta encontrar el proyecto que queremos subir, hacemos clic con el botón derecho del ratón sobre el mismo y elegimos «Import» en el menú contextual.

En el siguiente cuadro de dialogo escribimos la URL del repositorio.
Creamos una carpeta para el proyecto y hacemos clic en «OK»

En el siguiente cuadro de diálogo comprobamos que la ruta es la que pretendíamos y hacemos clic en «OK». En el siguiente cuadro de diálogo vemos el resultado de la importación.

En el siguiente cuadro de diálogo vemos los ficheros subidos en el servidor.

Al hacer clic con el botón derecho del ratón sobre el proyecto importado al repositorio, veremos todos los menús con las acciones que puedo realizar sobre el mismo.

Con la opción «Show log» del menú contextual, podemos ver las distintas revisiones-cambios en el proyecto, el autor y la fecha.

Podemos comparar una revisión con una de las anteriores haciendo clic en el botón derecho del ratón y eligiendo en el menú contextual una de las opciones de comparación.

En el cuadro de diálogo que se abre, podemos elegir el orden de comparación de la versión (con el botón de las dos flechas) y debajo los ficheros que se van a comparar.

Haciendo doble clic sobre el fichero en el cuadro de diálogo anterior, se abrirá el cuadro de la figura para mostrarnos las diferencias.

Revertir cambios Podemos regresar el proyecto al estado de una revisión concreta (Revert to this revision) o hacer que se deshagan los cambios hechos en una versión (Revert changes from this revision)

Crear repositorio local
Si no trabajamos en un equipo de desarrollo, podemos crear y gestionar un repositorio local con «TortoiseSVN». Para ello, elegimos la carpeta en la que ubicar el repositorio, hacemos clic con el botón derecho del ratón sobre la misma, y elegimos el menú «Create repository here». Así queda la carpeta

Haciendo clic con el botón derecho del ratón sobre el repositorio local, elegimos en el menú contextual «Repo Browser». En el cuadro de diálogo que se abre, creamos una carpeta para los ficheros del proyecto (botón derecho del ratón-Create folder).

En el explorador de Windows, buscamos la carpeta del proyecto que queremos importar al repositorio local, hacemos clic con el botón derecho del ratón y elegimos «Import» en el menú contextual. Seleccionamos la carpeta donde subir el proyecto y hacemos clic en «OK».

Crear una «branch» Hacemos clic con el botón derecho del ratón sobre la carpeta del proyecto y elegimos «Branch/tag» en el menú contextual.

En el cuadro de diálogo de la figura, elegimos la carpeta donde colocar la «branch». Y hacemos clic en «OK».

4.3. Pautas para la documentación. Uso de documentación alternativo.
En todo proyecto de software, es muy importante la documentación, no solo para el usuario final, sino para los propios desarrolladores, tanto para uno mismo como para otros desarrolladores que tengan que trabajar en el presente o futuro con el proyecto. Las razones principales para documentar el código fuente serían: Facilitar el mantenimiento Facilitar la reutilización El primer paso en una buena documentación es el uso apropiado de comentarios.

¿Qué documentar? Añadir explicaciones a todo lo que no es evidente. Ejemplos: ¿de qué se encarga una clase? ¿un paquete? ¿qué hace un método? ¿cuál es el uso esperado de un método? ¿para qué se usa una variable? ¿cuál es el uso esperado de una variable? ¿qué algoritmo estamos usando? ¿de dónde lo hemos sacado? ¿qué limitaciones tiene el algoritmo? ¿qué se debería mejorar ... si hubiera tiempo?

Tipo de comentarios javadoc
Se utiliza para generar documentación externa. Comentario de una línea Caracteres "//" y terminan con la línea. Se utiliza para documentar código que no necesitamos que aparezca en la documentación externa (que genere javadoc). Comentarios de más de una línea Caracteres "/*", se pueden prolongar a lo largo de varias líneas y terminan con los caracteres "*/".

El paquete de desarrollo Java nos proporcionan una herramienta para generar la documentación de nuestras clases en formato HTML a partir del código. Esta herramienta se llama javadoc. Los comentarios que comienzan con los códigos «/**» se llaman comentarios de documento y serán utilizados por los programas de generación de documentación javadoc. Los comentarios javadoc comienzan con el símbolo «/**» y terminan con «*/». Cada línea javadoc se inicia con un símbolo de asterisco. Dentro se puede incluir cualquier texto. Javadoc

El código javadoc se coloca en tres sitios distintos dentro del código de la aplicación:
Al principio del código de la clase (antes de cualquier código Java). En esta zona se colocan comentarios generales sobre la clase o interfaz que se crea. Dentro de estos comentarios se pueden utilizar Delante de cada método. Delante de cada método los comentarios javadoc se usan para describir al método en concreto. Además de los comentarios, en esta zona se pueden incluir @since Delante de cada atributo. Se describe para qué sirve cada atributo en cada clase. Puede poseer las

@author. Tras esa palabra se indica el autor del documento.
En el código javadoc se pueden usar etiquetas especiales, las cuales comienzan con el Pueden ser: @author. Tras esa palabra se indica el autor del documento. @version. Tras lo cual sigue el número de versión de la aplicación. Ejemplo: /** * Programa que calcula el mayor valor de entre los números de un array Alberto López 1.0 */

@see. Tras esta palabra se indica una referencia a otro código Java relacionado con éste. Ejemplo:
@since. Indica desde cuándo esta disponible este código @deprecated. Palabra a la que no sigue ningún otro texto en la línea y que indica que esta clase o método esta obsoleta u obsoleto.

@exception. Agrega un subencabezado Throws al documento con el nombre de la clase de la excepción que puede lanzar. @throws. Indica las excepciones que pueden lanzarse en ese código. Sinónimo del anterior. @param. Palabra a la que le sigue texto qué describe a los parámetros que requiere el código para su utilización (el código en este caso es un método de clase). Cada parámetro se coloca en una distinta, por lo que puede haber para el mismo método. @return. Tras esta palabra se describen los valores que devuelve el código (el código en este caso es un método de clase).

Ejemplo:

Javadoc con Netbeans NetBeans nos ayuda a editar los comentarios de documentación de los diferentes elementos de una clase: clase, atributos, métodos. Para agregar los comentarios de documentación a una clase se sigue el siguiente procedimiento: 1º) Colocamos el cursor en la línea anterior a la línea con el nombre del atributo o método al que vamos a agregarle un comentario de documentación y tecleamos los caracteres «/**». 2º) Al presionar la tecla Intro, veremos que NetBeans ha agregado un esqueleto para la documentación del elemento. 3º) En la segunda línea del comentario agregamos la descripción de lo que hace el método.

4º) Al lado derecho del nombre del parámetro de cada describimos el propósito del parámetro. 5º) Al lado derecho de cada describimos qué regresa el método. 6º) Al lado derecho del nombre de la excepción de cada describimos por qué razón se lanza la excepción. 7º) Si hay atributos no privados agregamos un comentario de documentación, describiendo su uso.

Generar la documentación Javadoc
Para generar la documentación Javadoc seleccionamos de la barra de menú de NetBeans la opción «Run/ Generate Javadoc (nombre proyecto)». Al terminar, Netbeans abre el navegador Web predeterminado y despliega en él la página inicial de la documentación del proyecto.

Haciendo clic en los enlaces podemos ver la documentación de las diferentes clases del
proyecto.

Configuración de Javadoc
Podemos configurar como NetBeans generará la documentación Javadoc para el proyecto. 1º) Hacemos clic con el botón derecho en el nombre del proyecto, en el árbol de proyectos y seleccionamos la opción Properties en el menú contextual. 2º) Aparecerá un cuadro de diálogo para establecer las propiedades del proyecto. Seleccionamos el nodo Documenting en el árbol Categories y, luego, las opciones que queremos.

Los archivos HTML Javadoc generados
Los archivos HTML Javadoc generados. Se encuentran dentro de la carpeta “dist/javadoc” que a su vez está dentro de la carpeta del proyecto.

4.4. Herramientas de refactorización, control de versiones y de generación de documentación del entorno de desarrollo. Herramientas de refactorización: PMD FindBugs Menú Refactor Herramientas de control de versiones: Subversion Git Mercurial Herramientas de generación de documentación: Javadoc

U. T Optimización y Documentación Refactorización

Presentaciones similares

Presentación del tema: "U. T Optimización y Documentación Refactorización"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

U. T Optimización y Documentación Refactorización

Presentaciones similares

Presentación del tema: "U. T Optimización y Documentación Refactorización"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback