Déjalo ir. Está tratando de comprometerse entre 3 o 4 prioridades: sus preferencias, las convenciones del código, las preferencias del desarrollador senior cuyo código cambió y la capacidad del equipo para darle sentido al código. Según el desarrollador senior, su estilo de codificación tiene sentido para el equipo. Por lo tanto, las prioridades 3 y 4 se pueden combinar. Ahora es entre usted, las convenciones de código y el equipo senior de desarrollo.

Entre estas opciones, las convenciones del equipo y su relación con el desarrollador sénior, en mi opinión, son más importantes para la capacidad del equipo para realizar el trabajo que sus preferencias y las convenciones del código.

Teniendo en cuenta que eres nuevo, recomendaría dejarlo pasar y aprender de ello que lo que crees que es correcto no es necesario, lo que siempre debería terminar sucediendo.

Sospecho que otros aquí podrían retroceder y definitivamente hay espacio para un orden diferente de prioridades, pero este es probablemente el camino que yo habría tomado, al menos cuando todavía era un empleado relativamente nuevo. ¡Buena suerte!

Entonces, su superior y usted no están de acuerdo sobre lo que significan las convenciones de codificación y de qué manera es más legible. La forma de resolver esto es aclarar su comprensión para que todos estén en la misma página.

Por lo tanto, habría reaccionado de la siguiente manera:

ES: ¿ Por qué haces esto? Estás cambiando mi código. Somos un equipo ...

J: Traté de que se adhiriera a la convención de codificación. ¿Dice que deberíamos hacer XXX y mejorar el código existente cuando lo veamos?

Y luego escuche lo que dice y trate genuinamente de entender su punto de vista.

Y una vez que termine el debate técnico (y esperemos que los ánimos se hayan calmado), abordaré el lado social de sus comentarios. Nuevamente, esto funciona mejor como una pregunta:

¿Qué debo hacer si veo algo en su código que no entiendo o que creo que podría hacerse más simple?

Y vuelve a escuchar lo que quiere.

Esto logra varias cosas:

1. Su respuesta bastante emotiva indica que está emocionalmente comprometido con su código y siente que no se respeta su juicio experto. Al preguntar por su experiencia, demuestras que valoras su experiencia, lo que debería calmar la discusión.
2. Comunica que no fue tu intención faltarle el respeto o hacer alarde de las normas sociales. Más bien, le hace darse cuenta de que simplemente aún no sabías lo que se esperaba de ti y que estás tratando de solucionarlo.
3. Aclara lo que se espera de usted para evitar más conflictos accidentales.

Ya ha revertido los cambios. Así que déjalo ir.

Dicho esto, la próxima vez que esto suceda. Asegúrese de que no haya margen de maniobra con su interpretación de las convenciones de codificación. Porque, si vas a tener una batalla con alguien, asegúrate de elegir una batalla en la que tengas un 100 % de posibilidades de ganar.

Esto es importante especialmente si no tiene tanto capital social con la gestión como ya tiene esta persona.

Además, asegúrese de agregar pruebas unitarias antes de modificar demasiado su código. Si introduce errores en su código, nunca escuchará el final. Y cuando encuentres algo suyo que valga la pena cambiar. Luego, adelante, pero tenga cuidado y siga las convenciones oficiales (y si no las convenciones oficiales no abordan un problema en particular, siga al menos las convenciones de Code Complete ).

Si se queja con usted, entonces puede decirle que luche por cambiar las convenciones de código y que una vez que reciba la aprobación de esas nuevas convenciones de codificación que tiene en mente, estará encantado de echarles un vistazo e implementarlas. ellos, pero no antes de eso.

Además, probablemente debería pedirle a la gerencia que organice revisiones de código semanales. Después de todo, si tiene la oportunidad de discutir las decisiones de codificación durante las revisiones de código. Le brindará una forma más segura y menos conflictiva de comprender y/o desafiar algunos de los malos hábitos de sus compañeros.

mucho está pasando

