Todas as correções sujas são iguais? [fechadas]

4

Eu vi algum código sujo no meu tempo. Eu ouvi vários comentários sobre "correções sujas" também:

a) um "reparo" sujo não é uma correção

b) algumas correções mais sujas do que outras, mas sujas    correções não são aceitáveis

c) algumas correções mais sujas do que outras e algumas    correções sujas são mais aceitáveis do que    outros

d) correções sujas mostram um    uso pragmático de tempo, mas deve    desanime

e) correções sujas mostram um    uso pragmático do tempo e deve    não desanime

f) outro

Com qual das alternativas acima você concorda e por quê? Como você impede que atitudes como (e) se tornem práticas padronizadas?

    
por CarneyCode 16.04.2011 / 11:06
fonte

9 respostas

11

Uma correção 'suja' é uma forma de Dívida técnica e, se você pode pagar, ela tem um custo final / análise de benefícios.

Pedimos desculpas a Olve Maudel, que (em uma conversa de raio (p3) no Conferência da ACCU ) pode ter dito algo não completamente diferente do seguinte, compare:

  • O custo imediato de corrigir um bug corretamente + o custo imediato de não tê-lo corrigido no tempo

vs.

  • O custo imediato de uma correção suja + o custo contínuo a longo prazo da correção suja

Se consertar corretamente, significa que você perdeu um prazo que teria um pagamento fixo ou significa que um concorrente chega ao mercado antes de você, então esse custo pode ser bem alto e pode ter valido a pena dívida em seu lugar. Mas lembre-se de que quanto mais tempo você deixar essa dívida não paga, mais juros você acumulará em termos de custo de suporte ao código e de adição de novos recursos.

Tenha cuidado, porém, se você usar ser pragmático como uma desculpa para a preguiça e continuar acumulando a dívida técnica, mas nunca pagar a dívida anterior através do re-factoring, você pode descobrir que a dívida aumenta tão alto que falência é a única opção pragmática . * 8 ')

    
por 17.04.2011 / 00:56
fonte
9

É verdade que uma "correção" suja não é uma correção (a). Se um produto tiver um problema, uma correção limpa destina-se a corrigir esse problema para:

  • Reutilize a parte em questão do produto e verifique se não há problemas conhecidos com ela,
  • Não precisa voltar a modificar o código mais tarde para resolver erros.

Com uma correção, o desenvolvedor:

  • Não é possível reutilizar a parte em questão, porque ela não pode ter certeza de que funcionará conforme o esperado,
  • É preciso retornar mais tarde para reescrever o código corretamente.

Então, em vez de gastar mais tempo consertando alguma coisa, uma solução inadequada é usada para gastar menos tempo imediatamente, mas mais tempo ultimamente, forçando a devolução e uma correção limpa, proibindo a reutilização de código enquanto isso.

É claro que isso pode não se aplicar a todas as correções sujas, e também depende do que chamamos de conserto sujo ou não. Exemplo:

Um usuário envia um relatório dizendo que um programa fornece um resultado incorreto quando a entrada é igual a 39,5. Uma correção de candidato DailyWTF estupidamente suja seria fazer:

if (input == 39.5)
{
    // 14.7 is a correct result, calculated by hand.
    output = 14.7;
}
else
{
    // Keep the old and broken algorithm.
    // ...
}

Provavelmente, em alguns dias ou semanas, outro relatório de outro cliente nos informará que a saída também está incorreta para algum outro valor de entrada.

Uma correção menos suja seria verificar o algoritmo, ver onde ele está quebrado e consertá-lo, sem consertar os testes unitários . As chances de vê-lo quebrar novamente são menores, mas isso pode acontecer, e há uma necessidade de retornar mais tarde para adicionar testes de unidade, talvez adicionar comentários, impor diretrizes de estilo, escrever documentação, etc.

Então, sim, algumas correções são mais sujas do que outras (b, c). Se alguns são mais aceitáveis do que outros , isso depende das diretrizes da sua empresa.

