¿Cómo convencer a la gente de que una sola clase con 11975 líneas de código es mala? (¿No es así?)

Question

Tengo una sensación de dejavu cuando leo [What to do about a 11000 lines C++ source file?] publicación, pero no creo que pueda comenzar a tomar medidas por mi cuenta ya que no tengo la autoridad para tomar medidas. Así que creo que el primer paso es convencer a las personas de la organización de que un gran trozo de código es malo.

Tengo una situación similar en la que hay una sola clase con 11975 líneas de código y cada vez que hay nuevas funciones, hay una gran probabilidad de que esta clase crezca y crezca.

Answer 1

Tiene mis condolencias. Cualquier clase que sea tan grande está rompiendo inevitablemente el Single Responsibility Principle, lo que dificulta su mantenimiento.

Mi mejor consejo es dar el ejemplo:

• Mantenga su nuevo pequeño código.
• Refactor sin misericordia al cambiar el código para reducir el tamaño de las clases y funciones.

Su código brillará como un faro en comparación con el código heredado y su equipo entenderá qué código es más fácil de mantener.

Answer 2

Tener una gran clase no es malo. Si el programador puede administrarlo y entenderlo, entonces es una clase perfecta. Si el programador se pierde por completo cuando intenta cambiar o agregar algo a la clase, entonces es malo.

Con la programación, se trata de preferencia. Si prefieren tener una sola clase de 11975 líneas de código, y pueden administrarlo, entonces es su elección.

Pero sí, en general es malo.

Answer 3

Si esta clase consiste en muchos métodos más pequeños Y estos métodos pertenecen realmente a la clase, es decir, son cohesivos entre sí y la clase, entonces esto no es necesariamente malo.

El mero hecho de que una clase es grande no la convierte en una mala automática.

Lo que es más importante es evitar una llamada "clase divina" que contiene muchos métodos que no tienen relación conceptual entre sí o con la clase misma.

También vale la pena concentrarse en mantener el tamaño de los métodos individuales, porque la mayoría de los desarrolladores necesitarán "cargar" un método completo en sus cerebros a la vez, no toda la clase. Por lo tanto, cuanto más conciso sea el método, más fácil será para los desarrolladores mantenerlo.

Debe recopilar métricas sobre la cantidad de problemas de soporte que se pueden remontar al código en esta clase. Además, ¿cuánto tiempo tardan los desarrolladores en realizar cambios en esta clase en comparación con otras clases más pequeñas? Una vez que tenga estas métricas, estará en una mejor posición para explicarle a la administración por qué una clase tan grande es mala.

En el caso de una clase grande con un número pequeño de métodos grandes, usaría las técnicas de refactorización descritas en Martin Fowlers book, junto con las pruebas unitarias para asegurar que no se introduzcan nuevos errores.

Una vez que haya rediseñado un método enorme hasta una cantidad de métodos comprensibles más simples y haya realizado pruebas unitarias exitosas, simplemente demuéstrelo a sus colegas.

En este punto, si sus colegas no están de acuerdo o no pueden ver una mejora general en la comprensibilidad y mantenimiento del código refactorizado, se trata de un problema político/de personalidad. En ese caso, depende de usted si desea continuar trabajando en dicho entorno.

Answer 4

11975 (o ya son 12000 :)) líneas de implementación de clase. ¿Es mala? Cerainly se ve así. Pero ...

Depende. Normalmente, las clases que implementan el patrón Mediator o el patrón Fachada tienden a ser muy grandes. Tienen un protocolo de enrutamiento/comunicación muy complejo. Las clases de "Dios" también tienden a ser muy grandes y monolíticas. En resumen, una clase A puede ser realmente grande, pero puede no ser un problema.

De modo que en lugar de enfocarse en el LOC como parámetro, concéntrese en la funcionalidad/diseño de la clase. ¿Viola la clase el Principio de Responsabilidad Individual? LOC solo no puede ser el único factor decisivo para concluir si una clase es realmente enorme. Mire otras métricas, p. Complejidad ciclomática.

Sin embargo, si llega a la conclusión de que esto es realmente malo en el contexto de su proyecto, debe tener una buena razón para convencer a las partes interesadas. Por ejemplo,

a. ¿Esta clase tiene muchos errores?

b. ¿Estas correcciones de errores de clase siempre introducen defectos de regresión? (Alto acoplamiento, baja cohesión?)

c. ¿Cuánto tardan los defectos en ser reparados en esta clase? ¿Cómo se compara esto con otros módulos?

d. Genere unos pocos diagramas UML para este módulo para ilustrar los problemas importantes (por ejemplo, el acoplamiento).

e. Lea tanto sobre métricas/consulte a su equipo de Quality/Metrics/QA y genere suficientes puntos de datos. Un ejemplo de métricas OOAD es here pero estoy seguro de que hay muchas.

EDIT 2 (algunos cambios menores)

f. Obtén el apoyo inicial de algunas partes interesadas clave en tu esfera de control. ¡Luego, consigue, alguien que pueda presentar bien estos hechos !. ¡He visto muchas cosas fallar en esta etapa !.

¡Buena suerte!

Answer 5

Dígales que resuman lo que la clase hace \ representa en un minuto.

Answer 6

Aquí está mi reacción inicial:

1. ¿No hay lugares para refactorizar para reducir el SLOC? ¿Has intentado refactorizar primero, antes que nada?
2. ¿Se está manejando más de una responsabilidad o como otro cartel declaró es una Fachada?
3. ¿Hay muchas macros de procesamiento previo integradas en el código que lo hacen "más pequeño" de lo que realmente parece?
4. ¿Se está construyendo alguna declaración de consulta de tipo SQL? He visto que ocupan una gran cantidad de espacio y se agregan rápidamente al SLOC sin ser necesariamente indicadores de mala calidad del código.
5. ¿Cómo se ha ensamblado este código y bajo qué tiempo las presiones? ¿Cuál es la historia del código?Solo he visto código como este (y he producido algunos) cuando los horarios han estado cerca de la locura límite. Tal vez fue una especie de monstruoso "... creado en 6 días, el séptimo para descansar" pero nunca lo arreglaron.
6. ¿Los otros desarrolladores son en realidad desarrolladores?

No hay sugerencias aquí excepto refactor lo que pueda. Encuentra cualquier funcionalidad que viole D-R-Y y luego restriégala.

Answer 7

Convencer a alguien para cambiar la implementación existente (especialmente si "funciona") no es fácil.

Comenzaría pidiéndole a los oponentes que hagan la tarea trivial (según mi experiencia con clases tan extremas, creo que hay pocos métodos suficientemente grandes) como agregar algo a uno de los métodos más importantes. Debería enseñarles una lección: encontrar el lugar correcto será realmente doloroso. Entonces, podrías preguntar: "imagina que apoyas esta clase, ¿será una tarea fácil?".

Puede intentar una aproximación diferente, pero probablemente falle: pídales que escriban una prueba de unidad para este código. O simplemente pídales que piensen en cualquier ...

Answer 8

Básicamente esas personas no están teniendo conocimiento sobre ¿uy? Hacer OOAD antes de comenzar el proyecto es la mejor Idea para evitar esto, por mi experiencia puedo decir que cada programador no tiene conocimiento sobre oops, así que obviamente no pueden escribir un código mejor.

Esto es donde la diferencia viene con un programador y analista-