Hay bastantes cosas pasando aquí. Se han abordado muchos de estos, y los mencionaré brevemente y mi visión de lo que debe o no debe hacer al respecto. Sin embargo, hay un punto que aún no he visto realmente abordado y que considero el mayor problema y lo abordaré con más detalle.

Corrección de errores y estilo

Solucionaste el problema y al mismo tiempo cambiaste el código.

En mi opinión, esto no es un gran problema, pero generalmente es mejor mantener cosas separadas en confirmaciones separadas. Esto habría tenido el agregado de separar el conflicto de la corrección de errores aquí también.

Diferentes puntos de vista

No está de acuerdo sobre qué versión sigue mejor las convenciones, es más legible y es más fácil de mantener.

Si es mayor que usted, podría ser bueno seguir su ejemplo en esto. Alternativamente, podría ser bueno que otra persona de la empresa revise el código junto con ustedes dos, observándolo desde esas tres perspectivas.

Código difícil

El código era difícil de entender para empezar.

Descubrí que es útil hacer preguntas sobre el código en tales situaciones, especialmente si sabe quién escribió el código (y/o el código fue escrito recientemente). Hacer preguntas puede ayudarlo a comprender mejor el código y ayudar a la otra persona a ver por qué el código fue difícil de entender para empezar. Esto a menudo trae a colación formas en las que el código puede aclararse por sí solo, lo que luego puede analizar antes de implementarlas.

El ataque

La otra persona se vuelve bastante agresiva al sugerir que tienes que separarte y que acudirá a tu gerente para mantenerte alejado de cierto código.

Como está escrito, esto es bastante serio. Depende un poco de qué manera se desvíe la diferencia entre las cosas reales que dijo y la forma en que lo parafraseó aquí, pero simplemente por la forma en que lo escribió, esto solo debería ser una razón para hablar con su gerente. Si lo hace, no lo haga por el código, sino por su actitud hacia usted en la que parece considerar que está bien amenazarlo.

Su código

No quiere que edites su código.

En mi opinión, este es el mayor problema. Esta es una actitud bastante tóxica y creo que golpea el núcleo del problema. Los programadores aficionados a menudo son muy protectores con su código y, a veces, eso se puede ver con los programadores profesionales que también han trabajado en el código por sí mismos. Sin embargo, no tiene cabida en ningún entorno profesional y es extremadamente tóxico cuando eres responsable del código como equipo.

En última instancia, el problema es que el código no es suyo. El código es de la empresa o quizás del equipo, pero no es suyo. En cambio, es código que ha escrito. Creo que es importante no referirse a él como su código, sino como el código que ha escrito. Sin indicar que no es su código o corregirlo cuando dice que es su código, puede ser beneficioso referirse a él constantemente como código que usted mismo escribió. Esto se aplica tanto en el momento en que está discutiendo la situación con él como cuando está discutiendo la situación con otros miembros del equipo o un gerente.

En primer lugar, diría que dejaría este incidente como está por ahora. Sin embargo, tampoco haría todo lo posible para evitar tocar el código que ha escrito en el futuro. Parece que esto va a ser algo que va a volver a surgir y caminar sobre cáscaras de huevo todo el día no va a ser de ayuda para nadie.

Suponiendo que está en un equipo con más miembros que ustedes dos, lo primero que podría hacer es hablar con otros miembros del equipo sobre el problema. Pregúnteles si han experimentado el mismo comportamiento y cómo lo manejaron o lo manejarían. Sus compañeros de trabajo son un recurso que no debe subestimarse. Si no hay otros miembros en su equipo, puede preguntar a otros colegas que hayan tenido que trabajar con esta persona en el pasado.

Luego, si este programador resulta ser sobreprotector con el código que escribió en otra ocasión, busque aplicar las sugerencias de sus colegas. Más allá de eso, también puedes preguntarle si está molesto porque cambiaste el código que escribió o si cree que el cambio afecta negativamente al código. Estos son dos problemas completamente separados y es importante hacerle saber que lo son.

