Sobre ser un "policía malo"

Como se mencionó anteriormente, el camino a seguir es separarse usted mismo o cualquier otra persona de los temas que se plantearán. Esto significa:

• Sus reglas deben ser claras y escritas, ya sea en un wiki, una guía de estilo, documentos de la empresa, lo que sea que esté usando. Este material debe ser accesible para el desarrollador en cuestión.
• Cuando señale errores en una revisión, no use frases que lo involucren de alguna manera. En cambio, culpe a sus documentos, como la guía de estilo, y a sus procesos en general. Un ejemplo de esto puede ser, "Línea X: De acuerdo con la guía de estilo [enlace], las variables miembro estáticas deben seguir el patrón Y".

No podrá evitar por completo la sensación de policía malo , esto es parte de las revisiones. Sin embargo, con un tono cuidadoso, puede establecer una cultura de revisión, donde está claro que no se cuestiona a un desarrollador, sino solo al código en sí. Todas las partes deben entender que una revisión no se trata de criticar a una persona o su trabajo, sino simplemente de mejorar el código y, por lo tanto, su producto.

Asignación de tareas adecuadas

Este es probablemente mi punto más importante y el que creo que justifica mi respuesta en primer lugar, ya que hay redundancias en todas las respuestas publicadas:

Otra respuesta de @ Ertai87 menciona que corregir todos los errores menores es agotador, supongo que tanto para el revisor como para el revisor. También menciona que hay tanto que corregir, que todo el ejercicio se descarrila un poco. La respuesta a la que me refiero establece que se centre en los problemas principales e ignore los problemas menores.

En mi opinión, este no es el enfoque correcto.

Cuando las tareas resueltas por el desarrollador en cuestión están tan llenas de problemas que revisarlas se convierte en una tarea enorme, entonces quiero argumentar que estas tareas son demasiado grandes para el desarrollador en cuestión. No están listos y necesitan que se les asignen tareas más pequeñas y que primero aborden las cosas menores. Eso significa, asignar, por ejemplo , correcciones de errores que presumiblemente solo vienen con unas pocas líneas de código, solo funciones muy pequeñas y otros problemas por el estilo. De lo contrario, pasará un montón de tonterías a su base de código porque está tan ocupado arreglando sus errores principales que no puede darse el lujo de arreglar todas las tonterías menores. En última instancia, es probable que este sea el tiempo que dedican otros empleados, que terminan arreglando todas estas cosas cuando, a su vez, trabajan en los mismos pasajes de código.

No debe esperar que su junior esté al mismo nivel que los demás, ya que el proceso de mejora debe ser gradual. Todavía son empleados, por lo que puede esperar que aporten valor a la empresa, incluso si ese valor es relativamente menor y solo aumenta con el tiempo. Así que asígneles tareas más pequeñas y permítales aprender lo básico primero. Cuanto mejor se vuelvan, mayor será su área de responsabilidad y, por lo tanto, sus tareas también pueden aumentar en importancia.

Pregúntate esto. Con el tiempo dedicado a arreglar el código de ese desarrollador, ¿cuánto tiempo en comparación habrías dedicado a hacerlo tú mismo?

Distribuir reseñas

Como líder de equipo, no está escrito en piedra que debe revisar todo el código. Todos los empleados experimentados pueden realizar revisiones, tiene la opción de utilizar esta táctica. Una forma común de hacer esto es tener un conjunto de revisores y un intervalo de tiempo designado, por ejemplo , una vez a la semana, cuando se procesan las revisiones. Durante ese tiempo, todos los miembros del conjunto deben revisar los problemas que están en espera de aceptación/rechazo.

Esto tiene tres ventajas principales:

• La revisión de código es una tarea que requiere mucha concentración. Solo puede hacer una parte por su cuenta durante un día antes de comenzar a pasar los errores a producción. Más gente en esta tarea significa más concentración como recurso.
• No importa qué tan experimentado sea, es probable que haya algunos patrones en su código y algunos errores que repite y de los que no está al tanto. Esto es cierto para sus compañeros también. Cuando varias personas revisan a los miembros de su equipo y entre sí, al menos el revisor puede ver otros patrones y otras formas de resolver el problema X. De esta manera, el conocimiento se distribuye en su equipo.
• Cuanta más gente haga reseñas, menos corre el riesgo de convertirse en el policía malo .

Sin embargo, diré que esto puede depender de la empresa y los procesos implementados. Algunos lugares de trabajo pueden requerir que un líder de equipo apruebe todos y cada uno de los códigos y algunos lugares de trabajo incluso pueden hacerlo debido a una calificación específica que solo un experto aporta. Un ejemplo de esto podría ser la seguridad en un entorno médico. Si no existen tales requisitos especiales, pero los procesos actualmente requieren que usted revise personalmente todo el código que va a producción, entonces esto se puede plantear con la administración argumentando a favor de una mayor eficiencia del equipo. Solo usted sabrá cómo funcionan las cosas en su empresa, use su mejor juicio para determinar si se puede lograr la distribución de reseñas en su lugar de trabajo.

Una nota personal: cuando comenzamos las revisiones de código en nuestra empresa, también hubo baches al principio, porque es difícil no sentirse criticado cuando se rechaza su solicitud de fusión con un montón de cosas que corregir. A estas alturas, el equipo valora las revisiones de código. Personalmente, he aprendido mucho al revisar mi código, al igual que mis compañeros.

Sobre el comportamiento defensivo

Hay algunas cosas que se pueden discutir y otras que no requieren debate. Discutir esta o aquella arquitectura no es raro. Al hacerlo, es importante tener una buena razón por la que desea cambiar la implementación X a la implementación Y. Simplemente decir "esto es mejor" es insuficiente. Por supuesto, puede seguir el camino de la autoridad, pero es probable que esto lo desmoralice y muestre una falta de perspicacia. Por otro lado, cuando su equipo desarrolló su guía de estilo, espero que haya pensado un poco en por qué decidió que quería hacer las cosas X de la manera Y. Estas cosas no deberían terminar en debates interminables cada vez, al menos si el consenso del equipo sobre el asunto no ha cambiado.

En general, el comportamiento defensivo no es un problema tan rápido o simple para resolver en mi experiencia. Sugiero hacer charlas uno-a-uno de vez en cuando. Similar a las revisiones de desempeño, pero con la intención de ser una conversación no interrogativa entre dos miembros del equipo, en lugar de un jefe que le da el negocio a su subordinado. Este es un momento en el que puede compartir sus quejas sobre el desempeño del empleado sugiriendo mejoras. Es importante escuchar su versión también. ¿Están contentos con lo que están haciendo? Si no, ¿cuáles son los problemas en su mente? ¿Cómo se pueden resolver?

Dicho esto, si todos esos intentos no dan fruto, entonces la forma autorizada puede ser todo lo que queda. En este caso, explíquele al desarrollador que su desempeño no es satisfactorio, por difícil que parezca. Esto es básicamente un disparo de advertencia y en este punto consideraría dejar ir a esa persona.

Entiendo que esto puede sonar duro, pero en última instancia, todos los empleados necesitan aportar valor a la mesa con el tiempo. El valor de un junior al principio puede ser apenas superior a cero, incluso puede ser una inversión en productividad futura, sin ninguna ganancia inmediata. Sin embargo, si pasa el tiempo y no se observa ninguna mejora, entonces la empresa está desperdiciando dinero y el empleado no es el adecuado para usted.

Sin embargo, hay muchas cosas que probar antes de que esto suceda, algunas mencionadas anteriormente. Debe preguntarse si puede mejorar su comunicación con ese empleado y partir de ahí. ¿Estás expresando cosas que los obligan a adoptar una postura defensiva? Si el desarrollador resulta ser un activo para la empresa que solo se vio obstaculizado por la mala comunicación entre ellos y usted, todos ganan una vez que esto se reconoce y se resuelve.

