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

Question

¿Que intentamos hacer cuando refactorizamos un código?

Answer 1

Hacerlo más fácil de comprender.

Answer 2

Hacerlo más complejo, pero con un funcionamiento más optimo.

Answer 3

Hacerlo más fácil de modificar.

Answer 4

Hacer un código más limpio.

Answer 5

Tener una revisión del código para ver su funcionalidad detectar fallos.

Answer 6

Cambiar la funcionalidad del programa de manera rápida.

Answer 7

Hacer unos cambios en el codigo sin cambiar su comportamiento observable

Answer 8

Mantener el código sencillo y bien estructurado.

Answer 9

Entender la funcionalidad del programa y mejorarlo.

Answer 10

Crear extensiones de ese código para añadir nuevas funcionalidades.

Answer 11

Etapa de análisis.

Answer 12

Etapa de diseño.

Answer 13

Etapa de programación.

Answer 14

Etapa de pruebas.

Answer 15

Etapa de documentación.

Answer 16

Etapa de mantenimiento.

Answer 17

Etapa de codificación.

Answer 18

No existe ninguna etapa de desarrollo especifica.

Answer 19

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.

Answer 20

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.

Answer 21

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.

Answer 22

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.

Answer 23

Escalabilidad. Refactorizar nos permite escalar un proyecto para añadirle funciones y hacerlo mucho más completo.

Answer 24

Continuar. Una vez empezado se debe terminar.

Answer 25

Frenar la inercia de seguir desarrollando.

Answer 26

Reiniciar de cero. Si algo que has hecho empieza a hacer costoso igual lo puedes hacer de cero de una manera más optima.

Answer 27

Bad Smells

Answer 28

Código errado

Answer 29

Código problematico

Answer 30

Para saber si el programa tiene el mismo funcionamiento que antes de los cambios.

Answer 31

Para saber si el desarrollo sigue cumpliendo los requisitos que implementaba.

Answer 32

Por que refactorizar sin ellas lleva un alto riesgo.

Answer 33

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.

Answer 34

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.

Answer 35

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.

Answer 36

Es necesario un replanteamiento de la refactorizacion para no perder el tiempo o tener gastos innecesarios.

Answer 37

Planificar nunca esta de mas. Mientras mas planificado este más perfecto sera.

Answer 38

No planifiques. Déjalo para otro momento o comienza la refactorizacion sin ello.

Answer 39

Definiendo claramente los objetivos antes de comenzar y estimando la duracion.

Answer 40

Teniendo un equipo vigilando de las personas que se encargan de refactorizar.

Answer 41

Haciendo documentación exhaustiva sobre la refactorizacion.

Answer 42

Una refactorizacion conduce a otra refactorizacion hasta que resulta ser mas complicada y no se puede determinar el tiempo que se tardara en refactorizar.

Answer 43

Una refactorizacion conduce a otra por lo que resulta más sencillo refactorizar el código y se tarda menos.

Answer 44

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.

Answer 45

Determinar el objetivo de la refactorizacion antes de empezar.

Answer 46

Si aparece nuevo código susceptible de refactorizacion se anota y no se refactoriza, aun.

Answer 47

Introducir código en el sistema de control de versiones.

Answer 48

Refactorizar todo el código que te encuentres.

Answer 49

Eliminar el código que sea susceptible a la refactorizacion.

Answer 50

JavaStyle.

Answer 51

BugFiction

Answer 52

Más tiempo que desarrollar.

Answer 53

Una pequeña parte relacionado al tiempo dedicado a añadir nuevas funcionalidades.

Answer 54

El mismo tiempo que desarrollar.

Answer 55

Escribir pruebas unitarias y funcionales.

Answer 56

Usar herramientas especializadas.

Answer 57

Dar formación sobre patrones de refactorizacion y de diseño.

Answer 58

Refactoriar los principales fallos de diseño.

Answer 59

Comenzar a refactorizar el codigo tras añadir cada nueva funcionalidad en grupo.

Answer 60

Implantar refactorizacion continua al desarrollo completo.

Answer 61

Elegir a un equipo competente para refactorizar.

Answer 62

Refactorizar todo el proyecto.

Answer 63

Evitar refactorizar continuamente el código durante el desarrollo para evitar perder el tiempo durante el desarrollo.

Answer 64

El riesgo de la refactorizacion disminuye. Al terminar se puede saber que todo sigue funcionando de manera correcta.

Answer 65

Evita efectos colaterales ya que cuando un desarrollar realiza una refactorizacion puede comprobar que no ha estropeado nada.