Después de ese punto, parece que sería hora de escalar el problema. Hable con el líder o gerente de su equipo (lo que sea más apropiado) y explíqueles que esta persona parece estar en desacuerdo con que usted toque el código que escribió. Si bien está abierto a la discusión sobre la calidad de cualquier código (que debería estarlo), parece ser el hecho de que esta persona quiere que el código que escribió no sea tocado (por usted, si esa es su impresión). es). Explique cómo esto divide falsamente la propiedad, la responsabilidad y la comprensión del código y cómo eso es perjudicial para el producto y aumenta la forma en que la empresa depende de personas específicas. (Por supuesto, dicha explicación no debería ser tan detallada cuando se habla con un líder de equipo como cuando se habla con un gerente).

En conclusión

Entonces, esencialmente, creo que lo más importante es separar los diferentes temas y abordarlos individualmente. Esto también debería hacer que sea mucho más fácil lidiar con cada uno de ellos, ya que ahora sabes lo que está pasando.

Vi una serie de respuestas que decían "Déjalo ir". No puedo estar de acuerdo con eso, porque el tema va a surgir una y otra vez.

Un equipo necesita estándares, específicamente para evitar discusiones como esta. Diría que hable con su compañero de trabajo nuevamente, una vez que los ánimos se hayan calmado un poco. Pídale que revise los estándares de codificación con usted y juntos determinen, si es posible, cómo creen que debería organizarse el código. Si pueden llegar a un acuerdo, coolio. Si no, reconozca sin rencor que simplemente no están en la misma página y pida al gerente que los ayude a resolver el problema.

Eliminó su ejemplo específico (que pensé que era una lástima, ofrece algo de contexto), pero déjeme agregar una cosa ... Esa parte potencialmente complicada (incrementar el recuento del módulo de índice para volver a 0) debería ser comprensible para J Random Programmer, pero no estaría de más dejar un comentario rápido encima de la línea como recordatorio... ;D

No creo que puedas dejar pasar esto: tu colega es muy protector con el código que ha escrito. Por lo tanto, cada vez que cambie un fragmento de código que él haya escrito y no tenga un error, es muy probable que venga a 'hablar' con usted al respecto.

Y su colega está tratando de intimidarlo, no se equivoque al respecto.

En primer lugar , el código en el que ambos están trabajando no es suyo ni suyo. Es propiedad de quien te paga.

En segundo lugar , no debes hacer lo que él dice que debes hacer, a menos que él sea tu jefe, lo que no es. Debe hacer lo que su empleador quiere que haga.

En tercer lugar , estoy de acuerdo contigo en que deberías dejar las cosas mejor de lo que has encontrado, por lo que hacer que el código sea más legible es algo bueno.

Entonces, no querrás complicarte la vida por 3 líneas de código. ¡Bien en ti! Pero, ¿qué vas a hacer la próxima vez que esto suceda?

Sugiero involucrar al líder/gerente de su equipo la próxima vez que esto suceda. Ver puntos, uno, dos y tres.

Si bien su compañero "mayor" puede haber reaccionado de forma exagerada, también debe considerar la posibilidad de que tuviera razón en cierto modo.

Desafortunadamente, las ediciones eliminaron el código en sí: tal vez esto sea mejor para la mayoría de los usuarios que no son de TI, pero en este caso se perdió una parte importante de la información.

A mi modo de ver, ha mejorado la legibilidad del código en la mayoría de las métricas formales: las condiciones están organizadas de manera más lógica, hay llaves y esas cosas. Sin embargo, su introducción del operador % (resto entero) es un truco inteligente que confundirá al 90 % de los desarrolladores junior y, aparentemente, también a algunos senior. Ahora, el código demasiado detallado es malo, las comprobaciones redundantes son malas, pero los trucos inteligentes son simplemente horribles, a menos que esté seguro de que todos los desarrolladores son al menos tan inteligentes como usted. Y ya tienes la prueba de que no lo son.

