¿Cómo acercarse a los desarrolladores que trabajan en torno a los estándares de calidad del código?

Me he hecho cargo de un grupo de 3 desarrolladores con una pésima calidad de código en su proyecto. Para aumentar la calidad de su código, se han realizado muchas reuniones y se ha agregado un control de calidad de código (sonarqube) a CI para monitorear el código y fallar la canalización si no pasa los requisitos.

Uno de los desarrolladores encontró una forma de solucionar los límites de complejidad de la función y comete un código incorrecto (ejemplo a continuación). Mi pregunta es ¿cómo debo abordar esto para evitar que él y otros desarrolladores usen soluciones alternativas en lugar de pensar y corregir sus códigos?

switch (true) { 
               case (first & second & otherthing):
                    dosomething();
                    break;
               case (unrelated_if || complex):
                    do_totally_unrelated_thing_to_previous_one();
                    break;
               ...
               }
Si tiene suficiente tiempo disponible, puede forzarlos solo a enviar solicitudes de extracción, luego podría revisarlas y simplemente denegar bs como esa.
Estoy de acuerdo con el comentario de arriba. El tener que hacer solicitudes, también hace que, si encuentras bs en el código o código que no cumple con los estándares, puedes revisar fácilmente el código para asegurarte de que no suceda.
¿Alguna vez les has preguntado a estos tipos por qué escriben código de mala calidad? Y si es así, ¿cuál fue su respuesta?
@FlorianSchaetz tenemos gitlab y todos los códigos se fusionan solo mediante la presentación de solicitudes de fusión (extracción) que serán auditadas por mí. El problema es que lleva mucho tiempo cerrar, pedirles que reescriban, probar de nuevo para cada solicitud de fusión. Quiero que escriban menos bs en las solicitudes de fusión.
¿Puedes activar los literales booleanos? Ni siquiera sabía eso. Está intentando automatizar el proceso de revisión del código, que solo funciona cuando los desarrolladores saben cómo es un buen código. Este no parece ser el caso para sus desarrolladores junior, por lo que primero tendrá que invertir en eso. Leer sobre programación espartana me ayudó a agregar claridad a mi código, tal vez también ayude a otros.
@rath: Puedes. En C o C++ significa que solo puede tener constantes verdaderas y falsas según los casos. En otros idiomas, encontrará el primer caso que se evalúe como verdadero o continúe con el valor predeterminado. En otros idiomas, podría realizar cada caso que se evalúe como verdadero. Pero claramente, esto no es lo que quería el desarrollador, sino un truco para sortear la herramienta automática.
¿No hay ninguna regla en Sonarqube que puedas habilitar o prohibir switch(true)? O puede escribir su propia regla para agregarla. Si han hecho algo que no entienden cómo escribir correctamente, debe explicárselo, si están interesados ​​en la calidad del código...
¿Cuenta con estándares de codificación? ¿Quién decide qué es la "calidad de código horrible"?
La respuesta simple a su pregunta es "despedirlos". En última instancia, es la única forma de lograr que alguien haga algo. Simplemente diga "He mencionado muchas veces que la calidad del código es baja. Esta es una advertencia final y luego tendremos que dejar ir a uno o a los tres". Tenga en cuenta que, en casi cualquier grupo de unos tres programadores, uno es despedido por incompetencia cada seis meses más o menos . ¿Cuál es el problema aquí? Solo despide al peor.
Lamento ser el idiota aquí, pero ¿qué tiene de malo ese código? Cuando tiene que cambiar entre condiciones complejas, este método es eficiente y permite tener un código que sigue la especificación.
@ gazzz0x2z en general, no desea que una estructura de código maneje 2 funciones no relacionadas. El programa debe centrarse en una tarea individual con una estructura de programa/programación diferente para cada tarea individual. Desde una perspectiva de depuración, esto permite aislar y corregir los errores mucho más fácilmente, ya que no tiene regiones de tareas interconectadas.
Mala herramienta. Introduzca la revisión por pares en su lugar. La inversión en tiempo se amortizará sustancialmente cuando se inicie el mantenimiento.
@ gazzz0x2z La estructura del código es casi definitivamente un truco para reemplazar if(x){} if(y){}porque el analizador estático marcó las ifdeclaraciones para el control de calidad, pero no marca el switch. Si está bien o no sin ese contexto, no es realmente importante.
¿La función contenedora se creó recientemente en la confirmación o fue una solución a una función ya existente?

