¿Debo eliminar el código sin referencia?

118

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
Simon Hutton
fuente
22
"Menos código, menos errores" - si realmente nunca se usan, es poco probable que causen errores
Konrad Morawski
19
@Morawski Pero si se deja adentro, algún día se usará. Y como no se ha mantenido, tendrá errores, que luego aparecerán.
DJClayworth
99
Por lo general, lo comentaría y las pruebas que dependen de él, y luego dejaría un comentario 'TODO' con una fecha. Una vez que no se ha usado durante un año, lo tiro. Otros recomiendan simplemente eliminarlo ahora, pero me resulta difícil hacerlo, especialmente si parece que el código alguna vez fue útil.
Trabajo
31
@ Job Si encuentro un código comentado, se elimina. No hay excusas. El código comentado solo grita "No confío en nuestro sistema de control de fuente". a mi.
Kristof Provost
26
@ Kristof Provost, ¿cómo podría saber que el código útil estuvo una vez en el archivo fuente A si ya no está? por supuesto, siempre puede verificar el historial del archivo en el que se encuentra, pero con qué frecuencia piensa: "Hm ... necesito cambiar / implementar una función aquí. O necesito probar cómo funcionó esto 5 años Hace RÁPIDAMENTE. Me pregunto si alguien ya lo implementó y luego lo eliminó ... déjame revisar el historial ". No estoy abogando por esa basura desordenado se mantiene alrededor, pero hay circunstancias en las que no esté utilizando el código en la producción, pero sí / usted pueda necesitar en ocasiones para la depuración, etc.
Trabajo

Respuestas:

219

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.

DeadMG
fuente
30
Estoy de acuerdo con eliminarlo, pero he tenido casos en los que rompí algo porque alguien estaba usando el código "no utilizado" a través de la reflexión. Así que uno debe tener cuidado de todos modos.
Falcon el
14
@Falcon, esa es una buena razón para eliminarlo lo antes posible, antes de que la gente comience a usarlo, o descubra la necesidad de hacerlo público.
StuperUser
66
@Falcon: Es la afirmación del OP de que el código no se usa.
DeadMG
44
@StuperUser: estoy totalmente de acuerdo. Pero hay que tener cuidado y prepararse para lo inesperado.
Falcon el
18
Si lo elimina y su unidad y las pruebas de regresión pasan, pero el producto se rompe en el campo, proporciona un caso sólido para establecer algún tipo de herramientas de cobertura de código.
Andrew T Finnell el
43

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.

StuperUser
fuente
1
Sí, el código sin referencia no debe dejarse en el código en vivo.
xdazz
Me parece que también obtienes estos beneficios simplemente comentando grandes fragmentos.
Steve Bennett
@SteveBennett De hecho, pero no entiendes el punto de esta respuesta. Enumero los beneficios de mantenerlo comentado, el punto es que obtendrá todos estos Y MÁS beneficios del control de fuente (que verá en otras respuestas).
StuperUser
Ciertamente no estoy en contra de VCS. :) (Sin embargo, sí noto que una vez que se eliminan las cosas de la versión actual, es mucho menos visible que otros enfoques, como almacenarlo en un archivo de texto sin referencia, en una wiki, en comentarios, etc.)
Steve Bennett
@Steve Bennet: puede ser "menos visible" que los comentarios en la versión actual de un archivo, pero es trivial verificar el historial de VCS de un solo archivo, y diría que es mucho más fácil que el archivo txt / wiki / etc. .. enfoques.
Zach Lysobey
23

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.

Nicholas Smith
fuente
40
Para mejorar ligeramente su analogía, es como mantener las baterías casi agotadas pegadas a su control remoto, en lugar de en una caja al lado de las baterías nuevas en el almacén etiquetadas como "baterías usadas pero no agotadas".
Scott Whitlock
¡Más 1 para la mejora mucho mejor!
Nicholas Smith el
15

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.

Giorgio
fuente
1
Como ejemplo de esto, tengo algunas rutinas de biblioteca que leen y escriben tipos de datos con y sin signo de varios tamaños dentro de una matriz de bytes. Parece más limpio tener un conjunto de tales rutinas para todos los tipos de datos, que tener algunos presentes y otros no, según lo que el código requiera en este momento.
supercat
11

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 .

KeithS
fuente
8

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.

Ed Staub
fuente
55
¡+1 por "decir 'puedes encontrarlo en el control de fuente' supone que sabes / recuerdas que está ahí!" - a veces encuentro pequeños recordatorios de código que fue cortado para ser útil, por alguna razón u otra.
Steven
3

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.

phresnel
fuente
3

"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).

Jessica Brown
fuente
2

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.

davorp
fuente
Eso no tiene sentido para mí: si no se usa en esta rama, elimínelo de esta rama. Si otra rama lo usa, permanecerá allí.
sleske
1

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.

Saeed Neamati
fuente
1

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.

Karl Bielefeldt
fuente
1

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.

usuario desconocido
fuente
1

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

Luca Botti
fuente
1

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.

haylem
fuente
0

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.)

dr jimbob
fuente
0

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.

Ali
fuente