Ingeniería de software - Resumen de los puntos clave del examen

descripción general

• ¿Qué es la ingeniería de software? es utilizar métodos de ingeniería para desarrollar software

• El objetivo de la ingeniería de software: crear software suficientemente bueno

• Definición de ingeniería de software: la ingeniería de software es una disciplina de ingeniería que guía el desarrollo y mantenimiento de software de computadora. Utilizar conceptos, principios, técnicas y métodos de ingeniería para desarrollar y mantener software, combinar técnicas de gestión correctas probadas y comprobadas con los mejores métodos técnicos actualmente disponibles, para desarrollar software de alta calidad de manera económica y mantenerlo de manera efectiva.

• El proceso de ingeniería de software se refiere a una serie de actividades relacionadas con el fin de lograr un objetivo específico en el ciclo de vida

• Los métodos de ingeniería de software incluyen métodos de desarrollo de software, métodos de medición de software, métodos de gestión de software y métodos de entorno de software.

• Software = programa + datos + documento

• Características esenciales del software: complejidad, variabilidad, invisibilidad, consistencia

• Software Crisis: Una serie de problemas serios encontrados en el desarrollo y mantenimiento de software de computadora

• Proceso de desarrollo de software: definición de problemas, desarrollo de requisitos, diseño de software, construcción de software, pruebas de software

• Ciclo de vida del software: estudio de viabilidad y plan de desarrollo del proyecto, análisis de requisitos, diseño del esquema, diseño detallado, construcción del software, pruebas, mantenimiento

 

modelo de cascada

Adecuado para el desarrollo de proyectos de software con requisitos de usuario claros y completos y sin cambios importantes

Es un modelo document-driven , luego de completar cada etapa de la tarea se genera el documento correspondiente

Revisar el trabajo implementado para cada actividad , enfatizando las etapas de desarrollo, planificación temprana e investigación de demanda y prueba de productos.

Desventajas: dado que es un modelo de desarrollo lineal ideal, no puede resolver el problema de requisitos poco claros o cambiantes

 

modelo de prototipado rápido

Es adecuado para muchas situaciones en las que el usuario no puede proporcionar una descripción completa y precisa de los requisitos, o el desarrollador no puede determinar la efectividad del algoritmo, la adaptabilidad del sistema operativo o la forma de interacción humano-computadora. de acuerdo a un conjunto de necesidades básicas del usuario un prototipo

Paso 4: Análisis rápido

Prototipo de construcción

Ejecutar y evaluar prototipos

Modificaciones y Mejoras

modelo incremental

Un modelo para el desarrollo incremental de versiones de software progresivamente refinadas. Modularice el sistema de software a desarrollar, trate cada módulo como un componente incremental y analice, diseñe, codifique y pruebe estos componentes incrementales en lotes.

Agregue características de forma incremental con cada nueva versión hasta que se construya la funcionalidad completa

 

 

ventaja:

• El producto completo se descompone en muchos componentes incrementales, que los desarrolladores pueden desarrollar paso a paso.

  • Envíe productos que puedan completar parte del trabajo a los usuarios en un corto período de tiempo, y envíelos en lotes y gradualmente. Los usuarios pueden hacer un trabajo útil desde el día en que se entrega el primer artefacto.

• Desarrollar en unidades de componentes reduce el riesgo de desarrollo de software. Los errores dentro de un ciclo de desarrollo no afectan a todo el sistema de software.

• La secuencia de desarrollo es flexible. Los desarrolladores pueden priorizar el orden de implementación de los componentes y completar primero los componentes principales con requisitos estables. Cuando cambia la prioridad de los componentes, el orden de implementación se puede ajustar a tiempo.

• El aumento gradual de las funciones del producto puede permitir que los usuarios tengan más tiempo para aprender y adaptarse a los nuevos productos, lo que reduce el impacto que un software nuevo puede tener en la organización del cliente.

dificultad:

• Al integrar cada nuevo componente incremental en la arquitectura de software existente, no debe destruir los productos que se han desarrollado originalmente. Además, la arquitectura del software debe diseñarse para facilitar la expansión de esta manera, y el proceso de agregar nuevos componentes a los productos existentes debe ser simple y conveniente, es decir, la arquitectura del software debe ser abierta.

• Los desarrolladores deben considerar el sistema de software no solo como un todo, sino también como componentes independientes, que son contradictorios. Se desarrollan varios componentes en paralelo y existe el riesgo de que no se puedan integrar.

