Cómo persuadir a los programadores para que sigan las reglas básicas

Hay varias reglas que debo seguir pidiendo a los programadores que sigan con mucha frecuencia. Escriben código y, si funciona, el trabajo acaba de hacerse, para ellos. Las reglas más básicas pueden ser:

• Comprometer cambios
• No escribir problemas de modelo en View o Controllers
• Evitar la codificación rígida

¿Puedes contarme sobre tu experiencia? ¿Como manejas esto?

Todos los trabajadores del conocimiento deben ser desafiados a hacer un trabajo de calidad. La calidad se verá afectada si sienten que se les imponen limitaciones de tiempo arbitrarias. ¿Por qué no simplemente hacer cosas que son "lo suficientemente buenas" cuando todos se preocupan por cumplir con las especificaciones y cumplir con los plazos?

Su lista de quejas son síntomas de una empresa que solo premia el cumplimiento de objetivos a corto plazo y no desea enfatizar la alta calidad. ¿Tienes un hotel de cinco estrellas o una parada de camiones?

Para poder seguir las reglas básicas, necesitan saber cuáles son las reglas y deben estar de acuerdo con ellas.

La forma de manejar esto es crear conjuntamente un documento de guía de codificación con el que todos puedan estar de acuerdo. No intentes forzar esto sobre ellos, será contraproducente si lo haces.

¡Así que reúna al equipo y comience a trabajar en una definición común de sus reglas básicas!

Hazlo como un taller donde se escuchen todas las voces. Timebox it para evitar discusiones interminables. Estás tratando de unir varias mentes, por lo que es posible que desees preparar el escenario con una nota positiva de que todos deben ser respetuosos y tener una mente abierta (la escritura de códigos es personal ...).

Estas pautas deben cambiarse cada vez que el equipo sienta que hay algo que debe agregarse o aclararse.

¿Cual es tu papel? Si no es más que otro desarrollador con un interés particularmente fuerte en la calidad del código, probablemente no tenga la autoridad para hacer que lo escuchen, y tal vez debería enviar estas ideas a la gerencia para establecer estándares de código que deberían / ​​deben ser seguido. Si usted es gerente / jefe de equipo / arquitecto, y tiene alguna autoridad, puede establecer esas prácticas usted mismo. Establezca un documento de estándares y un proceso de revisión de código para eliminar estas cosas.

No va a ser un interruptor mágico que puedas activar; Será un proceso lento y nunca será del 100%. Esa ha sido mi experiencia de todos modos.

Tiene que ser una combinación sensata de todas las respuestas hasta ahora. Al final, cuando se habla de un grupo de personas inteligentes (desarrolladores), debe darles las razones por las cuales el comportamiento es importante y darles el control suficiente sobre cómo se implementa ese comportamiento que se invierte en hacerlo bien. Por lo general, los mandatos de arriba son flojos con las personas inteligentes, porque si no han acordado que el problema es un problema, es probable que pasen más tiempo trabajando en el mandato que siguiendo la regla.

Estas son algunas de mis tácticas:

Cometer cambios:

Primero, el equipo necesita acordar cuándo comprometerse y qué comprometerse. Absolutamente esencial es una configuración de compilación que tenga sentido, para que las personas no se detengan solo porque no saben dónde poner algo. Y un consenso sobre cuándo / con qué frecuencia registrarse. "No rompa la compilación" es una buena regla obvia, pero ¿cómo se verifica eso y a quién se le informa al respecto? Otra línea de base es "no se hace si no se registra".

La mayoría de los desarrolladores que conozco están más que felices de verificar el código IF:

• El proceso de registro es fácil
• El proceso de sincronización es fácil (teniendo en cuenta los cambios de otros desarrolladores)
• Ver cambios y moverse entre versiones es fácil

Una cosa que noté recientemente fue que los registros se hicieron más frecuentes y menos dolorosos cuando avanzamos hacia una nueva herramienta CM. Nuestro equipo es pionero en Rational Team Concert que anteriormente usaba Clearcase. No me refiero a anunciar herramientas, pero la nueva ola (para mí) de registros de transmisión con muchas fusiones pequeñas y rápidas hace que sea mucho más atractivo registrarse temprano y con frecuencia.

Dejar que los desarrolladores se encarguen de eliminar el dolor de CM generalmente aumenta la cantidad de registro que ocurre.

Adherirse a la arquitectura: no escribir problemas de modelo en vistas y controladores

Estoy poniendo eso en el grupo general de "hacer la arquitectura correctamente". Estoy de acuerdo con quien dijo que las revisiones de pares: la presión de grupo es genial para esto. Una de las formas en que generalmente veo a las personas entrar en el redil por las mejores prácticas en esta área es cuando sus compañeros les preguntan por qué lo hicieron de la otra manera (de la manera no tan correcta). En general, la pregunta "por qué" llevará a las personas por el camino de darse cuenta de por qué deberían haberlo hecho de manera diferente. Cuando las personas tienen una razón bien entendida para la mejor práctica, es mucho más fácil adherirse a ella.

