El miembro del equipo está vehementemente en contra del formato de código

Soy el gerente de un pequeño equipo de desarrolladores (5 ingenieros, incluyéndome a mí).

Hace unos meses, por sugerencia de otro colega, introdujimos el formato de código obligatorio en la base del código, para nuestro proyecto principal. Nuestro proyecto está en Python y la herramienta de formato es black(no relevante, supongo).

Considero valioso tener la misma 'apariencia' del código en todos los archivos del proyecto, para mí es parte del control de calidad de todo el proyecto. Las solicitudes de combinación de código deben formatearse con la herramienta; de lo contrario, no se pueden agregar al software.

Desde entonces, un colega siempre se queja y expresa su desacuerdo sobre esta decisión cada vez que se presenta la ocasión.

¿Cómo lidiarías con tal situación?

¿Qué respondería a "el formato de código es una mierda total" , "son como los colores, a algunas personas les gusta el rojo, a otras azul, eso es todo" , "reduce mi libertad" , "hace que el código sea más complicado de leer sin valor agregado" etc. ?

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
Es posible que desee editar para aclarar que no hay problemas reales que consuman mucho tiempo al editar el código o registrarlo (tengo problemas con el formato que no se puede configurar de forma predeterminada en mi IDE; no soy realmente fanático de agregar espacios manualmente para hacer feliz al formateador/verificador de estilo). Claramente, las respuestas muestran que está viendo un problema interpersonal y no un punto de dolor real que ha introducido.
Una cosa que podría ayudarnos a comprender un poco mejor su situación es si discutió esta decisión con su equipo antes de que se implementara. Cuando dice "introdujimos el formato de código obligatorio", ¿quiere decir "nosotros, el equipo, decidimos..." o "como director del equipo, decidí que nuestro equipo..."? ¿Tuvo conversaciones constructivas con su equipo antes de implementar el reformateo? De ser así, ¿su 'desarrollador líder' planteó alguna objeción en ese momento? De ser así, ¿se escucharon sus objeciones? ¿O hicieron un tirón un día solo para descubrir que todo había sido reformateado debajo de ellos?
Es interesante saber qué significa exactamente el formato , ¿qué tan detallado es el formato? Si bien es absolutamente útil tener la misma sangría, la misma posición de las llaves y cosas por el estilo, es una tontería absoluta y no ayuda en absoluto imponer números exactos de líneas en blanco en todas las situaciones imaginables, como comentarios o funciones, o también en el medio. de funciones Para mí, tener razón o no está fuertemente ligado a tales detalles. ¿Podría agregar ejemplos?
@puck OP usa Black, que es una forma muy sensata de formatear el código. El empleado está siendo terriblemente irrazonable al quejarse de ese estilo.
¿Estaría realmente de acuerdo con un estilo de código y luego haría que la herramienta lo produjera como una opción? ¿Quizás comenzar con el valor predeterminado negro y luego discutir si es necesario algún cambio (ya que usar el mismo que todos los demás generalmente es una buena idea)?
@puck en particular, garantiza que no verá confirmaciones de millones de líneas solo porque alguien ejecutó un formateador diferente en todo el proyecto y se siente con derecho a su opinión al respecto.

Respuestas (26)

Sinceramente, mi reacción sería la siguiente:

Bob, agradezco los comentarios, pero como equipo hemos decidido que usaremos Black como nuestra herramienta de formato de código obligatoria, y esa decisión es definitiva. Entiendo que no es su preferencia personal, pero me temo que tendrá que aprender a trabajar con él.

¿Pero si quisiera entablar una discusión?

"formatear el código es totalmente una mierda"

Esa no es una retroalimentación muy constructiva, ¿podría ser más específico?

"son como los colores, a algunas personas les gusta el rojo, a otras el azul, eso es todo"

Por supuesto, pero la estandarización de esos "colores" es muy útil, ¡y teníamos que elegir uno!

"reduce mi libertad"

También lo es aceptar escribir código en el mismo idioma y versión de ese idioma, pero ¿te imaginas el caos si no lo hiciéramos?

"hace que el código sea más complicado de leer sin valor añadido"

Eso no es cierto. Después de un tiempo de leer el código en este formato, no será más complicado de leer; de hecho, será más simple de leer (valor agregado allí) porque solo tendrá que aprender un estilo en todo el proyecto. También significa que las diferencias son mucho más legibles para los relaciones públicas, podemos incorporar a otros desarrolladores y ponerlos al día más rápido, y los desarrolladores no se preocuparán por qué tipo de formato podría verse un poco mejor en una situación determinada.

Para ser claros, si sus comentarios fueron constructivos , diga sobre el formato "No creo que Black sea útil para nosotros por las razones x, y y z, ya que gran parte de nuestro código sigue un estilo de codificación bc que Black maneja mal, ha considerado (otra herramienta) en su lugar", entonces ese es un escenario muy diferente . Ahí es cuando debe hacer todo lo posible para participar en una discusión para validar sus preocupaciones y trabajar con él para abordarlas.

but I'm afraid that if you want to stay in this teamEn mi cabeza podría estar pensando eso, pero definitivamente no lo diría de esa manera, al menos al principio. Este tipo parece alguien que podría escalar rápidamente y esa redacción probablemente lo hará escalar más rápido. Usaría algo más como, "Entiendo que no es su preferencia personal, pero tuve que hacer una elección para el equipo y esto es todo". Creo que el objetivo general es ayudar a todos a comprender los beneficios y unirse al redil. Si continúa rebelándose, entonces sube el idioma.
@JeffC Sí, ese es un buen punto. ¡ Quise decir que no es negociable mientras él está trabajando allí, pero al leerlo de nuevo, parece mucho más conflictivo de lo que pretendía que sonara...!
but as a team we've decided that we're using Black as our mandatory code formatting tool, el OP nunca dijo que fuera una decisión del equipo.
@Akavall "por sugerencia de otro colega que presentamos ..." Énfasis mío, y eso hace que parezca que es una decisión de equipo para mí. Si no es así, entonces (creo que obviamente) simplemente deje de lado el bit "como equipo". El resto de la respuesta todavía se aplica.
"Nosotros presentamos" no significa que la decisión de presentarlo la haya tomado el equipo, pudo haberlo sido, pero no tenía por qué serlo. Tendría cuidado al afirmar que algo fue una decisión del equipo, cuando en realidad no lo fue.
@Akavall Creo que es un hecho que cualquier respuesta sugerida debe modificarse para adaptarse a la situación. Como dije anteriormente, si no es una decisión de equipo, descarta el "bit como equipo". ¡Eso debería ser bastante obvio, al igual que cambiar el nombre de dicho colega si no es "Bob"!
En cuanto al formato del código, depende completamente de cómo se reformatee exactamente. Si está cambiando automáticamente las definiciones de función al estilo K&R, por ejemplo, puede tener razón. O hacer cosas horribles para ajustarse a los límites de 80 caracteres, o truncar nombres de variables. Tratar de encontrar lo que no le gusta del formato estandarizado podría ser útil para el OP.
@Graham Absolutamente. Si su comentario fue "esto cambia automáticamente las definiciones de funciones a K&R, y eso no es útil", entonces eso es una crítica constructiva, y debería trabajar con él para ver si hay una solución alternativa o tal vez una herramienta diferente que se adapte mejor a la tarea. . Pero eso está muy lejos de los argumentos de "es una tontería y reduce mi libertad" que estamos viendo en el OP.
@berry120 Como alguien que pasó mucho tiempo siguiendo las reglas de MISRA, estoy totalmente de acuerdo. La libertad en la codificación generalmente está sobrevalorada. Me gusta tener cierres de seguridad en las cosas que podrían dispararme en el pie. :)
Decidí aceptar esta respuesta: solo puedo aceptar una, incluso si hay muchas otras con buenos puntos también. La decisión de tener un formato de código automático y obligatorio se tomó con la aprobación de los otros miembros del equipo (excepto uno, entonces...). Sin embargo, otros son más jóvenes. Utilicé la palabra "desarrollador principal" porque él tiene el panorama general del proyecto y es senior, pero también soy programador en el equipo... Sin duda, mi rol dual hace que las cosas sean más difíciles a veces. Gracias por la ayuda chicos !
Algunos comentarios míos específicos de Black pueden ser que no me gusta cómo formatea todo, forzando comillas dobles, pero elija lo que sea, pero lo dejaré por coherencia . La falta casi total de configurabilidad significa que no puedes tener todas estas pequeñas peleas sobre esto o aquello, es un tómalo o déjalo.
"¡Tuvimos que elegir uno!" solo me hace pensar "Soy daltónico y estandarizaste colores que dificultan la lectura, ¿por qué no se tomaron en cuenta mis necesidades? ¿Por qué no me consultaron?" . Esta respuesta tiene que ver con hacer que el desarrollador recalcitrante se conforme, haciendo que un entorno ya hostil sea aún más hostil. Ser gerente no se trata de mantener los latigazos hasta que la moral mejore, se trata de eliminar las barreras que impiden que las personas alcancen su potencial. Consulte Peopleware .

¿Cómo lidiarías con tal situación?

Después de consolarlo amablemente, lo cual ya has hecho, es hora de decirles con firmeza que se encarguen de eso . No es el código de un individuo, sino el de la empresa. Como gerente, necesita que el código sea lo más mantenible posible para su equipo y las nuevas incorporaciones que haga al equipo en el futuro.