• El uso del modelo incremental requiere un diseño más cuidadoso que los modelos en cascada y de creación rápida de prototipos, pero el esfuerzo adicional en la fase de diseño valdrá la pena en la fase de mantenimiento.

modelo espiral

• Adecuado para grandes sistemas complejos,

• impulsado por el riesgo

• El modelo espiral combina el modelo en cascada y el modelo incremental, añadiendo análisis de riesgo

• La idea básica del modelo en espiral es reducir el riesgo

Puede verse como un modelo de creación rápida de prototipos que agrega un proceso de análisis de riesgos antes de cada fase

El modelo en espiral divide el proceso de desarrollo en planificación, análisis de riesgos, ingeniería de implementación y evaluación del cliente.

modelo de fuente

Utilizado principalmente para apoyar el proceso de desarrollo orientado a objetos, iterativo

Impulsado por las necesidades del usuario e impulsado por los objetos

modelo iterativo

Envíe un sistema completo al principio y complemente y mejore las funciones de cada subsistema en versiones posteriores

 

 

RUP (Rational Unified Process, modelo de proceso unificado)

• RUP repite una serie de ciclos, cada ciclo termina con un producto entregado al usuario.

• Cada ciclo se divide en cuatro fases : iniciación, perfeccionamiento, construcción y entrega , y cada fase se itera en torno a nueve flujos de trabajo principales.

• Flujos de trabajo de soporte principal: entorno, gestión de proyectos, administración y gestión de cambios

• Flujos de trabajo de procesos centrales: implementación, pruebas, implementación, análisis y diseño, modelado empresarial

1. Fase inicial : realice la definición del problema, determine el alcance del sistema de destino, evalúe su viabilidad y reduzca los riesgos clave. **Equivalente al período de planificación en el modelo de ciclo de vida de tres segmentos.

2. Etapa de refinamiento: principalmente completar el análisis de problemas de dominio y el diseño de software, configurar varios recursos y establecer la arquitectura del sistema (incluidas varias vistas).

3. Fase de construcción: esta fase es el proceso de fabricación del producto, centrándose en la implementación y prueba del sistema, centrándose en la gestión de recursos y el control de las operaciones para optimizar el costo, el cronograma y la calidad.

4. Fase de entrega: * *Lanzamiento de producto, instalación, formación de usuarios. **La atención se centra en asegurarse de que el usuario final pueda utilizar el software.

Características: proceso de desarrollo de software basado en riesgos, centrado en la arquitectura, iterativo y configurable basado en la tecnología UseCase

desarrollo ágil

Con las características de iteración cíclica centrada en las personas y respuesta a los cambios, nos enfocamos en la entrega rápida y de alta calidad de software funcional que satisface a los clientes.

El proceso de desarrollo está centrado en el código, no en el documento

El desarrollo ágil divide todo el ciclo de vida del software en varias iteraciones pequeñas (2 a 4 semanas). Cada iteración es un pequeño modelo en cascada, y al final se debe generar una versión de software estable y verificada.

Programación extrema

Un enfoque flexible para el desarrollo de software con codificación en su núcleo

El objetivo de XP : convertir las necesidades vagas y cambiantes de los usuarios en productos de software que satisfagan los requisitos de los usuarios en el menor tiempo posible.

La diferencia entre RUP y XP:

RUP está orientado al nivel de gestión y XP está orientado al nivel de implementación. Los dos son complementarios y complementarios entre sí.

Solo bajo el marco de gestión de RUP se puede adoptar XP en el proceso de implementación iterativa y desempeñar el papel "rápido" de XP

estudio de factibilidad

Factibilidad Técnica, Factibilidad Social, Factibilidad Económica

Tres conclusiones: factible, básicamente factible, no factible

Análisis de requisitos de software

• Necesidades del negocio

• necesidades del usuario

• requisitos del sistema

• Requerimientos funcionales

Proceso: adquisición de requisitos—>análisis y modelado—>redacción de documentos—>verificación de requisitos—>cambio de requisitos

UML

constituir

Vistas: vista de caso de uso, vista de diseño, vista de proceso, vista de implementación, vista de implementación

imagen:

• use el diagrama del caso

• Diagramas estáticos: diagramas de clases, diagramas de objetos, diagramas de paquetes

