Cómo equilibrar la calidad del código frente a personalidades sólidas de desarrollador

En las revisiones de código en el trabajo, he estado viendo códigos y patrones que considero "inteligentes", aunque no necesariamente contribuyen a la calidad general o la facilidad de mantenimiento de la base de código. Destaco esto en mis comentarios y no estoy convencido por los argumentos en contra. Estoy un poco preocupado cuando este código entra en el repositorio y luego en producción.

Quiero mantener un equipo cohesionado, por lo que no quiero crear tensión al ser demasiado vocal sobre mis reservas. También quiero crear un gran producto para nuestros clientes sin ser demasiado indulgente.

Tradicionalmente, ¿quién tiene poder de 'veto' sobre lo que se registra y cómo?

¿Cómo puede el código que funciona, pero es demasiado complicado / inteligente ser eliminado sin pisar los pies?

Amo esta cita:

"La depuración es dos veces más difícil que escribir el código en primer lugar. Por lo tanto, si escribe el código de la manera más inteligente posible, por definición, no es lo suficientemente inteligente como para depurarlo". - Brian W. Kernighan

Por un lado, esto te cansa del código demasiado inteligente, ya que será difícil de depurar y extender más tarde.

Por otro lado, el código inteligente que funciona es una excelente manera de aprender. Probablemente para todo el equipo. ¿Qué hay de alentar al autor a dar una pequeña charla informal sobre el código a sus colegas? Solo asegúrese de que realmente funcione según lo previsto y que tenga sentido en el proyecto en su conjunto. ¡No quieres convertirlo en una competencia sin sentido!

Si no cree que agrega valor, coloque el contra desafío preguntando: "¿Cómo puede refactorizar esta parte (tiene pruebas en su lugar, ¿no?) Para que sea más legible?" Asegúrese de señalar que es más difícil crear un código inteligente y legible que hacer pepitas impenetrables.

Mi consejo es jugar al idiota, cuando sea el momento de hacer revisiones de código, siéntase libre de decir que no tiene idea de cómo funciona (si su ego necesita un masaje, puede decir que no tuvo tiempo de resolverlo) ) y haga que el desarrollador lo explique. Cuando haya terminado, puede sugerirle que escriba todo eso como un comentario para el mantenimiento futuro, con la sugerencia implícita de que es demasiado complicado para ser considerado un código 'bueno'.

Si su buen código es un poco demasiado complicado, la mayoría de las personas lo entenderán, sin que se haya dicho nada sobre la calidad del código o la experiencia del desarrollador.

PD. Obviamente, la mayor parte de este código será subjetivo de todos modos, por lo que el código increíblemente inteligente de una persona podría ser un algoritmo razonable e incluso estándar de la industria para otro desarrollador, por lo que no puede acusar a nadie directamente de escribir código incorrecto (excepto cuando es obvio) ¡como el contratista que copió una matriz de bytes en una lista stl, la pasó a una rutina de cifrado y luego la convirtió de nuevo en una matriz de bytes!)

Mi regla general es doblar las pautas de calidad del código a favor de personalidades sólidas de desarrolladores. Lo uso siempre cuando no tengo tiempo para cavar lo suficientemente profundo; por lo general, excavar requiere mucho esfuerzo (más sobre eso a continuación).

Esta regla se basa en la experiencia personal. Comencé (probablemente como cualquier neófito) siguiendo fanáticamente las pautas y luchando a fondo contra cada desviación. Con el tiempo adquirí suficientes habilidades y aprendí suficientes trucos para ganar tales peleas con relativa facilidad, lo que a su vez me permitió centrarme más en aprender el impacto general de mis "victorias". Y, por lo que puedo decir, fue bastante negativo: los hombres que "perdieron la pelea" estaban sufriendo y se volvieron menos productivos, y, como saben, el hecho de que su código cumpliera en un 200% con las pautas de calidad no compensó eso.

Este descubrimiento me hizo abandonar la mayoría de los combates, lo que a su vez me llevó a tener más tiempo para analizar casos problemáticos. Y descubrí que cuando cavo lo suficientemente profundo, generalmente hay un problema de diseño interesante en algún lugar detrás, un problema sutil (o no demasiado sutil) que se estaba escondiendo detrás de las peleas de personalidades.

