¿Debo eliminar el código sin referencia?

Estoy trabajando en una base de código de tamaño mediano (100k líneas), todo es código relativamente reciente (menos de un año) y tiene una buena cobertura de prueba de unidad.

Sigo encontrando métodos que ya no se usan en ninguna parte o solo se mencionan en pruebas unitarias que solo prueban ese método específico.

¿Debo eliminar este código si estoy seguro de que ya no es necesario?

Razones para eliminarlo:

• Menos código, menos errores
• Menos código es más fácil para otros para digerir
• Todavía está bajo control de fuente

Razones para mantenerlo:

• Puede ser utilizado como referencia
• Puede ser útil alguna vez
• Puede haber sido escrito para 'completar' la funcionalidad de una clase

La mayoría de sus razones para mantenerlo son completamente irrelevantes, en pocas palabras. Si no se usa el código, deséchelo; cualquier beneficio involucrado en mantenerlo puede derivarse trivialmente del control de origen. A lo sumo, deje un comentario que indique en qué revisión encontrarlo.

En pocas palabras, cuanto antes corte el código, antes no tendrá que perder el tiempo manteniéndolo, compilándolo y probándolo. Esas ventajas superan enormemente los beneficios triviales que ha esbozado, todos los cuales pueden derivarse del control de la fuente de todos modos.

Todas las razones para eliminarlo son válidas.

Razones para mantenerlo:

• Puede ser utilizado como referencia
• Puede ser útil alguna vez
• Puede haber sido escrito para 'completar' la funcionalidad de una clase

Todas estas razones para mantenerlo serán administradas por el control de origen. Elimínelo del código en vivo y podrá recuperarlo cuando sea necesario.

El código sin referencia es lo mismo que mantener esas baterías que son un poco planas en caso de que las necesite algún día para una antorcha.

Mientras esté usando algún tipo de control de versión, diría que lo elimine del código en vivo y use el historial de versiones en caso de que resulte útil.

La única buena razón por la que puedo ver para mantener el código que no se usa actualmente es si es parte de un módulo autónomo: si bien algunas partes del código pueden no usarse en este momento, es muy posible que lo sean utilizado en el futuro

Esto puede ser especialmente cierto para una biblioteca que usa en diferentes proyectos: no desea seguir arrojando piezas de código dentro y fuera, de acuerdo con lo que necesita para un proyecto específico: encuentro que esto consume mucho tiempo y es propenso a errores.

Mi enfoque es: (1) si lo usa una vez, solo conserve lo que realmente necesita; (2) si lo usa dos veces, cópielo y adáptelo la segunda vez que lo use; (3) si lo usa más de dos veces, cree un módulo estable y bien definido, y use este módulo según lo necesite.

Resumiendo: tiraría todo el código no utilizado a menos que sea parte de un módulo de propósito general que haya diseñado como tal y que sepa que va a reutilizar varias veces.

Nota : Por supuesto, una solución aún más limpia sería hacer un proyecto separado para una biblioteca y agregar una dependencia entre proyectos.

En general, me inclinaría ante YAGNI por esto. Si "no lo va a necesitar", entonces simplemente está ocupando espacio en su base de código, pruebas unitarias y ensamblajes. Puede terminar necesitándolo, pero también puede necesitar reescribirlo por completo porque entre ahora y cuando necesite algo así, muchas cosas pueden cambiar.

Sin embargo, eso cambia un poco cuando escribe una utilidad o API destinada al consumo general. Al igual que nunca puede esperar que los usuarios finales del software interactúen con el software de la manera que pretendía, tampoco puede esperar que los consumidores de su código quieran usar su código exactamente de la manera que creen que deberían hacerlo. En tales casos, siempre que pueda justificar la existencia de un método con "es una forma válida de querer interactuar con mi objeto", probablemente debería entrar, porque incluso si no lo va a necesitar, es muy probable que ALGUIEN lo haga .

Dado que la base de código tiene menos de un año, es probable que todavía esté en un gran flujo (¿sí?), Por lo que la idea de que algunos bits podrían resucitarse en el futuro cercano no es irrazonable.

Para los bits que fueron difíciles de obtener en primer lugar y parecen más propensos a resucitar, los mantendría un poco más "en vivo" que solo en el control de la fuente. La gente no sabrá / recordará que existen: ¡decir "puedes encontrarlo en el control de la fuente" supone que sabes / recuerdas que está ahí! En este tipo de casos, considere la desvalorización (con una "aserción (falsa)" showtopper) o comentando.

Si el código es trivial y poco interesante, lo descarto para eliminar la inercia innecesaria del sistema de software.

Para los cadáveres de código interesantes, uso una archiverama en mis sistemas de control de versiones.

"Se puede usar como referencia" No estaría de acuerdo con ser una buena razón para dejar el código sin usar. A menudo, solo una pequeña parte del código no utilizado en realidad está demostrando algo interesante. Hay varias formas de documentar y almacenar código útil pero no utilizado.

Aunque el control de versiones contendrá un historial que le permitirá restaurar fácilmente una funcionalidad particular si luego decide que se necesita el código, sabiendo que debe buscar en el historial de control de versiones para encontrar xy o z de quién sabe qué revisión previa puede ser un poco tedioso, y a menudo se pasa por alto a menos que tenga una idea bastante específica de lo que está buscando.

