Reglas no escritas para reescribir el código de otro miembro del equipo [cerrado]

Estamos practicando la propiedad del código colectivo. Según tengo entendido, esto significa que cualquier desarrollador puede cambiar cualquier línea de código para agregar funcionalidad, refactorizar, corregir errores o mejorar diseños.

Pero, ¿qué pasa con una reescritura completa de código de un desarrollador que todavía está en el equipo? ¿Debería preguntarle primero? cual es la mejor practica?

Creo que la buena comunicación es siempre la mejor práctica. Hable con el desarrollador y vea si hay una razón por la cual está codificado de la forma en que está. Puede ser que hayan tenido la intención de volver y refactorizarlo durante siglos, puede ser que lo hayan hecho de esa manera por una muy buena razón, o puede ser que ambos puedan aprender algo de la conversación.

Entrar y reescribir sin comunicación previa es una receta para la mala voluntad.

La premisa misma de esta pregunta plantea una serie de preocupaciones para mí que no creo que ninguna de las respuestas existentes estén tratando adecuadamente de abordar. Permítanme hacer algunas preguntas de seguimiento aquí:

1. ¿Estás absolutamente seguro de que estás hablando de reescribir y no refactorizar? Por definición, los cambios en el estilo o la estructura del código que dan como resultado una implementación mejorada (o simplemente diferente) sin cambios en el comportamiento externo es un refactor, no una reescritura. Romper una rutina monolítica de 500 líneas en un conjunto de 50 subrutinas puede implicar escribir bastante código nuevo, pero no es una reescritura. El término reescribir implica tirar un producto o característica completa y comenzar de cero; No es algo para tomar a la ligera.

2. Si el comportamiento del código original es tan incorrecto, o la implementación es tan defectuosa que requiere una reescritura completa, ¿por qué no fue captada por el proceso de su equipo y abordada en su contexto adecuado (es decir, técnicamente en lugar de socialmente)? El código incorrecto o cuestionable debe exponerse rápidamente en un equipo sano mediante pruebas, revisiones de código, revisiones de diseño, etc. ¿Tiene estos?

3. ¿El gerente / líder tecnológico está al tanto del problema? Si no, ¿por qué no? No importa qué tipo de proceso tenga, la calidad del código es normalmente responsabilidad del gerente de desarrollo. Él o ella es la primera persona a la que debería preguntarle, obviamente no en el contexto de "código de basura escrito de manera regular" sino simplemente "Creo que veo un problema importante aquí, ¿podemos hablar de una reescritura?" Si no garantiza este tipo de discusión, entonces ¿quizás tampoco justifica una reescritura?

4. Si el tamaño y el alcance del código infractor es lo suficientemente grande como para justificar una discusión seria de una reescritura, ¿por qué es propiedad exclusiva de un desarrollador? La mayoría, si no todas las veces que he visto código y pensado "reescribir", ha sido pisoteado por una docena de personas diferentes y la maldad es el resultado directo de la acumulación de inconsistencias de estilo, suposiciones erróneas o alteradas, y los viejos tiempos. trucos pasados ​​de moda. El código crece espinas con el tiempo precisamente por su propiedad compartida.

   Mi punto aquí es que es extraño que una persona sea propietaria de una franja de código tan grande en un entorno que supuestamente practica la propiedad colectiva. ¿Temen otras personas tocar el código de este desarrollador? ¿Tienen miedo de mencionar el tema? Tal vez haya un problema subyacente con la dinámica de su grupo, o específicamente con este desarrollador; si lo hay, no lo ignores. O, alternativamente, tal vez es la primera vez que trabaja en este proyecto, y si es así, ¿por qué pensar en una reescritura tan temprano en el juego? Algo sobre la situación no parece sumar para mí.

5. La cuestión establece, en el primer párrafo, any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs. ¿Una reescritura no hará estas cosas? ¿O hará algo extra ? Y si es así, ¿qué? Fundamentalmente, ¿cuáles son sus razones para querer reescribir, y qué tan seguro está de que beneficiarán al producto o al equipo? No es necesario que responda por mí, pero es mejor que tenga algunos puntos objetivos que hacer cuando decida discutirlo con el equipo.

Realmente siento que esta pregunta implica una gran cantidad de contexto y no debería ser respondida sin una comprensión muy clara de ese contexto. La respuesta "correcta" depende completamente de su equipo, su producto, su organización, su personalidad, su proceso, el alcance del código original, el alcance de los cambios, y así sucesivamente. Este es, IMO, un problema que absolutamente debe abordar con su equipo , no en un sitio de preguntas y respuestas en línea.

¿Por qué estás editando el código?

¿Hay errores o es un defecto de diseño más fundamental?

En el primer caso, me preocuparía una reescritura para corregir lo que podrían ser pequeños errores en el código.