Otra nota personal: he estado trabajando y enseñando bastante a jóvenes en mis últimas dos empresas, en su mayoría estudiantes de licenciatura y maestría, dando los primeros pasos de codificación para aplicaciones del mundo real, pero también programadores autodidactas. como juniors con un trasfondo educativo diferente. Una cosa que muchos estudiantes aprenden después de dar este paso es que las habilidades técnicas, sin importar cuán bueno sea, son parte de una ecuación más grande. Las habilidades blandas son más importantes y deben ponerse al día si es necesario.

Hoy en día filtramos a los candidatos evaluando su carácter más que su habilidad técnica. Tienen una educación similar y nos basamos en este hecho. Sin embargo, la compatibilidad de personalidades es muy importante, porque una manzana podrida puede envenenar toda la cesta. Hasta ahora, principalmente al promover una cultura empresarial muy acogedora, hemos podido integrar a todos nuestros estudiantes y cada uno de ellos se convirtió eventualmente en un activo, pero nos tomamos nuestro tiempo con ellos y no asignamos a alguien que esté aprendiendo el cuerdas tareas gigantes. Como se dijo, el progreso es incremental.

Espero que este muro de texto te ayude de una forma u otra. ¡Buena suerte!

Si hay tantos errores en el código, tal vez una revisión del código sea demasiado tarde para detectarlos. Tal vez necesites dar un paso atrás. Hay algunos enfoques alternativos que podría tomar:

1. Capacitación. No tiene que ser un curso. Podría ser un libro, una serie de videos, un sitio de ejercicios.

2. Orientación personalizada. En lugar de señalar repetidamente los mismos errores en las revisiones de código, tal vez lo lleve a un lado y explique los más comunes con más detalle.

3. Programación en pareja. Déjalo seguir a algunos de los otros desarrolladores. Es la forma más rápida de adquirir el estilo de código interno.

4. Tutoría. Asigne oficialmente a otro desarrollador como mentor para ayudar con las revisiones de código. Idealmente, esto debería ser algo en lo que ambas partes estén de acuerdo.

Se supone que el revisor de código es el "policía malo". Ese es tu trabajo. Si te sientes como un "policía malo", eso es algo bueno y debes aceptarlo. Dicho esto...

1. Los desarrolladores junior cometen muchos errores. Señalarlos a todos es agotador, frustrante y desmoralizador. Si, por ejemplo, nombran una variable incorrectamente, o usan una búsqueda lineal en lugar de una búsqueda binaria para un conjunto de datos lo suficientemente pequeño, o no escribieron una prueba unitaria para un fragmento de código que cree que funciona correctamente, probablemente no valga la pena discutirlo. Guarda tu energía para problemas serios, al menos en la primera pasada...

2. Haz varias pasadas. En el primer paso, observe solo los problemas más críticos. Luego, deje que el desarrollador los arregle y pase a los siguientes problemas más graves. Es posible que desee hacer 3-4 pases en un PR para solucionar todos los problemas. Demasiados temas es desmoralizador y confuso de leer.

3. Señale cuando el desarrollador hace algo genial que le gusta. También puede ser alentador en su revisión de código si agrega un comentario como "¡Oh, esa es una manera genial de hacer un buen trabajo!" de vez en cuando.

4. Reconsidere si tal vez sus prácticas de codificación son demasiado estrictas. Si tiene algo como "cada variable int tiene que terminar con la palabra Int", tal vez sea una restricción tonta que debería considerar relajar. ¿Cuántas de sus reglas son estándares de la industria y cuántas son esotéricas?