• Es como, digamos, encuentro que el archivo fuente de 31K excede el límite de tamaño recomendado, que es, por ejemplo, 30K. Mis opciones son pasar unos minutos / horas luchando para obligar al propietario del archivo a exprimir ese kilobyte adicional o pasar un día o dos pensando y cavando para descubrir que, por ejemplo, hay alguna API de biblioteca que se puede usar en lugar de todas el código en ese archivo (para que pueda eliminarse).

Tal descubrimiento a veces puede no ser muy útil desde la perspectiva del usuario final (aunque a veces puede tener un profundo impacto), pero tengo que admitir que la diversión que obtengo al romper esa tuerca hace que valga la pena el esfuerzo de todos modos ... y como La desviación de las pautas de la guinda del pastel también desaparece sin luchar. :)

Su organización debe tener un documento de pautas / estándares de codificación que se actualice periódicamente con los aportes del equipo de desarrollo. Ese documento puede explicar detalles específicos, como: cómo nombrar variables, cómo formatear código, etc. El documento también debe explicar los valores que la organización espera que los programadores adopten al escribir el código, incluida la importancia relativa de aspectos como la legibilidad, el mantenimiento, la corrección, la eficiencia y el cumplimiento de las normas.

Las revisiones de código deben realizarse utilizando ese documento de estándares de codificación. Si los estándares de codificación dicen que los programadores deberían preferir la legibilidad a la brevedad cuando los dos están en conflicto, entonces tendrá algún apoyo para argumentar en contra del código "inteligente". Si los estándares no dicen eso y piensas que deberían hacerlo, entonces puedes discutirlo en abstracto en la reunión de estándares de codificación en lugar de tratar de resolverlo cuando el ego de alguien está en juego.

En última instancia, a veces se reduce a una llamada de juicio, y en esos casos la última palabra debe ir a la persona que es la responsable final del código y / o producto. Por lo general, es alguien como un desarrollador sénior, líder técnico, gerente de proyectos o director de ingeniería. Si eres el responsable y crees que cierto código no es lo suficientemente fácil de mantener, no debes tener miedo de decirlo. Puede ser diplomático al respecto:

Sam, estoy impresionado con tu ingenio aquí, pero me preocupa que pueda ser demasiado inteligente. Necesitaré que trabajes en un nuevo desarrollo dentro de un año en lugar de mantener esto, y me preocupa que quien tenga que mantenerlo no comprenda completamente su genialidad. Sé que odias hacerlo, pero agradecería que volvieras a la implementación sencilla que discutimos.

Por otro lado, si no eres el responsable, entonces lo mejor que puedes hacer es explicar tu posición claramente e intentar convencer al resto del equipo. Si no recibe ayuda del administrador, acepte que no es su decisión y continúe.

En su lugar (y yo, a veces, soy uno de esos sabios) , no lo eliminaría, pero le pido personalmente al autor ingenioso / inteligente que lo documente muy bien en los comentarios y, si es posible, que incluya una discusión sobre alternativas y escritos más simples que podría haber usado, con ejemplos.

Subrayaría que esto es lo mejor, porque incluso él probablemente no recordará todos los bits y bobs que hay, en esas líneas, dentro de dos meses.

Probablemente soltará el código inteligente a favor del más simple, tan pronto como se vea obligado a escribirlo, como ejemplo.

¿Por qué funcionaría eso?

• Reconociste que te importa lo que escribe ,
• que le mostró respeto por preguntar ,
• citando problemas de memoria / enfoque que usted crea y analiza un escenario en el que ese código debe cambiarse y no puede hacerlo mientras todavía está trabajando para la empresa o el equipo

(sin esa última alusión, este tipo de solicitud puede recibirse como un intento, por parte de la compañía, de comercializar el programador , haciéndolo intercambiable con cualquier otro código mono en cualquier momento)

En mi experiencia, generalmente es muy difícil obtener código que cumpla con todos los requisitos de la base de código.

Sin embargo, la próxima vez que se mantenga el código, puede argumentar fácilmente su reemplazo como una medida de ahorro de costos futuros porque el código antiguo era más difícil de mantener.

En cuanto al poder de veto, la administración obviamente lo tiene.
Algunas veces son equipos o comités que están a cargo de la calidad del código, en cuyo caso también tendrían este poder.