"el formato de código es totalmente b *** $ hit"

Como codificador, en las empresas en las que he contribuido, se aplican algunos estándares de formato. Como desarrollador principal, en realidad esperaría que fueran fanáticos.

"son como los colores, a algunas personas les gusta el rojo, a otras el azul, eso es todo"

Como su gerente, me gusta el rojo, trátelo.

"reduce mi libertad"

El formato del código no afecta la libertad de crear una solución elegante. Llamo a BS en esto, y tú también deberías hacerlo.

"hace que el código sea más complicado de leer sin valor añadido"

Ummmm nop. Esto realmente me hace preguntarme si su desarrollador líder es realmente un líder...

Para reiterar: ha establecido un estándar, como gerente o como equipo, no importa. El líder necesita unirse o quizás seguir adelante .

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
@Eyal: a veces, ser el trasero de un burro es la única forma de hablar con un empleado, que es todo un burro. (En otras palabras, un culo por un culo).
Para mí, si no hay críticas específicas sobre el estilo de formato que no le gusta al empleado (pestañas frente a espacios, cantidad de espacios por tabulación [que, aparte, en realidad solo es un problema cuando se seleccionan espacios sobre pestañas ], colocación de corchetes, prácticas de continuación de línea, etc.), entonces simplemente están siendo difíciles por el bien de la dificultad. OP no indicó que el empleado tuviera ninguna crítica específica sobre la herramienta actual, solo el formato en general.
Una persona obstinada es extremadamente útil una vez convertida y puede volverse inútil cuando se la fuerza . Hay momentos en que esto último es necesario, pero es una excelente manera de destruir la productividad y la motivación. El primero suele ser más constructivo: una buena inversión para el equipo y el técnico a medio plazo si se hace bien. Es posible ahuyentar a alguien que podría convertirse con la delicadeza y la comprensión adecuadas y que sería un activo potente. Así que simpatizo con el objetivo de esta respuesta, pero -1 por ni siquiera reconocer el otro lado de esta compensación.
El líder no es un jugador de equipo. Siempre nos encontramos en situaciones en las que tenemos desacuerdos. Si no puede adaptarse a los deseos del equipo o de la gerencia, siempre puede irse.
En primer lugar, el formato de código y el resaltado de sintaxis son cosas diferentes y deben abordarse por separado. En EE. UU., el resaltado de sintaxis se puede cubrir con las adaptaciones de ADA para las necesidades de visualización de alto contraste. En segundo lugar, todos los IDE modernos se pueden personalizar para formatear y resaltar sobre la marcha y pueden reformatear el código según el estándar de la empresa en el momento de la confirmación. La mejor respuesta debería haber sido adoptar el estándar de la empresa Y proporcionar soporte y permiso para que los programadores personalicen la visualización del código para mejorar la legibilidad en sus estaciones de trabajo. A veces, un jefe necesita un culo, pero no esta vez.
Voté a la baja porque los argumentos en esta respuesta abordan la necesidad general de un estilo de codificación consistente , mientras que el conflicto del OP se planteó sobre la imposición de una herramienta específica . Siento que no es lo mismo: un estilo de codificación no requiere necesariamente una herramienta obligatoria.

Intentaría convencerlo de los efectos positivos del formato de código uniforme. Las diferencias de Git se vuelven mucho más fáciles de digerir cuando commit n y commit n+1 tienen el mismo formato. La capacidad de mantenimiento se vuelve más fácil, asumiendo que el formateador aplica buenas prácticas. Al final, el desarrollo de software corporativo es un deporte de equipo.

Si su formateador de código permite definir reglas, pregúntele si hay ciertas reglas que no le gustan y considere discutirlas con su equipo.

El mayor beneficio de las diferencias más fáciles de digerir es que ahora solo se concentra en las diferencias reales del código y no tiene que usar su limitada atención cognitiva en cambios de formato irrelevantes. O, dado que la pregunta es sobre Python, cambios de formato que pueden o no ser irrelevantes. Nuestro equipo ha comenzado a realizar confirmaciones de solo formato seguidas de la confirmación de cambio de código real para evitar este mismo problema.
+1, trabajaría contigo. Esta respuesta es la única que no intenta convencer al empleado de que la implementación es la correcta, sino que el objetivo es lo que debe tener en cuenta. Al ofrecer su opinión, puede contribuir a la mejor solución. Las respuestas como Dile que se aguante o se vaya son basura. Eso no es liderazgo.
"Las diferencias de Git se vuelven mucho más fáciles de digerir cuando commit n y commit n+1 tienen el mismo formato". por otro lado, se vuelven mucho más difíciles de digerir cuando se ve obligado a cambiar la sangría de un gran bloque de código solo para agregar o eliminar un condicional.
Siento que esta es la respuesta emocionalmente más inteligente. Mi líder técnico se ha enfrentado a nuestro gerente en ciertos estándares de proceso, pero por lo general pueden aceptar probarlo durante un trimestre y continuar la conversación. El enfoque de "aguanta y lidia con eso" no es mi taza de té, incluso si el empleado es el que tiene la mala actitud. Como gerente, debe elevarse por encima y no rebajarse a ese nivel.
+1 por preguntar si tiene ideas para mejorarlo. Siempre es completamente posible que pueda haber razones legítimas por las que un estándar de código en particular no se ajuste perfectamente, por lo que a veces vale la pena considerar modificaciones, pero solo si hay una buena razón para mejorar la legibilidad y la estructura, aunque si piensa que el formato del código no tiene ningún beneficio, supongo que es poco probable que tenga sugerencias.
Este. También buscaría soporte IDE (nativo o complementario) que reformateará el código a un estilo específico o incluso mejor a varios estilos. Deja que los desarrolladores trabajen como quieran. El último paso antes de la confirmación es "formatear el código según el estándar".
@PeterGreen, una de las cosas hermosas que uno puede hacer con git es reescribir el historial, de modo que todo esté en forma ennegrecida desde la confirmación inicial . Haga eso y agregue la aplicación continua, y no tendrá cambios sin significado semántico en la historia... nunca.
@ivanivan Ese sería el segundo paso final. El último paso es probarlo para asegurarse de que todavía funciona, por supuesto.
@PeterGreen, no confirmaría el formato y su cambio en la misma confirmación. Para eso están las confirmaciones de formateo.

¿Cómo lidiarías con tal situación?

Intentaría entender el punto de vista de los desarrolladores recalcitrantes. Pueden tener buenos puntos para hacer que estoy ignorando.

Antecedentes y experiencia de apoyo

Implementamos el formateo automático en nuestro código base hace algunos años y causó un sinfín de problemas, en parte debido a la forma en que se introdujo, pero principalmente debido a la forma en que impactó nuestro flujo de trabajo. Causó tanto trabajo adicional para solucionar los conflictos de fusión que, al final, desactivamos muchos aspectos del formateo automático, por lo que solo corrigió automáticamente las cosas que no causaron más problemas de los que resolvieron. También revisamos todos los escenarios e incluimos solo aquellos en los que todos estuvieron de acuerdo.

Un problema con el formateo automático es que no solo 'estandariza' el mal formato, sino que también 'estandariza' el buen formato.

Un formateador automático no puede notar la diferencia entre un espacio doble agregado accidentalmente y un espacio doble agregado para hacer que un elemento en una línea se alinee con un elemento de otra línea. Esta asociación visual puede hacer que sea mucho más fácil leer el código, ya que puede ser mucho más obvio que dos cosas en dos líneas están relacionadas.

Si va a implementar el formateo automático, necesita que todo el equipo lo compre.

Debe aplicar el formato globalmente, en una rama, y ​​solo fusionarse en esa rama una vez que todos hayan tenido la oportunidad de revisar el efecto que tiene en su flujo de trabajo, plantear sus objeciones y acordar un camino a seguir.

La mayoría de la gente compraría la eliminación automática de espacios en blanco de los extremos de la línea, pocas personas querrían que sus cuidadosas divisiones manuales de línea para facilitar la lectura se vuelvan a dividir sin pensar en el lío incoherente que producen muchas herramientas de formato automático.

Mi sospecha es que este desarrollador está molesto porque se enorgullece de su trabajo, ha dedicado mucho tiempo a hacer que su código sea lo más legible y fácil de mantener posible, y este reformateo automático ha destruido todo su formato cuidadosamente elaborado.

A pesar de que la sintaxis de Python ya impone una serie de requisitos de formato, aún deja mucha libertad para el desarrollador individual.

En breve. Escuche las objeciones de sus desarrolladores, es posible que pueda mejorar la base de código para todos. Como dice PEP 8, la Guía de estilo para el código de Python

Una consistencia tonta es el duende de las mentes pequeñas

Está justo ahí en la parte superior de la guía por una muy buena razón.

Teniendo en cuenta el comentario de jrh , ocasionalmente se ríen de las personas que describen la programación como "más un arte que una ciencia", pero no estoy de acuerdo cuando se trata de los aspectos de habilidades blandas de la codificación. Los programas no solo están hablando con el compilador/intérprete, están hablando con los programadores que pueden tener que corregir, mejorar o mantener ese código en el futuro.

Para abordar el comentario de VGR , no creo que este sea un buen lugar para criticar al negro . No he usado esta herramienta, pero al leer la descripción puedo ver cosas buenas en su mayoría, especialmente para el mantenimiento a largo plazo y la difabilidad (la ruina de las fusiones complejas).

