traduccion - process translate

Respetando a los Desarrolladores Compañeros (11)

Todos hemos estado allí. Usted ha escrito algunas pruebas de códigos y unidades, todas las pruebas pasan, y el código es decente (nada es perfecto, ¿no?). Luego, aparece alguien que está seguro de que saben mejor que usted y decide cambiar su código o las interfaces a su código solo porque no le gustan los nombres de variables / clases que utilizó. No hay refactorizaciones "reales", ni optimizaciones reales, ni mejoras reales, solo palabras diferentes, no necesariamente palabras mejores, solo diferentes.

Mi verdadero problema con esto es que (a) es una pérdida de tiempo y (b) muestra una flagrante falta de respeto por el compañero desarrollador que escribió el código en primer lugar.

Mi respuesta visceral es arremeter, pero eso es contraproducente. En cambio, pensé que podría escribir un párrafo o dos como una especie de "Carta" o "Filosofía" que se adopta para el proyecto. Me pregunto si alguien más ha intentado esto, y de ser así, ¿fue exitoso?

Después de ver los comentarios iniciales a continuación (que son apreciados), creo que mi problema es principalmente que este cambio rompió la construcción del código que ya estaba funcionando. Por lo tanto, había que dedicar tiempo para arreglar el código de lo que era (en mi opinión) un cambio sin valor agregado.

-- Gracias

... decide cambiar su código o las interfaces a su código solo porque no le gustan los nombres de variables / clases que utilizó.
Mi verdadero problema con esto es que (a) es una pérdida de tiempo y (b) muestra una flagrante falta de respeto por el compañero desarrollador que escribió el código en primer lugar.
Mi respuesta visceral es arremeter ...

Veo algunas cosas MUY CONCERNIENTES en esas declaraciones.

nombrar es REALMENTE, REALMENTE importante. Vale la pena volver a escribir el código para hacerlo correcto.
No es tu código
¿Cómo es irrespetuoso?

Lo estás tomando como algo personal.

Una vez trabajé con alguien que se asustó cuando hice cambios en "su" código. Su código es horrible. estaba lleno de errores y no se puede mantener. Siempre se quedaba hasta tarde, luchaba contra incendios y rompía cosas, básicamente, un colaborador negativo. Reescribí todo su código incorrecto para una gran pieza de funcionalidad para un proyecto un fin de semana y cuando regresó el lunes tenía un ataque de hisopo. No digo que tus cosas sean horribles, pero tal vez necesites calmarte y ser más objetivo al respecto.

No lo tomes tan personalmente. Da un paso atrás y piénsalo, quizás "tu" código necesite ser reparado

Es posible que podamos dar mejores respuestas si publica el código y los cambios, o al menos una mejor idea de la situación con un ejemplo o dos.

EDITAR: Después de ver el cambio de código y descubrir que la compilación se rompió, voy a tener que cambiar el tono de esta respuesta. Entiendo la frustración de Steve, y estoy de acuerdo, ese no es un buen cambio. Hace un typedef específico más general y no muy descriptivo.

Aunque creo que algunos de mis puntos son válidos, en este caso parece que los cambios no fueron apropiados.

La cuestión del código "propiedad" es irrelevante. Si el código cambia son inútiles, todos en el equipo no deberían estar contentos. Si son buenos cambios, todos deberían estar contentos con eso. Si hay una diferencia de opinión, entonces todos deben encontrar un terreno común.

Romper la construcción no es algo bueno.

Steve, lo siento si bajé duro, parece que en este caso estás justificado en tu frustración, pero no porque sea "tu" código.

¿Qué hay de usar un sistema de compilación automatizado, por lo que cuando esta persona cambia el código y rompe algo, el equipo recibirá una alerta al respecto. Esto resuelve tu problema con tener que perder tu tiempo arreglando algo roto por alguien más que cambia a tu código. De esta forma, todos sabrán que tal y tal hicieron un cambio y quebraron la construcción, y pueden ver por sí mismos. La regla es "no rompa la construcción".

A veces, cambiar los nombres puede estar justificado. Puede ser confuso si la mitad del proyecto se refiere al sexo de una persona, y luego se ingresa un nuevo código que se refiere al género o algo así. De acuerdo, este podría ser un mal ejemplo, ya que, técnicamente, son dos cosas diferentes y su significado es aún más obvio. Pero si el código de un proyecto utiliza dos términos diferentes para referirse al mismo concepto, puede ser confuso.

Por lo general, trato de dejar el código de las personas solo, a menos que tenga alguna justificación para refactorizar. Afortunadamente, parece que a mis colegas les pasa lo mismo, así que no, todavía no he tenido la necesidad de escribir una carta así.

Bueno, si ese tipo va a mantener tu código, que haga lo que quiera. Solo recuerda que no es "tu" código. El código pertenece a la empresa para la que trabaja. Usted escribió el código y le pagaron por ello. Deje que la administración haga lo que quiera con él.

No te tomes las cosas en forma personal, sigue adelante.

Creo que cada desarrollador debe asumir la responsabilidad y, por lo tanto, poseer parte del código, pero no todo el código. Entiendo el código que he escrito mejor (independientemente de lo bueno / malo que sea) que cualquier otro chico que lo haya visto. Por lo tanto, los cambios que haga serán más rápidos y menos propensos a error.

No me importa que alguien cambie el código que he escrito más adelante, pero tengo un par de condiciones:

