¿Cómo puedo convencer a mi equipo para que use clases / métodos más pequeños?

Descargo de responsabilidad: soy un recién llegado (este es mi tercer día de trabajo), y la mayoría de mis compañeros de equipo tienen más experiencia que yo.

Cuando miro nuestro código, veo algunos olores de código y malas prácticas de ingeniería, como las siguientes:

• Pautas de nomenclatura algo inconsistentes
• Propiedades no marcadas como de solo lectura cuando sea posible
• Clases grandes: noté una clase de utilidad que constaba de cientos de métodos de extensión (para muchos tipos). ¡Tenía más de 2500 líneas de largo!
• Métodos grandes: estoy tratando de refactorizar un método que tiene 150 líneas de largo.

Los dos últimos parecen ser un problema real. Quiero convencer a mis compañeros de equipo para que usen clases y métodos más pequeños. ¿Pero debería hacer eso? ¿Si es así, entonces cómo?

Mi equipo obtuvo un mentor del equipo principal (somos un equipo satélite). ¿Debo ir a él primero?

ACTUALIZACIÓN : Dado que algunas respuestas preguntaron sobre el proyecto, sepa que es un proyecto que funciona. Y en mi humilde opinión, las clases / métodos enormes de ese tamaño siempre son malos.

De todos modos, nunca quiero molestar a mi equipo. Por eso pregunté: ¿debería hacerlo, y si es así, cómo lo hago con suavidad?

ACTUALIZACIÓN : decidí hacer algo basado en la respuesta aceptada: porque soy un recién llegado, así que veo todo en "nuevos ojos". Tomaré nota de todos los olores de código que encontré (posición, por qué es malo, ¿cómo podemos hacerlo? mejor, ...), pero en este momento, solo trato de reunir los respetos de mi equipo: escribir "mejor código", conocer gente, saber por qué lo hicimos ... Cuando sea el momento adecuado, lo intentaré para preguntarle a mi equipo sobre nuevas políticas de código (pautas de nomenclatura, clases más pequeñas, métodos más pequeños, ...) y, si es posible, refactorizar algún código antiguo. Debería funcionar, en mi humilde opinión.

Gracias.

Tiene la ventaja de ver el código con nuevos ojos. Tome notas para documentar lo que descubra de las malas prácticas. Luego, cuando te instales con el equipo, saca tus notas en un momento oportuno, como cuando es el momento de refactorizar.

Code Complete, de Steve McConnell, tiene toneladas de buenas estadísticas sobre el mismo tema del que estás hablando. No recuerdo todos los números, pero habla sobre cómo aumentan los números de errores con los métodos / clases más largos, cuánto tiempo lleva depurar, etc.

Podrías comprar una copia del libro y mostrarle a tu compañero algunos de los estudios ... las estadísticas (aunque mienten todo el tiempo) tienden a convencer a la gente.

Descargo de responsabilidad: soy un recién llegado (este es mi tercer día de trabajo), y la mayoría de mi equipo tiene más experiencia que yo.

Es posible que desee reducir la velocidad un poco, escuchar y aprender de su equipo antes de comenzar a sugerir demasiados cambios. Puede haber o no buenas razones para que el código esté estructurado tal como está, pero de cualquier manera, tomarse el tiempo para escuchar y aprender primero solo puede ayudar.

Después de eso, cualquier sugerencia que pueda hacer seguramente se verá de manera más positiva y se encontrará con menos resistencia.

Sus posibilidades de introducir un cambio exitoso mejoran enormemente si se gana el respeto, o al menos no pierde el respeto, de sus compañeros de trabajo primero.

¿Como va? "Mide dos veces corta una vez ..." Algo así.

A menos que haya sido contratado con la intención específica de revisar la forma en que su equipo escribe el código, es posible que desee moderar su entusiasmo por las revisiones drásticas. La mayoría del código de trabajo funciona por una razón :) no importa cuán basura sea, y a veces las revisiones drásticas hacen que esos molestos casos de esquina sean aún más feos.

Creo que la palanca más fácil para escribir código más pequeño sería pedirles a los desarrolladores que se concentren en las pruebas unitarias . Nada fuerza un código conciso como pedirle que lo pruebe ; Es sorprendente cómo los desarrolladores de repente sienten una aversión a las estructuras de datos globales, pasando demasiados objetos y capas de profundidad, cuando saben que tienen que escribir pruebas para todo.

No soy un gran fan de TDD pero no encanta el hecho de que obliga a los desarrolladores a considerar la forma en que iba a escribir pruebas. Y esa es la razón por la cual el código es mejor, no es algo mágico acerca de tener las pruebas. (Aunque eso es útil cuando realiza cambios más adelante).

La mejor de las suertes.

