¿Qué dices en una revisión de código cuando la otra persona creó una solución demasiado complicada? [cerrado]

El otro día revisé el código que alguien de mi equipo escribió. La solución no era completamente funcional y el diseño era demasiado complicado, es decir, almacenaba información innecesaria, creaba características innecesarias y, básicamente, el código tenía mucha complejidad innecesaria, como el chapado en oro, y trataba de resolver problemas que no existían.

En esta situación, pregunto "¿por qué se hizo de esta manera?"

La respuesta es que la otra persona tenía ganas de hacerlo de esa manera.

Luego pregunto si alguna de estas características era parte de la especificación del proyecto, o si tienen alguna utilidad para el usuario final, o si alguno de los datos adicionales se presentaría al usuario final.

La respuesta es no.

Entonces le sugiero que elimine toda la complejidad innecesaria. La respuesta que generalmente obtengo es "bueno, ya está hecho".

Mi opinión es que no está hecho, tiene errores, no hace lo que los usuarios quieren y el costo de mantenimiento será más alto que si se hiciera de la manera más simple que sugerí.

Un escenario equivalente es: el
colega pasa 8 horas refactorizando el código a mano, lo que podría haberse hecho automáticamente en Resharper en 10 segundos. Naturalmente, no confío en la refactorización a mano, ya que es de dudosa calidad y no está completamente probada.
Nuevamente, la respuesta que obtengo es "bueno, ya está hecho".

¿Cuál es una respuesta apropiada a esta actitud?

Mentalidad / actitud

• Predicar con el ejemplo
• Amonestar en privado (uno a uno, fuera de la revisión del código)
• Fomentar una mentalidad de Keep-it-simple entre los miembros del equipo.

Gestión de equipos

• Dedique más tiempo a la especificación de un elemento de trabajo (como arquitectura, esquema de algoritmo, estructura de interfaz de usuario, etc.)
• Aliente a los miembros del equipo a buscar aclaraciones sobre el alcance de un elemento de trabajo.
• Aliente a los miembros del equipo a discutir formas de implementar un elemento de trabajo
• Haga estimaciones razonables para cada elemento de trabajo antes de comenzar, y haga el mejor esfuerzo para cumplirlas
• Monitorear la "mejora" de los miembros del equipo.
  • Después de ser amonestado o de que se le muestre la forma correcta de hacer las cosas, vea si el miembro del equipo mejora.

Nivel de habilidad

• Asigne algo de tiempo para sesiones de programación en pareja o sesiones de capacitación individuales para aprovechar al máximo las herramientas del desarrollador (refactorización, revisión de código)

Gestión de proyecto (riesgo)

• Realice una revisión de código con mayor frecuencia, de forma asincrónica (Nota)
  • Nota sobre "asincrónicamente"
    • El revisor del código debe recibir notificaciones / invitaciones para revisar los cambios tan pronto como se confirme
    • El revisor del código debe tener la oportunidad de revisar el código antes de cualquier reunión con el desarrollador.
    • Si se necesita una aclaración del desarrollador, hágalo informalmente en IM / correo electrónico sin emitir una opinión negativa

¿Qué dices en una revisión de código cuando la otra persona creó una solución demasiado complicada?

Dices: "construiste una solución demasiado complicada".

Entonces le sugiero que elimine toda la complejidad innecesaria. La respuesta que generalmente obtengo es "bueno, ya está hecho".

Si es demasiado tarde para cambiar algo, ¿por qué estás revisando el código?

"Ya está hecho" no es una respuesta satisfactoria. Hecho significa probado y funcionando. Cada código adicional que no esté haciendo nada útil debe mantenerse de la manera adecuada (eliminado).

Asigne nuevamente esta tarea pidiéndole que refactorice y optimice su solución. Si no hace eso, asígnele un programador de pareja y espere que aprenda algo del colega.

Entonces le sugiero que elimine toda la complejidad innecesaria. La respuesta que generalmente obtengo es "bueno, ya está hecho".

Esa no es una respuesta aceptable:

• Si realmente es demasiado tarde para cambiar, entonces la revisión del código fue en gran medida una pérdida de tiempo, y la gerencia necesita saber esto.

• Si esa es realmente una forma de decir "No quiero cambiar", entonces debe tomar la posición de que la complejidad adicional es MALA para la base de código POR LOS problemas / costos en los que incurrirá más adelante. Y reduciendo el potencial de problemas futuros, la razón real por la que está haciendo la revisión del código en primer lugar.

Y ...

... la solución no era completamente funcional ...

Ese es posiblemente un resultado directo de la complejidad innecesaria. El programador lo ha hecho tan complejo que ya no lo comprende completamente y / o ha perdido el tiempo implementando su complejidad en lugar de los puntos de función. Merecería la pena señalarle al programador que eliminar la complejidad puede llevarlo a un programa de trabajo más rápido.

Ahora, parece que no tienes el poder (o tal vez la confianza) para "retroceder" en esto. Pero aun así, vale la pena hacer un poco de ruido al respecto (sin personalizarlo) con la esperanza de que el codificador infractor haga un mejor trabajo ... la próxima vez.

¿Cuál es una respuesta apropiada a esta actitud?

En última instancia, llévelo a la atención de la gerencia ... a menos que tenga el poder de arreglarlo usted mismo. (Por supuesto, esto no te hará popular).

Tenías razón, estaban equivocados:

• principio roto YAGNI
• principio de KISS roto
• ¿Está el código completamente probado? Si no, entonces no está hecho

¿Cuál es una respuesta apropiada a esta actitud?

Haga la revisión de código adecuada. Si se niegan a implementar los cambios sugeridos sin una razón, entonces deje de perder el tiempo que revisa un código. También puede escalar el problema a su jefe .

Una acción que tomó nuestro equipo, que mejoró dramáticamente la situación en tales casos, fue el cambio a conjuntos de cambios mucho más pequeños .

En lugar de trabajar en una tarea durante un día o más y luego tener una revisión de código (grande), tratamos de registrarnos con mucha más frecuencia (hasta 10 veces al día). Por supuesto, esto también tiene algunos inconvenientes, por ejemplo, el revisor debe ser muy receptivo, lo que disminuye su propia producción (debido a interrupciones frecuentes).

La ventaja es que los problemas se detectan y pueden resolverse temprano, antes de que se realice una gran cantidad de trabajo de manera incorrecta.

Debería centrarse en la causa raíz del problema:

1. La educación de los programadores se centra en aumentar la complejidad dada a los programadores. La capacidad de hacer esto fue probada por la escuela. Por lo tanto, muchos programadores pensarán que si implementan una solución simple, no hicieron su trabajo correctamente.
2. Si el programador sigue el mismo patrón que ha hecho cientos de veces mientras estaba en la universidad, así es como piensan los programadores: más complejidad es más desafiante y, por lo tanto, mejor.
3. Por lo tanto, para solucionar esto, deberá mantener una separación estricta de los requisitos de su empresa en relación con la complejidad en comparación con lo que normalmente se requiere en la educación del programador. Un buen plan es una regla como "el nivel de complejidad más alto debe reservarse solo para tareas diseñadas para mejorar sus habilidades, y no debe usarse en el código de producción".
4. Para muchos programadores se sorprenderá que no se les permita hacer sus diseños más locos en el importante entorno del código de producción. Solo reserve tiempo para que los programadores realicen diseños experimentales, y luego mantenga toda la complejidad en ese lado de la cerca.

(en la revisión de código ya es demasiado tarde para cambiarlo)

No sé nada que funcione después de escribir el código.

Antes de escribir el código, las personas pueden discutir formas alternativas de hacerlo. La clave es contribuir ideas entre sí, por lo que esperamos que se elija una razonable.

Existe otro enfoque que funciona con los contratistas: los contratos de precio fijo. Cuanto más simple sea la solución, más $$ podrá mantener el programador.

No puedes arreglar el mundo.

Ni siquiera puedes arreglar todo el código de tu proyecto. Probablemente no pueda arreglar las prácticas de desarrollo en su proyecto, al menos no este mes.