Sin embargo, eso no ayuda si todo el equipo no compra el uso de un formato automático tan estricto e intransigente.

Esa parece ser la única parte de PEP 8 que la gente ignora (bueno, bueno, eso, y mucha gente se ha dado cuenta de que 80 caracteres es un anacronismo ridículo). Las partes de líneas similares alineadas verticalmente son superiores. pelea conmigo
Los límites de 80 caracteres son populares no porque los terminales de hace 30 años los tuvieran, sino porque de esta manera es mucho más cómodo ver de un vistazo qué está haciendo el código cuando solo lo escaneas con los ojos. Las líneas largas matan la legibilidad. Las guías tipográficas para texto suelen recomendar entre 45 y 70 caracteres por línea. A menudo formateo mis bloques de comentarios con un ancho de aproximadamente 60 líneas porque encuentro que es un punto óptimo en la legibilidad.
Esta respuesta toca algunos problemas importantes con los formateadores automáticos que rara vez se abordan; Consideraría el uso cuidadoso de espacios en blanco no estándar que no afectan la funcionalidad como una "característica oculta" de la programación, y realmente puede ayudar a veces. Los únicos contraargumentos que he escuchado en contra son más o menos "bueno, entonces pasas más tiempo haciendo tu diseño que formateando", pero nunca he encontrado que este tipo de trabajo sea un desperdicio, ni tampoco pasar horas y horas haciéndolo...
... y supongo que para dar un ejemplo específico, 1) ¿Alguien diría que las listas con viñetas y sangría en Stack Exchange no son útiles? 2) ¿Preferirían todos que eliminaran eso por el bien de la "estandarización"? 3) Aquí hay una muestra de cómo se vería. Supongo que preferiría que los programadores recibieran los mismos recursos que tendría un escritor (cuando sea práctico, sé que los tamaños de fuente y negrita/cursiva serían problemáticos); elimine los espacios en blanco al final de la línea y haga cumplir la sangría de tabulaciones frente a espacios, claro, pero no soy partidario de quitar herramientas para presentar bien las ideas.
Si bien tiene algunos buenos puntos, no vi ninguna mención del formato automático en la pregunta. Estoy totalmente a favor de los estándares de codificación, pero desprecio el formateo automático, ya que el resultado suele ser pobre. Cómo y dónde ajustarse a los estándares (como la mejor manera de romper una línea) es una tarea que es mejor dejar en manos de los humanos. mguijarr puede hacer cumplir los estándares de codificación sin el uso de formato automático.
-1 Workplace.SE se trata de manejar personas, no de soluciones técnicas. La respuesta de Wasmachien al menos describe cómo usar la tecnología para convencer a la persona.
No veo cómo su comentario me ayuda a mejorar mi respuesta @Chris, mis puntos principales se centran en las personas, mis puntos técnicos solo están ahí para reforzar la necesidad de comunicación.
@MarkBooth: Estás escribiendo sobre espacios en blanco, fusiones y guías de estilo de Python. Si hay consejos centrados en las personas, se ahogan en detalles técnicos.
La respuesta específica está justo en la parte superior @Chris, es difícil pasarla por alto. El resto es evidencia de apoyo de la experiencia personal de estar en una situación similar a la del desarrollador siendo 'administrado'.
@MarkBooth En realidad, es difícil pasarlo por alto. Su consejo son dos oraciones pequeñas en una respuesta muy larga. Pero otros parecen pensar que esta es una respuesta apropiada, por lo tanto, lo dejaré así.
"Si va a implementar el formateo automático, necesita que todo el equipo lo acepte". - ¡este! El beneficio de hacer esto viene cuando todos lo hacen. Es posible que desee que la cadena de herramientas de compilación verifique las fuentes en el momento de la compilación (y falle si no están formateadas correctamente) o que su herramienta de control de versiones verifique en el momento de la inserción.

Si tuviera una panadería, es posible que desee que mis panaderos usen un tamaño estándar de pan. Facilita la compra de bolsas para el pan, por ejemplo. Puedo tener un precio constante en los panes que hago.

Mis panaderos pueden sentir que esto restringe su creatividad. A algunos les puede gustar hacer hogazas de pan muy pequeñas o muy altas.

Otros panaderos pueden sentir que prefieren un pan mucho más grande.

Esto no significa que no haya razones válidas para establecer un estándar.

Sin embargo, algunos panaderos pueden señalar que el tamaño de pan que he solicitado no cabe en el horno. Sería un dueño de panadería muy sensato si escuchara a esos panaderos.

El miembro de su equipo ya cumple con una amplia gama de estándares que pueden restringir su creatividad y contradecir sus preferencias. Esto viene con el trabajo en equipo. Esto no significa que no deba establecer estándares, pero probablemente sea prudente permitir y fomentar la retroalimentación constructiva y no disruptiva.

Me gusta la analogía. ¡Considéralo robado para uso futuro!
La analogía me hace perder un poco porque el código sin formato funciona igual que el formateado, lo que no se puede decir del pan. Un pan pequeño no hará el trabajo de un pan grande. Es realmente difícil comparar este concepto con un bien físico tangible.
@Geobits Un pan redondo funciona igual que un pan rectangular, pero definitivamente requieren bolsas diferentes.
Creo que esta es una buena respuesta porque muestra que lo que probablemente falta en la pregunta es el motivo del estándar de formato de código. O al menos, no hay acuerdo sobre la importancia del estándar.
@user1234567890abcdef Sí, pero siguen siendo panes diferentes, mientras que con el código el producto final no es diferente. El formato de código es más como hacer que todos los panaderos organicen sus espacios de trabajo de la misma manera, de modo que sean intercambiables y todos sepan dónde está todo si tienen que trabajar en un lugar diferente. Tampoco es una analogía perfecta, pero se acerca más a mi mente.
@Geobits: hubo un error importante de SSL hace unos años dentro de un software de Apple que provocó una falla en el formato del código (es decir, escribir dos líneas de código bajo una declaración if). El ejemplo puede estar fuera de lugar, olvidé el detalle exacto, pero fue un error de codificación bastante tonto. El punto es que los estándares de código tienen un propósito.
Esta analogía se desmorona porque se espera que la producción de los programadores tenga un alto grado de originalidad, mientras que se espera que el pan sea uniforme. Hay espacio para debatir si un programa de formato de código siempre debe anular el juicio de un programador humano (suponiendo que el código producido por humanos se ajuste razonablemente a la guía de estilo y que las variaciones tengan sus justificaciones).
No me gustan mucho las analogías en la programación. Pueden parecer útiles, pero por lo general es más sencillo hablar en términos de, bueno, programación, cuando su público objetivo está formado por programadores.
@Ramhound Cierto, pero solo se habría detectado si el formato incorrecto produjera un error. OP está utilizando una herramienta que formatea automáticamente el código con formato incorrecto.
@Marc.2377 Eso es genial; Me gustan bastante las analogías en la programación, yo mismo, donde tiene algún sentido. No creo que esta pregunta tenga mucho que ver con la programación, sino con los estándares en el trabajo.
@PeteCon ¡Encantado de ser de servicio!
@Geobits Creo que la función del pan es un poco difícil de definir, pero podría decirse que funciona de la misma manera, aunque tiene razón, la analogía realmente no llega muy lejos. Creo que representa el punto de esta pregunta, aunque
@ 200_success Estoy totalmente en desacuerdo con este; el código que escribe la gente no tiene ningún requisito de originalidad; el producto final puede tener el requisito de ser original. A los clientes no les importa si su código fuente es original o no
@Geobits El código mal formateado puede funcionar, pero es más difícil trabajar con él en el futuro. Lo mismo ocurre con los diferentes tamaños de pan. Una persona talentosa puede trabajar con un tamaño de pan más pequeño, pero si los tamaños de pan siguen siendo los mismos, una gama más amplia de empleados podría trabajar en él en comparación con unas pocas personas altamente calificadas. Lo mismo ocurre con el código mal formateado, ya que una persona talentosa puede trabajar con él, pero para la gran audiencia, podría no ser tan fácil si todos tuvieran un estándar.
Hornear amores de pan de tamaño estándar es un trabajo a destajo. La programación no es un trabajo a destajo a menos que seas muy malo en ello.
@Brian Me temo que no estoy de acuerdo con que hornear pan sea un 'trabajo a destajo'. Tampoco estoy seguro de poder ver cómo la diferencia en el tipo de trabajo hace una diferencia en cuanto a la aplicabilidad de los estándares de calidad.
@Donald Suena como nakedsecurity.sophos.com/2014/02/24/… En realidad, reformatear habría ayudado a detectar el error, ya que habría movido el segundo goto a la izquierda debajo del si.
Soy consciente de que el reformateo lo habría detectado.

"formatear el código es totalmente una mierda"

Incluso si esto tuviera un punto (y no lo tiene), declaraciones en blanco y negro como esta a menudo insinúan una comprensión muy inmadura de:

  • cómo manejar las herramientas de desarrollo y discutir sus ventajas y desventajas de una manera equilibrada y rica en contexto (también conocida como profesional)
  • cómo lidiar con el trabajo en equipo

Necesitamos opiniones profesionales y constructivas, no axiomas fanáticos.

"son como los colores, a algunas personas les gusta el rojo, a otras azul eso es todo" / "reduce mi libertad"

No, no es como los colores. Se trata de la legibilidad y de los estándares compartidos .