No debes convencer a tu equipo. Como recién llegado, no te tomarán en serio, por lo tanto, perderás el tiempo.

En su lugar, continúe y escriba código compacto y limpio usted mismo. Luego, con suerte, después de un tiempo y algunas revisiones de código, algunos compañeros de equipo podrían comenzar a imitar su estilo.

De lo contrario, seguirá siendo más productivo y su arduo trabajo eventualmente lo llevará a una posición más alta donde puede comenzar a aplicar algunas de estas reglas.

Y sí, por supuesto, muestra cosas de Code Complete para todos.

Aquí hay un par de trucos:

• Conozca el estado actual y la historia del equipo: parece que tienen un mentor, ¿cuánta influencia tiene el mentor? Además, ¿qué tan nuevo es el mentor y estuvo allí mucho tiempo sin mentor? ¿Cuándo se origina el código del problema? Criticar al bebé del equipo actual puede ser muy diferente a criticar algún código antiguo que nadie recuerda haber escrito.

• Una cosa a la vez: no arrojes la bomba en todos tus pensamientos en una reunión de equipo. Comience con algunas preguntas tentativas que provienen de su perspectiva específica. Por ejemplo: "Oye, como el chico nuevo, noté que algunas de las clases de utilidad son realmente grandes, ¿hay alguna razón para eso?"

• Sugiera pequeños pasos: casi nunca es posible realizar una revisión total inmediata, por lo tanto, descubra algunos pasos iniciales para sugerir en caso de que todos estén de acuerdo en que este es un buen plan.

• Sugiera mecanismos de prevención futuros: por ejemplo, el equipo podría acordar una meta que nunca agregará a las pocas clases más grandes, pero que reestructurará cuando sea necesario aumentarlas aún más.

• Escuche las preocupaciones sobre el riesgo. Si este es realmente un código heredado, puede haber suficientes incógnitas y dependencias que la refactorización es extremadamente riesgosa. Puede que esa no sea una razón para evitar la refactorización, pero puede significar que necesita mejores estrategias de prueba o alguna otra forma de reducir el riesgo antes de abordar el trabajo real.

• Tenga en cuenta el lenguaje corporal y vaya despacio. Está planteando un problema en una base de código con el que no ha tenido mucha experiencia. Ahora tiene una nueva ventana de tipo, donde puede hacer algunas preguntas ingenuas y obtener respuestas útiles, y puede usar esas preguntas para sondear al equipo para considerar sus propias opciones de diseño. Pero va en ambos sentidos: como el chico nuevo, todavía no tienes un montón de "credibilidad", así que ve despacio y ten en cuenta las caras cerradas o las posturas. Si las personas comienzan a cerrar, sugiera una forma de retrasar cualquier decisión y busque formas de ganárselas.

Como gerente y miembro del equipo, puedo decir que me alegré por New Guy Insights. No acepté todos los comentarios constructivos que me dio un nuevo miembro del equipo, pero en general estaba dispuesto a escuchar si la crítica se expresaba como una preocupación y curiosidad sinceras y no se presentaba como una conferencia. La marca de respeto hacia el nuevo tipo se da cuando puede entregar la información y luego dar un paso atrás y manejar lo que venga: es fácil sentirse bien cuando se escuchan y toman sus decisiones, es más difícil cuando el equipo le dice "no". Es posible que aún tenga razón, el truco es descubrir qué hacer a continuación ... por lo general, esperar un poco y buscar más información es un buen paso en esos casos.

¿Cómo puedo convencer a mi equipo para que use clases / métodos más pequeños?

No lo hagas

Cómprate una licencia Resharper y lidera con el ejemplo. [Apóyate fuertemente en la refactorización del ' Método de extracción '.]

Con el tiempo, otros deberían apreciar su código más legible y ser persuadidos de hacer lo mismo.

• Sí, existe la posibilidad de que no sean persuadidos; pero sigue siendo tu mejor apuesta.

OMI: no vale la pena sus sílabas para tratar de persuadir a sus compañeros de equipo para que se conviertan en mejores programadores, lea ' Código completo ', siga a @Uncle Bob. Los principios SÓLIDOS y convertirse en mejores programadores si aún no están convencidos.

Recuerde: no puede usar la lógica para discutir a alguien fuera de una posición en la que no usó la lógica para entrar en primer lugar.

Esto parece ser más una cuestión de gestión que una cuestión técnica. Todo lo que dijo es válido, lo que su equipo realmente necesita es un buen arquitecto que pueda asegurarse de que todos se adapten a un patrón de diseño único y aplicarlo, el equipo debe refactorizar el código de manera constante y regular.