Lamentablemente, lo que está experimentando en la revisión de código es demasiado común. He trabajado en un par de organizaciones donde me encontré a menudo revisando 100 líneas de código que podrían haberse escrito en diez, y obtuve la misma respuesta que usted: "Ya está escrito y probado" o "Estamos buscando errores, no un rediseño ".

Es un hecho que algunos de sus colegas no pueden programar tan bien como usted. Algunos de ellos pueden ser bastante malos en eso. No te preocupes por eso. Un par de clases con malas implementaciones no derribarán el proyecto. En cambio, concéntrese en las partes de su trabajo que afectarán a los demás. ¿Son adecuadas las pruebas unitarias (si las tiene)? ¿Es utilizable la interfaz? ¿Está documentado?

Si la interfaz del código incorrecto está bien, no se preocupe por eso hasta que tenga que mantenerlo, luego vuelva a escribirlo. Si alguien se queja, simplemente llámelo refactorización. Si todavía se quejan, busque un puesto en una organización más sofisticada.

Debe haber una política estándar en el proyecto que controle los procedimientos y herramientas de control de calidad entregables utilizados.

Las personas deben saber qué deben hacer y qué herramientas se aceptan para su uso en este proyecto.

Si aún no lo ha hecho, organice sus pensamientos y hágalo.

La revisión del código debe tener una lista de verificación de elementos estándar. Si obtiene "ya está hecho" y no lo está, entonces, personalmente, no me gustaría ser responsable del trabajo de este desarrollador como gerente de proyecto o desarrollador senior. Esta actitud no debe ser tolerada. Puedo entender discutir sobre cómo hacer algo o incluso todo, pero una vez que se acepta una solución, no se debe tolerar la mentira y eso debe estar claramente establecido.

Su tienda necesita aplicar algunas metodologías de diseño.

• Los requisitos deben definirse claramente.
• Debe desarrollar casos de uso que admitan los requisitos.
• Debe especificar las funciones necesarias para implementar los casos de uso.
• Debe especificar los requisitos no funcionales (tiempos de respuesta, disponibilidad, etc.)
• Necesita una RTM (matriz de trazabilidad de requisitos) para asignar cada función del sistema a un caso de uso y un requisito real.
• Descarte cualquier función que no sea compatible con un requisito real.
• Finalmente, en su revisión de código, marque cualquier código que no implemente o admita directamente las funciones definidas.

Probablemente no es que sea demasiado complicado porque eso hace que la mayoría de las personas se sientan mal después. Supongo que cuando esto sucede ya se ha escrito mucho código sin decir una palabra al respecto. (¿Por qué es así? ¿Porque esa persona tiene suficiente autoridad para que su código no tenga que revisarse en realidad?)

De lo contrario, creo que la revisión del código es menos formal pero más frecuente. Y antes de escribir módulos grandes, tal vez debería discutir rápidamente qué enfoque tomar.

Decir "esto es demasiado complicado" no te lleva a ninguna parte.

Es lamentable, pero las revisiones de código son, muchas veces, más para el futuro que para el presente. Especialmente en un entorno empresarial / corporativo, el código enviado siempre es más valioso que el código no enviado.

Esto, por supuesto, depende de cuándo se complete la revisión del código. Si es parte del proceso de desarrollo, podría obtener algún beneficio en este momento. Pero si la RC se trata más como una autopsia, es mejor señalar lo que podría hacerse mejor en el futuro. En su caso (como han dicho otros), señale YAGNI y KISS en general, y quizás algunas de las áreas específicas donde estos principios podrían aplicarse.

¿Qué significa demasiado complicado? Si hace una declaración ambigua, obtendrá una respuesta ambigua / insatisfactoria en respuesta. Lo que es demasiado complicado para una persona es perfecto para otra.

El propósito de una revisión es señalar problemas y errores específicos, no decir que no le gusta, que es lo que implica la declaración "demasiado complejo".

Si ve un problema (demasiado complicado), diga algo más concreto como:

• ¿Cambiar la parte X a Y no simplificaría el código o facilitaría su comprensión?
• No entiendo lo que estás haciendo aquí en la parte X, creo que lo que estabas tratando de hacer es esto. Presente una forma más limpia de hacerlo.
• ¿Cómo probaste esto? ¿Probaste esto? Si es demasiado complicado, esto generalmente conducirá a miradas en blanco. Solicitar pruebas con frecuencia hará que la persona simplifique su código cuando no pueda descubrir cómo probar el código original.
• Parece que hay un error aquí, cambiar el código a esto solucionaría el problema.

Cualquiera puede señalar problemas, especialmente los ambiguos. Hay un subconjunto mucho más pequeño que puede presentar soluciones. Sus comentarios de revisión deben ser tan específicos como sea posible. Decir que algo es demasiado complejo no significa mucho, incluso puede hacer que otros piensen que USTED es incompetente por no poder entender el código. Tenga en cuenta que la mayoría de los desarrolladores no tienen idea de la diferencia entre un diseño bueno o malo.

A veces vale la pena como grupo concentrarse en algunos de los principios "ágiles": pueden ayudar a un grupo o individuo que parece estar un poco fuera de curso.

Centrarse no tiene por qué significar una gran reelaboración de su equipo, pero todos deben sentarse y discutir qué prácticas son más importantes para usted como equipo. Sugeriría discutir al menos estos (y probablemente bastantes más):

• ¿Hacer lo más simple que podría funcionar?
• No lo necesitarás (¿estás resolviendo problemas que no estaban en la especificación)
• Escriba la prueba antes de codificar (lo ayuda a enfocar su código)
• No te repitas

También las revisiones ocasionales (¿semanales?) De lo que funciona, lo que no funciona y lo que aún se necesita pueden ser realmente útiles ... Si nada más, ¿por qué no comprometerse a una hora a la semana para discutir los valores y prácticas del equipo?

Escalada, si tiene un gerente con mentalidad técnica. Esto suena como un hábito que debe romperse.

Si el código no está construido según las especificaciones, entonces, por definición, debería fallar la revisión del código. No entiendo el concepto de "bueno, hemos hecho algo que nadie pidió, y no funciona, así que lo dejaremos allí en lugar de hacer algo que alguien pidió que funcione".

Este es un mal hábito para cualquier desarrollador. Si él / ella estaba trabajando para una especificación de diseño, entonces no coincidir sin una buena razón es un no no.

Una palabra: ágil

Ciertamente no resuelve todo. Pero al reinar en sus iteraciones (1-2 semanas, por ejemplo), limitar el trabajo en progreso y aprovechar la planificación / revisión del sprint, debe evitar estos errores similares a las cascadas. Necesita una mejor visibilidad de lo que realmente se está haciendo, mientras se está haciendo.

Para el desarrollo normal basado en proyectos, recomendaría adoptar un enfoque Scrum . Para entornos de desarrollo / integración continuos, y especialmente si tiene muchos desarrolladores trabajando en el mismo proyecto o proyectos relacionados, considere incorporar elementos de Kanban . Otro enfoque efectivo es aprovechar la programación de pares , una práctica definida de programación extrema .

Tu situación no es única. E incluso con equipos pequeños, el proceso puede ser de gran ayuda para evitar la situación en la que se encuentra ahora. Con una visibilidad adecuada y una cartera de pedidos razonablemente preparada, preguntas como estas se convierten en decisiones de planificación de sprint, lo que le ahorra la administración de deudas técnicas .

Lo que he dicho en el pasado es "este código es complejo y no estoy seguro de lo que está tratando de hacer, ¿es posible simplificarlo o escribirlo más claramente?"

Para codificar después de eliminar / deshacer su código: "Vaya, su código se ha ido. Vuelva a escribirlo. Como ya lo ha escrito una vez, necesitará menos de veinte minutos para proporcionar SOLO el código requerido por la especificación.

"Mi próxima revisión es en 20 minutos.

"Buen día."

¡NO aceptes ningún argumento!

Listo, en mi humilde opinión

Chris