Las personas que hacen esta queja van por el camino egoísta y no se dan cuenta del valor agregado de los estándares comunes al tratar con el código y, sobre todo, comprender el código de otras personas y hacer que ellos entiendan el suyo.

El hecho de que todos tengan sus propias preferencias, por el contrario, es exactamente la razón por la que debe tener estándares de codificación, desde comentarios hasta nombres y formatos.

Sacrificar sus "preferencias personales" debe hacerse a menudo por un bien mayor, el buen trabajo en equipo se trata de compromiso para obtener el mejor resultado.

Imagina si:

  • desarrollador A tiene su estándar
  • el desarrollador B usa otros estándares de formato
  • el nuevo desarrollador "C" tendría que leer el código en dos estilos diferentes
  • D en tres... y así sucesivamente.

Se vuelve confuso y agotador porque tu cerebro tiene que adaptarse a diferentes estilos y cambiar constantemente entre ellos . Con un estándar compartido, solo tiene que adaptarse una vez . En proyectos compartidos, incluso si son de código abierto , se aplican estándares por muy buenas razones.

¿Y si editan el mismo archivo/clase? ¿Terminará con diferentes estilos de codificación?

"hace que el código sea más complicado de leer sin valor añadido"

Creo que lo que dije anteriormente es suficiente como respuesta a esta completa tontería.

Editar: mire también la respuesta de @nitarshs , brinda otro ángulo interesante desde el punto de vista de la psicología grupal que encontré interesante.

@NathanHughes no, tal vez una mala redacción, no soy un hablante nativo de inglés. Tenía la intención de decir "personas que golpean herramientas con tanta facilidad".

¿Quizás la causa raíz del problema no está relacionada con el formato de código, sino con algo más ?

En mi experiencia, esta situación muestra claramente que el individuo disidente no se ha expresado de manera madura y racional, independientemente de si tiene razón o no.

No estoy seguro de cuánto tiempo ha estado la persona en cuestión contigo y con el equipo, pero realmente creo que deberías conocer mejor la disposición de la persona para saber cómo manejar situaciones como esta.

Me he dado cuenta de que incluso las personas racionales se comportan de forma irracional cuando no están contentas con algo. Incluso ellos podrían no ser conscientes de la verdadera causa de sus irritaciones.

O simplemente es posible que la persona sea inmadura por naturaleza, en cuyo caso puede elegir ignorarla siempre que haga su parte del trabajo correctamente.

Tal vez llevarlos a tomar algo o cenar y darles un poco de cuidado y atención. Debes abrirte a ellos y dejar que ellos se abran a ti. Intenta conocer mejor a tus compañeros de equipo y haz que te conozcan mejor a ti y al resto del equipo.

Es posible que tengan una idea muy clara de cuál es el otro problema y sientan que no les corresponde mencionarlo.
Posible. En tales casos, simplemente ignore sus comentarios.

Esto no se trata de formato de código en absoluto. Se trata de la peor forma de microgestión posible. Cada vez que se realiza una confirmación, un estúpido microadministrador sin sentido cambia el código de una manera estúpida de microgestión. Y este desarrollador está cabreado. (Parece que algunas personas no entendieron esto; cuando digo "microadministrador" me refiero a la herramienta de formato de código).

Su ganancia, y la ganancia de sus equipos, de todo esto es indistinguible de cero. Tu pérdida es que tuviste discusiones, perdiste tu tiempo y cabreaste a alguien que hasta ahora ha sido un desarrollador decente. En el mejor de los casos, perderá su apoyo y compromiso. En el peor de los casos, pierde por completo a un miembro valioso del equipo.

Simplemente apague la herramienta y listo. Ha causado y causará más daño de lo que vale. Solo decida: ¿Quiere demostrar que tiene el xxxx más grande para saludar, o quiere un equipo que esté feliz y haga el trabajo?

El formato de código consistente hace que trabajar con el código de otras personas sea mucho más fácil y hace que las diferencias sean más sencillas. En mi opinión, se trata de profesionalismo y trabajo en equipo, no de microgestión. En ninguna parte dice que el administrador hace el cambio de código, es el desarrollador el que debe hacer el cambio de código antes de la confirmación.
Creo que está haciendo varias suposiciones injustificadas: que la ganancia es cero y que la persona en cuestión ha sido un desarrollador decente cuya participación perdida se debe a que debe trabajar de manera más eficiente con el resto del equipo. No creo que ninguno de los dos sea correcto: la mayoría de los proyectos ven ganancias en eficiencia (por ejemplo, la revisión de código requiere menos desciframiento del estilo "creativo" de alguien), y por lo que parece, esta persona ya tiene problemas para trabajar en un equipo y esto es una manifestación de eso en lugar de la causa.
El objetivo de la herramienta de formateo de código es eliminar toda la quisquillosidad que ocurre en las revisiones de código. Aquí no hay participación de microgerentes; el formateador de código hace su trabajo, y eso es todo.
@DanielRoseman Si tiene revisores de código quisquillosos con el formato del código, entonces tiene un problema real. Y no sé si no lo expresé lo suficientemente claro: la herramienta de formato de código es el microadministrador.
@ gnasher729 nah, es una muleta para aquellos colegas que no se molestan en proporcionar un código con un formato limpio. Si él mismo lo hizo "bien", la herramienta no haría cambios. Obviamente no lo hace. Entonces, esta es una forma de evitar cualquier discusión cuando alguien más ve los cambios, deshaciendo todo el buen formateo y ensuciando la revisión del código.
Dicho esto, es posible que esta herramienta o el formateo que hace esté haciendo su trabajo de manera incorrecta. Pero ese es otro punto de tener una herramienta de este tipo en general.
No podría sumar el tiempo total perdido en nuestro intento fallido de introducir el formato automático en nuestra base de código heredada hace unos años. Incluso ahora tenemos que dedicar tiempo a solucionar el conflicto de fusión ocasional debido a los cambios cometidos durante ese tiempo.
Equiparar los estándares de formato con la microgestión es incorrecto en muchos niveles.
¿Realmente te gusta formatear el código manualmente? Me he vuelto completamente dependiente del formateador automático que usamos en el trabajo. Es una tarea servil que estoy muy feliz de dejar a una herramienta automatizada. Soy demasiado mayor para molestarme en asegurarme de formatear siempre correctamente cada línea fuente.

No se trata de formatear el código. Se trata de ser un gerente bueno y eficaz y hacer cumplir una decisión que ha tomado sobre cómo funciona el equipo, lo que, como ha dicho, se considera y es probable que beneficie al equipo en general.

Creo que el problema se ilustra mejor eliminando los detalles de su pregunta:

Soy el gerente de un pequeño equipo de desarrolladores.

-- Tomé una decisión sobre un detalle de cómo trabajamos --

Desde entonces, un colega siempre se queja y expresa su desacuerdo sobre esta decisión.

Es un problema de personas, la parte difícil de ser gerente. Es tentador tratar de abordar el contenido de las quejas porque son un territorio familiar y cómodo y se pueden argumentar de manera más o menos objetiva.

Pero resista esa tentación, porque lo que realmente tiene que hacer es decirle a este miembro del equipo, de manera directa y sin ambigüedades, que debe aceptar la decisión y dejar de discutirla.

Es personal, es incómodo, pero hacerlo es parte del trabajo y es lo que el resto del equipo quiere y espera que hagas, te lo aseguro.

Es más, la causa es probablemente también un problema de personas. Si bien este colega protesta por el resultado del cambio, en realidad puede estar objetando la forma en que se realizó el cambio o algún otro aspecto del cambio. En cuyo caso, el formato es solo una pista falsa, el problema real es otra cosa, y la resolución es discutir las cosas con él, descubrir cuál es el problema real y abordarlo.
Si usted es un gerente bueno y eficaz , nunca debería ser necesario hacer cumplir una decisión que ha tomado .
La gestión autoritaria puede ser eficaz en algunos entornos, pero rara vez lo es para los trabajadores del conocimiento. Si se enorgullece de su trabajo, entonces ser microadministrado, que sus decisiones sean anuladas o que sus opiniones sean ignoradas puede ser un serio impedimento para la productividad y la creatividad. Cuando las cosas se ponen feas, tu gerente debe ser quien sostenga el paraguas mientras lo arreglas.
@MarkBooth completamente de acuerdo con esto. Mi suposición aquí es que es una decisión que se tomó teniendo en cuenta las opiniones de la mayoría del equipo; obviamente, si más que solo este individuo está en contra, o si después de probarlo en la práctica, sus objeciones tienen sentido y él cambia su / mentes de otros miembros del equipo, entonces, por supuesto, debe volver a evaluar la decisión.
No estoy muy seguro. Dado el "en la sugerencia de otro colega" y "Encuentro valor" en otros lugares, mi suposición fue que "presentamos" estaba usando el Royal we . Es un rasgo común de la gestión autoritaria que los dictados de un gerente individual estén envueltos en un consenso falso o falso. "¿No recuerdas, todos acordamos esto en la última reunión?", "No, tú lo sugeriste, expliqué por qué eso no funcionaría y dijiste que lo discutiríamos más tarde". Tal vez me estoy volviendo cínico en mi vejez. *8')

Hace unos meses, por sugerencia de otro colega, introdujimos el formato de código obligatorio en la base de código

Desde entonces, un colega siempre se queja y expresa su desacuerdo sobre esta decisión.