Además, aunque los documentos de su empresa dicen que debe "corregir el código que no está escrito con este estilo", probablemente sería mejor mencionar dichos cambios al autor original, si él o ella está disponible. Un mensaje rápido como "Mira, tuve problemas para depurar este código, ¿no crees que es más legible de esta manera?" podría haberlos ahorrado a ambos un poco de vergüenza.

Cuando eres nuevo, por lo general es una buena idea tomarte un tiempo para observar la dinámica y familiarizarte con el equipo, etc., antes de encargarte de hacer cambios importantes. Una buena regla general es "Si no está roto, no lo arregles", o un corolario de eso, "Si estuviera roto, alguien ya lo habría arreglado". Si el código en cuestión era un gran problema, probablemente lo sería (o al menos ya debería haberse solucionado). Es posible que algún código que encuentre en este trabajo deba corregirse, pero espere hasta que esté más familiarizado con el grupo sistema antes de decidir si dicho código califica.

A pesar de cuánto esfuerzo se dedica a desarrollar estándares universales de codificación/documentación, CADA LUGAR DE TRABAJO TENDRÁ SUS PROPIOS ESTÁNDARES y se necesita tiempo para inferir cuáles son exactamente.

Puede dejar pasar este incidente, pero no debe sentirse mal. Solo tienes que elegir tus batallas.

Tu mentalidad es absolutamente correcta. Cada vez que revisamos el código antiguo, si no es fácil de mantener, primero debemos comprenderlo. Una vez que se ha logrado la comprensión, si no documentamos o facilitamos el camino hacia esa comprensión, estamos desperdiciando el tiempo de otros mantenedores en el futuro, de la misma manera que el programador original le redujo ese costo. Por lo tanto, es el deber de cualquier programador que valga la pena documentar o mejorar el código sobre la marcha (lo último es menos riesgoso cuando se tiene un conjunto de pruebas sólido y exhaustivo que garantiza que las refactorizaciones y las mejoras no rompan la funcionalidad). Dejar comentarios no es ideal, pero deja un olor a que el código necesita algo de amor en el futuro.

Su equipo también está adoptando el enfoque correcto para las convenciones de codificación. Las convenciones no son reglas, por lo que debe haber cierto margen para romperlas cuando tenga sentido hacerlo. Pero representan un ideal que puede que no siempre se haya logrado y es más práctico hacer cumplir las convenciones del código en el código nuevo y actualizado en lugar de refactorizarlo exhaustivamente. En un proyecto ideal, el código nunca debería verse como si lo hubiera escrito una persona específica. Esto permite a todos los desarrolladores comprobar su ego en la puerta y tratar el código como el código del equipo, preocupándose por la calidad del código en lugar de quién escribió qué.

Esto nos lleva a su colega. Su comportamiento no es inusual, como podría pensar, ya que los programadores tienen una tendencia a sentirse orgullosos y dueños de su código (o buscan culpar a otros, a veces, solo para verse a sí mismos en la historia) y pueden desarrollar ego a pesar de los esfuerzos por resistirse a hacerlo. . Otros no se resisten en absoluto. "Mi código" es una mala actitud, todo el código debe pertenecer al equipo. Hay una inconsistencia entre su afirmación de que ha codificado cosas para que el equipo las entienda si contraviene las pautas de codificación del equipo. Él deja en claro que está codificado para que él lo entienda primero, no el equipo, y está molesto porque arruinaste su comprensión al tener la audacia de cambiar las cosas (todo buen código debe escribirse para que sea fácil de mantener y eliminar, no ser inmortal).

Empeora cuando afirma que nunca podrás entender su código y amenaza con usar su influencia para dejarte sin trabajo. Eso por sí solo es enormemente poco profesional, pero en respuesta a un pequeño formato es enormemente desproporcionado.

Tienes que elegir tus batallas y yo dejaría ir el lado del formato. Si es nuevo en el equipo y alguien dice que no está cumpliendo con la convención de código, todo lo que puede hacer es ceder a su experiencia y sugerir que actualice la documentación si se vuelve engañosa. Si esto causa fricciones, entonces debe apelar a su jefe, ya que mantener un estándar en el papel y otro en la práctica (especialmente a instancias de los desarrolladores individuales) es discordante y socavador.

