Repaso entornos de desarrollo: Refactorizacion. (Teoría)

Beschreibung

Quiz am Repaso entornos de desarrollo: Refactorizacion. (Teoría), erstellt von Alvaro Garcia Varela am 18/05/2016.
Alvaro Garcia Varela
Quiz von Alvaro Garcia Varela, aktualisiert more than 1 year ago
Alvaro Garcia Varela
Erstellt von Alvaro Garcia Varela vor fast 8 Jahre
66
1

Zusammenfassung der Ressource

Frage 1

Frage
¿Que intentamos hacer cuando refactorizamos un código?
Antworten
  • Hacerlo más fácil de comprender.
  • Hacerlo más complejo, pero con un funcionamiento más optimo.
  • Hacerlo más fácil de modificar.
  • Hacer un código más limpio.
  • Tener una revisión del código para ver su funcionalidad detectar fallos.
  • Cambiar la funcionalidad del programa de manera rápida.
  • Hacer unos cambios en el codigo sin cambiar su comportamiento observable

Frage 2

Frage
¿Cual es el objetivo final de la refactorizacion?
Antworten
  • Mantener el código sencillo y bien estructurado.
  • Entender la funcionalidad del programa y mejorarlo.
  • Crear extensiones de ese código para añadir nuevas funcionalidades.

Frage 3

Frage
Cual es la etapa de desarrollo especifica para realizar una refactorizacion.
Antworten
  • Etapa de análisis.
  • Etapa de diseño.
  • Etapa de programación.
  • Etapa de pruebas.
  • Etapa de documentación.
  • Etapa de mantenimiento.
  • Etapa de codificación.
  • No existe ninguna etapa de desarrollo especifica.

Frage 4

Frage
¿Cuales son las razones de la refactorizacion?
Antworten
  • Calidad. Hacer que el código sea sencillo bien estructurado, permitiendo que una persona externa al equipo de desarrollo pueda entender el proyecto sin haber estado integrado durante varios meses.
  • Eficiencia. Mantener un buen diseño y un código estructurado nos permite ser más eficientes a la hora de desarrollar. Mejora las modificaciones a la hora de eliminar código repetido o una simplificación del diseño.
  • Evitar la reescritura de código. Reescribir el código es peor que refactorizarlo. Leer y modificar un código que no se conoce es bastante complicado si este código no sigue estándares.
  • Modificación. Para modificar es bueno refactorizar. La refactorizacion nos permite modificar un código de manera segura y eso nos permite continuar de manera positiva el proyecto.
  • Escalabilidad. Refactorizar nos permite escalar un proyecto para añadirle funciones y hacerlo mucho más completo.

Frage 5

Frage
¿Que se debe hacer los cambios de un proyecto empiezan a ser muy costosos?
Antworten
  • Continuar. Una vez empezado se debe terminar.
  • Frenar la inercia de seguir desarrollando.
  • Reiniciar de cero. Si algo que has hecho empieza a hacer costoso igual lo puedes hacer de cero de una manera más optima.

Frage 6

Frage
¿Como se conoce a los síntomas que indican que algún código de software tiene problemas?
Antworten
  • Bad Smells
  • Código errado
  • Código problematico

Frage 7

Frage
¿Por que es imprescindible que un proyecto tenga pruebas automáticas?
Antworten
  • Para saber si el programa tiene el mismo funcionamiento que antes de los cambios.
  • Para saber si el desarrollo sigue cumpliendo los requisitos que implementaba.
  • Por que refactorizar sin ellas lleva un alto riesgo.

Frage 8

Frage
Refactorizar es considerado un avance significativo del proyecto para los clientes.
Antworten
  • True
  • False

Frage 9

Frage
¿Por que es importante tener la refactorizacion bajo control?
Antworten
  • Por que si refactorizar se te va de las manos se puede convertir en una molestia ya que llegas a sentir que es una perdida de tiempo y sobre todo te da una sensación de no estar avanzando en el proyecto.
  • No hace falta añadir moficiaciones que el cliente no ha pedido, por lo que hay que fijar los objetivos antes de empezar a refactorizar.
  • Refactorizar es un tipo de practica de alto riesgo, si no se saben los objetivos puede resultar que se cambie demasiado el código y cree un cambio en el funcionamiento del programa.

Frage 10

Frage
Cuando hay problemas de comunicación en el equipo de desarrollo hay que detener el desarrollo y reunir a todo el equipo.
Antworten
  • True
  • False

Frage 11

Frage
¿Que se debe hacer si se excede el tiempo planificado para refactorizar?
Antworten
  • Es necesario un replanteamiento de la refactorizacion para no perder el tiempo o tener gastos innecesarios.
  • Planificar nunca esta de mas. Mientras mas planificado este más perfecto sera.
  • No planifiques. Déjalo para otro momento o comienza la refactorizacion sin ello.

