¿Cómo lidiar con diferentes estilos de programación en un equipo?

Tenemos un pequeño equipo de desarrollo (solo 3 desarrolladores) y recientemente obtuvimos un nuevo miembro del equipo. Si bien es un codificador inteligente, su estilo de codificación es completamente diferente al nuestro. Nuestra base de código existente contiene código mayormente legible, limpio y mantenible, pero el nuevo miembro del equipo está cambiando rápidamente muchos archivos, introduciendo hacks y accesos directos feos, usando definiciones en todo el lugar, agregando funciones en los lugares equivocados, etc.

Mi pregunta es si otros han experimentado tal situación antes, y si alguien tiene consejos sobre cómo hablar con él.

Trabajo con un equipo que creció de 2 desarrolladores a 10 en menos de un año. Era el número 3 y el primero en plantear un problema de estándares de codificación. Los dos desarrolladores originales habían estado trabajando codo a codo durante algunos años y habían adoptado un estándar común que me parecía extraño. Tuvimos exactamente los mismos problemas que está describiendo.

Lo que hicimos fue:

Estándares de codificación de investigación

Pasamos unos días revisando proyectos de código abierto establecidos. Sabíamos que el equipo se expandiría rápidamente y estábamos buscando soluciones reales basadas en proyectos reales, no en algunas pautas genéricas. Tampoco nos interesaban los estándares de codificación óptimos, sino un conjunto de reglas y pautas que tendrían sentido y no exigirían la refactorización de toda nuestra base de código. Estábamos buscando un hack de estándares de codificación, por así decirlo.

Los tres decidimos que los mejores estándares de codificación para un proyecto PHP establecido eran los seguidos por Zend Framework. Afortunadamente, la gente de Zend Framework proporciona un documento de estándares de codificación muy completo .

Creando nuestros propios estándares de codificación

Por supuesto, la aplicación de los estándares de codificación de otro proyecto en nuestro proyecto no tiene sentido. Usamos el documento de Zend Framework como plantilla:

• Primero eliminamos todo lo que no se aplicaba a nuestro proyecto.
• Luego cambiamos todo lo que percibimos como una cuestión de estilo a nuestro estilo
• Y finalmente escribimos todo

Así que teníamos un documento bastante grande en nuestras manos, almacenado en nuestra elegante wiki , era una buena lectura, acordada por todos nosotros. Y completamente inútil por sí solo.

Mantenerse fiel a nuestra promesa

Nuestra base de código en ese momento era aproximadamente 1 * 10 ^ 6 sloc. Sabíamos que desde que adoptamos los estándares formales de codificación teníamos que comenzar a refactorizar nuestro código, pero en ese momento tuvimos problemas con otros problemas. Así que decidimos refactorizar nuestras bibliotecas centrales, un mero 5 * 10 ^ 3 sloc.

Asignamos a uno de nosotros para que sea el maestro de estándares de codificación (utilizamos malas palabras locales en lugar del maestro ) con la responsabilidad de verificar y hacer cumplir los estándares. Reciclamos el papel cada pocos sprints. Fui el primero, y fue mucho trabajo, ya que tuve que monitorear casi todos los commits.

Tuvimos varias discusiones nuevas y pequeñas adiciones al documento original durante mi mandato, y finalmente tuvimos un documento algo estable. Lo cambiamos de vez en cuando, pero la mayoría de estos cambios están en las nuevas características del lenguaje, ya que PHP 5.3 fue una versión importante en todo menos en el nombre.

Tratando con el chico nuevo

Cuando llegó el nuevo chico nuevo, era hora de poner a prueba nuestros estándares de codificación. Después de una pequeña introducción a nuestra base de código, le pedimos que evalúe nuestro documento de estándares de codificación. Casi lloró. Parecía que hacía todo de manera diferente.

Como era el maestro de estándares de codificación en ese momento, dependía de mí evaluar su aporte y revisar el documento en consecuencia. Sus propuestas fueron:

• Asuntos de estilo personal (desestimados sumariamente)
• Estándares que tenían sentido para su experiencia en Java pero no tanto con PHP (descartado)
• Convenciones que llevó de su breve exposición con PHP (algunas fueron descartadas, pero muchas resultaron ser convenciones populares que nunca pensamos o descubrimos en nuestra investigación inicial)

Durante las siguientes dos semanas se le asignó una tarea simple: actualizar varias partes de nuestra base de código con los estándares. Tuve que elegir cuidadosamente esas partes en función de algunas reglas:

• El código debería ser relativamente fácil para alguien que no esté familiarizado con nuestra base de código (y PHP en general)
• El código debe estar en lo que fue contratado para hacer

Supervisé su proceso e hizo un buen trabajo. Identificamos varias partes del código que era imposible ajustar a nuestro documento y lo revisamos en consecuencia (código y / o estándares, lo que tenga más sentido)

Y luego llegó otro chico nuevo. Repetimos el proceso (maestro diferente esta vez), y funcionó nuevamente. Y otra vez.

En conclusión

1. Cree un documento de estándares de codificación, pero asegúrese de que sus estándares no sean exclusivamente suyos sino que reflejen estándares comunes en la comunidad más amplia de su plataforma.
2. Asigne un papel similar a nuestro maestro de estándares de codificación. Alguien para monitorear al menos el nuevo código, y especialmente el nuevo código de los nuevos miembros. Recicla el papel, ya que es extremadamente aburrido.
3. Siempre evalúe las aportaciones de un nuevo miembro. Siempre revise sus estándares si tiene sentido. Su documento de estándares de codificación debería estar evolucionando, pero lentamente. No desea refactorizar su base de código en cada iteración.
4. Permita un tiempo para que cada nuevo miembro aprenda y se adapte a sus estándares y convenciones. Aprender haciendo funciona mejor en estas situaciones.
5. Wiki hace maravillas para tales documentos.
6. ¡Las revisiones de código hacen maravillas para cualquier situación!

En algún momento del proceso, se sugirió que usáramos un enlace previo a la confirmación para automatizar la verificación de los estándares. Decidimos no hacerlo por varias razones, hay algunas discusiones interesantes sobre StackOverflow sobre el tema:

• SVN formato de código automático al registrarse?
• Control de versiones y formato de codificación
• PHP codesniffer (phpcs): ¿cómo permitir la anulación cuando se usa como parte de un enlace de pre-compromiso svn?
• El gancho de confirmación previa de SVN se activará para una carpeta particular
• Implementación de estándares de codificación PHP

Algunos son específicos de PHP, pero las respuestas se aplican a todas las plataformas.

Sí, lo he experimentado antes. Cuando se trabaja en un equipo, los miembros del equipo deben acordar ciertas reglas y convenciones, y eso incluye el estilo.

Debe hacer que su equipo se siente junto y redacte un conjunto de reglas, normas de codificación , a las que deberá cumplir cada parte del código verificado.

Lo más probable es que la base para su conjunto de reglas, al menos el estilo, sea el código existente. Una vez hecho esto, todos deben cumplir y debe inspeccionarse como parte de la revisión del código . No debe permitirse el ingreso de código que no cumpla con los estándares.

No tiene que ser un voto democrático, por cierto, es una de las cosas donde el líder del equipo puede ejecutar cierta autoridad. Pero dicho esto, no creo que pueda imponer estándares que la mayoría del equipo rechaza. Usted puede imponer normas que una sola persona, especialmente una nueva, rechaza.

En cuanto a cómo hablar con él ... Todo programador experimentado sabe que cada lugar y equipo tiene sus propias convenciones y estilo, que deben seguirse. Puede decirle que es más que bienvenido para sugerir mejoras, pero tiene que cumplir con las reglas que tiene el equipo, y no debe cambiar el estilo del código existente, sino usar el mismo estilo al agregar código nuevo.

Además, puede decirle (si usted es el gerente, o hablar con su gerente al respecto) a esa persona para que no haga ciertas cosas que considere inapropiadas (usted mencionó definiciones, orden, pirateo y atajos, etc.).

1. Alguien está a cargo, deben actuar así.
2. Si el estilo de codificación es tan importante, ¿por qué no se le explicó esto a esta persona y le hizo saber que no tendrá acceso a ningún código hasta que aprenda las reglas?
3. Revisión de código: aparentemente no tiene ninguno o es muy débil. Ver # 1.

Tome nota en su proceso de contratación, que seguir los estilos de codificación aceptados es un requisito para el empleo. ¿Qué les haces a los que no siguen las reglas? Comience por eliminar su acceso al código en vivo hasta que lleguen al programa.

.

Esto es lo que se puede hacer:

