Você escreve código incorreto quando está sob pressão? [fechadas]

Quando você está sob pressão, o prazo está se aproximando e um gerente está respirando no seu pescoço, você começa a escrever um código incorreto? O TDD e as melhores práticas fogem do caminho para fazer as coisas? O que você faz em situações como essa? Quais foram suas experiências?

Em uma palavra, sim. Qualquer pessoa que diga o contrário provavelmente está enganada.

No entanto, a chave é aproveitar sua experiência para escrever um código menos ruim. Resista à tentação de colocar algo para fazê-lo "apenas funcionar", se possível, porque não funcionará. Você ainda precisa seguir algum tipo de processo (seja seu, da sua empresa ou de algum mix).

A experiência me diz que é muito melhor adiar o cronograma por alguns dias para evitar correções no valor de uma semana, especialmente quando "sob pressão" significa uma liberação acelerada da produção. Se você está com pressa para liberar o código, os testadores provavelmente também estão com pressa para substituí-lo.

Se a equipe está em crise, algo foi feito errado.

A falta de prazos é um sinal de mau planejamento e estimativa. Reconheça que o prazo será perdido e resolva o problema. Às vezes você não tem controle sobre o planejamento ou estimativa. Identifique quem faz e verifique se eles sabem que isso foi feito por engano.

Em uma situação em que o prazo não pode ser alterado, você interrompe as bebidas altamente cafeinadas e apressa-se. Identifique qualquer coisa que você possa sacrificar e corte-a. Pegue o que resta e implemente o mais rápido possível. Isso causará problemas como instabilidade, erros estranhos, práticas ineficientes de codificação, correções de band-aid e todos os tipos de outros horrores. Não é necessariamente um código ruim , mas não é o ideal .

Uma solução 50% boa que as pessoas realmente resolvem mais problemas e sobrevive mais do que uma solução de 99% que ninguém tem porque é no seu laboratório que você está polindo incessantemente. O envio é um recurso .

^{De Joel no software O programador de fita adesiva .}

O código não ideal pode ser tratado se for tratado . O código que não foi tratado será acumulado e, por sua vez, dificultará outras alterações, se não impossíveis. Pode chegar ao ponto em que o aplicativo é tão interdependentemente gravado que as adições só podem ser feitas pelos programadores mais cuidadosos a um custo de tempo exorbitante. Embora o envio seja um recurso, ele pode ser mantido.

Sou um grande fã do artesanato de software - escrevendo código limpo da melhor maneira possível, etc., mas às vezes tive que me apressar durante momentos em que o tempo é curto e o prazo se aproxima. Eu realmente tento não fazer isso da melhor maneira possível, mas às vezes você não consegue fugir disso.

Algumas pessoas dirão "Bem, isso é vida, você precisa enviar", mas eu realmente discordo dessa atitude.

Ao escrever um código apressado, você pode acabar saindo do software a tempo, mas o que acontece quando, durante os próximos dias, você recebe chamadas de suporte relacionadas a bugs no software (esses bugs que vivem na mesma peça) do código que você correu para terminar). Ou você recebe um cliente irritado, perguntando por que o módulo de relatórios dele não está mais funcionando, mesmo que você tenha prometido que tudo ficaria bem no dia do lançamento?

Está tudo muito bem dizendo "Você precisa enviar" , mas há uma diferença entre parecer eficiente e parecer um trabalhador desleixado.

Sim. Mas sempre volta a me assombrar mais tarde.

Quando estou em uma situação de estresse, meu código é feito para concluir o trabalho. É isso aí. Não me concentro na eficiência e em outras questões ruins, em minha opinião.

Vou trabalhar nisso embora.

Não acredito que escrevo pessoalmente um código significativamente pior, mas entrego um produto pior.

Quando nos deparamos com um prazo arbitrário e impossível, economizamos no processo de desenvolvimento. Fazemos análises de código mais superficiais (ou as ignoramos completamente). Testamos menos, ignoramos testes de unidade detalhados para testes de integração do tipo de verificação pontual e tentamos contar o teste de integração como uma qualificação formal. Tendemos a ignorar as anomalias durante o teste, se elas não estiverem diretamente vinculadas aos critérios de aprovação e reprovação. Ignoramos as atualizações da documentação, não checamos as notas de versão, esquecemos de examinar a lista de entregas de arquivos que não são mais necessários.

O código fonte que você escreve durante uma crise pode ser de alta qualidade, mas quase certamente será enviado como parte de um produto de má qualidade.

Depende.

É a pressão porque não há como tudo ser feito e porque os principais recursos novos estão sendo adicionados horas antes do lançamento?

Código ruim chegando!

Mas se é porque o cronograma é realmente muito apertado, mas o plano geral é sólido e eu apenas tenho que trabalhar muito mais do que o habitual e manter o foco contínuo enquanto aprimorando alguns recursos, ouço ... Então produzo um código muito melhor do que se a programação permitir toneladas de tempo. Mesmo que isso signifique que eu não recebo todos os testes de unidade escritos, mas abro as principais partes do código.

Conheço alguém que nunca escreve código ruim sob pressão. Ele também tem alguns feijões mágicos nos quais você pode estar interessado.

Às vezes, todo mundo escreve código ruim e prazos iminentes são a razão usual, o truque é evitar entrar nessa situação em primeiro lugar (e isso também não é fácil).