¿Es una mala práctica no eliminar archivos redundantes directamente de VCS, sino marcarlos como "Para eliminar" con comentarios primero?

El problema de agregar un comentario a un archivo de que debería eliminarse, en lugar de eliminarlo en el control de origen y poner la explicación allí, es la suposición de que si los desarrolladores no leen los mensajes de confirmación, seguramente leerán los comentarios en la fuente. código.

Desde la perspectiva de un forastero, esta metodología parece estar arraigada en una visión muy conservadora del control de la fuente.

"¿Qué pasa si elimino este archivo no utilizado y luego alguien lo necesita?" alguien podría preguntar.

Estás usando control de código fuente. Revertir el cambio, o mejor aún, hablar con la persona que eliminó el archivo (comunicarse).

"¿Qué pasa si elimino el archivo muerto, entonces alguien comienza a usarlo nuevamente y hace cambios?" alguien más podría preguntar.

De nuevo, estás usando control de código fuente. Obtendrá un conflicto de fusión que una persona debe resolver. La respuesta aquí, como en la última pregunta, es comunicarse con sus compañeros de equipo.

Si realmente duda de que se debe eliminar un archivo, comuníquese antes eliminándolo del control de código fuente. Tal vez solo recientemente dejó de usarse, pero una característica próxima podría requerirlo. Usted no lo sabe, pero uno de los otros desarrolladores podría hacerlo.

Si debe eliminarse, elimínelo. Cortar la grasa de la base del código.

Si hizo un "oopsie" y realmente necesita el archivo, recuerde que está usando el control de código fuente para poder recuperar el archivo.

Vincent Savard, en un comentario sobre la pregunta, dijo:

  

... Si sus colegas no leen los mensajes de confirmación y resucitan un archivo que se eliminó correctamente y pasa la revisión del código, definitivamente hay algo mal en su equipo y es una gran oportunidad para enseñarles mejor.

Este es un buen consejo. Las revisiones de código deberían captar este tipo de cosas. Los desarrolladores deben consultar los mensajes de confirmación cuando se realiza un cambio inesperado en un archivo, o se elimina o cambia el nombre de un archivo.

Si los mensajes de confirmación no cuentan la historia, los desarrolladores también deben estar escribiendo mejores mensajes de confirmación.

Tener miedo de eliminar el código o eliminar archivos es indicativo de un problema sistémico más profundo con el proceso:

• Falta de revisiones de código precisas
• Falta de comprensión sobre cómo funciona el control de fuente
• Falta de comunicación del equipo
• Mensajes de confirmación deficientes por parte de los desarrolladores

Estos son los problemas a resolver, por lo que no sientes que estás tirando piedras en una casa de cristal cuando eliminas códigos o archivos.

Sí, es una mala práctica.

Debes poner la explicación de la eliminación en el mensaje de confirmación cuando confirmes la eliminación de los archivos.

Los comentarios en los archivos de origen deben explicar el código como se ve actualmente . Los mensajes de confirmación deben explicar por qué se hicieron los cambios en la confirmación, por lo que el historial de confirmación en el archivo explica su historial.

Escribir comentarios que expliquen los cambios directamente en la fuente en sí solo hará que el código sea mucho más difícil de seguir. Piénselo: si comenta en el archivo cada vez que cambia o elimina un código, pronto los archivos se verán inundados de comentarios sobre el historial de cambios.

En mi opinión, ambas de sus opciones no son buenas prácticas , a diferencia de malas , práctica:

1. Agregar comentarios solo agrega cualquier valor si alguien lee esos comentarios.
2. Simplemente eliminar del VCS, (con un motivo en la descripción del cambio), puede tener un efecto crítico y muchas personas no leen la descripción del cambio, especialmente cuando están bajo presión.

Mi práctica favorita, en gran parte debido a que me han mordido varias veces a lo largo de los años, teniendo en cuenta que no siempre se sabe dónde o por quién se usa su código , es:

1. Agregue un comentario que indique que es un candidato para la eliminación y un desprecation #warning o similar, (la mayoría de los lenguajes tienen algún tipo de mecanismo, por ejemplo, en Java , en el peor de los casos, una declaración print o similar será suficiente), idealmente con algún tipo de escala de tiempo y con detalles de contacto. Esto alertará a cualquier persona que aún esté usando el código. Estas advertencias normalmente están dentro de cada función o clase si tales cosas existen .
2. Después de algún tiempo, actualice la advertencia a un alcance de archivo estándar #warning (algunas personas ignoran las advertencias de desaprobación y algunas cadenas de herramientas no muestran dichas advertencias de forma predeterminada).
3. Más tarde, reemplace el alcance del archivo #warning con un #error o equivalente. Esto romperá el código en el momento de la creación, pero puede eliminarse si es absolutamente necesario, pero la persona que lo elimine no puede ignorarlo. (Algunos desarrolladores no leen ni tratan ninguna advertencia o tienen tantas que no pueden separar las importantes).
4. Finalmente marque el (los) archivo (s), (en o después de la fecha de vencimiento), como eliminado en el VCS.
5. Si borro un paquete / biblioteca / etc completo en la etapa de advertencia, agregaría un archivo README.txt o README.html o similar con la información sobre cuándo y amp; por qué está previsto deshacerse del paquete y dejar solo ese archivo, con un cambio para decir cuándo se eliminó, como el único contenido del paquete durante un tiempo después de eliminar el resto del contenido.

