Versiones del código fuente con comentarios (práctica organizacional): ¿dejar o eliminar?

Antes de que comiences a amonestarme con " NO LO HAGAS ", "¡ MALA PRÁCTICA !" y " Aprende a utilizar el control de código fuente correcto ", por favor escúchame primero. Soy plenamente consciente de que la práctica de comentar el código anterior y dejarlo ahí para siempre es muy malo y odio tal práctica.

Pero aquí está la situación en la que estoy. Hace unos meses me uní a una compañía como desarrollador de software. Trabajé en la empresa durante algunos meses como pasante, aproximadamente un año antes de unirme recientemente. Nuestra empresa utiliza control de versiones de código fuente (CVS) pero no de forma adecuada.

Esto es lo que sucedió tanto en mi pasantía como en mi puesto permanente actual. Cada vez que fui asignado a trabajar en un proyecto (legado, entre 8 y 10 años). En lugar de crear una count de CVS y dejarme revisar el código y registrar los cambios, un colega senior exportó el código de CVS, lo comprimió y me lo pasó.

Mientras que este colega comtesting todos los cambios a granel cada pocas semanas, nuestra práctica habitual es hacer un control de versiones preciso en el propio código fuente (cada file se incrementa en versiones independientes del rest). Cada vez que se realiza un cambio en un file, el código anterior se comenta, se ingresa un nuevo código debajo y toda esta sección se marca con un número de versión. Se coloca una nota sobre los cambios en la parte superior del file en una sección llamada Historial de modificaciones . Finalmente, los files modificados se colocan en una carpeta compartida, listos y esperando el logging masivo.

/* * Copyright notice blah blah * Some details about file (project name, file name etc) * Modification History: * Date Version Modified By Description * 2012-10-15 1.0 Joey Initial creation * 2012-10-22 1.1 Chandler Replaced old code with new code */ code .... //v1.1 start //old code new code //v1.1 end code .... 

Ahora el problema es esto. En el proyecto en el que estoy trabajando, tuve que copyr algunos nuevos files de código fuente de otro proyecto (nuevo en el sentido de que no existían antes en el proyecto de destino). Estos files tienen una gran cantidad de código histórico comentado y versiones basadas en comentarios, incluida la sección de Historial de modificaciones generalmente larga o muy larga.

Como los files son nuevos en este proyecto, decidí limpiarlos y eliminar el código innecesario, incluido el código histórico, y comenzar de cero en la versión 1.0. (Todavía tengo que continuar practicando el control de versiones basado en comentarios a pesar de odiarlo. Y no preguntes por qué no empiezas en la versión 0.1 …) He hecho algo similar durante mi pasantía y nadie dijo nada. Mi supervisor ha visto el trabajo varias veces y no ha dicho que no debería hacer tal limpieza (si es que lo noté).

Pero un colega del mismo nivel vio esto y dijo que no se recomienda, ya que puede causar un time de inactividad en el futuro y boost los costos de mantenimiento. Un ejemplo es cuando se realizan cambios en otro proyecto en los files originales y estos cambios deben propagarse a este proyecto. Con files de código drásticamente diferentes, podría causar confusión a otro desarrollador que hace la propagación. Tiene sentido para mí, y es un punto válido. No pude encontrar ninguna razón para hacer mi limpieza más allá de la inconveniencia de un código ridículamente desorderado.

Entonces, para resumir: dada la práctica en nuestra compañía, ¿no debería hacer tal limpieza al copyr nuevos files de un proyecto a otro? ¿Es mejor hacer cambios en la (copy del) código original con el historial completo en los comentarios? ¿ O qué justificación puedo dar para hacer la limpieza?

Modificaciones de PS a: Espere que permita esta pregunta en algún momento, incluso si por alguna razón usted determina que no es apto para SO. Me disculpo de antemano si algo es inapropiado, incluidas las tags.

Si la copy de algún file de otro proyecto significa (para estas fonts) "El punto de divergencia" y la evolución independiente paralela de la fuente y el tenedor, que la historia henetworkingada y el código comentado son efectivamente "ruido blanco" y pueden eliminarse fácilmente de tu lado . Para una futura propagación posible desde el padre, mencionar solo el "punto de bifurcación" será suficiente en la primera línea del Historial de modificaciones, smth. me gusta

 ... * Date Version Modified By Description * 2012-10-25 1.0 ADTC Created from 12.34 of <filename> ... 

Addendum by asker (ADTC): Deseo citar un comentario además de la respuesta anterior.

[…] tomar el código fuente, eliminar los comentarios relacionados con quién hizo qué (comentarios de la historia) , pero retener el comentario sobre lo que hace el código fuente / class / método (comentarios informativos) . Eso es lo que se supone que es la sección de comentarios. Debe definir claramente qué está haciendo el método, cómo se implementa y bajo qué condición se lanzará una exception. – Victorias , 2012-10-25 00: 57: 57Z

Si estoy yendo a su position, preferiría modificar el otro código fuente y convertirlo en una biblioteca para usar en mi proyecto.

Sugiero usar algún control de versión usted mismo – Recomiendo git . Tenga una twig para el código "ascendente" que esté sincronizada con lo que tenga actualmente su colega principal. Entonces puedes tener una o más twigs para tu trabajo. Tendrá una buena visión general de los cambios que realizó utilizando git diff contra la twig "ascendente", puede search el historial de todo lo que hizo en ese proyecto, etc. Y todo esto es automático, sin versiones de código manual, los files están siempre "limpios" , con toda su historia disponible en git.