Respuestas (4)

Personalmente, encuentro que la mayoría de esas herramientas de código automatizado son inútiles. Hay momentos en los que falla el código por cosas que son simplemente preferencias y cosas que son malas en algunas circunstancias pero buenas o incluso necesarias en otras. Y, a menudo, dejan al desarrollador sin saber cuál debería ser la solución real. Si sabe que algo falla pero no entiende por qué falla o qué debería hacer en su lugar, la herramienta en sí ha fallado.

Lo que ayuda es la revisión del código al 100%. Ningún código se compromete con la rama de producción sin ser aceptado a través de la revisión del código y ningún desarrollador tiene los derechos para comprometer con la rama de producción solo el equipo de compilación o el líder.

Aquí es donde devuelve el código incorrecto, preferiblemente con una explicación de por qué es incorrecto. La clave es hacer que sea doloroso no arreglar el código. Sí, habrá algunas ocasiones en las que se perderá la fecha límite porque el código falló en la revisión del código. Y tendrán que explicar eso como una razón. Esto hace que las personas sean menos propensas a cometer el mismo error repetidamente para poder cumplir con sus plazos. Si no hay dolor en escribir código incorrecto, no hay razón para arreglarlo, siendo la naturaleza humana lo que es.

Dicho esto, usted y su equipo deben llegar a un acuerdo sobre qué es un buen código y qué es un código aceptable. Si sus estándares y los de ellos no coinciden actualmente, esto debe resolverse mediante discusiones y aprobar un estándar aceptable. Si tienen aportes al estándar (y sí, eso significa que debe comprometerse y aceptar sus estándares al menos en parte, tener la discusión es irrelevante, incluso contraproducente, si aún va a dictar los resultados finales), eso tendrá más comprar en realmente usarlo.

Hay momentos... Por supuesto que los hay. Es por eso que la mayoría de las herramientas son configurables . Puede, por ejemplo, cambiar de reglas, cambiar las prioridades de las reglas o incluso agregar nuevas reglas. Los analizadores de código estático pueden ser una herramienta valiosa que muestra muchos problemas típicos, pero son solo el comienzo de un buen código y no el final. Puede realizar algunas tareas básicas, pero para más, por supuesto, siempre necesitará revisiones de código.
Voy a salir a favor de algunas herramientas de código. Resharper es uno de mis favoritos. Usted (HLGEM) puede estar sufriendo la "Maldición del conocimiento": una vez que comienza a escribir código bien formado automáticamente, no ve el valor de la herramienta. Sin embargo, la herramienta puede ser invaluable para lograr que un desarrollador comience a escribir código bien formado. Mi opinión. YMMV. +1 por el resto del contenido.
Tal vez sea porque los únicos que he usado son para código SQL y universalmente son terribles porque no consideran el significado y la gente piensa que su código es bueno porque pasó cuando los resultados son incorrectos y cuando tuvimos que omitir la regla para Por razones de desempeño, se tomó prácticamente un acto del Congreso. Además, vi a demasiadas personas totalmente confundidas acerca de con qué reemplazar la subconsulta correlacionada o que no pudieron realizar un cambio y obtener el mismo conjunto de resultados.
Además, mi experiencia con las personas que usan estas herramientas es que tienen que pensar menos, lo que les dificulta pasar a un nivel avanzado y hacen las cosas de memoria porque la herramienta dice que son malas y no porque entiendan por qué son malas o qué condiciones podría necesitar la regla para tener una excepción. Hacer que las personas sean menos analíticas es malo para la profesión.
@FlorianSchaetz Hay una diferencia entre ejecutar una herramienta de análisis estático para buscar posibles errores (una buena idea) y colocar un bloque de verificación en función de su salida (una mala idea). El análisis estático puede encontrar algunos errores, también generará una gran cantidad de falsos positivos y problemas condicionales en los que simplemente no es lo suficientemente inteligente como para saber si algo está bien. También realizan liendres sin sentido y hacen grandes negocios con diferencias de estilo menores. Ejecútelos y mire los resultados, pero la única forma de garantizar la calidad es una revisión humana real, no automatizada.
Por otro lado, si nada aplica los resultados del analizador, se ignorará. Personalmente, tiendo a tener una mezcla de eso, no aplicarlos para cada solicitud de incorporación de cambios, sino resolver todos los problemas durante la fase final de refactorización.
No son solo sus limitaciones técnicas inherentes las que hacen que estas herramientas sean problemáticas: las personas pueden llegar a ver que su objetivo y su responsabilidad son satisfacer la herramienta y no alcanzar el objetivo subyacente. Convertirlo en una fuerte barrera administrativa solo hará que la atención se centre cada vez más en la herramienta. La herramienta dice que sí, así que hemos terminado, ¿verdad? La revisión de código hecha incorrectamente corre el riesgo de ser solo otra herramienta más poderosa con el mismo problema, hecha bien (100% es quizás demasiado) es una forma de hacer que las personas hablen entre sí y piensen en la calidad del código. Encuentre formas de cambiar la cultura, no de gestionar los detalles.