También sería útil dar un ejemplo de un patrón 'inteligente'. Tal vez solo estás exagerando ...

"inteligente" casi nunca es algo malo en mi libro, pero estoy de acuerdo en que puede haber una pendiente resbaladiza entre inteligente y enrevesada.

Como muchas otras prácticas, creo que la respuesta es que depende .

• Si es un defecto, definitivamente necesita ser reparado.
• Si el código funciona, debe equilibrar el valor de insistir en que se cambie el código frente al costo futuro del código inteligente. Si bien existen reglas generales con respecto a la relación entre el trabajo de desarrollo y el trabajo de mantenimiento, variarán mucho de un proyecto a otro. Sé razonable.
• Considere por qué no puede convencer a su compañero de equipo de que el código debe simplificarse.
• No siempre tienes que tener todo perfecto. Eso significaría revisiones de código en un bucle infinito y nada registrado porque nada (excepto mi código, jaja) es perfecto.
• Mi preferencia personal es que el autor del código tenga la última palabra. Obviamente, si continuamente están haciendo un trabajo muy pobre, entonces se deben tomar otras medidas, pero como usted dice, el valor negativo de obligar al desarrollador a cambiar el código puede ser mayor que la ganancia obtenida al solucionarlo si esta es una situación muy rara. .

Definitivamente puedo relacionarme con esta pregunta. Actualmente soy el líder técnico de 2 equipos y es mi trabajo asegurarme de que el código que producimos sea lo más legible y fácil de mantener posible. Al mismo tiempo, se sabe que produzco un código "inteligente" y sé que la mayoría de mis compañeros de equipo tendrán dificultades para seguirlo.

Pocas observaciones puedo ofrecer:

1. Su equipo necesita un líder que tomará la decisión final cuando haya un desacuerdo. En el último lanzamiento estaba en un equipo sin liderazgo y fue atroz. Todo se convirtió en una discusión, y si tienes pocas personas con personalidades fuertes, ninguno de ellos cederá. Si tiene una pista, independientemente de si se elige qué decisión, todos en el equipo DEBEN entender que lo que dice la pista es válida. Es por eso que la gerencia lo convirtió en el líder.

2. Mantener a la gente feliz es muy importante. Por lo tanto, en lugar de empujar a todo el equipo hacia su punto de vista, simplemente empuje allí. Explique los principios SÓLIDOS, explique la importancia de las clases / métodos / interfaces pequeños y coherentes y repita estas cosas cada vez que vea que se violan (es decir, en una revisión de código). Al mismo tiempo, no hagas que reescriban cada cosa que no te gusta. Al final del día, necesita un equilibrio entre la expresión personal y seguir los estándares del grupo. Con suerte, los dos convergerán a medida que las preferencias personales cambien hacia la forma en que opera el grupo en general.

3. Creo que es mucho más importante tener interfaces de clase limpias y fáciles de entender, que no tener ningún código "inteligente". Por ejemplo, tenemos una clase que mantiene una lista de entradas que se buscan de 3 maneras diferentes. Actualmente, simplemente usa la búsqueda lineal para todas las búsquedas que funciona a pequeña escala, pero debido a que esta clase está en un nivel muy bajo, veo que no escala muy bien. Estoy a punto de reemplazarlo con una clase diferente, que utiliza contenedores intrusivos Boost. Cada elemento admitirá la colocación en cada uno de los índices simultáneamente y toda la búsqueda se realizará en O (sqrt (N)). Sí, será mucho más complicado por dentro y a mucha gente no le gusta Boost, pero por fuera seguirá siendo 3 métodos: Agregar, Eliminar, Obtener. La conclusión es que las personas pueden escribir el código que quieran (dentro de lo razonable),

4. Mantener la idea de la propiedad del código. Aunque a veces es difícil de lograr ya que diferentes personas pueden necesitar agregar / modificar algún código. Cuando se escribe el código, el desarrollador original es el guardián final de ese código. Eso no significa que nadie más pueda tocarlo. Si otros modifican su código, está bien, pero al final del día el desarrollador original lo revisa y sigue siendo responsable de lo que sea que haya allí. Si ese código es simple o inteligente, es su bebé. Si / cuando, como está pronosticando, los errores comienzan a acumularse debido a las decisiones de diseño / codificación que se tomaron, en lugar de simplemente corregir esos errores a medida que entran, siéntese con ese desarrollador (quién debería estar arreglando todos esos errores) y reflexionar sobre esas decisiones para ver cómo se podrían haber hecho de manera diferente.