Frage 12

Frage
¿Como se debe mantener la refactorizacion bajo control?
Antworten
  • Definiendo claramente los objetivos antes de comenzar y estimando la duracion.
  • Teniendo un equipo vigilando de las personas que se encargan de refactorizar.
  • Haciendo documentación exhaustiva sobre la refactorizacion.

Frage 13

Frage
¿Es importante las reuniones diarias para facilitar la comunicación y conocer el estado actual, los problemas y el objetivo de nuestro proyecto?
Antworten
  • True
  • False

Frage 14

Frage
¿Que es la espiral refactorizadora?
Antworten
  • Una refactorizacion conduce a otra refactorizacion hasta que resulta ser mas complicada y no se puede determinar el tiempo que se tardara en refactorizar.
  • Una refactorizacion conduce a otra por lo que resulta más sencillo refactorizar el código y se tarda menos.
  • Se encuentran todos los Bad Smells y se usa una sola técnica de refactorizacion para terminar de refactorizar de forma más eficiente y rapida.

Frage 15

Frage
¿Que medidas aplicamos para evitar una "Espiral refactorizadora"?
Antworten
  • Determinar el objetivo de la refactorizacion antes de empezar.
  • Si aparece nuevo código susceptible de refactorizacion se anota y no se refactoriza, aun.
  • Introducir código en el sistema de control de versiones.
  • Refactorizar todo el código que te encuentres.
  • Eliminar el código que sea susceptible a la refactorizacion.

Frage 16

Frage
Las herramientas para detectar Bad Smells ayudan a sustituir al sentido comun.
Antworten
  • True
  • False

Frage 17

Frage
Selecciona las herramientas que sirvan para identificar Bad Smells.
Antworten
  • JavaStyle.
  • JCSC
  • PMD
  • FindBug
  • EasyUML
  • BugFiction
  • PDM

Frage 18

Frage
¿Cuanto tiempo ocupa refactorizar?
Antworten
  • Más tiempo que desarrollar.
  • Una pequeña parte relacionado al tiempo dedicado a añadir nuevas funcionalidades.
  • El mismo tiempo que desarrollar.

Frage 19

Frage
Tomar actitudes exigentes o criterios excesivamente personales respecto a la calidad del código puede acabar siendo un riesgo para el proyecto.
Antworten
  • True
  • False

Frage 20

Frage
Di las practicas saludables a la hora de implantar la refactorizacion de un código dentro de un proyecto.
Antworten
  • Escribir pruebas unitarias y funcionales.
  • Usar herramientas especializadas.
  • Dar formación sobre patrones de refactorizacion y de diseño.
  • Refactoriar los principales fallos de diseño.
  • Comenzar a refactorizar el codigo tras añadir cada nueva funcionalidad en grupo.
  • Implantar refactorizacion continua al desarrollo completo.
  • Elegir a un equipo competente para refactorizar.
  • Refactorizar todo el proyecto.
  • Evitar refactorizar continuamente el código durante el desarrollo para evitar perder el tiempo durante el desarrollo.

Frage 21

Frage
¿Como ayuda la existencia de pruebas automatizadas la refactorizacion?
Antworten
  • El riesgo de la refactorizacion disminuye. Al terminar se puede saber que todo sigue funcionando de manera correcta.
  • Evita efectos colaterales ya que cuando un desarrollar realiza una refactorizacion puede comprobar que no ha estropeado nada.
  • Permiten que la refactorizacion vaya más rápida por que se reduce el tiempo de comprobación sobre el funcionamiento del proyecto.
  • Aumenta la velocidad de implementacion de funcionalidades y su funcionamiento respecto al código.
  • Permite encontrar fallos en caso de implementar más funcionalidades.
  • Refactorizar sin test es una actividad de alto riesgo. Solo se debe hacer en casos sencillos y con herramientas especializadas.

Frage 22

Frage
¿Que significa TDD?
Antworten
  • Television Digital Distante.
  • Desarrollo guiado por Pruebas.
  • Test de Direccionamiento y Digitabilidad.

Frage 23

Frage
¿Que es la TDD y cual es su objetivo?
Antworten
  • Es una metodología ágil que propone integrar las pruebas y la refactorizacion.
  • Se busca implementar las pruebas antes de crear el código a probar. Agiliza la creacion de codigo y la realizacion de pruebas unitarias.
  • Es una metodología parecida a la scrum.
  • Busca solucionar los problemas de la "Espiral de Refactorizacion".

Frage 24

