Estamos practicando la propiedad colectiva de código. A mi entender, 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? ¿Debo preguntarle primero? ¿Cuál es la mejor práctica?
Creo que una 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 querido regresar y refactorizarlo por años, puede ser que lo hayan hecho de esa manera por una 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 de abordar adecuadamente. Permítame hacer algunas preguntas de seguimiento aquí:
¿Estás absolutamente seguro de que estás hablando de reescritura y no de refactorización? Por definición, los cambios en el estilo o la estructura del código que resultan en una implementación mejorada (o simplemente diferente) sin cambios en el comportamiento externo son un refactor, no una reescritura. Romper una rutina monolítica de 500 líneas en un conjunto de 50 subrutinas puede implicar escribir un poco de código nuevo, pero no es una reescritura. El término rewrite implica deshacerse de todo un producto o función y comenzar desde cero; no es algo que deba tomarse a la ligera.
Si el comportamiento del código original es tan incorrecto, o la implementación es tan defectuosa como para requerir 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 saludable a través de pruebas, revisiones de códigos, revisiones de diseño, etc. ¿Tiene estas?
¿El administrador / técnico es consciente del problema y, de no ser así, por qué no? No importa qué tipo de proceso tenga, la calidad del código es generalmente la responsabilidad del gerente de desarrollo. Él o ella es la primera persona a la que deberías preguntar, obviamente no en el contexto de "tal y como escribí el código basura" , sino simplemente "Creo que veo un problema importante aquí, ¿podemos ¿Hablar de una reescritura? " Si no justifica este tipo de discusión, entonces ¿quizás tampoco justifique una reescritura?
Si el tamaño y el alcance del código ofensivo es lo suficientemente grande como para justificar una discusión seria de una reescritura, ¿por qué es propiedad exclusiva de un desarrollador one ? La mayoría, si no todas las veces que he visto código y he pensado "reescribir", ha sido pisoteado por una docena de personas diferentes y la maldad es un resultado directo de la acumulación de inconsistencias de estilo, suposiciones erróneas o alteradas, y buenos viejos Hacks a la moda. El código se vuelve espino con el tiempo precisamente porque de su propiedad compartida.
Mi punto aquí es que es extraño que una persona posea una franja de código tan grande en un entorno que supuestamente practica la propiedad colectiva. ¿Otras personas tienen miedo de tocar el código de este desarrollador? ¿Tienen miedo de sacar el tema? Tal vez haya un problema subyacente con la dinámica de su grupo, o específicamente con este desarrollador; Si la hay, no la ignores. O, como alternativa, quizás sea su primera vez trabajando en este proyecto, y si es así, ¿por qué usted está pensando en volver a escribir tan temprano en el juego? Algo acerca de la situación no parece ser una solución para mí.
La pregunta indica, en el primer párrafo, any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs . ¿Un reescrito no hará estas cosas? ¿O hará algo extra ? Y si es así, ¿qué? Fundamentalmente, ¿cuáles son sus razones para querer volver a escribir 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 plantear si desea discutirlo con el equipo y cuándo lo hace.
Realmente siento que esta pregunta implica una gran cantidad de contexto y no debe 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. Esto 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 errores menores en el código.
En este último caso, aunque esperaría un aviso anticipado de que "mi" código podría estar siendo reescrito, estaría perfectamente feliz de que sucediera.
Ese es el punto de propiedad colectiva del código: el código que escribes debe modificarse o incluso reemplazarse 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. Discútalo con el otro desarrollador primero como una cortesía. Puede haber razones válidas por las que está escrito de cierta manera. A nivel personal, muchos desarrolladores se involucran emocionalmente en lo que producen y, como han dicho otros, no se quiere tener 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 de 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 eres el desarrollador original. Su equipo debe ejecutar la reescritura completa de cualquier , por los siguientes motivos:
Como dijo Matthew Flynn, es necesario hablar primero con el desarrollador. El desarrollador inicial podría contar cosas importantes sobre la funcionalidad y explicar por qué se dio esta o aquella solución.
Pero antes de refactorizar o volver a escribir el código, haga una copia de seguridad o una rama que contenga ese código. Si el código antiguo funciona bien, quedará la posibilidad de que se recupere.
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, verifique.
No elimines el código anterior, al menos antes de que estés 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á revisando algunas líneas para ser más eficiente, simplemente hágalo. Tal vez pregunte si hay algún peligro de que usted borre el comportamiento sutil. Informe el cambio durante el scrum o por correo electrónico una vez que esté hecho, a menos que sea realmente trivial (corregir un error tipográfico).
Si está revisando una clase de tamaño decente, probablemente debería preguntar para asegurarse de que comprende el diseño / comportamiento. Deje que las personas sepan con anticipación para que cualquier persona que pueda estar trabajando en la misma área pueda estar al tanto y coordinarse con usted.
Si está reelaborando un sistema más grande, definitivamente debería trabajar con su equipo para informarles de los cambios y planificar el diseño.
Si sus escritores originales están allí, comuníquese con ellos. No SOLO por ettiquette, sino por información adicional, en caso de que haya casos o circunstancias de los que no tenga conocimiento. A veces, te dirán algo valioso.
Tenemos control de código abismal. Actualmente tengo un montón de cosas que necesitan revisión y mantenimiento, y ni siquiera tengo a alguien 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 empresa. No hay nadie para preguntar sobre el código.
Cuando reescribo, comento, con comentarios que comenté, así como fecha y nombre / iniciales, y por qué fue comentado. Comento código nuevo, con nombre o iniciales, fecha, motivo por el cual se agregó, etc.
Se hacen comentarios adicionales en el encabezado del paquete (er, generalmente), que indican qué funciones / procs / SQL / etc. Se cambiaron, con fecha. Facilita la búsqueda de secciones que se han cambiado, 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 / jubilaciones), el código se puede limpiar de los comentarios anteriores y el resto es la nueva línea de base.
Desde mi observación, la práctica general es: Nunca elimine el código. Solo coméntalo y guárdalo.
Mi práctica es comentarlo mientras lo reemplaza. (Principalmente para referencia.) Luego bórrelo en la confirmación final del cambio de trabajo. (Esto requiere control de versiones y un entendimiento de cómo revertir los cambios).
Cuando encuentro un código comentado antiguo, trato de borrarlo en un comentario separado 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 utilizar el historial de revisiones para determinar los desarrolladores que crearon el código. (El historial de revisiones anotadas ayuda aquí.) Póngase en contacto 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 existe una razón legítima para no arreglarlo, agregue un comentario que explique por qué no se reparó o por qué no se debe cambiar. Esto le ahorrará tiempo al siguiente desarrollador.
Las etiquetas como FixMe, ToDo, Bug y Hack se pueden usar para indicar el código que podría cambiarse 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 en 20 millones de dólares, pero no perdería mucho tiempo en solucionarlo. eso.
El desarrollador original debe realizar cambios en la revisión del código si es apropiado modificar el código.
Probablemente depende de por qué la reescritura es necesaria. Si es porque hay problemas con lo que está escrito, y siempre ha tenido 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 emparejarse cuando se arregla 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. También (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 otras ocasiones en que se llama a una reescritura para:
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 aportación.
Un nuevo requisito de función cambia la situación de modo que una mini-reescritura dirigida sea apropiada.
En estos casos, probablemente no me molestaría con una conversación.
Pensándolo bien, me parece que cuanto más tiempo haya estado el código, es menos probable que sea necesaria una conversación.
Creo que @aaronaught hizo algunos buenos puntos, 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 bien no funciona como se esperaba o simplemente necesitas extender lo que realmente hace.
En un entorno de desarrollo de equipo, no debes tener (y es posible que no puedas) hablar con el codificador original, todo debe estar claro en el código.
Esto conduce 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 más a menudo conduce a la eliminación del código, y es por eso que deberíamos comentar todo y donde no tenemos experiencia. Los programadores subalternos más a menudo caen en faltas.
Cualquier programador que esté cambiando el código de otra persona (refactorización) debería, como cuestión de cortesía y práctica, copiar el mismo estilo de codificación del código ya existente, y primero tomar medidas para descubrir cómo funcionó el código original y qué estaba tratando de lograrlo, y en realidad lo iba a lograr. A menudo esto en sí mismo identifica los errores, pero ciertamente obliga a las personas a soportar el dolor que la próxima persona tendrá al mirar su código.
En mi equipo, cualquiera puede eliminar, refactorizar o reescribir cualquier cosa, y veo la "propiedad" como una práctica que genera pereza, como si una persona estuviera segura de que se le notificaría cualquier cambio, ¿por qué necesitarían hacer el código legible? .
En resumen, no, no deberías tener que preguntarle al autor original del código, y si miras el código que haces, es una señal de que su código no es lo suficientemente legible o que Necesitas 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 volver a escribir, 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.
Lea otras preguntas en las etiquetas programming-practices code-ownership