Además, si hay alguna formalidad que vincule a una persona con una decisión, entonces puede ser más fácil asignar errores en esa área ... así que si una persona es responsable de corregir errores en un área de diseño defectuoso, la necesidad de obtener algo justo antes pueden pasar a algo nuevo y emocionante puede ser un gran motivador.

Evite la codificación dura

Comenzaría con estándares de codificación claros e integrando una revisión estándar de codificación en revisiones por pares. La codificación rígida es una de esas cosas que fácilmente puede ser una casilla de verificación en una agenda de revisión por pares.

Me temo que este tipo de cosas es lo único que he visto convertirse en el papel del líder del equipo para hacer cumplir la regla. En los equipos que he corrido, generalmente no permitiremos que alguien siga adelante hasta que hayan corregido los comentarios de una revisión por pares de su código. Y "sin codificación rígida" es un comentario frecuente de revisión por pares.

En general

Con casi cualquier práctica recomendada, creo que debes elegir tus batallas. Ningún equipo se volverá absolutamente perfecto. Pero puede vigilar sus principales puntos de dolor y comenzar a abordarlos en grupos. Creo que se convierte en el papel del líder saber realmente qué es un punto doloroso para el equipo frente a una peculiaridad molesta de un individuo en particular.

Si su equipo se está perdiendo hacer una mejor práctica en particular, creo que la primera pregunta debe ser "¿cuánto daño está causando esto?" Si la respuesta es "mínima", entonces probablemente no valga la pena. Algunas de las mejores prácticas son más relevantes para tipos específicos de sistemas; si bien en general son buenas, puede que no valga la pena luchar por sistemas donde la práctica no es una ocurrencia frecuente o una parte importante del sistema.

Si la respuesta a "cuánto damange?" es "¡MUCHO!", entonces puede comenzar a construir un caso para mostrarle al equipo que todo este dolor y sufrimiento podrían eliminarse arreglando este punto flojo en las mejores prácticas. La mayoría de las personas están felices de evitar el dolor y el sufrimiento y cambia el diálogo de "haz esto porque te lo dije", a "decidimos hacer esto porque es mejor".

Revisión de código. Acepte solo código bien escrito que no tenga errores.

Al menos :

• Facilíteles el seguir líneas de código (Herramientas como resharper, StyleCop) Si es fácil, es más probable que lo adopten.

Además de eso, elija qué funciona según su organización, los desarrolladores y su rol dentro del equipo.

• Permítales corregir errores y solicitar cambios regularmente
• Programa en pareja con un desarrollador experimentado
• Revisiones de código de manera constructiva
• Tutoriales de código
• Comience a entrenar, use libros como Code Complete y The pragmatic programmer.

Mi rol es Gerente, pero como equipo pequeño desarrollo y prefiero dirigirme como entrenador.

Ya se han señalado los electrodos en la silla conectados a un analizador de códigos, pero los programadores no parecen tener miedo. Disparar no suena como un buen enfoque, ya que eso significa perder activos dignos.

Echaré un vistazo a todas esas herramientas y permaneceré abierto a cualquier otra que me digas.

Hay 3 formas de abordar este problema:

1. Análisis estático del código fuente para verificar problemas con la convención de codificación. Use herramientas como cppcheck y las de grammatech . Wikipedia tiene una buena lista: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis . Por lo general, la mayoría de los sistemas de control de origen tendrán enlaces mediante los cuales puede verificar dichos problemas directamente durante el check-in. Para los ganchos CVS busque en este enlace: http://goo.gl/F1gd2 . El incumplimiento significa un check-in fallido, y más de 3 fallas significan que el desarrollador tiene que explicarse al equipo.

2. Durante el proceso de codificación, se señalan los problemas al desarrollador. Tener secuencias de comandos personalizadas que estén integradas con el IDE de su elección es una forma genial de hacerlo. Mira este enlace: http://goo.gl/MM6c4

3. Siga los procesos ágiles y asegúrese de que la revisión del código sea parte del sprint

Aquí está mi plan de 3 pasos:

1. Despedir a los programadores
2. Contrata algunos ingenieros de software
3. ...
4. ¡Lucro!

:RE

Con toda seriedad, si no creen en hacer nada más que escribir código, se necesita un equipo más completo. Un programador donde trabajé utilizaba diferentes directorios en la computadora como su CM. Luchamos con su programador durante casi un año (ya que los cambios introducirían errores al copiar y pegar el código antiguo). Finalmente los despedimos.

