Como gerenciar casos especiais e heurísticas

Question

Costumo ter código com base em um algoritmo específico bem definido. Isso é bem comentado e parece adequado. Para a maioria dos conjuntos de dados, o algoritmo funciona muito bem.

Mas então os casos de borda, os casos especiais, as heurísticas são adicionadas para resolver problemas específicos com conjuntos específicos de dados. À medida que o número de casos especiais cresce, os comentários ficam cada vez mais nebulosos. Temo voltar e olhar para esse código em mais ou menos um ano e tentar lembrar por que cada caso especial ou heurístico foi adicionado.

Às vezes eu gostaria que houvesse uma maneira de incorporar ou vincular gráficos no código -fonte, para que eu pudesse dizer efetivamente ", no gráfico desse conjunto de dados, esse recurso em particular aqui estava fazendo com que a rotina acionasse incorretamente, é por isso que esse pedaço de O código foi adicionado ".

Quais são algumas das melhores práticas para lidar com situações como essa?

Os casos especiais parecem sempre ser necessários para lidar com esses casos incomuns/borda. Como eles podem ser gerenciados para manter o código relativamente legível e compreensível?

Considere um exemplo que lida com o reconhecimento de recursos de fotos (não exatamente o que estou trabalhando, mas a analogia parece adequada). Quando encontro uma imagem específica para a qual o algoritmo geral falha e é necessário um caso especial, gravo o melhor que posso em um comentário (ou como alguém sugerido abaixo, um nome de função descritivo). Mas o que muitas vezes está faltando é um link permanente para o arquivo de dados específico que exibe o comportamento em questão. Embora meu comentário deva descrever o problema e provavelmente diria "veja o arquivo foo.jp para um exemplo desse comportamento", esse arquivo nunca está na árvore de origem e pode facilmente se perder.

Em casos como esse, as pessoas adicionam arquivos de dados à árvore de origem para referência?

Answer 1

Se você tem uma base de conhecimento ou um wiki para o projeto, poderá adicionar o gráfico, vinculando -o ao método conforme Fowler de Matthewe e também na mensagem de comprometimento do controle de origem para a alteração do caso da borda.

//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

É mais trabalho, mas uma maneira de documentar casos mais detalhadamente do que meros casos de teste ou comentários poderiam. Mesmo que se possa argumentar que os casos de teste devem ser a documentação suficiente, talvez você não queira armazenar todo o conjunto de dados com falha, por exemplo.

Lembre -se, problemas vagos levam a soluções vagas.

Answer 2

Martin Fowler disse em seu livro de refatoração que, quando você sente a necessidade de adicionar um comentário ao seu código, primeiro veja se você pode encapsular esse código em um método e dar ao método um nome que substituiria o comentário.

Portanto, como resumo, você pode criar um método chamado.

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;
}

Então você pode escrever código como

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

Não é um exemplo concreto duro e rápido, mas ajudaria a legibilidade em um ano ou dois.

Answer 3

O teste de unidade pode ajudar aqui. Ter testes que realmente simulam os casos especiais podem servir como documentação sobre por que o código faz o que faz. Isso geralmente pode ser melhor do que apenas descrever o problema em um comentário.

Não que isso substitua a movimentação do manuseio de casos especiais para suas próprias funções e comentários decentes ...

Answer 4

Normalmente, não sou um defensor do desenvolvimento orientado a testes e estilos semelhantes que testam muito o estresse, mas esse parece ser um caso perfeito em que um monte de testes de unidade pode ajudar muito. E nem mesmo em primeiro lugar para capturar bugs de alterações posteriores, mas simplesmente documentar todos os casos especiais que precisam ser abordados.

Alguns bons testes de unidade com comentários são, por si só, a melhor descrição dos casos especiais. E os comentários do código em si também ficam mais fáceis. Pode -se simplesmente apontar para alguns testes de unidade que ilustram o problema que está sendo resolvido nesse ponto do código.

Answer 5

Sobre a

Às vezes eu gostaria que houvesse uma maneira de incorporar ou vincular gráficos no código -fonte, para que eu pudesse dizer efetivamente ", no gráfico desse conjunto de dados, esse recurso em particular aqui estava fazendo com que a rotina acionasse incorretamente, é por isso que esse pedaço de O código foi adicionado ".

papel:

Se o "gráfico" que você deseja incorporar for um gráfico e se você usa Doxygen, você pode incorporar ponto comandos em seu comentário para gerar um gráfico na documentação:

/**
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

Don Knuth inventou programação alfabetizada Para facilitar a documentação do seu programa, incluir gráficos, gráficos, gráficos, equações matemáticas e o que quer que você precise fazer com que seja entendido. Um programa alfabetizado é uma ótima maneira de explicar por que algo é o jeito que é e como chegou assim ao longo do tempo. Existem muitas, muitas ferramentas de programação de alfabetização; A ferramenta "Noweb" é uma das mais simples e é enviada com algumas distribuições Linux.

Answer 7

Sem conhecer a natureza específica do seu problema, não é fácil dar uma resposta, mas, em minha própria experiência, o manuseio de casos especiais em código rígido deve ser evitado. Você não pensou em implementar um mecanismo de regras ou algo parecido para lidar com casos especiais fora do seu algoritmo principal de processamento?

Answer 8

Parece que você precisa de documentação mais completa do que apenas comentários de código. Dessa forma, alguém poderia procurar a função em questão na documentação e receber uma imagem de exemplo que requer um caso especial.