Desenvolva rápido e com bugs, então corrija os erros ou seja lento, cuidado com cada linha de código? [duplicado]

53

Possible Duplicates:
Frankly, do you prefer Cowboy coding?
Prototyping vs. Clean Code at the early stages
Good design: How much hackyness is acceptable?
Does craftsmanship pay off?

Qual é o melhor:

  1. Codificando rapidamente, não se importando com possíveis erros e limites, talvez esquecendo de verificar a entrada, NULL retorna etc, apenas para completar a tarefa ou para chegar ao marco e corrigir todos os erros possíveis.
  2. Codificação lenta, verificando todas as linhas que você escreve muitas vezes, escrevendo testes e verificando todas as entradas possíveis para tornar um código livre de erros, mas pode levar semanas para escrever um programa de trabalho.

Na verdade, estou usando a segunda via, mas é frustrante trabalhar, trabalhar, trabalhar e ver apenas pequenas melhorias todos os dias ...

    
por Francesco Boffa 10.08.2011 / 16:43
fonte

12 respostas

62

Isso depende TOTALMENTE do tipo de trabalho que você está fazendo. Para muitas situações, o Test-Driven-Development, como você está fazendo atualmente, é definitivamente o caminho a percorrer. No geral, você gastará menos tempo no projeto, já que você não terá que constantemente voltar e consertar bugs e casos extremos que não foram contabilizados pela primeira vez. Com a primeira opção, sim, você terminará em tempo recorde, mas depois gastará uma boa parte do tempo voltando e consertando todos os erros.

Dito isto , se você está em uma situação onde você precisa ter um produto fora da porta o mais rápido possível (talvez você esteja tentando vencer a competição pela vantagem do "primeiro ao mercado"), jogue TDD pela janela e consiga algo funcionando e lá fora. Um lote de ótimos produtos aconteceu dessa maneira. Seu produto não o levará a qualquer lugar se você estiver polindo e consertando bugs se um concorrente com um produto "bom o suficiente" estiver comendo o seu almoço.

Considere o Facebook. Mark Zuckerberg criou o Facebook em seu dormitório com PHP e MySQL, numa época em que provavelmente outras vinte pessoas ou organizações estavam planejando ou já lançando sites de redes sociais. Parte da razão para o sucesso do Facebook foi que ele saiu da porta com pressa e venceu boa parte da competição apenas porque foi o primeiro no mercado de faculdades.

Se você tiver tempo: teste de unidade .

Se você está em uma corrida: código , e faça-o funcionar - se preocupe com os erros depois.

EDIT: Obviamente, você não pode liberar um produto que é tão buggy inutilizável. Ao usar o método "fora da porta", você precisa perceber quando a caça e correção de bugs adicionais só adicionam valor marginal ao seu produto quando comparado com o lançamento agora.

    
por 10.08.2011 / 16:52
fonte
33

A segunda maneira é melhor, na minha opinião. Parece mais lento, mas a quantidade de retrabalho, de correção e de novo teste será muito menor e, por fim, levará a um produto melhor. Você diz que são necessárias "semanas" para escrever um programa - mas você já sabe que, se usar o primeiro método, pode escrever o programa em "dias" e depois passar "semanas" no estágio "corrigir todos os erros possíveis".

A única vez em que defendo o método nº 1 é quando o código de prova de conceito descartável é usado para demonstrar uma única janela ou uma função que funcionará em parâmetros muito restritos.

    
por 10.08.2011 / 16:50
fonte
24

A única maneira de ir rápido é ir bem.

Eu vi "Uncle" Bob Martin falar sobre isso em uma conferência uma vez. Felizmente, uma citação está on-line.

There's no such thing as quick and dirty in software. Dirty means slow. Dirty means death.

Bad code slows everyone down. You've felt it. I've felt it. We've all been slowed down by bad code. We've all been slowed down by the bad code we wrote a month ago, two weeks ago, even yesterday. There is one sure thing in software. If you write bad code, you are going to go slow. If the code is bad enough, you may just grind to a halt.

The only way to go fast is to go well.

    
por 10.08.2011 / 21:04
fonte
12