1. Indíqueles cuando violen las reglas básicas.
2. Espere a que produzcan errores que simplemente no pueden rastrear o que se enfrenten a solicitudes de características que simplemente no pueden implementar debido a su código inflexible.
3. Recuérdeles lo que había dicho antes.
4. Déjalos ahogarse en su propia mierda por un tiempo.
5. Tómese el tiempo para refactorizar el código en cuestión, aislar los errores / proporcionar infraestructura de seguridad para conectar una nueva funcionalidad. Tómate un tiempo para explicar lo que hiciste.

Alternativamente, lo más cruel pero muy persuasivo es dejarles mantener una base de código extremadamente pobremente escrita, dada una agenda apretada. : D
Y luego, para variar, permítales mantener una base de código bien escrita, dada una agenda apretada.

En general, la falta de voluntad para adaptar ciertos estándares significa una falta de experiencia en el trabajo en equipo.

Al final, la gente solo aprende de los errores. NUNCA repare los problemas que se basan en la terquedad de otra persona. Si es realmente vital para el proyecto (es decir, su empresa será demandada si no realiza la entrega dentro de N días), entonces retírelos del proyecto primero.

Creo que su programador no cambiará su actitud hacia estos temas que ha mencionado hasta que se den cuenta de que esas cosas los beneficiarán o beneficiarán. Intenta explicarles por qué quieres que hagan estas cosas. Aún mejor, déjelos experimentar las ventajas.

Contrata a un ingeniero de software profesional. Y luego fuego más débil. Luego, lentamente reemplace a los que no pueden adoptar. Tener tales personas a veces trae más daño que ganancias a largo plazo.

La idea principal aquí es que el profesional comenzará a hacer la mayoría del trabajo, y despedir a otros no reducirá el valioso recurso humano.

Es un poco asqueroso, pero dejé Code Complete en el baño durante unos meses. No estoy seguro de que fuera efectivo, pero parecía una buena idea en ese momento.

Entonces, ¿cuáles son las consecuencias por no seguir las reglas y recompensas por seguir las reglas? Si la respuesta es la misma, nada, buena suerte para conseguir alguna tracción. Sugiero un enfoque escalonado. Primero reúnalos y discuta si están de acuerdo con las reglas. El siguiente paso es incluirlos en las revisiones de código. También puedes probar zanahorias y palitos. Algo así como cualquiera que deja un archivo desprotegido durante la noche tiene que traer donas a la próxima reunión semanal. Una zanahoria podría ser cualquiera que siga las reglas durante todo un mes y reciba un fin de semana en Las Vegas. Para dos.

O despedir al peor delincuente y dejar que el resto se preocupe.

Hacen sufrir las Consecuencias que desea evitar mediante el uso de esas reglas, es la única forma en que realmente se va a entender por qué está haciendo, por ejemplo: hacer un pequeño desorden controlado que se tienen que correcto.

Si este equipo realmente tiene problemas para verificar los cambios, cumplir con la separación de las preocupaciones y no codificar constantemente las constantes mágicas, entonces despediría a todo el equipo y los reemplazaría con programadores reales ¹ que realmente se preocupan por su oficio lo antes posible. Sé ese uno a la vez o en masa no podría decir, pero estos bromistas tienen que irse.

El tipo de codificación que está describiendo es adecuado para scripts desechables de un solo uso. No es cómo se construye una aplicación real. Si se les paga como programadores profesionales, entonces es su trabajo saber este tipo de cosas.

¹ Esto se usa a menudo como un término de broma para personas imaginarias que escriben su código directamente en binario o algo igualmente ridículo. Aquí no estoy bromeando. Soy un programador bastante novato y no necesitaría que me contaran estas cosas porque me importa mi oficio. Estos no son programadores reales con los que estás tratando

El trabajo de un gerente no es ser el amigo del empleado, a veces tienes que ser el malo. Hacer cumplir los estándares de codificación y los compromisos, la negativa a seguir la arquitectura proscrita, la falta de uso de herramientas prescritas, etc. son los momentos en los que debe ser impopular.

Exprese las políticas claramente. Realice revisiones formales del código y verifique si se siguen las políticas. No les permita pasar a otra tarea hasta que se hayan resuelto todos los problemas de la revisión del código.

Si la política se refiere a no comprometer el código, esto requiere una advertencia por escrito si no pueden hacerlo cuando se les pide que lo hagan. Si no están cometiendo código, en lo que a usted respecta, no han escrito ninguno.

Si no mejoran después de tener una oportunidad razonable de mejorar, despídalos. Los desarrolladores no profesionales son un lastre para su equipo, sin importar qué tipo de código escriban. Están afectando a otros con su falta de profesionalismo y no debe tolerarse. No son buenas personas para retener en ningún caso. Los buenos desarrolladores comprometen su código, los buenos desarrolladores siguen las decisiones arquitectónicas incluso si no están de acuerdo con ellos y los buenos desarrolladores no codifican. No te perderás nada excepto dolores de cabeza al deshacerte de los codificadores de vaqueros.