5. Si todo lo demás falla, a veces hay que poner el pie en el suelo. Usted es el revisor de código. El código no se fusiona sin su consentimiento. También eres el mayor del equipo, él es el menor. Llega un punto en el que simplemente dices "Soy mejor que tú, haz lo que digo". Trate de no sacar la tarjeta de antigüedad con demasiada frecuencia o se volverá tóxica y desmoralizadora, pero puede sacarla de vez en cuando cuando sienta que lo necesita. Si vas a sacar la tarjeta de antigüedad, asegúrate de estar 100% seguro de que tienes toda la razón. Si saca la tarjeta de antigüedad y resulta que está equivocado, perderá mucho prestigio, tanto con este desarrollador como con su jefe y equipo. A nadie le gusta el tipo que lloriquea y se queja y luego, cuando se sale con la suya, hace que la producción se derrumbe.

La respuesta es un poco mezquina, pero... todo se está alineando en el bote de "hacer todo lo posible por hacer cumplir la ley" , por mucho que odie verlo de esa manera.

Quiero decir, has dicho:

• Él "produce código de baja calidad" (incluso aparte de las diferencias de estilo)
• Las cosas que ya ha dejado pasar le han costado a sus otros desarrolladores tiempo innecesario.
• Es "muy inexperto".
• Es obstinado y no está dispuesto a cambiar.

La razón por la que señalo estas cosas es... ¿Qué pasaría si de repente simplemente dijeras: "¿Sabes qué? Este tipo no puede pasar nada de su código a producción hasta que el código se ajuste por completo a nuestros estándares".

No es que el desarrollador esté produciendo un montón de código increíblemente productivo y que sus estándares se consideren molestos y retrasen los resultados de la empresa. No es que el desarrollador sea receptivo a cambios no forzados y que este problema desaparezca después de otros meses. No es que el desarrollador esté publicando un código que no le cuesta el tiempo de mantenimiento innecesario del otro desarrollador debido a las desviaciones de los estándares.

... y tan triste como es? No es que el desarrollador sea un activo extremadamente valioso para la empresa. Eso es exactamente lo que sucede cuando combinas "Jóvenes sin experiencia" con "Renuencia a aprender o cambiar".

Debido a todo esto, lo mejor que puede hacer es trazar una línea y decir: "No puedes promocionar el código a menos que se ajuste por completo a los estándares. Punto. Tendrás que empezar a seguir los estándares cuando compongas tu código , o comience a presupuestar tiempo para reescribirlo antes de que pueda ponerlo en producción". Y no dejes que nada se escape.

Es probable que el desarrollador odie eso . Quizás terminen mejorando y escribiendo código de calidad. Tal vez no lo hagan. Pero... esa es la parte más triste. Un joven sin experiencia que se niega a aprender o cambiar y decide dejar su grupo no es un resultado tan terrible.

EDITAR: Oh, algo más que olvidé agregar: son un junior "muy inexperto". Si bien definitivamente no voy a decir: "Nunca escuches a los jóvenes porque no tendrán nada que aportar", no tiene nada de malo decir: "Escucha, sé mucho más sobre esto y te digo : esta es la forma en que opera nuestro grupo, y este es el estándar. Debe cambiar su código para que coincida", y luego pasar al siguiente problema en la revisión del código.

¿Cuántas de estas reglas de estilo están realmente escritas?

Mi organización (a veces) revisa el código, pero uno de los problemas es que no seguimos ninguna regla significativa con respecto a la autoría del código. Puede obtener comentarios completamente diferentes (y con frecuencia contradictorios) dependiendo de quién haga la revisión. Tampoco ayuda que la mayor parte del código se haya escrito antes de que llegara alguien del equipo actual, lo que significa que nada de eso se alinea y usar el código anterior como ejemplo no funcionó.

Para que la revisión del código sobre estilo/organización funcione, es necesario que existan reglas claras. Es increíblemente frustrante tratar de adherirse a reglas que son casi "simplemente conocidas" dentro del equipo. Imagine tratar de replicar una pintura mientras la ve a través de la niebla.

En el caso de su desarrollador junior, podría simplemente decirle que el código debe "adherirse a la guía de estilo" y enviárselo en lugar de hacer un aluvión de comentarios repetidos.