Introdujiste una herramienta que aparentemente solo se interpone en el camino. El código horrible que publicaste se creó porque el desarrollador creó un código inicialmente que no fue aceptado por tu herramienta y descubrió cómo, al empeorar el código, sería aceptado. Ese es completamente tu problema. Si crea situaciones en las que las personas son recompensadas por hacer algo incorrecto, lo estarán haciendo mal.

Lo que no sabemos, al escuchar solo un lado de la historia, es si tienen una calidad de código horrible o si tienen un código que no te gusta, lo que puede ser algo completamente diferente. ¿Eres un desarrollador experimentado? Luego dígales cómo mejorar el código, envíelos a cursos de capacitación y realice revisiones de código. ¿O eres un jefe de pelo puntiagudo? En ese caso, que se pongan manos a la obra.

Yo tengo cinco o seis años desarrollando experiencia mientras que ellos tienen unos dos años.
En ese caso, capacitándolos y diciéndoles cómo mejorar su código.
La capacitación debe ir de la mano con la implementación de reglas como esta: ha establecido un camino para el fracaso, asegúrese de darles también un camino para el éxito.
+1 personas hacen lo que se les incentiva a hacer. Configure el sistema y los procesos de manera que tengan los incentivos para lograr sus objetivos.
Si bien estoy de acuerdo en que este es solo un lado de la historia (aunque ¿qué pregunta aquí no lo es?), ese lado (junto con ese código) hace que parezca nada más que insubordinación, que puede solucionarse con capacitación u orientación solo si el la insubordinación es el resultado de haber recibido reglas poco claras. Si son insubordinados simplemente porque no respetan la autoridad de OP o porque no están de acuerdo (lo que parece mucho más probable, ya que 2 desarrolladores tienen un 99% de posibilidades de estar en desacuerdo con los estándares de codificación), la capacitación y la orientación no harán nada.

Hay dos problemas aquí:

  • la calidad de su código es mala

  • están trabajando en torno a su ejecutor de calidad de código

Hay una solución simple: revisión de código.

Revise cada solicitud de extracción que hagan. Si cometen código de mala calidad, explique por qué es de mala calidad. Explique por qué los estándares de calidad son importantes. Explique que ciertas decisiones de diseño pueden ser más rápidas a corto plazo, pero conllevan una deuda técnica significativa. Explique que es inaceptable escribir deliberadamente soluciones alternativas a su encargado de la calidad de la codificación. La clave aquí es enseñarles por qué es importante , no solo decirles qué hacer. No acepte las solicitudes de incorporación de cambios hasta que hayan realizado todos los cambios necesarios.