Sin embargo, hay otro director de "no lo necesitarás", si lo que ha existido funciona por un tiempo bastante largo, no importa cuán feo sea, cambiarlo no siempre es una buena idea. En cambio, si su equipo necesita reconstruir todo o reconstruir parte de él, acumule un documento de malas prácticas y problemas antes de llevar a cabo la codificación.

Algunos equipos no hacen ningún tipo de control de calidad para el código porque no conocen las herramientas adecuadas para ello. Hay muchas herramientas que pueden ayudar a un equipo a codificar mejor.

Visual Studio tiene "Análisis de código" que puede ayudar con las convenciones de nomenclatura.

También se podrían usar métricas de código, como la complejidad ciclomática. Esto ayuda a señalar clases y métodos que son demasiado complejos.

Mantener registros también es una buena idea. Si los miembros del equipo simplemente expresan verbalmente lo que hay que hacer, entonces la gente está obligada a olvidar. ¡Los humanos tienen recuerdos muy frágiles! =)

No haría mucho ruido sobre esto ... El equipo de desarrollo de un programador es como su propia familia ... Si usted señala errores, la gente puede enojarse con usted. Este tipo de cambio cultural no solo requiere mucha codificación, sino que también requiere un toque delicado con los seres humanos.

Como gerente, solo quiero agregar que quiero que mi equipo escriba un buen código la primera vez. Revisiones de código, TDD y todo eso. Pero una vez que esté en producción y funcione, tendrías que presentar un argumento sólido para que volvamos a hacerlo.

Sigo los consejos del tío Bob de dejar siempre el código mejor de lo que lo encontraste. Entonces, si tenemos errores que corregir o pequeñas mejoras, espero que estemos haciendo parte de la limpieza.

Pero tal como está, el negocio realmente mira su dinero. Tendría que argumentarles que la refactorización los beneficia lo suficiente como para que le den tiempo y recursos a mi equipo. Simplemente no me gusta el aspecto del código no es suficiente.

Entonces, si funciona, por mucho que lo odies, tendrás que dejarlo solo.

Ahora nuevo código, eso es diferente. Eso debería ser un buen código.

Métodos que son 150 líneas ... He visto métodos con 10.000 líneas de código.

Dos de sus problemas se pueden resolver con herramientas externas :

• Pautas de nomenclatura algo inconsistentes
• Las propiedades no se marcan como de solo lectura cuando es posible

En C # Resharper puede verificar ambos problemas. Los nombres que no siguen sus pautas están marcados como errores. Las propiedades no marcadas como de solo lectura también se muestran como errores. FxCop también podría ser de ayuda.

Estas herramientas también pueden ayudar a dividir métodos enormes en múltiples más pequeños gracias a su refactorización.

No sé si las clases grandes siempre son tan malas si están bien estructuradas con métodos bien nombrados. Utilizo Eclipse como mi IDE, por lo que tiene algo llamado vista de "esquema", que es algo que todos los IDE tienen solo con un nombre diferente, muy probablemente, que proporciona el nombre y el enlace a cada método dentro de la clase, puede ordenarlo alfabéticamente , etc. Cuando se usa esto, es fácil navegar en una clase grande, es más que tener métodos realmente largos sería malo, creo que porque es más difícil navegar inteligentemente dentro de ese método a menos que esté realmente familiarizado con él. No estoy abogando por las clases largas, pero creo que son manejables en algunos casos y no necesariamente deben dividirse en varias clases.

Trate el tema con algunos de los miembros de su equipo y obtenga su opinión sobre el tamaño de los métodos. Puede que se sorprenda al descubrir que están de acuerdo con usted. Lo que está viendo podría ser el resultado de malas prácticas anteriores, los antiguos desarrolladores ya no estaban en la compañía, o esa parte era un trabajo urgente y ahora han contratado a alguien con tiempo para refactorizarlo;)

Sigues siendo el chico nuevo. Construya cierta reputación asumiendo tareas desafiantes y completándolas rápidamente y sin errores. Si intenta comenzar a cambiar las cosas antes de ganarse el respeto de sus compañeros, es posible que tenga más dificultades para comprar (y posiblemente alienar a sus compañeros de trabajo).

Si puede encontrar formas de introducir los mejores hábitos de codificación en su propio trabajo que demuestren de manera efectiva cómo reducen el tiempo de desarrollo y dan como resultado soluciones más robustas, incluso podría pedirles que vean cómo lo logró.

Además de todas las otras excelentes respuestas, tal vez pueda matar dos pájaros de un tiro y hacer una limpieza de código como un proyecto destinado a obtener una cierta comprensión de la base de código. Puede venderlo a su equipo / gerente como una oportunidad de aprendizaje para usted, y recibirá comentarios de sus pares cuando revisen sus cambios que lo guiarán en su mejor enfoque para abordar el problema del diseño deficiente.