Una ventaja de este enfoque es que algunos sistemas de versiones (CVS, PVCS, etc.) no eliminarán un archivo existente en el proceso de pago si se ha eliminado en la VCS. También les da a los desarrolladores concienzudos, aquellos que solucionan todas sus advertencias, mucho tiempo para abordar el problema o apelar la eliminación. También obliga a los desarrolladores restantes a mirar al menos el aviso de eliminación y quejarse mucho .

Tenga en cuenta que #warning / #error es un mecanismo C / C ++ que provoca una advertencia / error seguido del texto proporcionado cuando el compilador encuentra ese código, java / java-doc tiene una anotación de @Deprecated para emitir una advertencia sobre el uso y amp; @deprecated para brindar información, etc. hay recetas hacer similar en python & He visto que assert se utiliza para proporcionar información similar a #error en el mundo real.

Sí, diría que es una mala práctica, pero no porque esté en los archivos en lugar del mensaje de confirmación. El problema es que está intentando realizar un cambio sin comunicarse con su equipo.

Cada vez que realice algún cambio en la troncal (agregando, eliminando o modificando archivos de alguna manera), antes de volver a ingresar a la troncal, debe hablar sobre esos cambios directamente con un miembro ( o miembros) del equipo que conocerían directamente sobre ellos (esencialmente, discutir qué pondrían en esos encabezados directamente con sus compañeros de equipo). Esto asegurará que (1) el código que está eliminando realmente deba eliminarse, y que (2) su equipo será mucho más probable que sepa que el código está eliminado y, por lo tanto, no intente revertir sus eliminaciones. Sin mencionar que también obtendrá detección de errores y similares para el código que agregue.

Por supuesto, cuando cambias cosas importantes, también deberías ponerlo en el mensaje de confirmación, pero como ya lo has discutido, no es necesario que sea la fuente de anuncios importantes. La respuesta de Steve Barnes también aborda algunas buenas estrategias para usar si el grupo potencial de usuarios para su código es demasiado grande (por ejemplo, utilizando los marcadores en desuso de su idioma en lugar de eliminar los archivos al principio).

Si no quiere pasar tanto tiempo sin comprometerse (es decir, su cambio tiene más sentido como varias revisiones), es una buena idea crear una rama desde el tronco y comprometerse con la rama, luego fusionar la rama nuevamente con tronco cuando el cambio está listo. De esa manera, el VCS todavía está realizando una copia de seguridad del archivo, pero sus cambios no están afectando el tronco de ninguna manera.

Un problema relacionado de proyectos que se basan en múltiples plataformas y configuraciones. El hecho de que I determine que está muerto no significa que sea una determinación correcta. Tenga en cuenta que la inactividad en uso podría significar una dependencia residual que aún debe ser eliminada, y es posible que se haya pasado algo por alto.

Entonces (en un proyecto de C ++) agregué

#error this is not as dead as I thought it was

Y lo comprobé. Espera a que termine la reconstrucción de todas las plataformas normales y que nadie se queje de ello. Si alguien lo encontrara, sería fácil eliminar una línea en lugar de confundirse con un archivo faltante.

En principio, estoy de acuerdo en que los comentarios que menciona están duplicando la función que se debe hacer en el sistema de administración de versiones . Sin embargo, es posible que tenga razones específicas para suplicar eso. No saber la herramienta VCS no es una de ellas.

En el continuo de malas prácticas, esto es bastante menor. Haré esto en ocasiones, cuando quiera revisar una sucursal y poder ver el código antiguo. Esto puede facilitar la comparación con el código de reemplazo. Por lo general recibo un comentario de revisión de código "cruft". Con una pequeña explicación paso el código de revisión.

Pero este código no debería vivir por mucho tiempo. Generalmente elimino al comienzo del próximo sprint.

Si tiene compañeros de trabajo que no leen los mensajes de confirmación o no le preguntarán por qué dejó el código en el proyecto, entonces su problema no es de estilo de codificación incorrecto. Tienes un problema diferente.

también puedes refactorizar la clase y cambiarle el nombre con un prefijo a UNUSED_Classname antes de que trates tu truco. Entonces deberías cometer directamente la operación de eliminación también

• Paso 1: cambia el nombre de la clase, agrega tu comentario, confirma
• Paso 2: borra el archivo y confirma

Si es código muerto, elimínelo. Cualquiera lo necesita, puede regresar, pero el paso de cambio de nombre evitará que lo usen directamente sin pensarlo.

También enseñe a las personas cómo mirar todos los mensajes de confirmación de un archivo, algunas personas ni siquiera saben que es posible.