métodos Refactoring en la base de código existente con gran número de parámetros

Question

He heredado una base de código existente donde las "características" son las siguientes:

• enormes clases monolíticas con (literalmente) 100 de variables miembro y métodos que van uno para las páginas (pantallas)
• métodos públicos y privados con una gran cantidad de argumentos.

Estoy tratando de limpiar y refactorizar el código, para dejarlo un poco mejor que cómo lo encontré. Entonces mis preguntas

• vale la pena (¿o no) refactorizar métodos con 10 o más argumentos para que sean más legibles?
• ¿Existen mejores prácticas sobre cuánto tiempo deberían ser los métodos? ¿Cuánto tiempo usualmente los guardas?
• son clases monolíticas malas?

Answer 1

vale la pena (o usted) métodos Refactor con 10 o más argumentos para que sean más legibles?

Sí, vale la pena. Por lo general, es más importante refactorizar métodos que no son "razonables" que los que ya son buenos, cortos y tienen una pequeña lista de argumentos.

Normalmente, si tiene muchos argumentos, es porque un método hace demasiado; lo más probable es que sea una clase propia, no un método.

Dicho esto, en los casos en que se requieren muchos parámetros, es mejor encapsular los parámetros en una sola clase (es decir, SpecificAlgorithmOptions), y pasar una instancia de esa clase. De esta manera, puede proporcionar valores predeterminados limpios, y es muy obvio qué métodos son esenciales frente a los opcionales (según lo que se requiere para construir la clase de opciones).

¿existen mejores prácticas sobre cuánto tiempo deberían ser los métodos? ¿Cuánto tiempo usualmente los guardas?

Un método debe ser lo más corto posible. Debe tener un propósito, y ser utilizado para una tarea, siempre que sea posible. Si es posible dividirlo en métodos separados, donde cada uno sea una "tarea" real y cualitativa, hágalo cuando refactorice.

son clases monolíticas malas?

Sí.

Answer 2

si el código está funcionando y no hay necesidad de tocarlo, no me gustaría refactorizar. solo refactoro casos muy problemáticos si de todos modos tengo que tocarlos (ya sea para ampliarlos para funcionalidad o corregir errores). Yo prefiero la forma pragmática: solo (en el 95%) toca, lo que cambias.

algunas ideas sobre su problema específico (aunque en el detalle que es difícil sin conocer el código):

• principio a las variables de instancia de grupo, estos grupos serán entonces objetivo de hacer 'clase extracto de'
• al agrupar estas variables, es de esperar que pueda agrupar algunos métodos, que también se moverán al hacer 'extraer clase'
• a menudo hay muchos métodos que no usan ningún campo. hacerlos estáticos (lo más probable es que sean métodos auxiliares, que se pueden extraer a clases auxiliares.
• en caso de que los campos de instancia no relacionados se mezclen en muchos métodos, hagan cargas de 'método de extracción'
• use herramientas de refactorización automáticas tanto como sea posible, porque lo más probable es que no hay pruebas en su lugar y la automatización es más seguro.

en cuanto a sus otras preguntas concretas.

vale la pena (o usted) métodos Refactor con 10 o así que los argumentos para que sean más legibles?

definetely. 10 parámetros son demasiados para entendernos a nosotros los humanos. lo más probable es que el método esté haciendo demasiado.

¿existen mejores prácticas sobre cuánto tiempo deberían ser los métodos? ¿Cuánto tiempo usualmente los guardas?

depende de las preferencias. Dije algunas cosas en este thread (aunque la pregunta era PHP). aun así, aplicaría estos números/métricas a cualquier idioma.

son clases monolíticas malas?

depende, lo que quiere decir con monolítico. si se refiere a muchas variables de instancia, métodos interminables, mucha complejidad if/else, sí.

también echar un vistazo a una verdadera joya (para mí una necesidad para todos los desarrolladores): working effectively with legacy code

Answer 3

Suponiendo que el código está funcionando Yo sugeriría que usted piensa acerca de estas preguntas primero:

• es el código bien documentado?
• ¿entiendes el código?
• ¿con qué frecuencia se están agregando nuevas características?
• ¿con qué frecuencia se informan y corrigen los errores?
• ¿Cuán difícil es modificar y corregir el código?
• ¿Cuál es la vida esperada del código?
• ¿Cuántas versiones del compilador está detrás (si es que lo tiene)?
• ¿Se espera que el sistema operativo en el que se ejecuta cambie durante su ciclo de vida?

Si el sistema será reemplazado en cinco años, está bien documentado, sufrirá pocos cambios, y los errores son fáciles de solucionar, dejándolo solo independientemente del tamaño de las clases y el número de parámetros. Si está decidido a refactorizar, haga una lista de sus propuestas de refactorización en el orden de máximo beneficio con cambios mínimos y ataque de forma incremental.