• Diagramas de comportamiento: diagramas de estado, diagramas de actividad

• Diagrama de interacción: diagrama de secuencia, diagrama de cooperación

• Diagrama de implementación: Diagrama de componentes, Diagrama de implementación

Elementos del modelo: elementos base, elementos estereotipados

mecanismo general

use el diagrama del caso

 

relación entre casos de uso

1. Incluir

　　La relación de contención significa que un caso de uso puede simplemente contener los comportamientos de otros casos de uso y usar los comportamientos de los casos de uso que contiene como parte de su propio comportamiento. En UML, la relación de contención se representa mediante un segmento de línea punteada con una flecha más la palabra <>, y la flecha apunta desde el caso de uso base (Base) hasta el caso de uso incluido (Inclusión).

　　Cuando se trata de la relación de contención, el método específico es abstraer las partes comunes de varios casos de uso en un nuevo caso de uso. Hay dos situaciones principales que requieren el uso de relaciones de contención:

• Primero, si varios casos de uso usan el mismo comportamiento, puede abstraer este comportamiento común en un solo caso de uso y luego permitir que otros casos de uso incluyan este caso de uso.

• En segundo lugar, cuando un determinado caso de uso tiene demasiadas funciones y el flujo de eventos es demasiado complejo, también podemos abstraer un determinado flujo de eventos en un caso de uso contenido para simplificar la descripción.

　　

　　

1. expandir

　　Bajo ciertas condiciones, se agregan nuevos comportamientos a los casos de uso existentes, y los nuevos casos de uso obtenidos se denominan casos de uso de extensión (Extensión), y los casos de uso originales se denominan casos de uso base (Base), y la relación de los casos de uso de extensión a casos de uso base es la relación de extensión. Un caso de uso base puede tener uno o más casos de uso de extensión, y estos casos de uso de extensión se pueden usar juntos.

3. Generalización

　　La generalización de un caso de uso significa que un caso de uso principal puede especializarse para formar múltiples casos de uso secundario, y la relación entre el caso de uso principal y los casos de uso secundario es la relación de generalización. En la relación de generalización del caso de uso, el caso de uso hijo hereda todas las estructuras, comportamientos y relaciones del caso de uso padre, y el caso de uso hijo es una forma especial del caso de uso padre. Los subcasos también pueden agregar, anular y cambiar el comportamiento heredado. En UML, la relación de generalización de un caso de uso se representa mediante una flecha triangular que apunta desde un caso de uso secundario a un caso de uso principal.

　　Ejemplo generalizado: hay dos formas de depósitos bancarios, una es el depósito en ventanilla bancaria y la otra es el depósito en cajero automático. Aquí, los depósitos en ventanilla bancaria y los depósitos en cajero automático son formas especiales de depositar, por lo que "depósito" es el caso de uso principal, y "depósitos en ventanilla bancaria" y "depósitos en cajero automático" son casos de uso secundario.

ejemplo:

Diagrama de clase

El propósito principal del diagrama de clases es reflejar la estructura de la clase (atributos, operaciones) y la relación entre las clases. Describe la estructura del sistema de software y es un método de modelado estático.

La "clase" en el diagrama de clases corresponde al concepto de "clase" en el lenguaje orientado a objetos, que es una abstracción de las cosas en el mundo real.

especificación

1. Escriba en minúsculas el nombre del atributo de una sola palabra.

2. Si el nombre del atributo se compone de varias palabras, combine las palabras múltiples, excepto la primera palabra. Poner en mayúscula la primera letra de otras palabras.

3. La sintaxis del atributo: VisibilityName:Type=DefaultValue[ConstraintCharacteristics]