Si cambias el código y eso hace que algo más se rompa, eres responsable de arreglarlo, no yo.
Si no estoy de acuerdo con los cambios que hizo, los cambiaré de nuevo a la manera que quiero, ya que tengo que asumir la responsabilidad de este código en el futuro.

No todos los desarrolladores deberían hacer cambios en todo el código, todo el tiempo. Solo algunas veces, con el propósito de conocer el código (compartir conocimiento).

Nunca he trabajado para un empleador que respalda una política de "todos pueden cambiar cualquier cosa". Los desarrolladores poseen ciertas partes del código y se les pide específicamente que realicen cambios / refactorizaciones basadas en una democracia de desarrollo.

Tocas mi código y rompes algo, (1) es mejor que tengas una buena razón para el cambio con el que todos los desarrolladores están de acuerdo y (2) es mejor que no dejes las cosas rotas o me pidas que haga la limpieza por ti A MENOS que eres mi superior Humildemente presentaré si ese es el caso.

Debería discutir esto con la persona que lo hizo, de una manera no amenazante.

En cualquier equipo de desarrollo de software con un tamaño> 1, la estandarización es la clave. No solo para que cada desarrollador entienda el código del otro, sino para que las personas que aparecen en 2 años, 5 años y 10 años puedan ver cualquier parte del código y ver un patrón claro y consistente. ¿Podrías ... y el resto del equipo ... en serio seguir estando allí, trabajando en este proyecto, años después?

Si ambos "simplemente tienen su manera de hacer las cosas" y no existe un estándar formal para el proyecto / compañía, les sugiero que trabajen con el equipo y / o su jefe para sugerir que se adopte un estándar formal. Ya se han publicado muchos estándares para los diversos entornos que puede usar como estándar o como punto de partida.

Si existe un estándar formal, todos los integrantes del equipo están obligados a seguirlo ... sin importar qué tan "mejor" piensan a su manera.

Demasiado para las habilidades duras.

Ahora en el lado de las habilidades blandas ...

Usted y su compañero deben desarrollar una relación saludable o decidir trabajar en diferentes lugares. Los tit-for-tats que hacen que las personas sientan que quieren atacar harán que todos estén descontentos, sin mencionar que ponen en grave peligro el proyecto que a todos se les paga por completar. Busque a una persona que ambos respeten (tal vez su jefe, tal vez un miembro senior del equipo respetado y sensato, tal vez RRHH si tiene un buen departamento de recursos humanos). Explique a esa persona cuál es el problema y que lo haga sentir no valorado y sin respeto. Pida ayuda para hablar sobre la situación con su colega y acordar una mejor manera de trabajar juntos.

Finalmente, debe estar abierto a la posibilidad de que su colega haga cambios subjetivamente correctos, incluso si la forma en que lo está haciendo le ofende. Separe la codificación correcta de las interacciones interpersonales correctas. Haz lo correcto para el proyecto.

Heey,

Chicos! ¡ TODOS NECESITAMOS HABLAR !

Solo siéntense y HABLEN ! Siempre hay razones para cambiar y siempre hay razones para NO hacerlo.

Decidir juntos !

No solo vaya a o a un foro y diga hacer este tipo de preguntas.

El nuevo desarrollador lo hace: obtiene respuestas de la comunidad probablemente positivas (sí , el código incorrecto debe ser refactorizado ).
El desarrollador actual lo hace; también recibe respuestas de la comunidad: "¡ Qué idiota podría hacer ese tipo de cambios! "

Y el resultado es: entorno contraproducente, destructivo y ofensivo durante mucho tiempo.

¿Quien lo quiere?

Solo pon tus argumentos sobre la mesa y eso es todo.
El nuevo desarrollador también necesita una introducción.
El desarrollador antiguo debe enumerarse TAMBIÉN.

Esto debería ser un trabajo colaborativo Y no molestarse unos a otros.

Decidir juntos, hablar, como EL EQUIPO .

Y ... mejor haga preguntas como "¿Cómo es mejor refactorizar esto?"

Aclamaciones.

Una cosa que podría ayudar en este tipo de situación es requerir revisiones de código para todos los cambios. Es menos probable que las personas realicen cambios inútiles si alguien más tiene que revisarlo primero. Si realmente pueden convencer a otro desarrollador de que su cambio debería entrar, entonces tal vez no sea tan inútil después de todo.

Tal vez no completamente sobre el tema, pero .... Si tienes desarrolladores que tienen tiempo para hacer cambios en el código solo porque no les gustan los nombres de variables usados, entonces tal vez la conversación debe ser sobre si tienes demasiados desarrolladores y a cuáles se les debe mostrar la puerta ... o cómo se va a justificar ante la gerencia el personal inflado que tiene, ¡especialmente en las circunstancias económicas actuales!

Estoy de acuerdo con Laurence en que las revisiones de códigos pueden ser útiles. Este es un problema de cómo su equipo debería trabajar en conjunto. Lo que podría ayudar es la noción de programación sin ego , en pocas palabras, considerar el código como un producto conjunto del equipo y tratar de tomar decisiones por el bien del código y no por el ego del programador. Su compañero de equipo violó el cuarto mandamiento de la programación sin ego : "No reescriba el código sin consultarlo". Tal vez si su equipo toma conciencia de estos principios, las cosas mejorarán. Intentaré esto.