Como tratar os bugs que os usuários pensavam serem um recurso?

Pergunta :

Qual é a maneira correta de solucionar um bug que um usuário final considerava um recurso?

Elaboração :

Eu estou supondo que, se uma grande porcentagem de usuários esperava isso como um recurso, ele deveria ser deixado "sem correção" ou "fixo" para ser mais estável? No entanto, e se uma porcentagem muito pequena de usuários espera que seja um recurso ... digamos 0,1% ou 1%, e esse bug deve ser corrigido.

Teoricamente, como essa é uma pequena correção de bug, ela pode se qualificar como PATCH conforme a versão semântica: xyZ No entanto, como quebra a compatibilidade com versões anteriores (mesmo que apenas para alguns usuários), deve haver um aumento MAIOR: Xyz correto? Ele ainda pode se qualificar como PATCH (já que não era um recurso), desde que documentado?

EDIT: neste caso específico, é um bug em uma API de uma biblioteca usada internamente que outros desenvolvedores usam.

Eu estou supondo que, se uma grande porcentagem de usuários esperava isso como um recurso, ele deveria ser deixado "sem correção" ou "fixo" para ser mais estável?

O bug agrega valor? Nesse caso, é mais um recurso. Às vezes, um "bug" pode acabar como um "recurso" de valor agregado.

É difícil realmente responder isso conclusivamente, porque cada situação será diferente.

Nesse caso específico, é um bug em uma API de uma biblioteca usada internamente que outros desenvolvedores usam.

Nesse caso, eu incluiria uma correção como parte de sua próxima alteração com relação à compatibilidade com versões anteriores. Você não pode realmente fazer isso consistentemente na maioria dos ambientes e provavelmente há um cronograma / prazo para isso.

Como desenvolvedor, a última coisa com a qual quero lidar é com uma API com comportamento incorreto ou inconsistente. Erros são considerados isso.

No mínimo, crie algum tipo de documento / wiki de "bugs conhecidos com a versão atual" internamente e assim você poderá garantir que todos os seus usuários internos saibam que a funcionalidade é semelhante a um bug. Espero que você tenha testes suficientes cobrindo as áreas em que as pessoas estão usando o bug como um recurso, para que você veja onde / quando as coisas quebram quando / se você corrige o bug.

Eu recomendo torná-lo mais estável. Os usuários são a fonte canônica do que seu software faz. Se eles querem, e passaram a confiar nele, eu pensaria duas vezes antes de puxá-lo.

Um bom exemplo disso é o mecânico "Skiing" no videogame "Tribes". Originalmente um bug na maneira como o mecanismo de física lidava com saltos em uma colina, ele acabou sendo uma das principais mecânicas do jogo. Você pode ler um pouco mais sobre isso aqui , se estiver curioso.

Como o bug está em uma biblioteca, aqui está outra abordagem que você pode adotar:

1. Faça um clone da função de biblioteca incorreta. Em muitos casos, as pessoas apenas anexam 2a ao nome da função nesses casos, mas, se você tiver outras alterações que gostaria de aplicar à interface dessa função, também poderá atribuir um nome completamente diferente.

2. Corrija o bug apenas no clone (e implemente todas as outras alterações de interface que você desejar enquanto estiver trabalhando).

3. Declare a função original como obsoleta.

4. Remova a função original em alguma versão principal futura.

Essa abordagem é especialmente útil para funções cuja interface é fundamentalmente quebrada: você não quebra o código do usuário imediatamente, mas dá o devido aviso a quem depende do código quebrado para fazer a transição para o código fixo. E mesmo que as pessoas não prestem atenção ao aviso, não poderão realmente culpá-lo quando você remover a função quebrada.

Nesse caso específico, é um bug em uma API de uma biblioteca usada internamente que outros desenvolvedores usam.

Se esses outros desenvolvedores pensaram que o comportamento era um recurso, é provável que eles o tenham usado e que tenham desenvolvido software funcional . A correção do bug provavelmente quebrará o código existente e eles o culparão por isso. Isso torna a correção do bug uma troca e você deve considerar

• é realmente importante corrigir o erro, por exemplo, porque há um alto risco de permitir que os usuários da sua API travem seus aplicativos caso o bug não seja corrigido? Ou isso é apenas sobre a consistência da API?

• ou é mais importante manter o software existente estável e sua biblioteca compatível com versões anteriores?

A resposta para a pergunta nem sempre é simples: você deve levar em consideração o número possível de usuários da sua API, a quantidade potencial de trabalho que eles terão para alterar o software deles, a quantidade de software que será interrompido se você alterar a API. , mas também os riscos do que pode acontecer se você não corrigir a API.

Só porque você documenta a alteração de correção de bug em uma "lista de alterações mais recentes em sua próxima versão principal" não deixa seus clientes satisfeitos - se você fizer isso, deve haver pelo menos algum raciocínio à prova de balas por que você não pode deixar a API como ela foi antes. Muitas vezes, manter a compatibilidade com versões anteriores é mais importante do que corrigir um bug. Portanto, corrija-o apenas se você puder estimar o impacto na base de usuários e no software deles e tiver certeza de que não fará esforços irracionais para eles quando tentarem atualizar para a versão mais recente da biblioteca. E se você não tiver informações suficientes para fazer uma boa estimativa sobre isso, provavelmente será melhor não mudar o comportamento.

(E sim, se você deseja fazer uma alteração na API que não seja compatível com versões anteriores, os números de versão devem expressar isso claramente, não importa se você o nomeou como "correção de bug" ou não).

Abrace-o. Pode tornar todo o seu produto.

GunZ: The Duel (um jogo online) tinha um bug que você poderia explorar e abusar constantemente para mudar praticamente toda a jogabilidade (chamada K-Style; procure no YouTube). Tornou todo o jogo muito mais desafiador; foi preciso habilidade e tornou a coisa incrível e divertida ... tão divertida que até os moderadores a usaram abertamente como seu estilo de jogo principal.
É o que fez o jogo.
Eu não jogava há anos, mas até hoje, como jogador, é um dos meus jogos favoritos de todos os tempos, porque é tão baseado em habilidades e tão divertido, e toda essa grandiosidade apenas por causa de um bug.

Eles corrigiram isso eventualmente, mas as pessoas odiavam tanto que os desenvolvedores o devolveram seriamente.

Portanto, minha resposta é estabilizar e mantê-lo (refatorar, se necessário).

Essa bela história sendo dita, não acho que a mesma resposta se aplique a qualquer coisa que não tenha uma vantagem direta. Se o seu bug causar um evento que causa a vantagem, geralmente será mais inteligente corrigi-lo e encontrar outra maneira de conseguir o que puder. Se estiver fora do escopo, considere deixá-lo de fora por estar fora do escopo ou crie outro módulo (talvez um pequeno) para apresentá-lo. Basicamente: não viole o princípio de responsabilidade única .