El problema central no se relaciona con la decisión en sí, sino con el hecho de que la opinión de este colega no se tuvo en cuenta al tomar una decisión que los afecta en gran medida. ¿Se discutió esto adecuadamente, con todos los pros y los contras evaluados cuidadosamente (eso también se aplica a la parte automática de la aplicación), o simplemente tomó la decisión unilateralmente "porque personalmente me gusta"? La práctica muestra que es mucho más probable que una persona defienda una decisión grupal si siente que su opinión fue escuchada y tenida en cuenta, incluso si al final no llegó a la decisión.

Siendo realistas, la gente deja los equipos. El uso de estilizadores como estos hace que sea más fácil para otra persona retomar el proyecto en el futuro y comprender el contenido real en lugar de entender el formato del mismo.

Trate de responder con un positivo de usarlos. Por ejemplo, "los formateadores de código son bs", "bueno, puede ser más fácil encontrar errores simples en el código cuando sabes cómo debe verse", etc. Aún mejor si pueden ser relevantes para tu proyecto/equipo directamente.

Si hubiera sido más de un miembro del equipo, habría sugerido realizar una reunión para explicar por qué se usa esta herramienta de formato, el beneficio que brinda y por qué es tan importante que sus desarrolladores la usen. A la gente no le gusta el cambio cuando no entienden las razones detrás de él.

Estoy de acuerdo. El código correcto debe verse bien y el código incorrecto debe verse mal. Y el poder de esto es que el cerebro humano, al ser una máquina de búsqueda de patrones y creación de significado, analizará los patrones de código que ve una y otra vez y luego desarrollará un "sentido" cuando algo no se ve bien, con todo esto sucede sin un esfuerzo consciente. Eventualmente, los errores se detectan, o ni siquiera se escriben, porque "el código incorrecto se ve mal". Cuando un equipo no es consistente, cada miembro diferente experimentará "advertencias" falsas sobre el código incorrecto, solo para descubrir que es solo una diferencia de formato. Eso es malo.
@CodeSeeker: bien dicho.

Lejos de ser una respuesta completa, pero hay un punto aquí que me llama la atención. El formato de código en sus confirmaciones de ninguna manera necesita ser el mismo formato de código que se usa en el IDE de un desarrollador mientras trabajan en una copia local del repositorio. No sé si alguna vez trabajé en un proyecto colaborativo en el que cada desarrollador no tuviera su código formateado tal como lo querían. Aplicar el formato al confirmar es bastante fácil de configurar a través de git hooks .

Totalmente de acuerdo con esta respuesta. los ganchos de compromiso previo son la respuesta. Otras herramientas de VC tienen controles similares. El uso más básico de esto es garantizar terminaciones de línea coherentes en entornos de desarrollo mixtos. El desarrollador es libre de hacer lo que quiera, pero el enlace de confirmación garantiza confirmaciones "limpias".
Esto es exactamente lo que estaba pensando, cómo formateo el código, es muy diferente de cómo los otros desarrolladores de mi grupo forman el suyo. Cuando abren mi código en su IDE (generalmente usamos VS Code para material web y VS Studio para escritorio), aparece en su formato. Es cierto que no estamos escribiendo Python, lo que requiere un manejo riguroso de la sangría, pero no hay ninguna razón por la que un desarrollador determinado tenga su código formateado deba hacer alguna diferencia en la forma en que otros formatean el suyo.
@delliottg: Sí, y el uso de un formateador automático de este tipo podría resolver el problema de Python, donde el código escrito por alguien que usa tabulaciones literales para la sangría se desmorona en un editor con un espaciado de tabulación diferente.
Y tenemos exactamente eso, a uno de nuestros desarrolladores senior le gusta usar espacios para las sangrías, yo prefiero las tabulaciones, pero no cambio el formato de su código para eliminar los espacios, y él no cambia mis tabulaciones por espacios. (Recuerde que no usamos Python u otros lenguajes con formato de sangría). De vez en cuando discutimos al respecto, pero no es tan importante para ninguno de nosotros que queramos imponerlo con un linter o alguna otra herramienta.
No estoy seguro de que las personas que sugieren esto en realidad sean desarrolladores que trabajan con código. El reformateo automático hace que las fusiones, los números de línea y las diferencias sean una pesadilla.

Encuentro una gran diferencia entre insistir en un código bien formateado y la imposición de un formateador automático en el registro.

En mi trabajo, tenemos una especie de mandato de formato de código, que se carga en el IDE, pero cuando sale realmente mal, realmente hay algo que podemos hacer al respecto porque nada intentará volver a aplicarlo en el momento de la confirmación .

Estoy dispuesto a creer que tiene un problema real de un desarrollador principal que hace cosas deliberadamente para que sean más difíciles de retomar, pero es muy posible que lo que realmente esté sucediendo aquí sea que el formateador automático está estropeando bloques formateados a mano donde el el lenguaje se ha convertido en otra cosa y, por lo tanto, necesita un formato diferente que coincida con la estructura que realmente tiene en lugar de lo que el analizador cree que tiene.

Estos casos no se distinguen de su publicación. Dependiendo de lo que esté sucediendo, es posible que pueda o no hablar con sus otros desarrolladores y averiguar cuál es. Sin embargo, tenga cuidado con la actitud de "Creo que es mejor porque el jefe lo cree"; no se te hablará, pero lo he visto caer así antes.

De hecho, es posible que todo el mundo tenga un problema con eso, y todos dejen que este tipo sea el portavoz. Tal vez puedas averiguarlo.

Pero al hacer su diligencia debida, si descubre que está en un viaje de poder, es hora de deshacerse de él.

Y si descubre que es usted quien está en un viaje de poder, es posible que desee pensar en cómo eso afectará el rendimiento de su equipo en el futuro.

Tienes una conversación franca sobre lo que significa la palabra "profesionalismo".

Su "desarrollador principal" está actuando como un niño que hace pucheros. Él/ella puede tener las habilidades técnicas de un líder, pero obviamente carece de las habilidades profesionales de un líder. Se trata de algo más que escribir código: las habilidades técnicas son un requisito previo necesario pero no suficiente para ese puesto. Ser líder significa, al menos para mí, comprender que no se trata de ti . Eso no significa que no negocies y abogues por ti mismo, significa que no te enfades por las cosas que son las mejores prácticas de la industria, incluso si en privado piensas que son una mierda (mirándote, JIRA ).

Comenzaría diciendo que él/ella necesita superarlo diplomáticamente, luego pasar a decirlo sin diplomacia, luego pasar a un PIP. Ya has desperdiciado demasiado de tu valioso tiempo en la rabieta de otra persona.

EDITAR basado en la conversación en los comentarios.

Un comentarista señala correctamente que la autoridad del líder técnico puede haber sido socavada injustamente, lo que provocó descontento. Aunque ciertamente estoy de acuerdo en que ese podría ser el caso, quejarse de la herramienta en público es una respuesta poco profesional e inaceptable a la situación . Ser socavado debe abordarse directamente y en privado .

Conocí a algunos programadores que no podían entender la necesidad de estándares de codificación consistentes. Si no pueden entender eso, les garantizo que habrá otras cosas importantes acerca de la programación que no podrán entender. No hay cura para eso.
@Ed Plunkett: Pero hay una diferencia entre consistente y bueno. He conocido a personas que aplican un formato de código perfectamente consistente que hace que su código sea casi ilegible, para mí, de todos modos. ¿Quizás sus cerebros funcionan de manera diferente?
@jamesqf "Coherente" en el sentido de que todo el equipo lo hace de la misma manera, preferiblemente de una manera (PEP3 en el caso de OP) que sea común en la industria y que los nuevos miembros del equipo entiendan fácilmente. En C#, en mi equipo, usamos los valores predeterminados de VS. No es mi favorito personal, pero es muy claro y muy cercano a lo universal, lo cual es mucho mejor que simplemente cumplir con mis estándares estéticos privados.
@jamesqf Los tipos del "cerebro funcionan de manera diferente" son los que tienen los problemas de comprensión incurables que mencioné. Disfrutan siendo difíciles. En una industria llena de personas "no neurotípicas", con mucho tacto, obtienes algunas de esas.
PEP 3 son las Pautas para el manejo de informes de errores @EdPlunkett, creo que quiso decir PEP 8 , y el negro va mucho más allá de PEP 8.
@MarkBooth. Correcto, eso fue un error tipográfico. Gracias. Mi punto era que OP no está imponiendo un extraño conjunto arbitrario de convenciones de formato.
Habiendo echado un vistazo al negro, el formato que aplica es bastante extraño @EdPlunkett. Ciertamente, nunca he visto a nadie escribir código a mano que se parezca al formato que genera, y apoyo un producto que contiene un intérprete de python incorporado, por lo que puedo ver todo tipo de python extraño y maravilloso generado por el usuario. De hecho, apruebo los cambios que hace, en teoría, pero no puede esperar que a todos les guste desde el principio, sin tener la oportunidad de acostumbrarse a las ventajas que ofrece potencialmente.
@MarkBooth, el argumento no se trata de los méritos de ese formato en particular (o la falta de él), el compañero de trabajo de OP está en contra de tener un formato estándar, punto. No soy un gran admirador de PEP 8 en varios aspectos, pero bueno, no se trata de mí. Los argumentos sobre qué estilo de formato es mejor son para la barra (los disfruto tanto como el próximo idiota obstinado), no para la sala de juntas.
Esto probablemente debería trasladarse a The Workplace Chat @JaredSmith, pero mi punto fue que el uso del negro no es una decisión incontrovertible, puedo ver lo que hace cumplir, molestando mucho a algunas personas. Ciertamente, no debería haberse hecho sin la participación del desarrollador principal del proyecto. El OP nunca debería haberse metido en esta posición en primer lugar.
@MarkBooth está de acuerdo contigo sobre el chat. No estoy seguro (después de leer su respuesta) de no estar de acuerdo con usted, no tenemos suficiente información para juzgar. Pero definitivamente he trabajado con desarrolladores que insistieron a pesar de haber sido amenazados con la rescisión del contrato por su propio formato extraño e ilegible porque, y cito, "es a lo que estoy acostumbrado y no quiero cambiar". Si el desarrollador tiene objeciones legítimas, hay una manera de hacerlas. Pero según mi lectura del tono de la pregunta, suena mucho más como el caso de un ataque de histeria que como uno cuidadosamente considerado.
Mi sospecha es que el 'ataque de silbido' fue solo después de que el desarrollador principal ya había visto socavada su autoridad irrazonablemente. Recuerde que solo escuchamos esto desde el punto de vista del OP, por lo que lo mejor que podemos hacer es leer entre líneas. Ahora se trata de control de daños, y eso significa escuchar, no dictarles lo que es 'profesionalismo' o hablar de medidas disciplinarias, como parece estar haciendo esta respuesta. Hablando de eso, es posible que desee definir lo que quiere decir con "pasar a un PIP". Supongo que te refieres a "Plan de mejora profesional", pero no estoy seguro.
@MarkBooth sí, plan de mejora del rendimiento. Y no, ahora me doy cuenta de que no estoy de acuerdo contigo: incluso si la autoridad fue socavada sin razón (y tienes razón, bien puede haber sido así), lo denuncias directamente y en privado . No lo haces quejándote de la herramienta en público. Yo llamo travesuras.
@EdPlunkett ¿Incluyendo la sección de PEP 8 (supongo que quisiste decir 8) que dice "Una consistencia tonta es el duende de las mentes pequeñas"?
@immibis Gracias. Ese comentario destila toda una cosmovisión tan perfectamente.

