Nombres de métodos dolorosamente estúpidos en código heredado: ¿Arreglar o dejar como advertencia? [duplicar]

7

Para este caso, supongamos algo como ... "RemovedNonPriceChangingConfermations" que de ninguna manera se relaciona con cosas que sucedieron en el tiempo pasado, ni devuelve una lista de elementos eliminados (que nunca necesitaría en este contexto) .

Si no puedes detectar el otro problema, te desafío a participar en un concurso de ortografía de alto rendimiento.

El dilema:

¿Es mejor cambiar el nombre del método para describir de forma más precisa y menos dolorosa lo que realmente hace?

O dado que se encuentra dentro de una montaña rusa de 20 clases de fallas (mapear una tabla consultada db con un bean) es mejor dejarlo como una especie de boya de advertencia del único ¿Las mentes que elaboraron el código con comentarios para explicar lo que realmente hace en la definición? Al menos hasta que podamos refactorizar adecuadamente la cosa tonta.

Si es relevante, asuma una alta tasa de rotación pero siempre buenas intenciones.

Nota: no es difícil cambiar el nombre del método. Esta pregunta es más general acerca de si no es mejor dejar intacto el nombre de un método realmente tonto para que las personas puedan ver que están entrando en "una de esas partes" de la base del código o si de hecho debería cambiarlo para mejorar. refleja lo que realmente hace.

    
pregunta Erik Reppen 09.07.2013 - 21:38

6 respuestas

3

¿Es útil como señal de advertencia? Realmente no. Solo confundirá a la gente y será difícil de recordar.

Una función bien nombrada que le dice a alguien que no está familiarizado qué hace realmente el código de hairy es muy útil. El código malo o confuso, que usted insinúa está en la función, puede ser horrible de resolver. Si has hecho eso y puedes dar una buena descripción de la función en el nombre, has facilitado mucho el trabajo del siguiente programador.

Comentar lo que hace también es útil, pero los comentarios no siempre se leen, pero el nombre de la función es.

Las ventanas rotas siempre deben repararse. No se corrige el nombre dejará una ventana rota y alentará al programador siguiente a que no comience a modificar el factor.

    
respondido por el Dominic McDonnell 10.07.2013 - 02:42
17
  • Suprimir la base de código completa para el nombre del método. Averigüe qué tan público es, cuántas confusiones lo mencionan, etc.

  • Cambie el nombre del método sin piedad (un buen IDE puede hacer esto), grep nuevamente, actualice manualmente cualquier referencia que el IDE haya omitido. Agregue un comentario que explique las peculiaridades del método, si corresponde.

  • Si el método no es público (solo tiene visibilidad de paquete o más limitado), ¡listo!

  • Si el método es de alguna manera público (expuesto a terceros o simplemente tiene visibilidad pública sin ninguna razón aparente), cree un método con el nombre antiguo que llama al método cuyo nuevo nombre ha cambiado y logs el hecho. De esta manera usted descubrirá qué otros clientes de estos métodos son. Si estos están bajo su control, finalmente haga que usen el nuevo nombre.

  • Ejecutar pruebas. Si no tiene una prueba para ese método, o para algunos de sus clientes, es un buen momento para agregarlos.

respondido por el 9000 09.07.2013 - 22:22
3

Refactorízalo, pero primero haz una impresión. Enmarcalo. Y ponlo en un salón de la vergüenza de la fama.

    
respondido por el Tulains Córdova 09.07.2013 - 22:22
1

Cómo abordaría esto:

Si la refactorización realmente va a ocurrir en algún momento, lo dejaría como está con un comentario.

Si solo se llama en algunos lugares y tiene una buena cobertura de prueba, entonces lo cambiaría.

Si ninguna de estas situaciones se aplica pero te mantiene despierto por la noche, lo cambiaría.

Si no, pasa a algo más importante.

    
respondido por el Joel 09.07.2013 - 21:51
0

Probablemente lo arreglaría, especialmente si tuviera algo de trabajo que hacer en esa área ... No hay necesidad de dejar el código incorrecto. Ejemplos de buenos nombres triunfan ejemplos de malos nombres.

Pero, algunas cosas que podrían afectar esa decisión son si puedo probarla para detectar consecuencias no intencionadas. Especialmente si es público y desde una interfaz en código heredado.

Me encontré con eso hoy, de hecho, un método que era público y en una interfaz, que no parecía estar referenciado desde ningún lugar, hasta que ejecuté la aplicación y encontré un marco heredado en nuestra aplicación que está configurado con nombres de métodos en XML lo usé.

Si no pudiera confirmar que las cosas todavía funcionaban correctamente después del cambio, probablemente lo dejaría para fermentar.

    
respondido por el Kevin Rubin 09.07.2013 - 22:12
0

Lo arreglaría. La pregunta se refiere a Java, pero codifico en C # para ganarme la vida y poseo una copia de ReSharper, por lo que cambiar el nombre de un miembro del código, desde un campo privado hasta la raíz del espacio de nombres, es bastante simple; haga clic con el botón derecho- > Refactor- > Renombrar. Entonces, solo lo hago, porque realmente es así de simple (el 99% del tiempo; si trabajo en bibliotecas compartidas entre diferentes bases de código, podría ser más cauteloso, ya que un poco de nuestro código heredado no tiene compilación automática) en TeamCity).

No sé qué tipo de herramientas en este sentido están disponibles para Eclipse, pero JetBrains también escribe IntelliJ IDEA, que tiene muchas de estas operaciones de refactorización integradas.

    
respondido por el KeithS 10.07.2013 - 03:55

Lea otras preguntas en las etiquetas