En el último caso, aunque esperaría un aviso de que "mi" código se estaba reescribiendo, estaría feliz de que ocurriera.

Ese es el punto de propiedad del código colectivo: el código que escribe está allí para ser modificado o incluso reemplazado si aparece algo mejor.

En general, si todos están de acuerdo en que todos son responsables del código, entonces está bien volver a escribir cualquier código si es una mejora. Discuta con el otro desarrollador primero como cortesía. Puede haber razones válidas para que esté escrito de cierta manera. A nivel personal, muchos desarrolladores se invierten emocionalmente en lo que producen y, como otros han dicho, no quieres mala voluntad.

Específicamente depende algo de la dinámica del equipo. Un desarrollador senior a punto de reescribir el código de un desarrollador junior probablemente debería realizar una revisión del código (mi sitio) con ellos antes de simplemente reescribirlo. De esa manera, el desarrollador junior puede aprender de la situación.

Realmente no importa si el desarrollador original está en el equipo o no, o incluso si usted es el desarrollador original. Su equipo debe ejecutar la reescritura completa de cualquier código compartido, por las siguientes razones:

• Lleva una cantidad de tiempo significativa. Si alguien más está trabajando en un cambio relacionado, no querrá perder su tiempo.
• Otras personas tienen una perspectiva diferente. Incluso si ha estado programando 20 años, alguien más podría saber cosas sobre las interacciones con el código que rara vez toca.
• Otros desarrolladores son el "cliente" del código fuente. El código fuente está escrito para que otros desarrolladores lo lean. Es posible que tengan requisitos de arquitectura, información sobre el estilo o solicitudes de características que hayan estado esperando en ese código, pero que no hayan tenido tiempo. No desea finalizar un refactorizador solo para descubrir que otro desarrollador necesita refactorizarlo de una manera diferente.

Como dijo Matthew Flynn, primero es necesario hablar con el desarrollador. El desarrollador inicial podría decir cosas importantes sobre la funcionalidad y explicar por qué se dio esta o aquella solución.

Pero antes de refactorizar o reescribir el código, haga una copia de seguridad o una rama que contenga ese código. Si el código anterior funciona bien, habrá una posibilidad de que se pueda recuperar.

Si tiene un sistema de control de fuente (que supongo que tiene), entonces, si es posible, refactorice todo el código y solo después, cuando esté seguro de que funciona bien, verifíquelo.

No elimine el código anterior, al menos antes de estar seguro de que el nuevo código funciona bien. Pero dejar el viejo código allí para siempre tampoco es algo bueno. Le sugiero que elimine el código algún tiempo después, como en un mes después de que pasó la prueba.

¿Cuál es el alcance de esto?

• Si está reelaborando algunas líneas para ser más eficiente, simplemente hágalo. Tal vez pregunte si hay algún peligro de que borre un comportamiento sutil. Informe el cambio durante el scrum o por correo electrónico una vez que se haya realizado, a menos que sea realmente trivial (corregir un error tipográfico).

• Si está reelaborando una clase de tamaño decente, probablemente debería pedir asegurarse de comprender el diseño / comportamiento. Informe a las personas con anticipación para que cualquier persona que pueda estar trabajando en la misma área pueda conocer y coordinarse con usted.

• Si está reelaborando un sistema más grande, definitivamente debe trabajar con su equipo para informarles sobre los cambios y planificar el diseño.

Si sus escritores originales están allí, comuníquese con ellos. No es SOLO para ettiquette, sino para información adicional, en caso de que haya casos o circunstancias que no conozca. A veces, te dirán algo valioso.

Tenemos un control de código abismal. Actualmente tengo un montón de cosas que necesitan revisión y mantenimiento, y ni siquiera tengo a nadie con quien revisar el código. Los escritores anteriores (aparte de moi) no se molestaron en comentar ningún código. Y se han ido de la compañía. No hay nadie para preguntar sobre el código.

Cuando reescribo, comento, con comentarios que lo comenté, así como fecha y nombre / iniciales, y por qué estaba siendo comentado. Comento un nuevo código, con nombre o iniciales, fecha, se agregó el motivo, etc.

Se hacen comentarios adicionales en el encabezado del paquete (er, por lo general), que indican qué funciones / procs / SQL / etc. fueron cambiados, con fecha. Facilita la búsqueda de secciones que han sido modificadas, y esas secciones tienen documentación completa.

Los comentarios son baratos. Las fechas serán un indicador de lo que cambió, y después del número x de (días / revisiones / nuevas contrataciones / retiros), el código se puede limpiar de comentarios antiguos y el resto es la nueva línea de base.

Desde mi observación, la práctica general es: nunca borre el código. Solo coméntalo y mantenlo.