Correções sujas mostram um uso pragmático do tempo (d, e). Num momento preciso. Porque gastando alguns minutos a menos, você desperdiça horas do seu próprio tempo ultimamente (ou seus colegas gastarão mais tarde limpando sua correção). É por isso que correções sujas devem ser desencorajadas especialmente em uma equipe. Se um desenvolvedor faz muitas correções, deixa a empresa, as outras pessoas da equipe terão dificuldade em limpar as correções.

Como podemos impedir que atitudes como "correções sujas mostram um uso pragmático do tempo e não devem ser desencorajadas" de se tornar prática padrão?

Ao aplicar as melhores práticas, mas também garantindo que os desenvolvedores em uma equipe / em uma empresa se comuniquem bem sobre o que estão fazendo. Muito pressão e estresse da gerência também podem forçar os desenvolvedores a usar mais correções sujas apenas para terminar rapidamente. Isso é especialmente verdadeiro quando o gerente da equipe é inexperiente o suficiente e / ou não se importa com a qualidade do código .

    
por 16.04.2011 / 11:30
fonte
2

Depende do contexto.

Eu certamente coloquei algumas correções horríveis no meu tempo, mas o código em que eu estava trabalhando estava além da redenção - uma confusão completa de PHP que era copiar / colar massa de dependências em todos os lugares (com variações) e o banco de dados mais aleatório "design" que eu já vi. É claro que nunca mostrarei de bom grado esse código em apoio a um pedido de emprego!

Normalmente eu vou com a) No mínimo o que eu faço deve ser compreensível e sustentável. Se eu puder melhorar / refatorar um pouco ao mesmo tempo, tanto melhor.

d) ee) são simplesmente preguiçosos ... você pode economizar 30 minutos agora, mas e quando a próxima atualização / correção é necessária em seis meses? É falsa economia.

    
por 16.04.2011 / 11:31
fonte
2

Em geral hacks / dirty fixes devem ser evitados e rejeitados. Existem exceções.

  1. Se a estrutura / linguagem for muito limitada para fazê-lo adequadamente sem a reestruturação do projeto em massa.
  2. Se o framework / idioma tiver um bug que deve ser contornado
  3. Se não houver uma maneira previsível de realmente corrigir o problema principal (relacionado ao # 1)

Para o nº 3: Por exemplo, eu fiz algumas coisas muito estranhas trabalhando em torno do ciclo de vida de páginas tortas do ASP.Net. Eu entendi exatamente como cada evento foi chamado e porque meu código não estava funcionando. Então, acabei chamando _Click methods manualmente verificando a matriz Form no início do ciclo de vida da página, do que os eventos são normalmente chamados.

Para o nº 1: Eu tinha uma consulta SQL sendo construída manualmente, então acabou sendo como

query="select * from table where";
if(Option1){
  query+=" option1='"+Option1String+"' ";
}
if(Option2){
  query+=" option2='"+Option2String+"' ";
}
if(Option3){
  query+=" option3='"+Option3String+"' ";
}

Então acabou que, se nenhuma das opções fosse selecionada, eu teria um erro de sintaxe. Minha outra opção era constantemente construir um if(Option1 | Option2 | Option3) que eu pensava ser um pesadelo de manutenção para quando as opções foram adicionadas. Então eu consertei com uma única alteração:

query="select * from table where 1=1";

Eu consideraria esse truque sujo / porque não é imediatamente aparente porque 1=1 foi colocado lá. Eu, claro, comentou o inferno de explicá-lo. Mas ainda é um truque. A alternativa "correta" era mais difícil de manter.

    
por 17.04.2011 / 05:45
fonte
2

Uma correção "suja" é uma correção; caso contrário, não seria uma pausa?

Acho que a questão de se uma correção "suja" deve ser inaceitável ou desencorajada presume que há uma distinção clara entre uma correção "suja" e uma correção "limpa", e não acho que exista. Eu apliquei correções que achei que eram "limpas", que acabaram se mostrando "sujas" em comparação com a próxima correção. (Menos frequentemente, eu apliquei correções que eu achava que estavam "sujas" que acabaram se mostrando bastante "limpas"). Acho que seria mais valioso distinguir entre uma correção "suja" e uma correção "mais suja", sendo a primeira preferível, tudo o mais igual.

Tanto a correção "suja" quanto a "mais suja" devem resolver o problema imediato, mas quando comparada à correção "mais suja", a correção "suja" deve reduzir a probabilidade de erro futuro e, caso ocorra um erro, reduzir o esforço necessário para resolver esse erro. Isso pode exigir tanto quanto refatorar o código ou pode exigir apenas documentar o código e registrar sua execução, para que o próximo desenvolvedor possa diagnosticar e corrigir o erro.

Quanto a como desencorajar os desenvolvedores a escolherem a correção "mais suja", eu diria que parar de encorajar os desenvolvedores a escolher a correção mais "suja", preferindo explicitamente a correção mais rápida e, assim, preferindo implicitamente "mais sujo" um.

    
por 17.04.2011 / 07:34
fonte
1

Em geral, uma "correção" ou um "hack" é uma coisa ruim. E na escola aprendemos a não consertar. Mas na vida real, quando o tempo é essencial, as correções acontecem como constantes de IDs em código, não tornando o código geral o suficiente. Enquanto todos do projeto concordarem com o que está sendo feito, acho que está tudo bem. O risco é que o código não seja alterado mais tarde para ser corrigido. O risco é que se esteja construindo um labirinto de código que será mais difícil e mais difícil de corrigir quanto mais tempo as correções permanecerem. Também o tempo para alterar as correções aumenta logarítmico quanto mais tempo eles estão autorizados a permanecer na solução.

Então eu concordo em c) ed) se possível - ou seja, se você precisa corrigir, comentar bem e tornar o código simples o suficiente para o próximo programador, que pode ser o único a corrigir a correção. Então você aproveitou ao máximo a situação atual.

    
por 16.04.2011 / 11:31
fonte
1