Answer 66

Permiten que la refactorizacion vaya más rápida por que se reduce el tiempo de comprobación sobre el funcionamiento del proyecto.

Answer 67

Aumenta la velocidad de implementacion de funcionalidades y su funcionamiento respecto al código.

Answer 68

Permite encontrar fallos en caso de implementar más funcionalidades.

Answer 69

Refactorizar sin test es una actividad de alto riesgo. Solo se debe hacer en casos sencillos y con herramientas especializadas.

Answer 70

Television Digital Distante.

Answer 71

Desarrollo guiado por Pruebas.

Answer 72

Test de Direccionamiento y Digitabilidad.

Answer 73

Es una metodología ágil que propone integrar las pruebas y la refactorizacion.

Answer 74

Se busca implementar las pruebas antes de crear el código a probar. Agiliza la creacion de codigo y la realizacion de pruebas unitarias.

Answer 75

Es una metodología parecida a la scrum.

Answer 76

Busca solucionar los problemas de la "Espiral de Refactorizacion".

Answer 77

La refactorizacion y las pruebas unitarias.

Answer 78

El desarrollo y ampliación del programa.

Answer 79

Tipo de mantenimiento y refactorizacion.

Answer 80

Sustituir una variable llamada "v" y renombrarla a "velocidad" para que sea más significativa

Answer 81

Crear un método común para evitar el código duplicado.

Answer 82

Trasformar el código dentro de un bloque en una subrutina.

Answer 83

Transformar una sentencia "if" en polimorfismo.

Answer 84

Reducir el tamaño de un método para reutilizarlo con mayor facilidad.

Answer 85

Cambiar un método de clase por que utiliza más elementos de la clase nueva que de la antigua.

Answer 86

Mismo código en más de un lugar.

Answer 87

Más corto más fácil reutilizarlo.

Answer 88

Se pasan demasiados parámetros.

Answer 89

Los cambios no están relacionados.

Answer 90

Varias modificaciones en diversos lugare

Answer 91

Utiliza más elementos de otra clase.

Answer 92

Solo tienen "get" y "set".

Answer 93

Uso de pocas caracteristicas de supclass

Answer 94

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.

Answer 95

Se debe crear una lista de parámetros extensa para evitar que el objeto consuma muchos recursos del sistema. Mejora el rendimiento.

Answer 96

El objeto recibe muchos parámetros y la mayoría no son usados. Se vuelve un método inútil y se debe eliminar.

Answer 97

La clase suele ser modificada por diversos motivos los cuales no tienen relación entre si.

Answer 98

La clase sufre muchos cambios. Se debe buscar una solución para que no se modifique tanto.

Answer 99

La clase tiene variables difíciles de llamar y suelen estar en privado. Las modificaciones se vuelven muy tediosas.

Answer 100

Después de un cambio en determinado lugar, se deben cambiar otro código en diferentes partes del proyecto.

Answer 101

Es una solución referente a que se deben hacer ciertos cambios en diferentes lugares para hacer un método más sencillo.

Answer 102

Eliminar ciertos métodos relacionados inútilmente con el código a refactorizar para evitar el acceso a datos de forma incorrecta.

Answer 103

El método utiliza más cantidad de elementos de otra clase que de la propia

Answer 104

Se suele resolver el problema pasando el método a la clase que tiene los elementos usados.

Answer 105

El método utiliza elementos de otras clases.

Answer 106

Se suele resolver pasando los datos necesarios a atributos antes de iniciar el método problemático.

Answer 107

Las subclases usan pocas características de su superclase.

Answer 108

La jerarquia no fue pensada de forma correcta, ya que la subclase apenas necesita a su superclase.

Answer 109

Las superclase pasa demasiadas características a sus subclases.

Answer 110

La jerarquia es inútil por que no se necesitan distinguir las clases jerarquicamente.

Nächster

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

Beschreibung

Zusammenfassung der Ressource

Frage 1

Frage 2

Frage 3

Frage 4

Frage 5

Frage 6

Frage 7

Frage 8

Frage 9

Frage 10

Frage 11

Frage 12

Frage 13

Frage 14

Frage 15

Frage 16

Frage 17

Frage 18

Frage 19

Frage 20

Frage 21

Frage 22

Frage 23

Frage 24

Frage 25

Frage 26

Frage 27

Frage 28

Frage 29

Frage 30

Frage 31

ähnlicher Inhalt

	Erstellt von Alvaro Garcia Varela vor mehr als 8 Jahre