En última instancia, como han dicho otras respuestas, como gerente, tiene la autoridad para simplemente hacer cumplir un estilo de código, y si a alguien no le gusta, puede renunciar. Sin embargo, esto probablemente no sea bueno para la moral o el compromiso, y un empleado que a regañadientes fuerza su código redondo a un estilo cuadrado probablemente no sea feliz ni productivo.

Con ese fin, su mejor curso de acción probablemente sería convencerlos de que tener un estilo consistente en una base de código es beneficioso. Algunas respuestas ya han presentado algunos puntos, pero hay artículos y, de hecho, libros completos que argumentan a favor. Tienen razón en que son como los colores: todos tienen un favorito, pero si cada desarrollador de UI que trabaja en un proyecto simplemente eligiera su color favorito para diseñar, el producto final no se vería nada bien.

Un par de buenos artículos que acabo de encontrar con una búsqueda rápida:

Asumiré que sus representaciones de los comentarios de su desarrollador principal son precisas.

Estos no son los comentarios de un desarrollador principal competente. Lo digo como un software experimentado y gerente de ingenieros de software.

La retroalimentación es poco constructiva y altamente imprecisa. Un desarrollador líder que no comprende el valor de los estándares de formato es un desarrollador líder que no comprende la dinámica de la ingeniería colaborativa.

Es muy posible que tengan preocupaciones legítimas y procesables y comenzaría desde esta perspectiva. Eres su gerente; ayudarlos a hacer bien su trabajo.

Primero, llámelos en privado por sus malos comentarios. Están haciendo mal su trabajo, si solo están molestos.

A continuación, demuestre que está abierto a comentarios prácticos sobre cómo mejorar la implementación de los estándares de codificación si su desarrollador tiene alguno. Si necesitan tiempo para encontrar la mejor manera de articular esto, dáselo.

Si no tienen nada específico, entonces dígales que sigan el programa y dejen de quejarse. No es solo improductivo. Es perjudicial para el equipo.

También debe comenzar a prestar atención a su desempeño como líder en el equipo en general. ¿Están realmente brindando liderazgo a los otros miembros del equipo o son simplemente la persona que ha estado presente por más tiempo? Personas como esta realmente pueden socavar la productividad de un equipo si solo actúan como guardianes del crecimiento (que es lo que esta persona está haciendo en este momento).

Sugeriría que la explicación más probable es un gerente en un viaje de poder, representando lo que dice el líder del equipo de la manera más negativa posible. Por ejemplo, me parece muy poco probable que un desarrollador diga "el formato de código no tiene sentido" porque en realidad no tiene otra opción que formatearlo de alguna manera, pero que alguien diga "las herramientas de formato de código no tienen sentido", eso puedo creerlo.
Ciertamente es posible, pero definitivamente escuché a ingenieros senior decir las cosas más tontas sobre "su libertad está restringida" cuando lo que realmente quieren decir es "No puedo molestarme en considerar a las otras personas que verán este código".

Desde un punto de vista pragmático, me encanta el formato de código simplemente porque hace que diferenciar código sea mucho más fácil. También facilitará mucho los envíos, ya que si todos usan el mismo formateador de código, entonces, en principio, agregar un cambio tonto e intrascendente a un archivo no hará que git piense que el código ha cambiado.

Personalmente, no estoy loco por el aspecto del código, pero los beneficios descritos anteriormente me ayudan a pasar por alto esto.

-1 Esto no responde la pregunta. Sí, el formato del código es bueno, pero OP ya lo sabe.

Muchas otras respuestas discuten si el formato de código vale la pena o no. Eso es completamente irrelevante para esta pregunta.

Se trata de comunicación, no de convencerlo de que el formato de código estandarizado es excelente. Da un paso atrás. Lo que necesitas comunicar es:

  • Lo que estás tratando de lograr.*
  • Cómo planea medir el éxito.

Esa información adicional les permitirá ver las cosas desde su punto de vista, lo que a menudo es suficiente para apaciguarlos. La segunda parte (medir el éxito) es necesaria para demostrar que realmente piensas en ello y hace que sea más fácil para ellos confiar en ti. También les permite encontrar alternativas o modificaciones a la póliza que satisfagan sus solicitudes y las de ellos.

Si eso falla, hay 2 formas principales de tratar con los empleados que no están de acuerdo con un cambio de política:

  • Escúchalos. Son profesionales pagados y sus preocupaciones pueden ser más válidas de lo que piensas.
  • Cállatelos. "Esta es la decisión. Sé que no te gusta y he escuchado tus preocupaciones, pero ahora necesito que lo aceptes y trabajes con el equipo".

*No se trata de una lista de beneficios, se trata de su motivación para implementar el cambio. Tal vez desee empoderar al equipo y por eso hizo que el equipo decidiera sobre los estándares y el formato del código. Tal vez acabas de implementar una sugerencia de arriba. Tal vez esté planeando múltiples cambios de automatización y/o análisis en el futuro que se beneficiarán del formato estandarizado. Tal vez desee utilizar un formato estandarizado para vender mejor su equipo a los superiores. Tal vez impulsó el formato estandarizado simplemente porque le gusta.

el formato de código es una mierda

Esto se puede refutar fácilmente tomando algún código de ejemplo (desconocido para el desarrollador), eliminando todas las líneas nuevas, tabulaciones y reduciendo múltiples espacios a espacios únicos, y pidiéndole al empleado que le diga qué logra el código.

son como los colores, a algunas personas les gusta el rojo, a otras el azul, eso es todo

Sí. Este es el caso de casi cualquier disputa de programación. Tabulaciones vs espacios, corchetes estilo C o corchetes egipcios, ... Pero la respuesta es siempre la misma: a algunas personas les gusta conducir por la izquierda, a otras les gusta conducir por la derecha. Cualquiera de los dos está bien, pero permitir ambos al mismo tiempo conduce a la locura.

O, si realmente quieres usar su analogía en su contra: pero usar azul y rojo juntos da púrpura, lo que significa que nadie obtiene lo que quiere.

Se ha tomado una decisión ejecutiva para elegir este formato. Su empleado no tiene la autoridad para anular esa discusión. Fin de la historia. No seguiría con esta línea de preguntas.
Siempre estoy abierto a comentarios constructivos, pero el argumento de su empleado es de cabeza dura, no es constructivo. No dejes que lo conviertan en una competencia de ser el más terco. Incluso si gana, le está indicando a su personal que ser obstinado es una forma aceptable de expresar su desacuerdo.

Eso no significa que no puedas ayudarlo si es simplemente una cuestión de inexperiencia. Tal vez pueda encontrar un formateador automático para que pueda escribir en su propio formato y convertirlo.

Le dije a las personas que administré que no me importa la legibilidad de su código antes de que lo registren. No espero que respeten completamente la guía de estilo en cada segundo. Siempre que el código se limpie antes de que se fusione con la rama, es aceptable. A menudo empiezo con un código rápido y sucio y solo lo limpio una vez que lo tengo funcionando. Algunas personas trabajan de esta manera, y está bien, siempre y cuando no se salten la limpieza requerida al final.

reduce mi libertad

Nadie tiene la libertad de hacer lo que quiera. Tener que pagar a los empleados también reduce la libertad de la empresa.

