Cómo garantizar el cumplimiento de los estándares de codificación

Para ser atendido, los estándares deben ser entendidos.

Tu dices eso

una lista de verificación[...]/las casillas de verificación [no son] ideales

porque

En los equipos anteriores, los estándares de codificación eran como una ética que el gerente de desarrollo de aplicaciones defendía, en la que el equipo creía y que se enseñaba a los nuevos desarrolladores cuando se incorporaban.

Lo que deduzco de esto es que su principal preocupación es que quiere que el equipo se preocupe por los estándares, no solo aceptarlos y defenderlos por el hecho de estar de acuerdo y defenderlos. (Corrígeme si estoy equivocado.)

Para hacer eso, su equipo debe comprender los estándares y por qué existen .

Considere las siguientes tres conversaciones.

1. "Mira a ambos lados antes de cruzar la calle". "¿Por qué?" "No lo sé, es solo lo que me han dicho ".
2. "Mira a ambos lados antes de cruzar la calle". "¿Por qué?" "Porque es la ley ".
3. "Mira a ambos lados antes de cruzar la calle". "¿Por qué?" "Porque si no lo hace, es más probable que lo atropelle un automóvil, lo que resultará en una muerte sangrienta o tal vez en lesiones graves, como una lesión en la columna que le impedirá volver a caminar".

Ahora considere las siguientes tres conversaciones:

1. "Nunca concatene cadenas a SQL". "¿Por qué?" "No lo sé, es solo lo que me ha dicho el DBA ".
2. "Nunca concatene cadenas a SQL". "¿Por qué?" "Porque está en la lista de control ".
3. "Nunca concatene cadenas a SQL". "¿Por qué?" "Porque si concatena una cadena que contiene la entrada del usuario a su SQL en lugar de parametrizarla correctamente, se expone a un ataque de inyección de SQL, que puede dar a los piratas informáticos mucho más acceso a nuestra base de datos de lo que queremos darles".
   • (Seguido, por supuesto, de "¿No significa eso que está bien concatenar cadenas constantes en SQL?" "Tienes razón. Actualicemos el estándar").

¿Ves las similitudes y diferencias allí?

Según mi experiencia, los estándares de codificación más efectivos son aquellos impulsados ​​directamente por los desarrolladores.

Un enfoque que he visto que funciona bien es tener una comunidad de práctica de desarrolladores que discuta los estándares de codificación y los acuerde por consenso.

Al introducir estándares de esta manera, los desarrolladores tienen la posibilidad de que tengan éxito. Si sienten que un estándar de codificación no es valioso, pueden plantearlo en la comunidad y discutirlo. Si el consenso es que el estándar no agrega valor, entonces puede descartarse.

En este caso, la solución más sencilla sería usar algunos linters para el código que produce, ya sea SQL u otro. Ver también:

• pelusa (software)
• Lista de herramientas para el análisis de código estático

Estas herramientas automatizarán algunas de las reglas, pero solo cubren la sintaxis. Todavía necesita que la gente se ponga de acuerdo sobre un estándar de calidad y luego se ciña a él porque es algo importante para ellos. Sin embargo, esto no es tan fácil de obtener como la verificación de sintaxis con herramientas.

Debe mencionar este tema en su próxima retrospectiva, averiguar qué sucedió y ponerse de acuerdo sobre lo que podría hacer a continuación. Sin embargo, trate de mantener las cosas simples.

Vuelva a revisar el tema si las cosas vuelven a suceder y recuérdeles a todos que fue una decisión que tomaron juntos y acordaron implementar porque era importante. Si las cosas continúan sucediendo, eso puede ser una señal de que solo estuvieron de acuerdo con los estándares de codificación en palabras y en realidad no lo respaldan con sus acciones.

Ninguna cantidad de herramientas, estándares o procesos garantizará que se sigan los estándares si las personas no consideran que el cumplimiento de los estándares de codificación sea valioso y la forma normal de trabajar.

Como escribió, es probable que sea una combinación de educación y tarea de proceso.
El estándar de codificación debe entenderse, digerirse y practicarse antes de que se convierta en un hábito y en parte de la ética profesional.

Encuentro que las Definiciones de Listo son muy útiles para educar a los equipos y lograr que estos hábitos se integren en la forma normal de trabajar.

Puede agregar una lista de verificación dedicada en el DoD y, a medida que pasa el tiempo y los equipos mejoran, puede eliminarse o hacerse más sofisticada.
Si también usa Confluence, es muy fácil vincular una página de Confluence que contiene la lista de verificación asociada a un DoD, a un elemento de Jira. También puede hacer que la historia de Jira se pueda cambiar solo si se ha completado la lista de verificación.

En el último sprint, hubo algunos estándares que el desarrollador pasó por alto y también el revisor.

¿Por qué se perdió? ¿Fue por falta de tiempo o por falta de intención?

Si se debe a la falta de tiempo, entonces, cuando planifique el próximo sprint, el equipo de desarrollo debe dejar de lado las estimaciones para asegurarse de verificar que el código que desarrollan cumpla con el estándar de codificación. Puede intentar aplicar la programación en pares aquí, donde otro desarrollador puede asegurarse de que los estándares de codificación estén en su lugar cuando el primer desarrollador termine su trabajo de desarrollo.

Si se debe a la falta de intenciones del equipo de desarrollo, entonces, como se menciona en otras publicaciones de respuesta, realice una discusión honesta y sincera durante la retrospectiva sobre la necesidad real de adherirse al estándar de codificación.

Si el equipo de desarrollo está completamente de acuerdo en que se deben seguir los estándares de codificación, entonces una opción más podría ser incluir la adhesión al estándar de codificación como parte de los criterios de aceptación de la historia de usuario. De esa forma, el equipo de desarrollo sabrá que la historia del usuario no se puede marcar como "terminada" a menos que se adhiera e implemente el código según el estándar de codificación acordado.

Esto es lo que haría a continuación: "llévales tus preocupaciones ". Alértelos sobre el hecho de que usted percibe que los estándares no se cumplen "correctamente" y "pregúnteles por qué". Escuche con mucha atención lo que dicen.

Los problemas y preocupaciones técnicas, particularmente con SQL, ya se han presentado en este hilo y son válidos. Pero, el propio equipo también debe conocerlos a fondo. "Plantee la preocupación de que 'está preocupado'", luego escuche lo que sucede a continuación y use esto para informar su próximo movimiento. Si lo desea, vuelva a plantear sus hallazgos a esta comunidad para recibir más comentarios. (El objetivo es no sopesar su respuesta en sus "méritos" técnicos, sino considerar más a fondo cómo manejarla).

La gestión de proyectos normalmente incluye un plan de gestión de la calidad ; tener estándares de codificación es uno de los pasos, pero debe planificar una forma de revisión y aceptación de la calidad.

Algunos equipos dividen la función de aceptación de calidad en un equipo separado.

Los equipos Scrum (según yo los entiendo) aceptan la responsabilidad de entregar un producto de calidad aceptable como parte de su autoorganización.

Por supuesto, las otras respuestas señalan una suposición no declarada: la calidad debe estar conectada a algo. La gestión de calidad se trata de evitar la repetición del trabajo: la mayoría de los desarrolladores quieren evitar la repetición del trabajo. Las otras respuestas son excelentes para explicar cómo contextualizar la calidad.

Si el problema fundamental es que a los desarrolladores no les importa, entonces este no es un problema de calidad, este es un caso de desarrolladores a los que no les importa, y no puedes resolver eso sin importar cuánto inviertas en calidad.