Você escreve código ruim 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ê se vê começando a escrever um código ruim? O TDD e as melhores práticas escorregam à beira do caminho para que as coisas sejam feitas? O que você faz em situações como essa? Quais foram suas experiências?

    
por ysolik 19.10.2010 / 17:28
fonte

8 respostas

27

Em uma palavra, sim. Qualquer um que diga o contrário provavelmente está, na melhor das hipóteses, equivocado.

No entanto, a chave é aproveitar sua experiência para escrever códigos que sejam menos ruins. Resista à tentação de colocar algo para que "funcione", se possível, porque não funcionará. Você ainda precisa seguir algum tipo de processo (seja o seu, o da sua empresa ou uma mistura deles).

A experiência me diz que é muito melhor ( suspiro ) diminuir o cronograma em alguns dias para evitar correções de uma semana, especialmente quando "sob pressão" significa uma liberação rápida para a produção. Se você está com pressa para liberar o código, os testadores provavelmente terão pressa em testá-lo também.

    
por 19.10.2010 / 17:36
fonte
16

Se a equipe está em uma crise, então 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 a estimativa de ou . Identifique quem faz e garanta que eles saibam que isso foi feito por engano.

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

A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature.

Do Joel on Software O Programador de Fita Adesiva

O código não ideal pode ser tratado com se for tratado . O código que não foi tratado se acumulará e, por sua vez, tornará as mudanças adicionais mais difíceis, se não impossíveis. Pode chegar ao ponto em que a aplicação é tão interdependentemente gravada em conjunto que as adições só podem ser feitas pelos programadores mais cuidadosos a um custo de tempo exorbitante. Enquanto o envio é um recurso, por isso é de manutenção.

    
por 19.10.2010 / 17:38
fonte
6
Sou um grande fã de artesanato de software - escrevendo código limpo da melhor maneira possível, etc., mas às vezes tive que me apressar em momentos em que o tempo é curto e um prazo está se aproximando. Eu realmente tento não fazer isso da melhor maneira possível, mas às vezes você não consegue se livrar disso.

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

Ao escrever um código apressado, você pode acabar recebendo o software na hora certa, mas o que acontece quando, durante os próximos dias, você acaba recebendo chamadas de suporte relacionadas a bugs no software (esses bugs que vivem em o mesmo trecho de código que você correu para terminar. Ou você recebe um cliente irritado ligando para perguntar por que o módulo de relatórios não está mais funcionando, mesmo que você tenha prometido que estaria tudo bem no dia do lançamento?

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

Felicidades. Jas.

    
por 19.10.2010 / 17:55
fonte
3

Sim. Mas sempre volta para me assombrar mais tarde.

    
por 19.10.2010 / 23:09
fonte
2

Quando estou sob uma situação de estresse, meu código destina-se a realizar o trabalho. É isso aí. Eu não me concentro em eficiência e outras questões, o que é ruim, em minha opinião.

Eu vou trabalhar nisso.

    
por 19.10.2010 / 18:19
fonte
1

Eu não acredito que eu, pessoalmente, escreva um código significativamente pior, mas eu entrego um produto pior.

Quando nos deparamos com um prazo arbitrário e impossível, minimizamos o processo de desenvolvimento. Fazemos revisões de código mais superficiais (ou as ignoramos completamente). Testamos menos, ignoramos testes de unidade detalhados para testes de integração do tipo spot-check e, em seguida, tentamos contar o teste de integração como uma qualificação formal. Tendemos a ignorar as anomalias durante os testes, se elas não estiverem diretamente ligadas aos critérios de aprovação / reprovação. Ignoramos as atualizações da documentação, não checamos as notas da versão, esquecemos de eliminar a lista de resultados dos arquivos que não são mais necessários.

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

    
por 19.10.2010 / 21:44
fonte
0

Depende.

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

Código incorreto chegando!

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

    
por 19.10.2010 / 18:05
fonte
0

Eu conheço alguém que nunca escreve códigos ruins sob pressão. Ele também tem alguns feijões mágicos nos quais você pode se interessar.

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

    
por 19.10.2010 / 23:19
fonte

Tags