• Visibilidad indica si el atributo es visible para elementos fuera de la clase. Los más utilizados son público (+), protegido (#) y privado (-).

• Nombre indica el nombre del atributo, que es una cadena.

• Tipo define el tipo de atributo (tipo básico o tipo personalizado)

• El valor predeterminado representa el valor inicial de la propiedad.

Las representaciones de propiedades de restricción describen restricciones en los atributos.

cosas en el diagrama de clases

(un tipo

1. Se divide en tres partes de arriba a abajo, que son nombre de clase, atributo y operación. el nombre de la clase es obligatorio

2. Si una clase tiene atributos, cada atributo debe tener un nombre y también puede tener otra información de descripción, como visibilidad, tipo de datos, valor predeterminado, etc.

3. Si la clase tiene operaciones, cada operación también tiene un nombre y otra información opcional incluye visibilidad, nombre del parámetro, tipo de parámetro, valor predeterminado del parámetro y tipo de valor de retorno de la operación, etc.

(2) Interfaz

Un conjunto de operaciones, solo la declaración de la operación pero sin implementación

(3) Clase abstracta

Las clases que no se pueden instanciar generalmente contienen al menos una operación abstracta

(4) Clase de plantilla

Una clase parametrizada que vincula los parámetros de la plantilla a diferentes tipos de datos en tiempo de compilación, lo que da como resultado diferentes clases

3. La relación y explicación en el diagrama de clases

(1) Relación de asociación: describe la relación entre la estructura de la clase. Tiene información como dirección, nombre, rol y multiplicidad. La semántica de asociación general es débil.

También hay dos semánticas fuertes, a saber, agregación y combinación.

1. Relación de agregación: relación de asociación especial, que indica la relación entre un agregado (todo) y sus componentes

   

2. Relación de composición - agregación con semántica más fuerte, parte y todo tienen el mismo ciclo de vida

(2) Relación de generalización——※En orientación a objetos, generalmente se denomina relación de herencia, que existe entre la clase principal y la subclase, la interfaz principal y la subinterfaz

(3) Relación de implementación - correspondiente a la relación entre clases e interfaces

(4) Dependencia: ※ describe la situación en la que un cambio en una clase tiene un impacto en las clases que dependen de ella. Hay muchas formas de expresión, como vinculante (bind), amigo (amigo), etc.

ejemplo:

Diagrama de estado

Describe la secuencia de estados por los que pasan los objetos en respuesta a eventos durante su vida y sus respuestas a esos eventos.

diagrama de flujo

Los diagramas de secuencia se utilizan para representar la secuencia de acciones en un caso de uso. Cada mensaje en el diagrama de secuencia corresponde a una operación o evento de clase que provoca una transición en la máquina de estado al ejecutar un comportamiento de caso de uso.

 

 

Diagrama de colaboración

Un diagrama de colaboración es un diagrama de interacción que enfatiza la estructura organizativa entre los objetos que envían y reciben mensajes , y utiliza un diagrama de colaboración para ilustrar la dinámica del sistema.

diagrama de actividad

ejemplo:

Método de ingeniería de software orientado a objetos

• Análisis orientado a objetos (OOA)

• Diseño Orientado a Objetos (DOO)

• Programación Orientada a Objetos (POO)

• Pruebas Orientadas a Objetos (OOT)

Para desarrollar software con el método orientado a objetos, normalmente es necesario establecer tres tipos de modelos:

• Un modelo funcional que describe la funcionalidad del sistema.

• Un modelo de objetos que describe la estructura de datos del sistema.

• Un modelo dinámico para describir la estructura de control de un sistema

diseño de software

El diseño de software incluye dos partes, una es el diseño estructural y la otra es el diseño detallado.

• El diseño de la estructura del sistema (diseño arquitectónico) también se denomina diseño general o diseño del esquema. (incluyendo diseño de datos/clases, diseño de arquitectura de software, diseño de interfaz)

• El diseño procedimental del sistema también se denomina diseño detallado (incluido el diseño a nivel de componentes)

Esquema de diseño (diseño general, diseño estructural):

Incluyendo el documento de diseño general del sistema y el documento de diseño general de cada módulo. Sobre la base de la especificación de requisitos, describa la arquitectura del sistema, la división de los módulos funcionales, la definición de las interfaces de los módulos, el diseño de la interfaz de usuario, el diseño de la base de datos, etc.

Diseño detallado (diseño de proceso):

De acuerdo con la división del módulo basada en el diseño del esquema, realice el diseño del algoritmo de cada módulo, realice el refinamiento del diseño de la interfaz de usuario, el formulario, los datos requeridos y el diseño de la estructura de datos, etc.

diseño orientado a objetos

Las características principales son: fácil mantenimiento

persistencia de datos

Dos caminos:

• Sistema de gestión de base de datos (DBMS)

• modo de almacenamiento de archivos

estructura MVC

objeto modelo

Ver (ver) objeto

Objeto controlador (Control)

 

Diseño Detallado Orientado a Objetos

Describe principalmente cada clase en el componente en detalle, incluyendo:

• Diseño de estructura de datos de atributos

• diseño de métodos

• El diseño de los mecanismos necesarios para implementar la interfaz.

diagrama de flujo del programa

 

ejemplo:

 

Diagrama NS (entender)

 

mesa de juicio

 

árbol de decisión

 

nota

Dividido en:

• Comentarios del preámbulo (al comienzo del programa), que incluyen:

  1. título del programa;

  2. Una descripción de la función y propósito de este módulo;

  3. algoritmo principal;

  4. Descripción de la interfaz: incluye formulario de llamada, descripción de parámetros, lista de subrutinas;

  5. Descripción de datos relevantes: variables importantes y sus usos, limitaciones o restricciones, y otra información relevante;

  6. Ubicación del módulo: en qué archivo fuente o a qué paquete de software pertenece;

  7. Currículum de desarrollo: diseñador de módulos, revisor, fecha de revisión

• Comentarios funcionales (en el cuerpo del programa)

Explicar lo que hace un programa o declaración.

los datos muestran

 

Cuando se declaran múltiples nombres de variables en una declaración, las variables deben enumerarse en orden alfabético.

prueba de software

Las pruebas de software se ejecutan a lo largo de todo el ciclo de vida del desarrollo de software.

Las pruebas solo pueden encontrar errores en el programa, pero cuando no se encuentran errores, no se puede probar que no haya errores en el programa.

Encontrar errores no es el objetivo final de las pruebas de software. El objetivo fundamental de la fase de prueba es encontrar tantos errores ocultos en el software como sea posible y, finalmente, entregar un sistema de software de alta calidad a los usuarios.

El propósito de las pruebas de software es encontrar y corregir errores y defectos en el software, diseñar casos de prueba apropiados y usar la menor cantidad posible de casos de prueba para encontrar tantos errores de software como sea posible.

Clasificación:

• Prueba unitaria (prueba de corrección de los módulos del programa) (unidad)

• Pruebas de integración (método de integración incremental y método de integración no incremental) (parcial)

• Prueba del sistema (general)

• Pruebas de aceptación (debe tener participación activa del usuario o pruebas centradas en el usuario) (participación del usuario)

 

El proceso de análisis de un producto de software se denomina prueba estática y el proceso de prueba de ejecución del software se denomina prueba dinámica .

La verificación asegura que el producto es correcto y la validación asegura que se ha producido el producto correcto.

 

prueba estática

Confirme la corrección del programa mediante análisis manual o prueba de corrección del programa.

Inspección de escritorio, triaje de códigos, inspección a pie

Pruebas Dinámicas

Verifique el comportamiento dinámico del software y la exactitud de los resultados de la ejecución ingresando datos, ejecutando el software y observando el estado y los resultados de la ejecución.

Prueba de caja blanca (proceso de trabajo interno conocido del producto):

 

Pruebas de caja negra (funcionalidad conocida del producto)

Taxonomía de equivalencia: Independientemente de la estructura interna del programa

Método de análisis del valor límite (seleccione exactamente igual a, apenas mayor o menor que el valor límite como datos de prueba)

Malas adivinanzas: empíricas

Método gráfico de causa y efecto (que describe la combinación de múltiples condiciones de entrada, generando correspondientemente múltiples acciones para diseñar casos de prueba y finalmente generando una tabla de decisiones)

Pruebas de integración

Prueba no incremental:

Adopte un método de un solo paso para integrar el sistema. Sobre la base de las pruebas unitarias de cada módulo, ensamble todos los módulos de acuerdo con los requisitos de diseño.

Prueba incremental:

Combinación de arriba hacia abajo: no es necesario escribir módulos de controlador, solo es necesario escribir módulos auxiliares

Combinación de abajo hacia arriba: solo es necesario escribir el módulo del controlador

Pruebas alfa y pruebas beta

• Prueba alfa : el desarrollador simula a los usuarios para probar el producto de software que se lanzará próximamente. Los desarrolladores necesitan registrar los errores encontrados y los problemas encontrados en el uso.La prueba se lleva a cabo en un entorno controlado.

• Prueba Beta : Realizada por usuarios finales del software en uno o más sitios de clientes. La prueba beta es la aplicación "real" de software en un entorno fuera del control del desarrollador. Los usuarios registran todos los problemas (reales o imaginarios) encontrados durante las pruebas beta e informan estos problemas a los desarrolladores de forma regular. Después de recibir los problemas informados durante la prueba beta, el desarrollador realiza los cambios necesarios en el producto de software y se prepara para lanzar el producto de software final a todos los clientes.

Pruebas de regresión

• La prueba de regresión es una actividad de prueba utilizada para garantizar que los cambios debidos a la depuración u otras razones no generen un comportamiento inesperado del software o errores adicionales.

• Las pruebas de regresión se refieren a volver a ejecutar un subconjunto de pruebas que ya se han realizado para garantizar que los cambios no tengan efectos secundarios no deseados.

pruebas orientadas a objetos

Estrategia:

• Prueba intraclase: equivalente a la prueba unitaria, incluye prueba de método y prueba de comportamiento de clase en la clase.

• Prueba entre clases: equivalente a la prueba de integración, debe ensamblarse de acuerdo con la relación entre clases, incluidas las clases independientes y las clases dependientes.

• Pruebas basadas en escenarios: equivalentes a las pruebas de confirmación y las pruebas del sistema.

Los métodos de prueba de caja blanca y caja negra también son aplicables a las pruebas orientadas a objetos.

Depuración de software

La depuración es el proceso de resolución de errores después de que las pruebas los encuentren.

método:

• Método brutal --- seguimiento punto por punto (paso único)

• Retroceder --- retroceder desde el punto de error a lo largo del flujo de control

• Eliminación de Causas --- Búsqueda Binaria, Inducción y Deducción

Mantenimiento del software

La documentación es el factor determinante que afecta la mantenibilidad del software

Proceso de mantenimiento:

 

tipo:

• Mantenimiento correctivo (para identificar y corregir errores de software, corregir defectos en el rendimiento del software y eliminar el mal uso en la implementación)

• Mantenimiento adaptativo (modificar el software para adaptarlo al cambio)

• Expansión y mantenimiento de la integridad (los usuarios proponen nuevas funciones y requisitos de rendimiento)

• Mantenimiento preventivo (para mejorar la capacidad de mantenimiento y la confiabilidad del software, sentar una buena base para una mayor mejora del software en el futuro) (también conocido como reingeniería de software)

mantenimiento no estructural

• Solo el código fuente está incluido en la configuración del software.

• Como no hay un documento de análisis y diseño, es imposible rastrear a la inversa la función del programa, y ​​es muy doloroso entender el código de otras personas.

• Dado que no hay documentación de prueba en la configuración, el código mantenido no puede someterse a pruebas de regresión. Como resultado, la estructura del programa se destruye constantemente y no se puede garantizar la calidad del mantenimiento.

mantenimiento estructural

• La configuración del software a mantener está completa.

• La solicitud de mantenimiento enviada por el usuario se puede rastrear fácilmente desde el documento de análisis y diseño hasta el código a través del seguimiento hacia adelante, de modo que el personal de mantenimiento pueda ubicar fácilmente el punto de mantenimiento del código. Entonces este mantenimiento no rompe la estructura del software.

• El mantenimiento estructurado no solo puede reducir la carga de trabajo del mantenimiento, sino también mejorar la calidad del mantenimiento.

Tipos de documentación para sistemas de software

• Documentación del usuario : describe principalmente las funciones del sistema y los métodos de uso, y no le importa cómo se implementan estas funciones.

• Documentación del sistema : describe todos los aspectos del diseño, la implementación y las pruebas del sistema.

reingeniería de software

El mantenimiento preventivo también se conoce como reingeniería de software . Se refiere a refactorizar o reescribir parte o la totalidad de un sistema existente sin cambiar su funcionalidad.

Objetivo:

• En un esfuerzo por hacer que el sistema sea más mantenible, el sistema necesita ser reestructurado y redocumentado.

• Reducir el riesgo: volver a desarrollar un sistema vivo es muy arriesgado, con potencial para problemas de desarrollo, problemas de personas y problemas de especificación.

• Bajo costo: el costo de la reingeniería es mucho menor que el costo de volver a desarrollar software

refactorizar

Sobre la base de no cambiar las funciones existentes del software, la calidad y el rendimiento del software mejoran ajustando el código del programa, de modo que el modo de diseño y la estructura del programa sean más razonables, y la escalabilidad y mantenibilidad del software. se mejoran

La refactorización debe prestar atención a dos puntos:

1. Mantener el valor central del sistema sin cambios

2. Presta atención a los riesgos