Cómo gestionar casos especiales y heurísticas

Question

A menudo tengo código basado en un algoritmo específico bien definido.Esto se comenta bien y parece apropiado.Para la mayoría de los conjuntos de datos, el algoritmo funciona muy bien.

Pero luego se agregan los casos extremos, los casos especiales y las heurísticas para resolver problemas particulares con conjuntos de datos particulares.A medida que crece el número de casos especiales, los comentarios se vuelven cada vez más confusos.Temo volver atrás y mirar este código dentro de aproximadamente un año y tratar de recordar por qué se agregó cada caso especial o heurística en particular.

A veces desearía que hubiera una forma de incrustar o vincular gráficos en el código fuente, para poder decir efectivamente, "en el gráfico de este conjunto de datos, esta característica particular aquí estaba causando que la rutina se activara incorrectamente, por eso esta pieza de se agregó el código".

¿Cuáles son algunas de las mejores prácticas para manejar situaciones como esta?

Parece que siempre se requieren casos especiales para manejar estos casos inusuales o extremos.¿Cómo se pueden gestionar para mantener el código relativamente legible y comprensible?

Considere un ejemplo que trata sobre el reconocimiento de características a partir de fotografías (no es exactamente en lo que estoy trabajando, pero la analogía parece adecuada).Cuando encuentro una imagen en particular para la cual falla el algoritmo general y se necesita un caso especial, registro lo mejor que puedo esa información en un comentario (o como alguien sugirió a continuación, un nombre de función descriptivo).Pero lo que a menudo falta es un vínculo permanente al archivo de datos particular que muestra el comportamiento en cuestión.Si bien mi comentario debería describir el problema y probablemente diría "consulte el archivo foo.jp para ver un ejemplo de este comportamiento", este archivo nunca está en el árbol de fuentes y puede perderse fácilmente.

En casos como este, ¿la gente agrega archivos de datos al árbol de fuentes como referencia?

Answer 1

Si usted tiene una base de conocimientos o un wiki para el proyecto, se podría añadir el gráfico en el mismo, que une a él en el método de acuerdo con Fowler de Mateo quot correos y también en el control de código fuente se comprometen mensaje para el caso de cambio borde.

//See description at KB#2312
private object SolveXAndYEdgeCase(object param)
{
   //modify param to solve for edge case
   return param;
}

Commit Message: Solution for X and Y edge case, see description at KB#2312

Es más trabajo, sino una manera de documentar los casos más a fondo que los casos de prueba simples o comentarios fuera posible. A pesar de que se podría argumentar que los casos de prueba deben ser documentación suficiente, puede que no desee almacenar toda su defecto conjunto de datos en el mismo, por ejemplo.

Recuerde, los problemas vagas conducen a soluciones vagas.

Answer 2

dijo Martin Fowler en su libro refactorización que cuando se siente la necesidad de agregar un comentario a su código, primero ver si se puede encapsular ese código en un método y dar al método de un nombre que se sustituye el comentario.

así como un resumen se podría crear un método llamado.

private bool ConditionXAndYHaveOccurred(object param)
{
   // code to check for conditions x and y
   return result;
}

private object ApplySolutionForEdgeCaseWhenXAndYHappen(object param)
{
   //modify param to solve for edge case
   return param;
}

A continuación, puede escribir código como

if(ConditionXAndYHaveOccurred(myObject))
{
    myObject = ApplySolutionForEdgeCaseWhenXAndYHappen(myObject);
}

No es un ejemplo concreto duro y rápido, pero ayudaría con la lectura en un año o dos.

Answer 3

Prueba de la unidad puede ayudar aquí. Que tienen pruebas de que realmente simulan los casos especiales a menudo pueden servir como documentación sobre por qué el código hace lo que hace. Esto a menudo puede ser mejor que limitarse a describir el problema en un comentario.

No es que esto sustituye a mover el manejo de sus propias funciones y comentarios decentes caso especial ...

Answer 4

Normalmente no soy un defensor del desarrollo basado en pruebas y estilos similares que hacen hincapié en las pruebas demasiado, pero esto parece ser un caso perfecto donde un grupo de prueba de la unidad puede ayudar mucho. Y ni siquiera en el primer lugar para coger los insectos de los cambios posteriores, sino simplemente para documentar todos los casos especiales que necesitan ser abordados.

Algunos buena prueba de la unidad con comentarios en ellos son en sí la mejor descripción de los casos especiales. Y la comentando del propio código se hace más fácil también. Uno puede simplemente señalar algunas pruebas de unidad que ilustran el problema que se está resolviendo en ese punto en el código.

Answer 5

Sobre el

  

A veces me gustaría que hubiera una manera de incrustar o vincular gráficos en el código fuente,   por lo que podría decir de manera efectiva "en el gráfico de este conjunto de datos, este particular   presentará aquí estaba causando la rutina para disparar de forma incorrecta, así que por eso esta pieza de   se añadió código".

Pieza:

Si el "gráfico" que desea incrustar es un gráfico, y si se utiliza Doxygen , puede incrustar dot comandos en su comentario para generar un gráfico en la documentación:

/**
If we have a subgraph looking like this:
\dot
digraph g{
A->B;
A->C;
B->C;
}
\enddot
the usual method does not work well and we use this heuristic instead.
*/

Answer 6

programación literaria para hacer más fácil para la documentación del programa para incluir parcelas, gráficos, tablas, ecuaciones matemáticas, y todo lo que necesita para que sea entendido. Un programa de leer y escribir es una gran manera de explicar por qué algo es la manera que es y cómo llegó a ser así con el tiempo. Hay muchas, muchas herramientas de programación leer y escribir; la función "noweb" es uno de los más sencillos y se envía con algunas distribuciones de Linux.

Answer 7

Sin conocer la naturaleza específica de su problema no es fácil dar una respuesta, pero en mi propia experiencia, el manejo de los casos especiales en código duro debe ser evitado. ¿No ha pensado en la implementación de un motor de reglas o algo por el estilo para el manejo de casos especiales fuera de su algoritmo de procesamiento principal?

Answer 8

Parece que es necesaria una documentación más completa que sólo comentarios de código. De esa manera alguien podría mirar hacia arriba la función en cuestión en la documentación y se presenta con una imagen ejemplo que requiere un caso especial.