Si después de algunas rondas de esto siguen escribiendo un código deficiente y utilizando soluciones alternativas, puede ser una señal de incompetencia o insubordinación, que debe abordar adecuadamente. Con toda probabilidad, no están acostumbrados a escribir código en un nuevo estilo y necesitan algo de tiempo para adaptarse. Es su trabajo como supervisor ayudarlos a aprender y adaptarse, pero como dice el refrán, puede llevar a un caballo al agua, pero no puede obligarlo a beber.

Si se niegan a seguir las reglas que se les dan, es fácil. Déles una advertencia, en esa advertencia, indique que si reciben 2 advertencias, habrá consecuencias. El hecho de que estés a cargo de ellos, significa que si continúan haciéndolo, las consecuencias irán hacia ti.

Vaya a lo seguro, haga reglas escritas (por correo electrónico) sobre lo que TIENEN que hacer. Si no siguen estas reglas, repórtelo a su superior.

Además, asegúrate de hablar con él, puede haber algo mal. Escribir un código incorrecto podría deberse a que hay un problema en su espacio de trabajo/privado. Así que asegúrese de que eso no sea lo que hace que cometa un código incorrecto.

-1 Este es un enfoque de mano dura. Si yo fuera el administrador del OP, mi primera pregunta sería ¿funciona el código? Luego, esperaría que OP argumentara que el tiempo futuro de corrección de errores aumenta significativamente con la calidad del código actual, luego invertiría en capacitación para los desarrolladores junior. No hay nada para jugar seguro porque no hay nada para jugar. Este es un problema menor considerando todas las cosas
Si alguien más tendrá que hacerse cargo del proyecto con un código mal escrito, se necesitará MUCHO tiempo, esfuerzo y dinero para solucionar los problemas. No poder escribir código que cumpla con los requisitos significa que no está haciendo bien su trabajo. Hacer reglas asegura que los trabajadores tengan la oportunidad de mejorar las cosas y no empeorarlas para ellos y la empresa. @rath
@FlorianSchaetz En un mundo de ideas, sí, pero lamentablemente no vivimos allí. El código bien escrito a veces es un lujo. El código de trabajo mantiene las luces encendidas. Depende de nosotros encontrar el equilibrio. Detener una función o corregir un error porque sonarqube lo dijo no es aconsejable. Ninguna herramienta debe interponerse en el camino del negocio. YMMV se aplica a todo eso, por supuesto.
Escribir código limpio que cumpla con los estándares no es un privilegio, si sabe que su código no es lo suficientemente bueno, debe cambiar algo al respecto. Si los compañeros de trabajo se esfuerzan, es otra historia. OP mencionó que uno de los desarrolladores "encontró una forma de solucionar los límites de complejidad de la función". lo que significa que ponen más esfuerzo en solucionar el problema que en solucionarlo
No, lo siento, el bacalao bien escrito nunca es un lujo. El código mal escrito significa trabajar activamente hacia la catástrofe, porque tarde o temprano llegará a un punto en el que ya no podrá mantenerlo y en el que será imposible corregir los errores o agregar nuevas funciones sin romper las cosas existentes. No se trata de herramientas, sino de código limpio. Y a menos que tenga un software que no necesita mantener (dispara y olvida el software), el código incorrecto solo está tomando prestado tiempo de un futuro incierto.
@rath Realmente deberías estudiar ingeniería de software. Se sabe desde los años 80 que su enfoque conduce a un software menos mantenible, menos confiable y más costoso. Pierdes el dinero de la empresa escribiendo software basura. Ahora podemos discutir cuál es la definición de basura, pero el ejemplo de OP definitivamente califica.
@GabeSechan Estoy completamente de acuerdo contigo. A veces, comienzas con un código basura, y cualquier esfuerzo por ponerlo en forma terminará desperdiciando más tiempo del que puedes permitirte. Hay código zen y hay WTF-ery absoluto, y en algún lugar en el medio está la zona Goldilock de semi-mierda-pero-algo-funcional. Todos leen lo anterior y lo ubican en su contexto, yo trabajo con código heredado y me enfrento a ese dilema todos los días.
¿Cómo acercarse a los desarrolladores que trabajan en torno a los estándares de calidad del código?
RespuestasAquíPolítica de privacidad1y, 0v