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

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.

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.

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.

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.

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.

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

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 *

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.

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. :)

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.

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.

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.

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.