Sin embargo, es mucho más probable que me concentre en la amenaza dirigida hacia ti. Si se hizo verbalmente, no tiene buenas pruebas en este momento y no tiene una buena opción para actuar en este momento, pero tendría mucho cuidado con él en el futuro y trataría de obtener todo lo que dice por escrito, por ejemplo. interactuar por correo electrónico tanto como sea posible. Si vuelve a amenazarte por escrito, puedes empezar a hablar con tu jefe al respecto. Por lo que parece, su ego es lo suficientemente frágil como para volver a tener problemas con él, tarde o temprano.

Donde podría tener problemas es que no conoce la disposición del terreno. Si este tipo realmente es tan malo como parece, es posible que haya escrito grandes fragmentos de código y que nadie más que él pueda mantenerlos. Como tal, efectivamente se ha vuelto indescifrable ya que la compañía no puede darse el lujo de perderlo, lo que ha permitido su mal comportamiento. Esto puede ser bueno a corto o mediano plazo para la seguridad laboral, pero a largo plazo es degenerado, contraproducente y puede arruinar tu reputación. No aspires a esto.

Con eso en mente, tenga cuidado de no poner a la empresa en posición de elegir, ya que antepondrá los intereses del negocio. Trate su trabajo actual como una experiencia de aprendizaje en el trato con personas difíciles. Pase tiempo con sus colegas y descubra cómo tratan a este tipo y no pierda la oportunidad de aprender otras cosas de ellos también. Mientras tanto, esté atento a otras oportunidades y prepárese para aterrizar de pie en caso de que tenga la influencia y lo eche por alguna otra infracción percibida.

La respuesta a esto depende en gran medida de cuál sea el enfoque general de "cumplimiento del proceso" dentro de la empresa, y ya debería tener una idea al respecto.

Trabajé en una empresa que tenía, en papel, la certificación ISO9001, pero el director ejecutivo siempre nos molestaba con solicitudes de cotización hechas por llamadas telefónicas rápidas e incompletas, aunque teníamos un formulario de solicitud donde se podía recopilar toda la información. Probablemente adivine que, en ese caso, hacer cumplir el estándar fue una batalla perdida.

Tienes dos alternativas:

1. La empresa tiene una cultura de cumplimiento del proceso : tiene razón al seguir la Convención de codificación de la empresa y, si la cosa empeora, simplemente deje en claro que siguió el estándar.
2. La adherencia al proceso es solo en el papel : olvídese del manual y siga la "pista" de este senior.

"La convención de código dice claramente que puedo cambiar el código para hacerlo en el espíritu de la convención de código. La convención fue escrita por su gerente directo".

No puedo evitar pensar que esta es una directiva terrible. Por supuesto, genere un ticket para "mejorar" una sección específica del código, o actualizarlo al estándar, pero "cámbielo si no le gusta cómo se ve" es una receta para el desastre. ¿Cómo controla estos cambios cuando se realizan como parte de otra solución? ¿Cómo se prueban los cambios?

Por lo que veo, su problema con el código de sus compañeros es la convención de código formal de la cual tiene una comprensión diferente a la del senior.

Existen muchas herramientas que formatearán automáticamente el código por usted mediante un conjunto de reglas configurables. No dejan mucho espacio para interpretar las convenciones.

Entonces, en una reunión regular del equipo (preferiblemente una retrospectiva de scrum), puede referirse a su discusión con el senior y decir que no se siente satisfecho con la situación y luego sugerir que su equipo (o al menos usted) comience a usar un formateador automático de este tipo y nomine el senior para configurar el conjunto de reglas.

La próxima vez que cambie el código de personas mayores (para corregir un error), el reformateo se realizará mediante una herramienta que él configuró. Tengo curiosidad de cómo puede echarte la culpa entonces...