¿Cómo evita que usted y sus compañeros de trabajo creen grandes clases?

Question

Usuarios de Stackoverflow, ¿Cómo evitar la creación de clases grandes con métodos grandes de cuerpo? Cuando los plazos son ajustados, terminas tratando de hackear cosas y termina siendo un desastre que necesitaría ser refactorizado.

Para mí, la única forma era comenzar con el desarrollo impulsado por pruebas y que se presta para un buen diseño de clase, así como el SRP (principio de responsabilidad única).

También veo que los desarrolladores solo hacen doble clic en los controles y teclean línea tras línea en el método de evento que se activa.

¿Cuáles son sus sugerencias?

Answer 1

Supongo que depende tanto de sus procesos internos como de cualquier otra cosa.

En mi empresa, practicamos la revisión por pares, y todos los códigos que se contratan deben ser 'compilados' por otro desarrollador, a quien debe explicar su código.

Las limitaciones de tiempo son una cosa, pero si reviso un código que tiene clases atrozmente largas, entonces no aceptaré el check-in.

Es difícil acostumbrarse al principio, pero al final del día, es mejor para todos.

Además, tener un desarrollador sénior que sea un campeón para un buen diseño de clase, y esté dispuesto y sea capaz de dar ejemplos, ayuda tremendamente.

Por último, a menudo hacemos una sesión de 'mostrar y contar' de codificación donde mostramos nuestro trabajo a nuestros compañeros, ¡nos corresponde no hacer esto con un código feo!

Answer 2

Utilice una herramienta como Resharper y el comando Extraer método.

Answer 3

Long classes es un mal olor de código de muchos posibles.

Recuperar clases demasiado grandes creando muchas pequeñas puede crear sus propios problemas. A los nuevos ingenieros en su proyecto puede resultarles difícil seguir el flujo del código para determinar qué ocurre. Un artefacto de este problema pueden ser las pilas de llamadas muy altas, anidación de ejecución a través de muchas clases pequeñas.

Answer 4

Somos una tienda de Java y Maven, y una de las ... Supongo que se podría decir que los métodos forenses que usamos son los excelentes FindBugs, PMD y los complementos javancss. Todos darán advertencias sobre la longitud excesiva en un método, y los cálculos de complejidad ciclomática pueden ser muy reveladores.

Answer 5

El paso más importante para evitar las clases grandes que a menudo violan el SRP fue utilizar un marco de inyección de dependencia simple. Esto me liberó de pensar demasiado acerca de cómo unir cosas. Solo uso la inyección de constructor para mantener el diseño libre de ciclos. Herramientas como Resharper ayudan a inicializar campos desde argumentos de constructor. Esta combinación lleva a una sobrecarga de casi cero para crear y conectar nuevas clases, y me alienta implícitamente a estructurar el comportamiento con mucho más detalle.

Esto funciona mejor si los datos se mantienen separados del comportamiento, y su lenguaje admite construcciones como eventos que se pueden usar para desacoplar la comunicación que fluye hacia abajo en el gráfico de dependencia.

Answer 6

utiliza algunas herramientas de análisis de código estático en tus construcciones automáticas y escribe/configura/usa algunas reglas para que, por ejemplo, alguien tenga que escribir una justificación cuando la rompa.

Answer 7

Otra sugerencia es hacer solo lo que se solicita. No juegue al juego "Qué pasa si" e intente sobre diseñar una solución. Esto tiene la idea de "Mantenerlo simple, estúpido" detrás de esto.