No debe detener las revisiones de código, pero también debe asegurarse de que el nuevo desarrollador esté en una posición razonable para saber cuáles son las reglas.

Hay muchas buenas respuestas a esta pregunta, voy a agregar algunos pensamientos que no he visto en las otras respuestas.

• ¿Sus estándares de codificación se desvían mucho de los estándares del lenguaje? Si es así, será más difícil lograr que los desarrolladores lo sigan, especialmente los nuevos desarrolladores que tienen dificultades para entender el código.
• Si sus estándares de codificación no se desvían mucho de los estándares de idioma, puede señalar que son los estándares de idioma, y ​​será lo mismo para la mayoría de las empresas.
• ¿Utiliza herramientas para hacer la mayor parte posible de la revisión de forma automática? Dar formato a las plantillas en el editor resuelve muchas cosas. El análisis de código estático ayuda con mucho más.
• Las revisiones de código son para mejorar el código ahora y en el futuro. Debe asegurarse de que el desarrollador pueda aprender. Una forma es dar crédito cuando algo es bueno. Otro para permitir que el desarrollador revise el código de otros, de esa manera es posible ver un buen código. Tenga en cuenta que no sugiero necesariamente que el desarrollador junior deba ser el único revisor.
• La mayoría de las personas recién egresadas de la universidad o lo que sea no saben cuánto no saben y creen que lo saben todo. Si bien esto puede ser frustrante, es así, y será mejor cuanto más aprendan que no saben. La actitud mejorará al mismo tiempo.
• Creo que debe esperar que algún código no cumpla con todos sus estándares, especialmente para un desarrollador junior. Concéntrese en lograr que las partes importantes cumplan con los estándares y agregue comentarios adicionales cuando corresponda. De esa manera, el desarrollador no sentirá que nada es lo suficientemente bueno y se dará por vencido.

No he visto esta opción en ninguna parte... pero si no tiene algo como la aplicación automática de linting/stylecop como parte de su proceso de desarrollo, este sería un excelente primer paso, ya que detectará una gran parte de los problemas. sin que nadie tenga que sentirse como un "policía malo".

Póngalo en el código como parte de una compilación: si se viola alguna de las reglas, como si tal vez esperara un espacio con un si, es decir, en lugar de o si if (...)una if(...)variable no debería tener un guión bajo y debería ser camelCase en lugar de PascalCase y eso rompe la compilación si se viola... entonces si violan la regla y les explota, sabrán qué hicieron mal y qué deben hacer para solucionarlo sin tener que afectar el tiempo de nadie más.

Con esto en su lugar, los sentimientos o el orgullo de nadie están siendo heridos innecesariamente porque sus problemas menores están siendo capturados por la biblioteca de aplicación de estilo y no por otra persona. Esto también le permitirá concentrarse en los olores del código y en problemas más importantes.

Cuando llegue el momento de poner ojos reales en su código, si algo no está bien, dígalo y explique POR QUÉ se hizo incorrectamente. Espere un poco de rechazo, y eso está bien si pueden dar una razón válida (rendimiento, mantenibilidad, etc.) por qué lo hicieron de una mejor manera. Mantén una mente abierta al respecto. Si empiezan a ponerse demasiado a la defensiva y erizados, dígaselo también, pero de una manera no combativa, como "Oye, somos un equipo, nos hundimos o nadamos juntos. No estoy tratando de hacerte sentir mal, yo Estoy tratando de ayudarte a evitar trampas en las que yo mismo caí".

Cuando alguien tiene que ser un "policía malo", intente impulsar eso en el código sin emociones tanto como sea posible, ya que no le importa si a alguien le gusta o no. Cuando tenga que asumir ese papel, sea un "policía bueno" que dé "amor duro" en lugar de un "policía malo".