1. Escriba un documento que explique el estilo de codificación requerido y haga que todos en el equipo lo aprendan. Recopila información de cada miembro del equipo.
2. divida las tareas de tal manera que cada miembro del equipo sea responsable de su propia pieza y pueda decidir las convenciones de esa parte del código. Si se encuentra algún problema, quien lo escribió lo solucionará.
3. agregue una herramienta automática al control de versiones que corrige la sangría y otras cosas cada vez que el código se confirma en el control de versiones
4. Los diferentes programadores siempre tienen un estilo de programación diferente, y luego puede ser difícil cambiar. La mejor manera de manejarlo es compartir información entre los miembros del equipo para que todos aprendan qué estilos han usado las personas. Si tiene un miembro del equipo que escribe un código diferente, es una oportunidad para que los miembros de su equipo actual aprendan el nuevo estilo.
5. Un buen truco es nunca modificar el código existente. En lugar de modificar el código, escriba un nuevo código reemplazando las líneas vacías con un nuevo código. Y una vez que el código esté listo, realice solo la menor cantidad de modificaciones al sistema existente para que el nuevo código se use. Esto evita ajustar el código existente, posiblemente rompiendo lo que ya funcionaba bien.

Esto es lo que debe evitar:

1. decidir que el código de alguien es mejor o peor que otros miembros del equipo. Simplemente no funciona así: todos conocen cierto subconjunto del lenguaje lo suficientemente bien como para usarlo en el código. Cada programador ha elegido un subconjunto diferente para aprender, y a menos que lo hayan aprendido juntos, se verá diferente.
2. Cambiar cómo alguien escribe el código. Todo lo que obtienes al obligar a las personas a escribir un estilo desconocido es que obtienes una gran cantidad de errores en el código. Las personas simplemente no conocen suficientes detalles de algo que usan la primera vez. Los programadores siempre eligen un subconjunto de lenguaje y lo usan solo. Si sus programadores han escrito miles de líneas de código que están llenas de gotos, entonces los gotos le darán un código que tiene la menor cantidad de errores.
3. Tampoco debería pensar que su base de código existente es agradable, limpia y fácil de mantener. Siempre hay cosas para mejorar. Pero también cada cambio desdibuja la idea de diseño original que se le escribió. Apunte a escribir un código perfecto la primera vez, para que los cambios no se necesiten más tarde. (el nuevo chico no necesitaría "romper" su código perfecto, si se hizo correctamente la primera vez)

Nuestra base de código existente contiene código mayormente legible, limpio y mantenible

Una cosa que he aprendido a lo largo de los años es que la legibilidad está en el ojo del espectador. He visto muchos casos en los que se justifica que el estilo de codificación de arañazos de pollos sea "legible", y he visto a personas perfectamente razonables discutir sobre qué estilos de codificación son los más "legibles". ¿Quizás este chico no ve tu estilo como legible?

Dicho esto, el chico nuevo debe ajustarse a tus estándares, no al revés.

Considere usar solicitudes de extracción para código nuevo en el repositorio. Esto le da un lugar conveniente para hacer la revisión del código. El código que falla la revisión del código no se fusiona en el repositorio hasta que esté listo.

Solo tenga cuidado de no hacer que las solicitudes de extracción sean demasiado grandes. En mi experiencia, no deberían ser más grandes que entre medio día y un máximo de dos días o tendrás demasiados conflictos de fusión.

Los sistemas vcs en línea como bitbucket o github admiten esta funcionalidad. Si prefiere un alijo de aproximación local, parece ser la mejor apuesta actualmente.

Hay una regla simple que puede seguir: si modifica un archivo con código, utiliza el estándar de codificación utilizado en ese archivo. Si crea un nuevo archivo, utiliza cualquier buen estándar de codificación. (Además: si su compilador puede dar advertencias, habilite todas las advertencias razonables, active advertencias = error si es posible y no permita ningún código con advertencias. Además: si usa herramientas que realizan cambios al por mayor en un archivo, como cambiar pestañas a espacios o similares, NO los use).

La razón por la cual hay grandes argumentos sobre los estándares de codificación es que un estándar no es mejor o peor que otro (generalmente) sino simplemente diferente. Lo único realmente malo es mezclar estilos de codificación.

Obviamente, espero que cualquier programador decente pueda escribir código siguiendo cualquier estándar de codificación, ya sea que prefiera ese estándar en particular o no.

Y por otro lado, hay estándares de calidad. Nunca acepte códigos que no cumplan con sus estándares de calidad.