Eu faço teste de desenvolvimento orientado, onde eu defino todos os meus casos antes da mão. Isso me permite codificar rápido e solto, e depois ver o que perdi. Eu então volto e refaço o que eu errei. Minha opinião sempre foi, descobrir o que é suposto fazer, "desenhá-la" no papel e descobrir onde minhas suposições estão erradas. Houve muitas vezes que tentei fazer algo perfeito na primeira vez, apenas para perceber que tenho que voltar e refazê-lo por causa de uma suposição incorreta da minha parte.

    
por 10.08.2011 / 16:52
fonte
9

Acho que sua pergunta cria algo como uma falsa dicotomia. Na realidade, a decisão não é binária ("codigo lenta e cuidadosamente, ou rápida e imprudentemente?"), Mas sim em um espectro. As duas opções que você apresentou são extremas.

Exatamente onde você quer estar no espectro depende muito do produto específico em que você está trabalhando e do que seus clientes esperam de você. Você precisa examinar as restrições com as quais está trabalhando e, em seguida, tomar uma decisão inteligente sobre o tipo de processo que deseja usar.

Por exemplo, se você está em uma posição onde é muito caro corrigir erros, ou onde as falhas são potencialmente catastróficas, você quer estar mais perto da opção nº 2. Software incorporado, orientação de mísseis código e ferramentas médicas são bons exemplos. Ao consertar um bug significaria recuperar milhões de dólares em hardware, ou quando seu erro pode resultar em pessoas morrendo, você precisa ter certeza de que acertou na primeira vez.

O outro extremo do espectro é quando o ambiente de negócios exige mudanças rápidas de código, mas é fácil corrigir erros e as penalidades por falha são baixas. Os aplicativos da Web geralmente se encaixam nessa descrição. Seus usuários estão clamando por novos recursos e mudanças na lógica de negócios, e querem que eles sejam implementados ontem. Se um pequeno erro no código for feito, levará quinze minutos para editar o script incorreto, revisar o código de alteração e corrigi-lo. Nesse caso, desde que você gerencie as expectativas do usuário adequadamente, elas aprenderão a ignorar o bug ocasional desde que você responda às necessidades dele e mantenha um tempo de resposta rápido. É claro que, mesmo ao adotar essa abordagem, você ainda deve ter proteções para evitar falhas catastróficas: manter backups, fazer revisões de código e verificar se você tem um bom processo de correção / reversão.

Eu acho que a realidade do desenvolvimento de software é que a maioria dos projetos está em algum lugar entre esses dois extremos. Você geralmente quer ser diligente na prevenção de bugs, mas talvez não queira um ciclo de lançamento de um ano devido a um processo de QA pesado.

Além dos fatores ambientais que mencionei anteriormente, acho que a melhor maneira de descobrir exatamente onde você deveria estar é avaliar o feedback dos usuários. Se eles estiverem frustrados com os longos períodos de espera por novos recursos, convém ajustar um pouco o processo de controle de qualidade para ter mais capacidade de resposta. Apenas certifique-se de que você é extra rápido sobre como corrigir quaisquer erros que você possa apresentar. Por outro lado, se eles estão exigindo confiabilidade absoluta, certifique-se de ter salvaguardas suficientes para atender a essa demanda da melhor forma possível.

    
por 10.08.2011 / 21:08
fonte
5

Ir para 2.

Think -> think further -> do a peer discussion, for complex devs -> code -> test -> eventual fix.

Muito melhor que

Code -> code more -> realize it won't work -> fix -> discover a new bug the first code raised -> go back to scratch

    
por 10.08.2011 / 16:52
fonte
4

Você está seguindo uma abordagem de Desenvolvimento Orientado a Testes (TDD)? Você encontrará após 1-2 meses de desenvolvimento com esta abordagem que você é tão rápido quanto se estivesse seguindo 1. e que você mantenha a barra de qualidade mais alta de 2. Você também será capaz de fazer mudanças (re -fator) sem medo, pense nisso como poupar tempo no futuro!