También probé sesiones de comentarios uno a uno para evitar revisiones públicas, pero fue infructuoso, ya que el desarrollador estaba tratando de justificar cada comentario hasta el punto de descarrilar la sesión.

Parece que sus estilos de trabajo son incompatibles : usted quiere que él trabaje de una manera particular (apertura a la retroalimentación, código de alta calidad, enfoque en la mantenibilidad, ...) y él quiere trabajar de manera diferente (llamémoslo "vaquero solitario"). codificación"). Eso es frustrante para ambos lados.

Tomando prestada la terminología de los juegos de roles: necesita una sesión cero . Siéntese, explíquele lo que se espera de él a largo plazo (apertura a la retroalimentación, código de mayor calidad, voluntad de cambio, etc.) y determine si esto es algo que realmente quiere .

• Si lo hace... explíquele que usted está aquí para ayudarlo a convertirse en ese yo futuro que encaja bien con su empresa, y que se requerirá mucho aprendizaje y cambios. Necesita comprometerse con ese objetivo y aceptar que las revisiones de código son una herramienta para llevarlo allí. Cuantos más comentarios reciba sobre las revisiones de código, más podrá mejorar y alcanzar ese objetivo.

• Si no lo hace... bueno, podría ser mejor para ambas partes separarse amistosamente. Actualmente, los programadores tienen una gran demanda, por lo que no debería tener problemas para encontrar una empresa en la que se aprecie un enfoque menos estructurado para el desarrollo de software (hay muchas preguntas aquí en The Workplace.SE que se quejan de tales empresas).

Póngalo en un Plan de Mejora del Desempeño.

Parece que en este momento está generando un valor negativo para la empresa: le pagan un salario para que desperdicie el tiempo de otros desarrolladores más experimentados. Obviamente, esta no es una posición viable para él en el negocio, y algo debe cambiar. Como resultado, podría ser una buena idea formalizar esto con un Plan de Mejora del Desempeño que incluya hitos y metas concretas que debe alcanzar, de modo que pueda mejorar su desempeño para obtener un beneficio neto para el negocio o ser despedido con causa. para que ya no sea un perjuicio neto para su rendimiento.

Diría que le asignas una tarea pequeña, luego revisas el resultado y le dejas que vuelva a trabajar en lo que ha hecho hasta que estés satisfecho con ella. Si trata de discutir y se equivoca (eso es importante obviamente), entonces dígale que debe saber qué es lo que está mal y pregúntele por qué cree que tiene que defender lo indefendible. Si hay estilos de codificación a los que todos se adhieren, dígale que se adhiera a ellos. Tenga cuidado allí: tengo algunos hábitos de codificación porque son mejores, algunos porque la consistencia es importante en algunos casos y otros hábitos de codificación que son solo hábitos.

El problema es: cuando reviso su código, tengo que dejar demasiados comentarios hasta el punto de sentir que me estoy excediendo . Algunas veces dejé pasar algunos problemas, pero esto siempre termina costando el tiempo de otro desarrollador (o el mío).

Significa que el primer problema a solucionar es usted y la empresa. ¿Cómo? ¿Por qué?

Si la empresa es al menos mínimamente profesional, debe haber lineamientos formales de codificación por escrito, lineamientos de diseño, etc. está de acuerdo), opcional. Estas pautas deben ser obligatorias y seguidas por todos.

Si lo anterior se implementa y funciona, el chico nuevo puede simplemente revisar su trabajo de acuerdo con las reglas, antes de revisarlo. Muchas de las cosas se arreglarían "por sí mismas".

Ya que hablamos de software, el uso de una herramienta de análisis estático (acordada y configurada por la empresa) debería ser obligatorio. Esa herramienta captará una buena cantidad de cosas (con suerte), y el chico nuevo puede hacer mucho trabajo de forma independiente antes de hablar con alguien más.

Reseñas - con un toque

No solo que sus colegas deben revisar su trabajo, sino que él también debe revisar el trabajo de sus colegas. Aprenderá cómo funcionan realmente las reseñas y aprenderá por qué algunas cosas son importantes.