El esfuerzo requerido para formatear el código desde el principio dará sus frutos cuando alguien más tenga que leer su código.

Dados los comentarios de este empleado, sospecho que es probable que se haya quejado del formato de código o las convenciones de nomenclatura de otras personas. Señale que otros sentirán lo mismo acerca de su formateo y denominación. La uniformidad significa que todos pueden leer el código de todos, sin importar si es la preferencia personal de todos.

hace que el código sea más complicado de leer sin valor añadido

Ahora le resulta más difícil leer porque no está acostumbrado. Cuanto más se resista al cambio, más luchará con él. La decisión ha sido tomada, está ocurriendo, fin de la historia.

Me centraría en el punto de que el empleado ha sido informado del nuevo formato y se espera que ahora lo respete. Si no cumplen (o no hacen un esfuerzo genuino), cualquier retraso causado por el rechazo de sus solicitudes de extracción recae directamente sobre sus hombros.

Las solicitudes de combinación de código deben formatearse con la herramienta; de lo contrario, no se pueden agregar al software.

Cuando dice "no se puede", ¿quiere decir que no está permitido o que no es posible (por ejemplo, un revisor siempre rechazará la solicitud)?

Si es lo último, ese es el palo que necesitas. Si el desarrollador no sigue las reglas de formato, sus solicitudes no se aceptan y los retrasos que esto genere son su responsabilidad, lo que resultará en una mala revisión de rendimiento.

Si es lo primero, entonces realmente estás confiando en que todos participen deliberadamente en el sistema, que solo funciona si todos lo hacen. Actualmente estás tratando con alguien que se resiste. Es posible que se resista específicamente porque sabe que no lo impones, sino que solo lo pides.

Entonces crees ciegamente lo que OP te dijo. Claramente está fallando como gerente y quiere apoyo aquí, por lo que no creo que ninguna de sus citas sea precisa.
@gnasher729: No es una cuestión de creencia. SE no tiene un formato que permita que la contraparte diga su versión y luego nos permita arbitrar entre dos partes opuestas. El formato de preguntas y respuestas nos vincula inherentemente con el contenido de la pregunta tal como se formula. Solo puedo responder la pregunta como se me hizo, su aplicabilidad en la vida real depende completamente de cuánto se base la pregunta en la vida real. Aunque comúnmente se espera, no existe una verdadera protección para situaciones ficticias o tergiversadas.
@gnasher729: En segundo lugar, ¿en qué medida califica a OP como "fracasado como gerente"? No están seguros de cómo acercarse a un empleado que, según la experiencia de OP, se resiste a una convención de equipo sin ninguna razón real más que la falta de voluntad para adaptarse. ¿Cómo tratar de resolver el problema y adquirir información adicional equivale a fallar como gerente? ¿Recorre todas las preguntas publicadas sobre SO/SE y señala la incompetencia de cada OP porque no saben la respuesta a su pregunta?

Eres un gerente, así que tratemos de manejarlo (y esto), no solo lo regañes o lo veas como un problema:

"John, mi responsabilidad es hacer que esto sea lo más fácil posible para todos y para los futuros empleados, no solo para algunas de las personas que están aquí hoy".

"Cuando la mayoría de los desarrolladores revisan el código, es más rápido si pueden dar algunas cosas por sentadas, como la forma en que se realizará el código y la forma en que algunas cosas se estandarizarán. Si alguna vez es necesario que alguien analice el código [ externo ¿auditoría de código? ¿Responsabilidad? ¿Diligencia debida?] , es mejor si está estandarizado. Tienes razón en que a algunos les gusta el azul y a otros el rojo, y fuera del trabajo, tú y yo podemos codificar de la manera que queramos. Pero mientras Al escribir código que un equipo debe mantener y que los futuros ingenieros deben comprender de manera rápida y precisa, creo que la estandarización ayudará, y yo dirijo el equipo, no tú, ni Bob, ni Alice, así que tengo que hacer ese tipo de llamadas si siento la necesidad, y lo hago".

"Cuando te encuentres gestionando proyectos como este en el futuro, puedes hacer la llamada que quieras y esperar que los demás sigan tus instrucciones. Pero espero que cuando lo hagas, y eres bueno, así que probablemente lo harás [un cumplido nunca está de más si es cierto, si no lo dejas fuera] , que lo reconsiderarás y verás los beneficios que brinda, incluso si impone una disciplina que no le ves ningún sentido, en este momento".

"Creo que ahorrará una pequeña cantidad de tiempo en el trabajo diario, cuando se rehace el código, creo que reducirá los errores y creo que es profesional. Me gustaría que respetes eso incluso si no estás de acuerdo con él."

Tenga en cuenta que es probable que el desarrollador líder sepa mejor que el gerente cómo desarrollar código con éxito.

El espacio en blanco es en realidad parte de la pythonsintaxis. La legibilidad ya está diseñada en el lenguaje. De hecho, Python tiene sus propias recomendaciones sobre cómo formatear su código. Mejores prácticas, convenciones de nomenclatura, etc. se llama PEP (más específicamente PEP8). ¡Empieza por ahí! ¡Conocer a PEP es algo que pueden agregar a su currículum!

¿Cómo lidiarías con tal situación?

Creo que los otros cuatro desarrolladores están del lado correcto de este argumento y usted puede estar equivocado aquí. Acepte honestamente los comentarios de sus empleados y tómelos en serio. Ponte en sus zapatos. Si el cheque de pago se basa en el rendimiento y esta herramienta reduce eso, básicamente les está quitando dinero en su mente .

Creo que un buen próximo paso es decidir si continuar o no usando la herramienta. Si lo considera beneficioso, explique por qué . Por ejemplo, si el usuario final/cliente le brinda mejores reseñas o proyectos futuros porque el código es hermoso, ¡dígaselo a sus empleados! ¡Eso significa más dinero en su bolsillo!

Recuerde, sus KPI para el control de calidad pueden no ser lo que está en la descripción del trabajo para los miembros de su equipo. Haga que su equipo se involucre en sus proyectos. Que sea algo de lo que estén orgullosos. Cuando un fuerte sentido de propiedad es una norma en el lugar de trabajo, la garantía de calidad es algo natural.

Solo un desarrollador en el equipo se opone al formato consistente, no cuatro. La herramienta OP mencionada, negra, aplica PEP8 . No es realista afirmar que el formato de código coherente reduce el rendimiento de nadie. Todo lo contrario: el valor de los hábitos de codificación consistentes ( incluido el formateo) está en la facilidad de mantenimiento. El rendimiento laboral de un programador no depende de cuántas sentencias if pueda escribir en una hora determinada.
@EdPlunkett Es divertido que diga "hace cumplir PEP8" porque una sección de PEP8 dice que no debe aplicarse. Por lo tanto, hacer cumplir PEP8 no es en realidad conforme a PEP8.
@immibis Eres un regalo, amigo. Un regalo absoluto. Nunca supe que la ciudadanía soberana había sido portada a Python.
@EdPlunkett Nomino esto como el comentario más absurdo del mes.
Justo en la parte superior de PEP8: ¡ A Foolish Consistency está el Hobgoblin of Little Minds !

Vale la pena considerar dos puntos adicionales.

  1. Estás pidiendo una respuesta en blanco y negro para un problema de escala de grises. Sus reglas de formato de código podrían ser razonables, podrían ser relajadas, podrían ser quisquillosas. He visto todo tipo de reglas. Entonces, antes que nada, verifique si las reglas de formato de código que exige son realmente razonables o no.
  2. ¿El formato del código y todas las reglas estándar del código fueron simplemente impuestas desde arriba, o acordadas por los desarrolladores del equipo, aquellos que realmente escriben el código y que leen/usan el código de otros? Podría ser una buena práctica decidir sobre un conjunto de reglas estándar de codificación por comité, solo una vez, y luego estas reglas se aplican. Si la mayoría de los desarrolladores están de acuerdo con ellas, entonces tienes muchas posibilidades de que estas reglas sean razonables, y si alguien se queja, lo más probable es que él sea el problema. Si las reglas fueran simplemente impuestas por decreto de una persona... bueno, entonces podrías tener un problema ahí.
  3. Una alternativa es encontrar una herramienta de formato/inspección de código que sea más o menos el estándar de la industria para el lenguaje que utiliza. Por ejemplo, para C# uso Resharper. Entonces la decisión será imparcial, y el formateo se puede hacer más o menos automáticamente en el editor, a medida que se escribe el código. Si Resharper está feliz, yo estoy feliz. Encuentra algo de ese tipo para Python.

Mi regla general personal cuando dirijo un equipo es insistir en reglas estrictas solo cuando el código de alguien se ve realmente feo... y si eso sucediera, podríamos estar viendo un problema más profundo que solo el formato del código. Un problema que parte de Recursos Humanos y de contratar a la persona equivocada. De lo contrario, si el código se ve más o menos claro y organizado, y su arquitectura/diseño es bueno, los detalles sobre el formato a menudo causan más problemas de los que valen la pena.

La consistencia es un argumento débil. Para una persona que no está de acuerdo con una regla de formato en particular, puede sentir que hay un problema con la microgestión o con un arquitecto hambriento de poder. El formato casi nunca importa: "son como los colores, a algunas personas les gusta el rojo, a otras el azul".