Eu também vou acrescentar que você pode ir para a opção 1. se você estiver com pressa para entrar no mercado, ou se você está fazendo protótipos. Basta lembrar que o resultado final desse trabalho deve ser idealmente rm -rf *

    
por 10.08.2011 / 16:54
fonte
4

Depende. Em muitas coisas, mas uma coisa que os outros perderam é que isso depende do tamanho do projeto. Para grandes projetos complexos, a depuração pode ser monstruosa e ter ramificações profundas. Planejamento e estrutura adequados podem economizar uma quantidade significativa de tempo. Pequenos projetos simples, por outro lado, são mais fáceis de depurar. Há apenas tantas partes móveis.

Quanto maior o projeto, mais cuidadoso você tem que ser para não se preparar para uma grande dor de cabeça.

    
por 10.08.2011 / 17:15
fonte
3

Pessoalmente, eu faço # 2. Eu não digo que algo seja feito a menos que eu saiba que passará no teste. Sim, isso faz com que eu demore mais e eu costumo repassar meus horários nos tickets.

Quando fecho um ticket, é muito raro que o QA envie de volta para mim. Por isso, não só poupa tempo, como também poupa tempo às equipas de controlo de qualidade, uma vez que não têm de voltar a testar se existirem erros.

Meu gerente aceitou que, a cada hora, eu passo agora, ou seja, duas ou mais horas que não desperdiçamos nos testes.

É lento? Às vezes. Mas, acho que é mais rápido a longo prazo. Colocar o esforço extra agora pode me salvar de trabalhar um fim de semana ou dois antes do final do projeto, corrigindo todos os defeitos. Isso para mim vale a pena. :)

    
por 10.08.2011 / 16:59
fonte
3

Se eu tiver que escolher entre apenas 2, então definitivamente o número 1. Mas eu não escolho entre os 2. Da sua descrição, parece que a maioria do trabalho que você faz é conceitual, pensando sobre o código e como ele deve funcionar. Para mim, uma parte importante do processo de desenvolvimento é ver o que o código realmente faz quando compilado. Claro, eu posso pode trabalhar isso na minha cabeça, mas isso nem sempre significa que o compilador vai fazer do jeito que eu acho que vai. O que eu faço é, basicamente, um código, compilação e loop de teste, no qual detecto erros precocemente sem ter que gastar uma hora olhando para uma linha de código. Desta forma, você pode produzir resultados muito mais rápidos e ainda manter a alta qualidade. Eu não estou em um ambiente TDD agora, mas estou trabalhando na implementação de um.

    
por 10.08.2011 / 16:49
fonte
2

Seja rápido e sujo primeiro para provar seu conceito. Certifique-se de que você realmente provou o conceito que está tentando provar, então jogue-o fora (quero dizer, exclua).

Agora faça novamente, mas desta vez seguindo o processo correto e a programação defensiva. Vai demorar muito menos do que você pensa, porque você já sabe o que está fazendo, e seu código será muito melhor do que qualquer coisa que você poderia ter feito fazendo apenas rápido e sujo.

    
por 10.08.2011 / 16:52
fonte
2

Jarrod respondeu isso ao longo da dimensão da situação do negócio.

Embora isso seja válido, também acho que a resposta varia com base no tipo de programa - ou mesmo em partes diferentes ou "níveis" do mesmo programa grande.

Profundamente em um "motor" usado amplamente pelo programa, ele vai pagar para ir devagar, firme, cuidadoso. Faça uso de testes. Faça um favor a si mesmo e defina as interfaces de forma suficientemente estreita para que você não precise de um teste bazillion para cobrir um excesso de permutações.

Mas, mais perto das "arestas" do programa, como a interface do usuário ou interfaces para desenvolver APIs externas, provavelmente é mais inteligente ir mais rápido. Afinal, é mais provável que os requisitos mudem. Além disso, é mais provável que você encontre problemas por meio de observações diretas feitas por você e pelos testadores beta, do que por escrever um conjunto elaborado de testes que têm menos esperança de obter uma cobertura completa.

Basicamente, este é o senso comum, baseado na sua avaliação de quão estável ou bem definida é uma determinada parte do programa.

    
por 11.08.2011 / 01:41
fonte