Recordará las críticas que hizo por el trabajo de otra persona cuando su trabajo sea criticado.

• Si yo fuera el chico nuevo, y
• si no hubiera pautas formales,

entonces tendría una postura mucho más fuerte contra sus críticas:

¿Por qué tu opinión es mejor que mi opinión?

o mejor:

¿Por qué? ¿Dónde está escrito?

Actualización: ¡ el chico ya lo está haciendo! (Me perdí esta información cuando leí la pregunta inicialmente)

También probé sesiones de comentarios uno a uno para evitar revisiones públicas, pero fue infructuoso, ya que el desarrollador estaba tratando de justificar cada comentario hasta el punto de descarrilar la sesión .

Al carecer de un punto/sistema de referencia, cualquier opinión es tan buena como cualquier otra opinión.

En la Philokalia, se dice que tal y cual puede ayudar a la gente con tal o cual deficiencia, y tal y cual puede ayudar a la gente con tal o cual deficiencia, "pero solo Dios puede ayudar a los orgullosos".

El orgullo es, además de un pecado, una debilidad que pone una guardia de hierro alrededor de otras debilidades (cf. Chesterton). Alguien que es humilde e inexperto puede progresar constantemente aprendiendo. Alguien que te mira con desdén y se exime de cada corrección tiene una calificación de problema más alta que alguien que es bueno, anticuado e inexperto.

Necesitas un humilde programador. Póngalo en un plan de mejora del rendimiento, como última medida de misericordia en lugar de simplemente despedirlo (lo cual está justificado).

su estilo de código difiere demasiado del equipo

No me queda claro si crees que el estilo es el único/principal problema con su código, o si también es pobre en otros aspectos, pero este es fácilmente solucionable.

La solución es hacer que sea imposible verificar el código que se desvía de sus expectativas. No tienes que ser el malo. Deja que la computadora sea la mala.

El primer paso es codificar sus expectativas. Checkstyle (una herramienta de Java) utiliza un formato de estilo XML. También es extensible para cheques personalizados. Lo he encontrado bastante bien. También debe tener una versión legible por humanos, preferiblemente con ejemplos.

A continuación, desea asegurarse de que su compilación falle si un desarrollador se desvía del estilo esperado (tiene una compilación automatizada, ¿no es así?). Usamos el complemento Maven Checkstyle para nuestros proyectos.

Es más fácil solucionar problemas localmente que esperar hasta que falle la compilación automatizada, por lo que me parece recomendable configurar un gancho de confirmación previa para ejecutar el mismo complemento de compilación, de modo que no sea posible (sin eludir deliberadamente el gancho) empujar algo que se desvía del estilo esperado.

El último paso es asegurarse de que la vida de sus desarrolladores no se consuma tratando de adherirse a su estilo; necesita distribuir recursos para ayudarlos a hacerlo. Este paso es importante para asegurarte de que no te odien por los 3 pasos anteriores. Configure su IDE para que coincida con su guía de estilo y exporte la configuración para que su equipo pueda importarla. Coloque el archivo de configuración en un repositorio al que todos tengan acceso. Si diferentes miembros del equipo prefieren diferentes IDE, considere EditorConfig que hace esto de una manera independiente del IDE. Una vez que haya hecho esto, adherirse al estilo debería ser tan fácil como presionar un atajo de teclado.

También busque complementos IDE que coincidan con la herramienta que está utilizando como parte de la compilación. Usamos un complemento de estilo de verificación para IntelliJ que puede cargar un archivo XML de estilo personalizado y mostrará las infracciones en línea, como un error de sintaxis.

Para tantas infracciones como sea posible, automatice las correcciones . Encuentro que el formateo automático de todo el código a menudo da algunos resultados extraños. En algunos casos, como declaraciones de importación no utilizadas, una computadora puede arreglarlas fácilmente con poco riesgo.