El beneficio real de las reglas de formato automatizadas es que los programadores no pierden el tiempo discutiendo cosas que no importan. Se dedica demasiado tiempo a las revisiones de código en los comentarios sobre la sangría. Se debería concentrar mucho más poder mental en problemas reales con el código.

Presente al desarrollador el término Bikeshedding . Deje en claro que considera que sus comentarios son una gran contribución al diseño de cobertizos para bicicletas. Pierde el tiempo de los demás. Es un mal jugador de equipo. Se utilizará en su contra durante la evaluación.

Además de las otras respuestas que ya cubrieron The Talk bastante bien, una metodología para introducir formato en su proceso, le guste o no a Bob:

Realice revisiones de código utilizando el principio de los cuatro ojos en todas y cada una de las solicitudes de fusión. Solo debe modificarse mastercon la solicitud de fusión aceptada, de ninguna otra manera. Todas las solicitudes de fusión deben estar sujetas a control de calidad, es decir, un miembro del equipo diferente debe revisar el código. Aplique el formato y deje que los MR de Bob se rechacen debido a un formato de código incorrecto.

Si Bob se niega a cumplir, sus solicitudes de fusión quedarán atrapadas en el limbo. Cuando se le pregunta, "¿por qué no se ha realizado la característica XY, a pesar de que la fecha límite ya pasó?", Bob puede responder, "esto se ha hecho durante un tiempo, pero fue rechazado por el colega Y". Se puede argumentar que entonces no se hace. Para eso está el control de calidad. Los compañeros de trabajo deben rechazar tales solicitudes y reasignar a Bob, entonces es el trabajo de Bob lidiar con eso.

Hay varios grados de agresividad si se actúa de esta manera, por lo que si desea que el tono se mantenga lo más amigable posible, tenga cuidado con la forma en que lo implementa. Sin embargo, debe hacer revisiones de código de todos modos.

En una nota personal, las supuestas declaraciones de Bob sobre la utilidad del formato me inclinan a pensar que posiblemente no son adecuados para un papel principal o simplemente carecen de educación específica en ciertas áreas. Tal vez conozcan el código base por completo, pero debido a la falta de mejores prácticas ayudaron a convertirlo en un desastre gigante y solo ellos conocen un camino a través del caos. Este tipo de cosas es peligrosa, porque puede volverse muy dependiente de una sola persona a medida que su base de código se vuelve cada vez menos mantenible.

Creo que en este caso sería posible agregar un git hook que cambie el formato del código al deseado por el equipo al confirmar, y otro (usado solo por ellos) que cambie el formato del código al deseado por el miembro del equipo en la actualización.

Si el miembro del equipo está tan convencido de esto, también puede ser una buena ocasión para aprender más sobre el formateador de código y las herramientas de git, todos los conocimientos que pueden ser útiles más adelante.

Un gran no. Es propenso a las inconsistencias y no hay forma de que todo el equipo deba adaptarse a los lloriqueos sin fundamento de uno solo.
Me gusta su idea, pero hay demasiadas cosas que las herramientas no pueden solucionar (p. ej., cualquier cosa en los comentarios, como el código de ejemplo en las anotaciones de autodoc, cualquier sintaxis más nueva para la que no se haya parcheado, etc.). No vale la pena tener que verificar constantemente el código de los infractores y pasar por múltiples fallas de revisión de código en cada solicitud de extracción.
No sé qué tan relevante es para python, pero solíamos tener una herramienta (más limitada a diferenciar/fusionar) que conocía la sintaxis del lenguaje y hacía diferencias sintácticamente conscientes.
Esto suena ridículamente propenso a errores, y el tipo de colega me parece alguien que se opondría a cualquier estilo de código o autocorrección (es decir, no es consistente en su propio estilo). Esto no es factible.

Aquí hay muchas respuestas que se centran en buenos argumentos técnicos. Para resumir: el equipo tomó una decisión acertada sobre cómo proceder, y un individuo rechaza la decisión del equipo y las instrucciones del gerente.

La conversación que tendría es más parecida a: ¿acabas de llamar "mierda" a mis instrucciones y la decisión del equipo? ¿De verdad te quejaste de que cobrar por trabajar "restringe tu libertad"? Le sugiero encarecidamente que registre su código con un formato agradable ahora mismo, y organizaré una reunión con Recursos Humanos para hablar sobre el respeto hacia su empleador, gerente y equipo.

Entonces, ¿estás diciendo que una decisión es la decisión correcta porque viene de arriba y el respeto debe estar ahí? Yo diría que no, no es exactamente así como deberían funcionar las empresas de tecnología, los codificadores deberían estar convencidos de lo que hacen y cómo, no forzados. Eso sería muy improductivo hasta peligroso.
@ Mayou36 No, lo que digo es: llamar a las herramientas de equipo "b******t" está fuera del alcance de la comunicación profesional, especialmente si no tiene argumentos sólidos. Y afirmar que las pautas en el trabajo "restringen su libertad" es una forma extraña de entender un contrato de trabajo. Especialmente para algo que en realidad es un tema de equipo.
@ Mayou36 tal vez publique el comentario en la respuesta incorrecta. Esta respuesta maneja el lado político/interpersonal del problema y no hace ningún juicio sobre el problema técnico: se toma como "sólida" porque está de acuerdo con la gerencia y el equipo, pero uno.
No, Mayou tiene razón. Cuando contratas a un programador (o a cualquier otra persona), obtienes un cerebro gratis con cada empleado. Si los intimida, y esta respuesta sería intimidante, incluso si algunos la consideran válida/legítima, daña la moral y la productividad. Los demás sabrán que reacciona de esa manera, y se formará una división entre usted y el equipo, y las cosas que necesita escuchar no se le dirán a usted, para su propio perjuicio y el del equipo. Los malos gerentes coaccionan temprano. Los buenos gerentes prueban enfoques cooperativos y reservan líneas duras para cuando realmente se necesitan debido a la urgencia o porque otros...
... los enfoques han fallado. Pero a pesar de las conversaciones en el OP, no veo nada en la pregunta que sugiera que se ha llegado a ese punto, porque no se describe ninguna descripción de ningún intento de manejar la situación de manera real y adecuada. El OP está preguntando cómo manejarlo en este momento. Entonces, una respuesta de intimidación es demasiado exagerada, y estaría hablando con cualquier gerente que vea dañar a su equipo si lo veo sin una muy buena razón, que aún no existe: y usar esta situación como una forma de mejorar sus habilidades de gestión de personas y comprobar si tenemos un problema cultural al acecho.
@Stilez: Informar a un empleado que en algún momento la insubordinación y el rechazo al trabajo en equipo puede tener consecuencias profesionales no es acoso. Llamar "b******t" a lo que dicen tus compañeros de trabajo.
"En algún momento"... Y de esa manera. Es la forma, más que la información, lo que me hace verlo como una respuesta de intimidación. La misma información se puede dar de muchas maneras, y el problema también se puede tratar de muchas maneras. Escalar a una amenaza implícita simplemente no es necesario ni útil para el OP como se describe, y la respuesta no parece un juicio apropiado de dónde está ese punto, y no muestra comprensión de la gestión: habilidades blandas y formación de equipos. Puedes ganar una discusión por la fuerza, pero aun así perder a tu equipo, buena voluntad, cooperación y (a largo plazo) la guerra. Esta respuesta va en esa dirección.
En cuanto a "el equipo tomó una decisión acertada sobre cómo proceder", tengo la impresión de que no fue el equipo en su conjunto el que tomó esta decisión sino el entrenador quien tomó la decisión y quiere nuestro consejo sobre cómo puede imponérselo a su equipo. De ahí el problema.
@Paolo, ese es mi punto, si el equipo y la gerencia estuvieran de acuerdo, lo desaconsejaría encarecidamente usar "Soy su superior" como argumento para hacer que lo siga. Es como una "última relación" y debería estar allí para evitar daños, no como un concepto comercial, y sobre todo, no para los desarrolladores. Ponlo de tu lado, no le ordenes que haga cosas.
@Stilez: no, el bullying sería lo siguiente: Frente al equipo decir "Anda, empaca tus cosas y renuncia. No tenemos lugar para morder ponis especiales".
No. Es posible que desee pensar que no lo es. Haga ese tipo de cosas de forma rutinaria y su personal contará una historia diferente cuando regresen a casa del trabajo. Y esa es la historia que cuenta, no puedes hacer una redefinición de GWB de que el submarino no es una tortura en realidad, o hacer ese tipo de amenazas (que es lo que son) ya que tu respuesta básica no es realmente intimidación. Lo verán así, y tu equipo será el perdedor. No realices conductas de acoso, incluso si no consideras que esa es la palabra adecuada para ello.
La pregunta es, ¿quién es el acosador en esta situación? ¿El desarrollador principal cuya autoridad en el proyecto acaba de ser socavada y (algo) comprensiblemente reaccionó negativamente a las noticias, o el gerente que ahora está buscando formas de hacer que su desarrollador se alinee con sus declaraciones? Solo tener acceso a un lado de la historia hace que esto sea difícil de llamar. Por lo que sabemos, los comentarios citados por el OP pueden haber sido hechos extraoficialmente por el desarrollador principal, en privado, en un bar después del trabajo. El contexto lo es todo, y simplemente no lo sabemos.
Marca: O no en absoluto. Porque la mayoría de las citas parecen cambios ligeros en afirmaciones muy razonables.
El miembro del equipo está vehementemente en contra del formato de código
RespuestasAquíPolítica de privacidad1y, 0v