Cómo equilibrar la calidad del código frente a las personalidades fuertes del desarrollador

Me encanta esta cita:

  

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

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

Por otra parte, el código inteligente que funciona es una forma de aprender excelente . 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 funciona según lo previsto y que tiene sentido en el proyecto en su conjunto. ¡No quieres convertirlo en una competencia sin sentido!

Si no crees que agregue valor, coloca el contrapeso preguntando: "¿Cómo puedes refactorizar esta parte (tienes pruebas implementadas, verdad?) para que sea más legible? Asegúrese de señalar que es más difícil hacer un código inteligente y legible que hacer pepitas impenetrables.

Mi consejo es que juegues al idiota, cuando sea el momento de hacer revisiones de códigos no dudes en decir que no tienes idea de cómo funciona (si tu ego necesita un masaje, puedes decir que no tuviste tiempo para hacerlo). averiguarlo) y hacer que el desarrollador lo explique. Cuando haya terminado, puede sugerir que escriba todo eso como un comentario para el mantenimiento futuro, con el indicio implícito 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 se darán cuenta, sin que se haya dicho nada sobre la calidad del código o la experiencia del desarrollador.

PS. Obviamente, la mayoría 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 y tal vez incluso estándar de la industria para otro desarrollador, por lo que no puede acusar a nadie directamente de escribir un código incorrecto (excepto cuando es obvio como el contratista que copió una matriz de bytes en una lista de stl, la pasó a una rutina de cifrado y luego la convirtió de nuevo en una matriz de bytes.

Mi regla de oro es doblar las pautas de calidad del código a favor de personalidades sólidas de los desarrolladores. Lo utilizo siempre que no tengo tiempo para profundizar lo suficiente, ya que, por cierto, este tipo de excavación requiere bastante esfuerzo (más sobre esto más adelante).

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 una de las desviaciones. Con el tiempo, adquirí suficientes habilidades y aprendí suficientes trucos para ganar esas 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, el impacto fue bastante negativo: los hombres que "perdieron la pelea" sufrieron y se volvieron menos productivos, y, ya sabes, el hecho de que su código fuera compatible 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 los casos problemáticos. Y descubrí que cuando cavo lo suficientemente profundo generalmente hay un problema de diseño interesante detrás, un problema sutil (o no demasiado sutil) que se escondía detrás de las personalidades que luchan.

• Es como, ya sabes, como decir que encuentro un archivo fuente de 31K que excede el límite de tamaño recomendado, es decir, 30K. Mis opciones son pasar unos minutos / horas luchando para forzar al propietario del archivo a que de alguna manera exprima ese kilobyte extra o 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 todo el código en ese archivo (para que solo pueda eliminarse).

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

Su organización debe tener un documento de estándares / pautas de codificación que se actualice periódicamente con los aportes del equipo de desarrollo. Ese documento puede detallar detalles, como: cómo nombrar las variables, cómo dar formato al 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 cosas como legibilidad, facilidad de mantenimiento, corrección, eficiencia y cumplimiento de los estándares.

Las revisiones del 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á algo de apoyo para argumentar contra el código "inteligente". Si los estándares no lo dicen y usted piensa que deberían hacerlo, entonces puede discutirlo en el resumen en la reunión de estándares de codificación en lugar de tratar de resolverlo cuando el ego de alguien está en la línea.

En última instancia, a veces se trata de una decisión de juicio, y en esos casos, la palabra final debe dirigirse a la persona que es el responsable del código y / o producto. Por lo general, es alguien como un desarrollador senior, líder técnico, gerente de proyectos o director de ingeniería. Si eres el responsable y sientes que cierto código no es lo suficientemente mantenible, no debes tener miedo de decirlo. Puedes ser diplomático al respecto:

  

Sam, estoy impresionado con tu ingenio aquí, pero me preocupa que   puede ser un poco demasiado inteligente Te necesito para estar trabajando en un nuevo   desarrollo en un año a partir de ahora en lugar de mantener esto, y estoy   preocupado de que quienquiera que tenga que mantenerlo no pueda   comprender su genialidad. Sé que odias hacerlo, pero yo   Apreciaría si volviera a la implementación directa.   que hemos discutido.

Por otra parte, si no eres el tipo a cargo, lo mejor que puedes hacer es explicar tu posición claramente y tratar de convencer al resto del equipo. Si no está recibiendo asistencia del administrador, acepte que no es su llamada y continúe.

En su lugar (y yo, a veces, soy uno de esos smartasses) no lo eliminaría, pero pida personalmente al autor ingenioso / inteligente que lo documente muy bien en los comentarios, y si es posible, incluir alguna discusión sobre escritos alternativos y 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, eliminará el código inteligente a favor del más simple, tan pronto como se vea obligado a escribirlo, como ejemplo.

¿Por qué funcionaría?

• Reconociste que te importa lo que escribe ,
• le mostraste respeto al preguntar ,
• citando problemas de memoria / enfoque que creas y le desglose un escenario en el que ese código debe cambiarse y no puede mientras trabaja para la compañía o el equipo

(sin esa última alusión, este tipo de solicitud puede recibirse como un intento, por parte de la empresa, de mercantilizar al programador , haciéndolo intercambiable con cualquier otro código mono en cualquier momento)

En mi experiencia, normalmente es muy difícil obtener un código que sea suficiente para todos los requisitos fuera del código base.

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

En cuanto al poder de veto, la administración obviamente tiene eso.
A veces hay 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 si da 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 depende .

• Si es un defecto, entonces definitivamente debe ser arreglado.
• Si el código funciona, debe equilibrar el valor de insistir en que se cambie el código en comparación con el costo futuro del código inteligente. Si bien hay reglas generales sobre la relación entre el trabajo de desarrollo y el trabajo de mantenimiento, varían 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 no se registrará nada 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 están haciendo un trabajo muy pobre, entonces se debe tomar alguna otra acción, pero como usted dice, el valor negativo de obligar al desarrollador a cambiar el código puede ser mayor que la ganancia al arreglarlo 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 mi trabajo es asegurar que el código que producimos sea lo más legible y fácil de mantener. Al mismo tiempo, se me ha dado a conocer algunos códigos "inteligentes" y sé que a la mayoría de mis compañeros de equipo les costará mucho seguirlo.

Algunas observaciones que puedo ofrecer:

1. Su equipo necesita un líder que tomará la decisión final cuando exista un desacuerdo. En el último lanzamiento estuve en un equipo sin liderazgo y fue atroz. Todo se convirtió en un argumento, y si tienes pocas personas con personalidades fuertes, ninguno de ellos cederá. Si tiene un cliente potencial, independientemente de si se elige la decisión, todos los miembros del equipo DEBEN entender que lo que dice el cliente potencial va. Es por eso que la gerencia lo convirtió en el líder.

2. Mantener a las personas felices 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 de SOLID, explique la importancia de las clases / métodos / interfaces pequeños y cohesivos y repita estas cosas cada vez que vea que se violan (es decir, en una revisión del 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 los siguientes estándares grupales. Con suerte, los dos convergerán a medida que las preferencias personales cambien hacia la forma en que funciona 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 utiliza 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 está escalando muy bien. Estoy a punto de reemplazarlo con una clase diferente, que utiliza contenedores intrusivos de Boost. Cada elemento admitirá que se coloquen 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 muchas personas no les gusta Boost, pero por fuera se mantendrán 3 métodos: Agregar, Eliminar, Obtener. La conclusión es que las personas pueden escribir el código que quieran (dentro de lo razonable), pero las interfaces NO DEBEN ser inteligentes.

4. Mantener la idea de propiedad del código. Aunque a veces es difícil de lograr ya que diferentes personas podrían necesitar agregar / modificar algún código. Cuando se escribe el código, el desarrollador original es el mejor guardián 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 ocurra 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 corregirlos a medida que entran, siéntese con ese desarrollador (quien por cierto debería corregir todos esos errores) y reflexione sobre esas decisiones para ver cómo se podrían haber hecho de manera diferente. Luego, déle un libro sobre refactorización y vea cómo puede "unclever" algo de él.

He pasado muchos años liderando y administrando equipos de desarrollo. Por naturaleza, soy un poco OCD en términos de código y muy en blanco y negro. Aprendí por experiencia que escoger tus batallas es una de las habilidades más difíciles de aprender como líder de un equipo. Sí, las normas son importantes. Sí, la legibilidad y la capacidad 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 son 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 code & Los patrones que considero "inteligentes" aunque no necesariamente aumentan la calidad general o la capacidad de mantenimiento del código base.

Está bien ... para que no agreguen, ¿pero restan valor? ¿Estamos hablando solo de una cuestión de preferencia personal en los estilos de codificación, o el código se escribe 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 un desarrollador es encontrar soluciones creativas para los problemas. Tal vez (y a la mayoría de nosotros no nos gusta admitirlo), a veces nos sentimos intimidados por los enfoques que no entendemos, y o bien no queremos preguntar o no tenemos la energía adicional para aprender el nuevo enfoque.

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

La mejor manera de inculcar la responsabilidad en su equipo es alentar a otros a que lo hagan responsable. Si mantiene la mente abierta y no cierra a las personas cuando sugieren mejoras en su código, es posible que se muestren más receptivas a sus sugerencias.

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

Me esforzaré mucho para entender 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 se justifica, depende de si la complejidad del código es acorde con la complejidad del requisito.

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

Dependiendo de la metodología de control de origen, es posible que el código deba comprometerse provisionalmente en el sistema de control de origen (quizás en una rama) antes de que pueda comenzar esta fase de prueba.

Mi respuesta está basada en 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 los doctorados, quizás los primeros porcentajes de los doctorados. Si el código es que es 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.