Mi práctica es comentarlo mientras lo reemplazo. (Principalmente como referencia). Luego bórrelo en la confirmación final del cambio de trabajo. (Esto requiere control de versiones y una comprensión de cómo revertir los cambios).

Cuando encuentro un viejo código comentado, trato de eliminarlo en una confirmación separada con los comentarios apropiados. Esto hace que sea más fácil revertir o inspeccionar el cambio si fuera necesario.

Para todos los cambios, debe poder usar el historial de revisiones para determinar los desarrolladores que crearon el código. (El historial de revisión anotado ayuda aquí). Comuníquese con ellos si es posible para ver por qué el código es como es. En muchos proyectos, el tiempo de limpieza simplemente no ocurre y las cosas se quedan atrás. Verifique el rastreador de errores para ver si hay un registro de la limpieza requerida. En algún momento, los cambios deben limpiarse una o dos versiones más tarde.

Si está cambiando el código, debe haber una razón por la que está trabajando con ese código. Consulte con el desarrollador original para averiguar por qué el código es como es. Si hay una razón legítima para no solucionarlo, agregue un comentario que explique por qué no se solucionó o por qué no se debe cambiar. Esto ahorrará tiempo al próximo desarrollador.

Las etiquetas como FixMe, ToDo, Bug y Hack se pueden usar para indicar código que podría modificarse más adelante. (Es aceptable etiquetar las limitaciones como Error y no corregirlas si no se activarán en las condiciones requeridas). Podría ser un error si un programa de contabilidad doméstica se desborda a 20 millones de dólares, pero no perdería mucho tiempo arreglando eso.

Los cambios de revisión de código deben ser realizados por el desarrollador original si es apropiado modificar el código.

Probablemente depende de por qué es necesaria la reescritura. Si es porque hay problemas con lo que está escrito y siempre ha habido problemas con él, entonces es necesario hablar de ello, aunque solo sea para minimizar la frecuencia con la que se debe corregir el código en el futuro.

Mi sugerencia en este caso es emparejar al arreglar el código. De esta manera, proporciona un buen ejemplo de los estados intermedios, y (con suerte), algún contexto sobre por qué el código reescrito es mejor. Además (aunque solo sea como un ejercicio personal), intente refactorizar el código para que sea mejor sin una reescritura total. Será más difícil, pero es bueno para ti.

Por otro lado, hay otros momentos en que se requiere una reescritura:

• El equipo ha aprendido mucho desde que se escribió el código, y los desarrolladores que lo escribieron lo escribirían de manera diferente ahora, incluso sin su aporte.

• Un nuevo requisito de función cambia la situación de modo que sea apropiado una mini-reescritura específica.

En estos casos, probablemente no me molestaría con una conversación.

Pensando en ello, me parece que cuanto más tiempo haya estado allí el código, menos probable es que sea necesaria una conversación.

Creo que @aaronaught hizo algunos buenos comentarios, lo que realmente lleva a la respuesta que quería dar, y es que realmente depende de quién está haciendo el cambio (y por qué) y quién escribió el código.

En mi experiencia personal, el código normalmente se cambia porque o no funciona según lo previsto, o simplemente necesita extender lo que realmente hace.

En un entorno de desarrollo de Team, no debería tener que (y puede que no pueda) hablar con el codificador original, todo debe estar claro en el código.

Eso lleva a la pregunta que consume la mayor parte de mi tiempo, que es lo que pretendía el programador original, y es esa pregunta la que a menudo lleva a que se elimine el código, y es por qué deberíamos comentar todo y dónde los programadores junior sin experiencia a menudo caen mal.

Cualquier programador que esté cambiando el código de otra persona (refactorización) realmente debería, por cortesía y práctica, copiar el mismo estilo de codificación del código que ya está en su lugar, y primero tomar medidas para descubrir cómo funcionaba el código original y qué estaba intentando a, y realmente va a lograr. A menudo, esto en sí mismo identifica errores, pero ciertamente obliga a las personas a soportar el dolor que la próxima persona tendrá que mirar su código.

En mi equipo, cualquiera puede eliminar, refactorizar o reescribir cualquier cosa, y yo veo 'propiedad' como una práctica que genera pereza, como si una persona estuviera segura de ser notificada de cualquier cambio, ¿por qué tendrían que hacer que el código sea legible?

En resumen, no, no debería tener que preguntarle al autor original del código, y si al mirar el código lo hace, es una señal de que su código no es lo suficientemente legible o necesita mejorar Tus habilidades. Sin embargo, me parece una buena forma de dejar el código original en su lugar, comentado, hasta que esté absolutamente seguro de que al reescribir, no ha eliminado accidentalmente la funcionalidad requerida. Nadie es perfecto.

A menudo, el código se escribe de cierta manera por una razón. Comunicar el cambio al autor siempre funciona de la mejor manera.