He pasado muchos años liderando y administrando equipos de desarrollo. Por naturaleza, soy un poco TOC en términos de código y muy blanco y negro. Gracias a la experiencia, he aprendido que elegir tus batallas es una de las habilidades más difíciles de aprender como líder de equipo. Sí, los estándares son importantes. Sí, la legibilidad y la facilidad de mantenimiento son increíblemente importantes. Sí, todos debemos esforzarnos por escribir un código uniforme que cumpla con los estándares. Sin embargo, los desarrolladores son humanos ... no herramientas de generación de código. Tenemos personalidades, opiniones, nos aburrimos y queremos aprender cosas nuevas.

En las revisiones de código en el trabajo, he estado viendo códigos y patrones que considero "inteligentes", aunque no necesariamente contribuyen a la calidad general o la facilidad de mantenimiento de la base de código.

OK ... entonces no suman, pero ¿restan? ¿Estamos hablando solo de una cuestión de preferencia personal en los estilos de codificación, o el código que se escribe es completamente innecesario (por ejemplo, usar árboles de expresión y reflexión solo porque es divertido usar árboles de expresión y reflexión)? Si es lo primero, déjalo ir. Parte de la diversión de ser desarrollador es encontrar soluciones creativas a los problemas. Tal vez (y a la mayoría de nosotros no nos gusta admitir esto), a veces nos sentimos intimidados por enfoques que no entendemos, y no queremos preguntar o no tenemos la energía adicional para aprender el nuevo enfoque.

Ahora, cuando la creatividad conduce a un código innecesario y una complejidad completamente injustificable, entonces, por supuesto, sea vocal y defienda su caso. Ser un jugador de equipo es importante, pero también lo es ser (y responsabilizar a otros). Las revisiones de código se refieren tanto a la responsabilidad como al aseguramiento de la calidad y el aprendizaje. Vas a pisar algunos dedos de los pies, pero si sientes que tienes un fuerte argumento de por qué se debe gastar esfuerzo (dinero) reescribiendo el código de trabajo Y un ego debe ser lastimado en el proceso Y quieres arriesgarte a aplastar el entusiasmo de alguien por su oficio , entonces no debes evitar ponerlo sobre la mesa. Si usted es el líder del equipo, este es su trabajo. Sé consciente del impacto y hazlo. Si no eres un líder de equipo y no tienes la autoridad, ponlo al equipo para que decida.

La mejor manera de inculcar la rendición de cuentas en su equipo es alentando a otros a responsabilizarlo. Si mantiene una mente abierta y no cierra a las personas cuando sugieren mejoras en su código, puede encontrar que son más receptivas a sus sugerencias.

Por experiencia personal, cuando esto sucede, pediría permiso para ser un probador voluntario de la unidad de confrontación para escribir pruebas con el fin de torturar la implementación desconocida.

Haré todo lo posible para comprender realmente cómo funciona el código, y también intentaré probarlo de muchas maneras diferentes.

Tenga en cuenta que este es un compromiso de tiempo. Pueden ser horas, o decenas de horas, o incluso una buena parte de una semana. Si está justificado depende de si la complejidad del código es proporcional a la complejidad del requisito.

Si no prevaleciera, es decir, si el código sobrevive a las muchas pruebas, me convencería de que tal vez la implementación sea realmente más clara de lo que soy, y apoyaré su inclusión en el producto principal.

Dependiendo de la metodología de control de fuente, el código puede tener que ser asignado provisionalmente al sistema de control de fuente (quizás en una rama) antes de que pueda comenzar esta fase de prueba.

Mi respuesta está coloreada por mi experiencia de usar OpenCV. Hay algoritmos que son mucho más sofisticados de lo que cualquier programador puede implementar por sí mismo; ni siquiera doctorados, tal vez los mejores porcentajes de doctorados. Si el código es tan bueno, debe confiar en eso, actuando en contra de sus propios instintos y prejuicios, incluso si no tiene medios efectivos para cuantificar ese nivel de confianza.