Eu me inclino para f) com uma boa dose de d) e c).

Se a próxima versão do código estiver sendo ativamente desenvolvida, uma correção rápida (rápida) pode ser uma ação apropriada no ramo de produção. A correção deve ser a mais limpa possível e certamente não deve se qualificar como um candidato ao DailyWTF. Ele pode permitir que você corrija a ramificação de produção nos casos em que a correção limpa precisará de mais trabalho do que é prático.

Se você usar uma correção suja, ela não deverá ser mesclada na ramificação de desenvolvimento. Com poucas exceções (recursos descartados), todas as correções de produção devem ser aplicadas ao fluxo de desenvolvimento. Se você pode aplicar uma correção limpa, mesclá-lo no fluxo de desenvolvimento é apropriado. Caso contrário, a correção deve ser refeita de forma limpa no fluxo de desenvolvimento.

    
por 17.04.2011 / 20:01
fonte
1

A questão é em grande parte acadêmica. Na maioria das vezes, em um ambiente de produção, não há tempo para fazer as coisas "limpas" quando um problema aparece em um sistema de produção. Assim, você escolhe a rota mais rápida para corrigir o problema, limitando o tempo de inatividade o máximo possível. Isso pode ser uma "solução suja", já que não é o código mais atraente, mas faz o trabalho ser muito mais importante, pois o tempo de inatividade significa perda de receita, código que não parece legal significa apenas pontos de brownie perdidos para os programadores egos.

Se for um hack real, você provavelmente vai marcá-lo para refatorar na primeira oportunidade (ou seja, quando essa parte do código estiver agendada para a próxima alteração, NÃO no próximo lançamento, apenas porque você quer se livrar dele) mas vai entrar agora porque simplesmente não há tempo para fazer as coisas bem.

Tal é o mundo dos prazos, trabalhando para os requisitos do mundo real, em vez de trabalhos de casa.

    
por 18.04.2011 / 08:30
fonte
0

Minha opinião é de que nunca é um bom motivo para uma correção, apenas desculpas que sugerem um problema maior. Às vezes, esse problema é algo que você não pode consertar (por exemplo, sem compromisso de gerenciamento, problema com a estrutura / linguagem que você está usando), mas ainda assim é sempre uma desculpa para encobrir outra coisa.

Não é de surpreender que eu tente evitar fazer as coisas da maneira "suja" sempre que possível, já que minha experiência é que você nunca será capaz de consertá-lo apropriadamente e "pagar de volta" a Dívida Técnica.

    
por 18.04.2011 / 17:57
fonte