Reducción de los estándares de codificación 'duración del lavado de cerebro' y esfuerzo de las nuevas contrataciones

Question

En mi trabajo actual, somos bastante estrictos con respecto a la calidad del código y los estándares de codificación. Todas las nuevas contrataciones pasan por un período de "lavado de cerebro" en el que los desarrolladores senior los instruyen para escribir (con suerte) un mejor código.

El proceso de revisión del código es meticuloso y normalmente reduce a la mitad la productividad de los desarrolladores que realizan la revisión. Y a veces el período de "lavado de cerebro" se prolonga durante 2 o 3 meses. A veces, las correcciones son sutiles (por ejemplo, estructurar una instrucción IF de manera que cortocircuite lo más temprano posible) y, a veces, no puedes evitar levantar una ceja (por ejemplo, declarar una cuerda y configurarla en String.Empty y en la siguiente línea) asignarle otro valor).

Estoy buscando sugerencias para reducir el tiempo y el esfuerzo para obtener nuevas contrataciones asimiladas a los estándares de codificación del equipo.

¿Qué están haciendo otros en circunstancias similares? ¿Qué procesos o herramientas utilizan ustedes? Hay alguna manera de automatizar esto? He considerado FxCop pero en realidad no lo he probado y no sé si realmente ayudaría a reducir el tiempo y el esfuerzo o si es la herramienta adecuada. Por razones logísticas, no podemos hacer programación de pares si eso fue una sugerencia. Y dudaría sobre eso, reduciendo el esfuerzo.

Hemos intentado mantener una wiki interna de 'correcciones', pero eso está fallando tristemente. La falta de cumplimiento y también porque es más fácil "hacer que alguien corrija sus errores" en lugar de "leer y tratar de evitar los errores".

Además, ¿cómo están ustedes metiéndolo en nuevas contrataciones que la calidad del código es importante? ¿Y ustedes eliminan a los que son lacónicos hacia la calidad en la entrevista o intentan cambiarlos después de que son contratados?

Muchas gracias.

EDIT: Gracias por todas las respuestas. No estoy seguro de si hay una respuesta correcta para esta pregunta, pero voy a marcar como correcta la que definitivamente voy a probar.

Answer 1

Dedica algo de tiempo a escribir una aplicación que demuestre todos tus principios de código óptimo. La fuente de esto se puede convertir en un manual sobre "Qué apuntar". La gente hace mucho mejor para lograr un objetivo con objetivos concretos en lugar de ser continuamente penalizado por golpear "anti-objetivos". También lleva menos tiempo orientar a las personas en la dirección correcta que describir la dirección correcta en términos de todas las que están equivocadas.

Su proyecto de cebador de código óptimo también se puede suboptimizar deliberadamente con errores comunes y construcción algorítmica pobre. Las notas sobre la diferencia entre las dos se pueden insertar en la cartilla con hechos concretos sobre cómo se puede demostrar que no es óptimo en comparación con la otra.

No solo los principiantes pueden beneficiarse de tal artefacto, yo mismo estoy bastante aislado en mi trabajo y confío en las comunidades de codificación en línea para la mayor parte de mi desarrollo profesional. Serán de mucho interés para mí algunos ejemplos claros de mejores prácticas en los que todos puedan estar de acuerdo.

Answer 2

No estoy seguro de si tiene algunas de estas en su lugar, pero podrían ser útiles.

• periodo de formación para los nuevos empleados - donde orientarse en cualquier cosa y todo lo relacionado con su empresa, incluyendo una parte de las normas del código.
• Multas por no seguir los estándares de código - si tiene un "bote de violación de código estándar" donde pagan una multa por no seguir las normas, o tienen que tratarlo por cada 10 violaciones. Por supuesto, la motivación negativa no siempre funciona
• Elimina sus confirmaciones que no siguen los estándares - no estoy seguro si todos los sistemas de control de fuente lo permiten, pero si un codificador comete un código no conforme, entonces eso significa que tiene que ir. No hay excusas.

En última instancia, creo que el entrenamiento es todo lo que necesita, sin embargo, las otras dos sugerencias tienden a rozar el fascismo, lo admito.

Answer 3

Si usted es tan estricto con sus estándares de codificación y está haciendo todo este trabajo manualmente, podría ahorrar mucho tiempo al emplear varias herramientas automatizadas. Harán que la vida de tus desarrolladores senior sea mucho más fácil (supongo que la usas).NET como usted ha mencionado FxCop):

1. En el lado del cliente - se puede usar cosas como ReSharper R# con la funcionalidad de las plantillas para asegurarse de que el código cumple con las directrices de su
2. En el lado del servidor - que necesita para configurar una Sistema de Integración Continua e integrar herramientas como FxCop en él. Usamos FxCop y lo complementamos con un producto de nuestra compañía llamado PBA que permite la misma funcionalidad.

Answer 4

tal vez no es realmente relacionado con lo que usted pidió, pero sólo quiero compartir con ustedes:

Una vez mi maestro algoritmo vio que alguien lleva una escritura de la camiseta en él: "No hay error, buen programador! " Luego dijo "No lo creo. Debes tener errores para ser un buen programador". -Fue un punto interesante.

Entonces, ¿por qué no enseña a escribir errores? Estoy hablando de usar una forma inversa para hacer que la gente sea un buen programador.

Answer 5

1. hacer un entrenamiento de las normas del código y tener un documento de referencia
   • uso de una herramienta de verificación estilo de código - incluso tratar algunos errores de estilo como errores de generación
   • hacer revisiones de código en compromete
   • sistemas de control Fuente permitir el establecimiento de ganchos y colas de commit, por lo que ningún código incorrecto va al árbol principal
   • Un correo electrónico de 'lecciones aprendidas' y 'consejos de estilo' enviado a todos de vez en cuando no estaría de más. A veces el "por qué" de algunas pautas no es obvio para todos y por lo tanto es difícil aplicarlo, por lo que dicho correo puede incluso desencadenar una discusión de almuerzo/café de la que todos puedan aprender.

Answer 6

no creo que se puede reducir la duración del período de aprendizaje, pero se puede reducir la cantidad de trabajo necesario un-causado durante ella por tener las revisiones de código más frecuentes de lo que sería de más experiencia desarrolladores.

Comience por darles algunos errores a los nuevos iniciadores y repase cada una de sus correcciones tal como lo han hecho. Un beneficio adicional de comenzar con la reparación de errores debería ser que estarán expuestos a su código existente, el cual espera que cumpla con sus estándares (lamentablemente una proporción demasiado alta no lo hace).