Se me ha encomendado la tarea de enseñar a otros equipos un nuevo código base, pero me encuentro con un problema. Cada vez que voy a leer el código con la gente, no llegamos muy lejos antes de que todo el ejercicio se convierta en un bikeshedding (miembros de una organización que le dan un peso desproporcionado a cuestiones triviales) ejercicio. Como no conocen el código base, pero creen que necesitan mejorarlo, se enfocan en las cosas que pueden entender:
Why is that named that?
(2 minutos para explicar por qué se llama así, 10+ minutos debatiendo un nuevo nombre)
Why is that an abstract base class rather than an interface?
(2 minutos para explicar, 10+ minutos debatiendo los méritos relativos de esta decisión)
... y así sucesivamente. Ahora, no me malinterpretes: los buenos nombres y el diseño bueno y consistente son importantes, pero nunca discutimos lo que realmente hace el código o cómo se diseña el sistema de manera significativa. He hecho algunas reuniones de arbitraje para sacar a la gente de estas tangentes, pero se han ido, distraídos por lo que el código será / debería ser cuando se arregle su trivialidad como mascota, y se pierden el panorama general.
Así que volvemos a intentarlo más tarde (o con una parte diferente de la base de código) y como la gente no obtuvo el conocimiento suficiente para superar el efecto de motos, se repite.
He intentado grupos más pequeños, grupos más grandes, códigos, pizarras blancas, diagramas de visio, muros gigantes de texto, dejándolos discutir, cortando los argumentos de inmediato ... algunos ayudan más que otros, pero nada
Entonces, ¿cómo educas a otros programadores lo suficiente para que dejen de fijarse en las trivialidades y puedan contribuir de manera significativa al diseño?