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

solo learn para pc (8)

Tengo una sensación de dejavu al leer la publicación de [¿Qué hacer con un archivo de código fuente de C ++ de 11000 líneas?] , Pero no creo que pueda comenzar a tomar medidas por mi cuenta ya que no tengo la autoridad para hacerlo. Así que creo que el primer paso es convencer a las personas de la organización de que el gran número de códigos es malo.

Tengo una situación similar donde hay una sola clase con 11975 líneas de código y cada vez que hay nuevas características, hay una alta probabilidad de que esta clase se haga más y más grande.

¿Básicamente esas personas no están teniendo conocimiento en oops? Hacer OOAD antes de comenzar el proyecto es la mejor idea para evitar esto. Desde mi experiencia, puedo decir que no todos los programadores tienen conocimientos sobre Oops, por lo que obviamente no pueden escribir un código mejor.

Aquí es donde la diferencia viene con un programador y analista

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

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

Entonces, en lugar de enfocarse en el LOC como parámetro, enfóquese en la funcionalidad / diseño de la clase. ¿La clase está violando el principio de responsabilidad única? LOC solo no puede ser el único factor decisivo para concluir si una clase es realmente enorme. Mira otras métricas, por ejemplo, la complejidad ciclomática.

Sin embargo, si concluye que esto es realmente malo en el contexto de su proyecto, debe tener una razón sólida para convencer a las partes interesadas relevantes. Por ejemplo,

a. ¿Esta clase tiene muchos errores?

segundo. ¿Las correcciones de errores de esta clase siempre introducen defectos de regresión? (Acoplamiento alto, baja cohesión?)

do. ¿Cuánto tiempo tardan en arreglarse los defectos en esta clase? ¿Cómo se compara esto con otros módulos?

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

mi. Lea tanto sobre métricas / consulte a su equipo de Calidad / Métricas / QA y genere suficientes puntos de datos. Un ejemplo de métricas OOAD está here pero estoy seguro de que hay muchas.

EDIT 2 (algunos cambios menores)

F. Obtenga el apoyo inicial de algunas partes interesadas clave en su esfera de control. A continuación, consigue, alguien que pueda presentar bien estos hechos !. He visto muchas cosas fallar en esta etapa !.

¡Buena suerte!

Aquí está mi reacción inicial:

¿No hay lugares para refactorizar para reducir el SLOC? ¿Has intentado refactorizar primero, antes que nada?
¿Está manejando más de una responsabilidad o, como dice otro cartel, es una fachada?
¿Hay muchas macros de preprocesamiento integradas en el código que lo hacen "más pequeño" de lo que realmente parece ser?
¿Se está construyendo alguna instrucción de consulta de tipo SQL? He visto que estos ocupan una gran cantidad de espacio y se agregan rápidamente a SLOC sin ser necesariamente indicadores de una calidad de código deficiente.
¿Cómo se ha montado este código y bajo qué presiones de tiempo? ¿Cuál es la historia del código? Solo he visto un código como este (y produje algunos) cuando los horarios han estado casi al límite de la locura. Tal vez fue un "... creado en 6 días, el séptimo para descansar", una especie de carrera monstruosa pero nunca reparada.
¿Los otros desarrolladores son en realidad desarrolladores?

No hay sugerencias aquí, excepto refactor lo que pueda. Encuentra cualquier funcionalidad que infrinja DRY y luego frótala.

Convencer a cualquiera de que cambie 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 lo suficientemente grandes) como agregar algo a uno de los métodos más grandes. Debería enseñarles una lección: encontrar el lugar correcto será realmente doloroso. Entonces, podrías preguntar: "Imagina que apoyas a esta clase, ¿va a ser una tarea fácil?".

Puede intentar un enfoque diferente, pero probablemente fallará: pídales que escriban una prueba de unidad para este código. O simplemente pídales que piensen en cualquier ...

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

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

El mero hecho de que una clase sea grande no la hace automáticamente mala.

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

También vale la pena centrarse 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 al mismo tiempo, no toda la clase. Así que cuanto más conciso sea el método, más fácil será para los desarrolladores mantenerlo.

Debe reunir métricas sobre la cantidad de problemas de soporte que se pueden rastrear hasta el código en esta clase. Además, ¿cuánto tiempo pasan los desarrolladores haciendo 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 explicar a la administración por qué una clase tan grande es mala.

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

Una vez que haya reformulado un método enorme a un número de métodos comprensibles más simples y tenga pruebas de unidad exitosas, simplemente demuestre esto 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 mantenibilidad del código refactorizado, está enfrentando un problema político / de personalidad. En ese caso, depende de usted si desea continuar trabajando en ese entorno.

Tener una clase enorme no es malo. Si el programador puede manejarlo y entenderlo, entonces es una clase perfecta. Si el programador está completamente perdido cuando intenta cambiar o agregar algo a la clase, es malo.

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

Pero sí, generalmente es malo.

Tienes mis simpatias Cualquier clase que sea tan grande está rompiendo inevitablemente el Principio de Responsabilidad Única , haciendo que sea difícil de mantener.

Mi mejor consejo es predicar con el ejemplo:

Mantenga su nuevo código pequeño.
Refactor sin piedad 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.