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

14

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?

ysolik
fonte
Deixe-me desafiá-lo de uma maneira importante: algumas das maiores e melhores inovações que me foram apresentadas foram o produto de uma necessidade imediata e premente. Às vezes, o calor da batalha traz um foco nítido que dias e dias de pontificação e habilidade não inspiram.
user1172763

Respostas:

31

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.

Wonko, o são
fonte
eu daria mais 10 para o cargo, muito bem dito
maz3tt
16

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.

Josh K
fonte
1
A única coisa que eu mudaria é a palavra "você" no seu ponto principal. Eu diria que, para cada membro da sua equipe, existe um fator multiplicativo de coisas que podem dar errado, e para cada dependência externa, há algum fator exponencial de coisas que podem dar errado. Ou vice-versa. ;)
Wonko the Sane 19/10/10
2
@ syolik: Veja a reformulação. Pode não ser sua culpa que o planejamento ou estimativa tenha sido FUBAR.
Josh K
2
@ syolik: Você escreve menos do que o código ideal para cumprir um prazo e reza para ter a chance de corrigi-lo mais tarde. Com o planejamento adequado, isso nunca acontece.
Josh K
2
Never say never ... :)
Wonko the Sane 19/10/10
3
@Wonko: Correto, com o planejamento adequado isso raramente acontece.
Josh K
7

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.

Jason Evans
fonte
5

Sim. Mas sempre volta a me assombrar mais tarde.

Dima
fonte
2

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.

ivorykoder
fonte
Fazê-lo funcionar, fazê-lo direito, torná-lo rápido :) c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast
Juha Untinen
1

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.

AShelly
fonte
0

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.

ElGringoGrande
fonte
Oooh - bom comentário, exceto que a última frase me assusta um pouco.
Wonko the Sane 19/10/10
Bem. Isso não significa que eles nunca serão escritos. É assustador, mas acho que isso me ajuda a manter o foco. E há teste de unidade, apenas não 100% de cobertura. Mais como 66%.
ElGringoGrande
O único problema é que os 34% que não são cobertos são o novo código que você coloca com pressa, e não o código já estabelecido que não tem tanta probabilidade de (todas) interromper suas alterações. Para não dizer que nem todos fizemos, apenas que é uma proposta assustadora.
Wonko the Sane 19/10/10
0

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

FinnNk
fonte