Frage
Di dos aspectos de gran importancia en el Desarrollo de aplicaciones.
Antworten
  • La refactorizacion y las pruebas unitarias.
  • El desarrollo y ampliación del programa.
  • Tipo de mantenimiento y refactorizacion.

Frage 25

Frage
Selecciona ejemplos de refactorizaciones complejas o que sean triviales para el proyecto.
Antworten
  • Sustituir una variable llamada "v" y renombrarla a "velocidad" para que sea más significativa
  • Crear un método común para evitar el código duplicado.
  • Trasformar el código dentro de un bloque en una subrutina.
  • Transformar una sentencia "if" en polimorfismo.
  • Reducir el tamaño de un método para reutilizarlo con mayor facilidad.
  • Cambiar un método de clase por que utiliza más elementos de la clase nueva que de la antigua.

Frage 26

Frage
Di que significan los siguientes patrones de refactorizacion: [blank_start]Código duplicado.[blank_end] [blank_start]Método Largo.[blank_end] [blank_start]Lista larga de parámetros.[blank_end] [blank_start]Cambio divergente.[blank_end] [blank_start]Cirugia de escopeta.[blank_end] [blank_start]Envidia de funcionalidad.[blank_end] [blank_start]Clase de datos.[blank_end] [blank_start]Legado Rechazado.[blank_end]
Antworten
  • Mismo código en más de un lugar.
  • Más corto más fácil reutilizarlo.
  • Se pasan demasiados parámetros.
  • Los cambios no están relacionados.
  • Varias modificaciones en diversos lugare
  • Utiliza más elementos de otra clase.
  • Solo tienen "get" y "set".
  • Uso de pocas caracteristicas de supclass

Frage 27

Frage
En el patrón de refactorizacion: Lista de parámetros extensa ¿Cual es el problema principal?
Antworten
  • Se pasan muchos parámetros al objeto, resultan ser demasiado difíciles de entender y suelen variar con frecuencia. Los métodos solo deberían tener aquellos minimamente necesarios para que el objeto consiga su objetivo.
  • Se debe crear una lista de parámetros extensa para evitar que el objeto consuma muchos recursos del sistema. Mejora el rendimiento.
  • El objeto recibe muchos parámetros y la mayoría no son usados. Se vuelve un método inútil y se debe eliminar.

Frage 28

Frage
En el patrón de refactorizacion: Cambio divergente ¿Cual es el problema principal?
Antworten
  • La clase suele ser modificada por diversos motivos los cuales no tienen relación entre si.
  • La clase sufre muchos cambios. Se debe buscar una solución para que no se modifique tanto.
  • La clase tiene variables difíciles de llamar y suelen estar en privado. Las modificaciones se vuelven muy tediosas.

Frage 29

Frage
En el patrón de refactorizacion: Cirugía de escopeta ¿Cual es el problema principal?
Antworten
  • Después de un cambio en determinado lugar, se deben cambiar otro código en diferentes partes del proyecto.
  • Es una solución referente a que se deben hacer ciertos cambios en diferentes lugares para hacer un método más sencillo.
  • Eliminar ciertos métodos relacionados inútilmente con el código a refactorizar para evitar el acceso a datos de forma incorrecta.

Frage 30

Frage
En el patrón de refactorizacion: Envidia de funcionalidad ¿Cual es el problema principal y como se resuelve?
Antworten
  • El método utiliza más cantidad de elementos de otra clase que de la propia
  • Se suele resolver el problema pasando el método a la clase que tiene los elementos usados.
  • El método utiliza elementos de otras clases.
  • Se suele resolver pasando los datos necesarios a atributos antes de iniciar el método problemático.

Frage 31

Frage
En el patrón de refactorizacion: Legado Rechazado ¿Cual es el problema principal?
Antworten
  • Las subclases usan pocas características de su superclase.
  • La jerarquia no fue pensada de forma correcta, ya que la subclase apenas necesita a su superclase.
  • Las superclase pasa demasiadas características a sus subclases.
  • La jerarquia es inútil por que no se necesitan distinguir las clases jerarquicamente.
Zusammenfassung anzeigen Zusammenfassung ausblenden

ähnlicher Inhalt

ein kleines Informatik Quiz
AntonS
PuKW - STEP1 Prüfungsvorbereitung WS 13/14
kathvee
Elektrische Spannung
Peter Kasebacher
Städte Europas
Laura Overhoff
Projektmanagement
zok42.com
Kommunikationssoziologie teil 2 grimm
Victoria N.
FOST 3 - Inferenzstatistik
Kathy H
Ökologie
Zami I.
Vetie - Radiologie Übungs-K
Fioras Hu
Vetie: Geflügelkrankheiten Der Graupapagei
Björn Sake
Vetie Fleisch 2022
Maite J