El código podría comentarse con una nota sobre cuándo se eliminó y por qué no se eliminó simplemente del código. Sin embargo, esto generalmente se considera un mal estilo, y el código que no se usa y no se mantiene adecuadamente puede introducir todo tipo de errores si no se comenta más adelante, por lo que generalmente es mejor como un paso temporal de depuración / prueba mientras se refactoriza a mediados Una forma de dejar el código de producción.

Mi forma favorita de almacenar el código eliminado, si parece ser útil en el futuro, es hacer un documento de referencia secundario que contenga todos los diversos fragmentos de código eliminado que valga la pena. Cada bloque de código está etiquetado con una breve mención de su origen o cualquier otra cosa pertinente para recordar, como cuándo se eliminó o el número de revisión en el que estaba por última vez en el código. Todo lo eliminado pero "potencialmente útil" está en un solo lugar, se puede buscar fácilmente, pero no requiere un esfuerzo constante para mantener y probar de forma continua (esa prueba se anula en cualquier punto en el que se reintroduzca el código).

Una buena razón para mantener los métodos no utilizados es: ¡ podrían usarse en otras ramas / etiquetas!

Explore todas sus ramas y etiquetas activas antes de eliminarlas.

Si usa un sistema de control de versiones, no se preocupe por futuras referencias, ya que simplemente puede ver a través del historial de ese código y encontrar la parte eliminada. Si no lo hace y cree que se usará algún día, simplemente deje que permanezca allí, pero coméntelo con una descripción que explique por qué está comentado.

Sin embargo, si está seguro de que no lo usará en el futuro, simplemente quítelo . Creo que las razones que ha mencionado son bastante sencillas para que se elimine el código.

Pero antes de quitarlo, asegúrese de que no se use en ningún lado. Visual Studio tiene una función llamada Buscar todas las referencias que busca en toda la solución y encuentra cualquier referencia a la variable, método, propiedad, clase, interfaz, etc. actual. Siempre me aseguro de que no haya ninguna referencia antes de eliminar parte de mi código.

Con relativa frecuencia he tenido la experiencia de encontrar una función que parece que hará exactamente lo que necesito, y confiar en que funcione ya que ha estado en producción durante mucho tiempo, solo para descubrir que en realidad no se ha utilizado en varios años. El código que no se usa no se mantiene, y aunque puede haber funcionado hace años, la API a su alrededor ha cambiado lo suficiente como para que no pueda confiar en él.

En el mejor de los casos, terminas pasando mucho tiempo asegurándote de que realmente sigue haciendo lo que quieres. En el peor de los casos, parece funcionar hasta que te muerde un error desagradable más tarde, y tardas más en rastrearlo porque asumiste que el código "probado en producción" funciona, por lo que el problema debe estar en otro lugar en tu nuevo código. En mi experiencia, casi siempre es más rápido escribir una nueva función yo mismo.

Si lo elimina, pero descubre relativamente pronto que realmente lo necesita, está ahí en el control de la fuente. Si no lo necesita hasta que haya pasado tanto tiempo que no recuerde que está bajo el control de la fuente, probablemente sea mejor escribirlo desde cero de todos modos.

Nada consume menos tiempo que ningún código.

Si tiene que sumergirse en una base de código, necesita algo de tiempo para averiguar, para qué se usa ese código, y si no se usa para nada, necesita aún más tiempo.

Ok, esto podría ser curado como un comentario, pero nuevamente, todos razonarán sobre por qué este código no utilizado todavía está en la base del código, ya sea que deba eliminarse o no.

Si no hay nada, nadie perderá tiempo con eso.

Si fue difícil hacerlo bien, necesita una buena documentación, que este código existe, pero si la base de código evoluciona a lo largo de algunas iteraciones, tal vez ya no funcione, si se reactiva.

Elimine el código no utilizado: menos desorden, mejor comprensión. Su sistema de control de versiones se encargará. Además, si está utilizando algo mejor que el bloc de notas, su entorno le permitirá utilizar un código anterior como referencia.

Los comentarios largos del código antiguo distraen y dificultan la navegación.

Saludos

Sigue este algoritmo simple:

1. ¿Está respaldado en un SCM? Si es así, salta a 3.
2. Configurar un SCM.
3. Tira las cosas a la basura .

Todos sus puntos a favor de la eliminación son válidos.

Todos sus puntos a favor de mantener el desorden no son válidos una vez que tenga un SCM para buscarlo o restaurarlo. En realidad, su SCM debería poder ayudarlo a determinar por qué ese código está aquí y sin usar, si se usó correctamente.

Se llama "código muerto" por una razón. Déjalo morir y descansa en paz.

Permanecerá en el control de la fuente; no debe permanecer en la base del código activo.

La única excepción es si el código completa el diseño y, si bien no está utilizando el código, planea hacer público el código y otros pueden desear esa funcionalidad básica. Luego, solo diseñe pruebas para asegurarse de que estas partes del código funcionen y simulen cómo propone que otros puedan usar estas partes del código. Sin embargo, si incluso está considerando eliminar el código y no puede encontrar una razón sólida para mantenerlo, debería desaparecer. El código no utilizado hace más trabajo para todos (más difícil de leer el código; el código puede estar roto; más trabajo para mantener; etc.)

En mi experiencia, eliminar el código no utilizado también puede ser contraproducente. Puede olvidar que tenía ese código y no lo buscará en el historial. O tal vez ni siquiera sepa que alguien implementó ese código y luego lo eliminó más tarde. De nuevo, no lo buscarás en la historia ...

Sin duda, tener código no utilizado es un mal olor.

ACTUALIZACIÓN: Acabo de notar que Ed Staub dio una respuesta muy similar.