Como faço para lidar com a paralisia da análise?


61

Com muita frequência, fico preso ao escolher a melhor decisão de design. Mesmo para pequenos detalhes, como definições de funções, fluxo de controle e nomes de variáveis, passo períodos extraordinariamente longos examinando os benefícios e as compensações de minhas escolhas.

Sinto que estou perdendo muita eficiência gastando minhas horas em detalhes insignificantes como esses. Mesmo assim, eu sei que posso mudar essas coisas se meu projeto atual não der certo, tenho problemas para decidir firmemente uma opção.

O que devo fazer para combater esse problema?



Discuta com um colega em um quadro branco. Este frequentemente ajuda a esclarecer o assunto e se você pode concordar, então ele tem uma boa chance de ser uma boa escolha

Respostas:


35

Duas regras simples:

  1. Faça a coisa mais simples que possa funcionar.
  2. Refatorar continuamente.

Ao começar a fazer cada uma dessas coisas, você ganhará confiança de que pode tomar decisões simples agora sem comprometer sua capacidade de responder às mudanças posteriormente.

Lembre-se de que provas futuras significam facilitar a alteração do código, não tentando prever todas as formas possíveis de alterar o código.


4
A refatoração contínua é razoável apenas se você tiver uma boa cobertura de teste. Então, eu diria "Escreva um teste de unidade. Em seguida, faça a coisa mais simples para passar no teste. Refatorar. Repita".
kevin Cline

Definitivamente concordo. "Vermelho, verde, refatorador" é o caminho a percorrer.
Rein Henrichs

5
Adorável petisco do manual do XP, mas realmente não é um ótimo conselho quando retirado do contexto.
Aaronaught

2
Fora de contexto, é literalmente equivalente à codificação de cowboy. Veja o projeto de Fowler Is Dead? que adverte contra os princípios de seleção de cereja do XP e metodologias similares. Talvez você seja um excelente designer e codificador e seja intrinsecamente e implicitamente capaz e motivado para manter a integridade conceitual ao refatorar, mas a maioria dos programadores não é, e dar a eles esse conselho fora de contexto é irresponsável (embora todos gostem de ouvi-lo, pois significa menos trabalho para eles).
Aaronaught

11
"Fazer a coisa mais simples que poderia funcionar" não requer nenhum contexto extra. A refatoração sim, mas como alguém que não conhece o contexto aprende a refatorar, mas aprendendo o contexto?
Rein Henrichs

9

Normalmente, quando me sinto assim, significa que preciso tentar:

  1. Levante-se, dê uma volta e verifique se toda a biologia está funcionando bem.
  2. Vá para um quadro branco e desenhe até que eu tenha uma sensação de confiança.
  3. Encontre um "amigo de reclamação de design" com quem você possa conversar sobre o problema.

Se o problema envolver sintaxe e pequenos pedaços, então:

  1. Satisfaça a si mesmo que, mesmo que seja feio, está bem encapsulado em algum lugar e representa um tipo de crosta puramente local.
  2. Adicione marcadores TODO ou apenas comentários que expliquem por que o código o incomoda.
  3. Vá para a próxima tarefa.

+1 para o primeiro e o segundo nº 2. Desenhar caixas, linhas, rotular e obter imagens grandes geralmente me ajuda a decidir entre as opções. Se você possui um bom analisador de código que rastreia tarefas (o Hudson pode rastrear TODOs e exibi-las perfeitamente em suas compilações), você pode acompanhar facilmente as coisas que não gosta.
Randy

5

É muito fácil pensar em inação. Mesmo que você consiga, de alguma forma, encontrar a melhor solução agora que possa mudar facilmente antes de concluir o projeto, e depois?

É melhor escolher uma solução decente e executá-la, do que ficar sentado sobre qual seria a melhor solução. A melhor solução é ilusória e, pior, subjetiva. Se os requisitos mudarem um pouco, sua solução pode ser pior do que uma solução que você descartou porque não era a melhor na época.


Estou ciente disso, mas ainda tenho dificuldade em escolher qualquer opção.
Anne Nonimus

@anne: É melhor fazer algo construtivo imediatamente, do que a coisa certa tarde demais. A única coisa que com certeza será a coisa errada é não fazer nada.
Satanicpuppy

4

Também estou aprendendo a evitar a paralisia da análise, então parabéns para nós =) Isso geralmente acontece porque queremos fazer o "melhor design". Na realidade, o "melhor" está nos olhos de quem vê . Minha fórmula para evitar a paralisia da análise é aplicar o princípio de design suficientemente bom . Como eu faço isso? Eu trago variáveis ​​como restrições de tempo, agendamento e me pergunto qual é o design mais simples que pode fazer o trabalho (isso não significa o mais fácil) sem comprometer a qualidade, mas, ao mesmo tempo, asseguro que seja testável e um aberto para extensão fechado para modificação (OCP)design também. O que quero dizer com testável e OCP? Bem, em vez de procurar o que eu considerava melhor, considerei um design que pode me dizer quando as coisas estão indo mal e tentar fazer apenas o código suficiente que me permita refatorar e melhorar mais tarde. Além disso, tente separar o código que será alterado pelo código que permanece o mesmo. A refatoração se torna mais fácil, porque o código que não deve ser alterado é mais seguro do seu futuro, você ou outra pessoa.


2

Que tal deixar seu instinto decidir por uma das opções? Isso deve ir muito rápido e combinar bem com o timeboxing , que a munição também propôs . Você pode tentar um limite de 1 minuto se as opções já estiverem estabelecidas ou 2 minutos se precisar defini-las primeiro. Ou o que parecer apropriado (definido de antemão). Ao aprender a ouvir seu instinto, sua escolha intuitiva se tornará mais rápida e melhor com a prática .

Caso você seja atormentado por preocupações com a possibilidade de escolher não-perfeitamente, aqui estão algumas idéias para abordar isso:

  • Se houvesse uma opção com uma vantagem clara sobre as outras, você não se perguntaria qual escolher. Portanto, por esse raciocínio, sempre que você não tem certeza sobre alguma escolha em um assunto não muito complicado, isso indica que as opções são todas iguais; portanto, não há muito a perder apenas optando por qualquer um deles.
  • Dito isto, a intuição não é aleatória, mas um palpite bastante bom e educado para a solução ideal. Muitas vezes, melhor do que aquilo que se poderia imaginar através de intermináveis ​​reviravoltas.
  • Atendendo ao perfeccionismo, pode-se avaliar a rapidez da decisão maior que a idealidade da escolha ao avaliar semiconscientemente o desempenho. O que faz todo o sentido com escolhas sem importância, mas não é trivial ter em mente.

Boa sorte! :)


2

Eu acho que vai embora com um pouco de experiência. A maior parte da minha paralisia acontece porque tento imaginar como será a base de código muito mais à frente do que o necessário para superá-la. Faço a coisa mais simples possível que funcionará e depois seguirá em frente. Uma vez que o projeto tenha uma forma definida, as unidades de código repetitivo começam a se destacar e é fácil o suficiente abstrair os padrões repetitivos e simplificar o código.


1

Para superar sua relutância em decidir, aplique o timeboxing : defina um despertador para tocar em alguns minutos; atormenta sua mente até então, mas quando o alarme disparar, escolha a melhor opção que você encontrou até então.


3
E então ele pode passar horas se atormentando sobre exatamente por quanto tempo o despertador deve ser ajustado! :)
Jordânia

11
Jordan: Existem várias soluções possíveis para esse problema também. Infelizmente, não consigo decidir qual deles propor.
user281377

0

Crie um protótipo. Lembre-se, um protótipo é feito para ser jogado fora, por isso não importa quais funções, nome da variável ou mesmo a grande arquitetura que você usa. Você acabou de construí-lo para provar que funciona.

Depois de criá-lo e jogá-lo fora, eu estaria disposto a apostar que você teria mais facilidade para tomar essas decisões.


Você nunca deve jogar fora um protótipo, porque talvez possa expandi-lo mais tarde quando adicionar um recurso. Ou talvez você precise testar um bug com um SSCCE. Eu sempre controle todos os meus protótipos em um local separado.
Maple_shaft

2
Eu acho que a idéia por trás de "jogar fora" não é que você perca dados, mas que você não deve usar protótipos como base para um programa, já que todo o objetivo dos protótipos é experimentar a liberdade de cometer erros.
Darien

protótipo em uma ramificação, faça os testes necessários e crie uma versão limpa no núcleo.
zzzzBov

0

Eu também sofro desse problema. O que eu diria é que você não tem incentivo de conclusão suficiente.

Por exemplo, quando eu escrevia o código de renderização, recebia um grande incentivo de conclusão porque sabia que, se eu continuasse com ele, veria o sistema em ação e pensaria em como eu era incrível ao texturar um quad, ou transformar uma vert. Mas agora que estou re-fatorando (tentativa 4, se você gostaria de saber), estou sofrendo porque dá muito trabalho e, mesmo que eu termine, vou ver o mesmo quad antigo. E eu realmente não quero ter que refatorar novamente e estou cansado de ver o mesmo velho quadriciclo repetidas vezes, e isso não é mais uma recompensa para mim.

Você precisa dividi-lo em componentes e se recompensar por terminá-los, mesmo que seja apenas com alguma E / S de console que mostre que está funcionando.


0

Eu estava lendo sua pergunta e pensando as coisas ao longo da linha dos outros pôsteres: você não é adequado para esse trabalho; dê a si mesmo um limite de tempo; faça outra coisa por um momento. Após algumas reflexões, não tenho certeza se alguma das respostas é realmente útil.

O problema com problemas mentais como esse é que eles não são fáceis de resolver, fazem parte de você e, obviamente, você se preocupa (talvez demais) com o seu trabalho, não tem confiança para concordar consigo mesmo, também inexperiente em considerar que sua primeira escolha estava certa o tempo todo, ou se estressa demais em acertar perfeitamente. Por que mais você se preocuparia com essas trivialidades ?!

Agora eu tenho problemas semelhantes, mas não tanto com código .. geralmente é o que ter para jantar .. pizza ou curry .. hmm ... pizza mas depois curry é bom, mas eu me sinto como um curry, pizza é mais barata , mas você ganha mais curry, mas ... e assim por diante. :)

Então pensei: por que não tenho problemas semelhantes com a codificação e acho que é simplesmente porque tenho um conjunto de padrões que uso regularmente. Se eu precisar de uma definição de função, é fácil .. estará na mesma linha que todas as outras definições de função que eu já codifiquei. Se eu precisar de um fluxo de controle, primeiro decido se preciso de um loop for ou while, e depois crio o mesmo código antigo que usei na última vez em que precisei de uma dessas coisas. O mesmo vale para tudo, eu quero uma fila? Claro - vamos recortar e colar meu código de fila 'padrão' (arquivado no último projeto em que trabalhei ou em qualquer um em que me lembro de usar uma dessas coisas). Resultado final ... Só me preocupo com coisas novas e, para ser sincero, é um prazer.

Portanto, meu conselho é começar a criar uma biblioteca de trechos de código - eu costumava enviá-los por e-mail para mim e colocá-los em uma pasta, mas o que quer que você trabalhe é o melhor - e então você começará a saber o que fazer todas as vezes. Você sempre acessará o código antigo que escreveu e resolverá o problema, pronto para o próximo problema. Você descobrirá que se tornou um desenvolvedor muito mais rápido (sério, esta é a única maneira de obter produtividade do programador) e, com sorte, encontrará tempo para os momentos divertidos, não para as coisas cotidianas sombrias que você já resolveu muitas vezes sobre.

Obviamente, a última parte de tudo o que é importante também - quanto mais trabalho você tiver, menos luxo terá para gastar tempo pensando.


programação trecho é o pior tipo de má prática
Neil Butterworth

@ Neil: Usar trechos de outras pessoas como programação de trechos, e não saber o que eles fazem, é uma prática ruim. Usar seus próprios trechos de código geralmente é bom, pois é bem provável que você entenda o que escreveu. Caso contrário, provavelmente não há esperança para você.
Jordan

@ Neil, você está de mau humor hoje! A maioria dos codificadores seniores tem uma vasta biblioteca de trechos em suas cabeças, de qualquer maneira, você simplesmente não se nota usando-os. Para um júnior, anotá-los ajuda a construir isso.
Gbjbaanb

0

Aqui está uma estratégia que combina as sugestões de Rein Henrichs ( inicie simples, refatorar ) e ammoQ ( timeboxing ):

  1. Dê a si mesmo um prazo bastante rigoroso para uma primeira solução que simplesmente funcione. Por exemplo, 30 segundos para um nome de variável. Você pode primeiro criar algo como x, depois refinar string, nameaté que o tempo acabe.
  2. Em seguida, prossiga para outras tarefas por um tempo especificado, por exemplo, 10 minutos.
  3. Somente então permita-se outra caixa de tempo para melhorar ainda mais sua decisão, por exemplo,userHandle

Possíveis benefícios dessa abordagem:

  • o conhecimento de voltar a isso mais tarde pode facilitar a abertura do problema por enquanto
  • Enquanto continua outras tarefas, você pode simplesmente encontrar uma solução satisfatória sem vasculhar demoradamente
  • depois de deixar a etapa 1 e seguir o fluxo da etapa 2 , pode ser fácil manter a etapa 3 realmente rápida, pois você deseja continuar com a etapa 2 e, assim, felizmente, basta escolher uma solução decente e aceitá-la

Essa resposta parece mais específica e completa que a anterior , mas ambas parecem cobrir o mesmo terreno. Mesclá-los em um ou escolher o que você deseja manter.
Adam Lear

@ Anna Eu fiz dois posts separados, porque descobri que eles contêm idéias de conceito diferentes que devem ser votadas independentemente: Esta: deixar de lado adiando a decisão final. O anterior: intuição. De fato, ambas as técnicas vão bem juntas, mas uma também funciona sem a outra.
Aaron Thoma

0

Quando eu fiz a pesquisa e não tenho a melhor opção, eu me dou um limite de tempo (geralmente 5 minutos) para escolher uma, e apenas passo adiante. Mesmo quando você se depara com obstáculos, neste momento, não há garantia, você não teria atingido um obstáculo igual ao tomar uma decisão diferente. Não consigo pensar em um momento em que me arrependi da minha decisão.


0

Geralmente, o motivo pelo qual você não pode decidir é que a diferença é insignificante ou você não possui informações suficientes.

No caso a) Defina um prazo para apresentar opções razoáveis ​​a serem consideradas. Não decida qual ainda. No final do tempo, escolha uma (aleatoriamente, se não houver uma preferência clara) das opções identificadas e outro limite de tempo. Se nenhuma decisão clara for tomada no final do tempo, a já escolhida será. Comece a codificar e refatorar se você claramente entendeu errado. Se o chefe perguntar por que, diga "Eu joguei uma moeda, você tem um jeito melhor?"

No caso b) - você precisa de mais informações, e ficar sentado na sua grande gordura A ... o dia todo não vai fornecer isso. Saia do modo de design e entre no modo de coleta de informações. Protótipos, faça perguntas, leia revistas técnicas. O que quer que você faça, não durma por muito tempo.


0

Freqüentemente, a melhor solução é tentar explicar sua decisão a um colega. No entanto, como você não deseja fazer isso com muita frequência, a próxima melhor coisa é pensar no papel - com um papel / caneta ou uma janela vazia do bloco de notas.

Comece escrevendo absolutamente qualquer coisa - apenas para entrar no ritmo da escrita. Em uma janela do bloco de notas, você pode apenas digitar "Estou pensando no papel" e depois continuar com um fluxo de consciência. Após alguns segundos, você estará no ritmo da escrita, então pressione enter algumas vezes e comece a explicar seu dilema.

Indique o problema, depois as possíveis soluções, o que há de bom em cada uma delas, etc.

Embora nem sempre funcione, o processo de obter pensamentos fora da sua cabeça (RAM) e na mídia externa (o documento do bloco de notas) oferece mais liberdade para fazer novas conexões e ver a decisão sob diferentes perspectivas.


0

Eu sofro do mesmo problema. Para pequenos problemas, a maneira como tento lidar com isso é seguir o primeiro design que penso que não é estúpido. Não faz sentido tentar encontrar um design ideal; é difícil, se não impossível, raciocinar sobre todas as nuances de qualquer design que você possa imaginar sem escrevê-lo. Ao codificar, você descobrirá que pode fazer pequenas melhorias. Feito corretamente, acho que é bastante fácil convergir para uma solução razoavelmente boa dessa maneira.

Para problemas maiores, acho que há mérito em pensar em suas opções primeiro, mas cronometrar. Grandes problemas têm grandes espaços de solução, você não pode avaliar todas as possibilidades, nem deve tentar.

TLDR; Escolha uma solução razoável, melhore-a à medida que avança.

Isso também é relevante:

O professor de cerâmica anunciou no dia da abertura que estava dividindo a turma em dois grupos. Todos os que estavam no lado esquerdo do estúdio, disse ele, seriam classificados apenas na quantidade de trabalho que produziram, todos aqueles no lado direito apenas em sua qualidade. Seu procedimento era simples: no último dia de aula, ele trazia suas balanças de banheiro e pesava o trabalho do grupo "quantidade": cinquenta libras de panelas com classificação "A", quarenta libras com "B" e assim por diante. Aqueles classificados em "qualidade", no entanto, precisavam produzir apenas um pote - ainda que perfeito - para obter um "A".

Bem, chegou a hora da classificação e surgiu um fato curioso: os trabalhos de mais alta qualidade foram todos produzidos pelo grupo avaliado por quantidade. Parece que, enquanto o grupo "quantidade" estava ocupado produzindo pilhas de trabalho - e aprendendo com seus erros -, o grupo "qualidade" continuava teorizando sobre a perfeição e, no final, tinha pouco mais a mostrar por seus esforços do que teorias grandiosas e uma pilha de argila morta.

em http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .


-8

Eu nunca entendi isso. Quando eu era instrutor, eu dizia algo como:

"OK, create an integer variable and assign the return value of strlen() to it."

Não é muito complicado, você pode pensar, e 95% das pessoas escreveram algo como:

int x;   // or y, or len, or whatever
x = strlen( s );

Mas ocasionalmente haveria alguém sentado como um coelho paralisado nos faróis. Eu simpaticamente perguntava qual era o problema e eles diziam "eu não sei como chamá-lo!".

Essas são as pessoas que devem procurar outra carreira. Como talvez você devesse.


2
@ Anne Eu não estou fazendo suposições - você mesmo disse que acha difícil pensar em nomes para as coisas - "Muitas vezes, fico preso ao escolher a melhor decisão de design. Mesmo para pequenos detalhes, como ... nomes de variáveis"
Neil Butterworth

3
E por que devo procurar outra carreira porque tenho dificuldade em nomear algumas coisas? Nem todo conceito tem um mapeamento limpo e curto da linguagem natural.
Anne Nonimus

2
@ Anne O ponto central da sua pergunta original parece-me que você está tendo problemas para fazer o que é natural para bons programadores. Não há vergonha nisso - a maioria das pessoas (mesmo a maioria dos programadores!) É péssima em fazer essas coisas. No entanto, assumindo que, como eu, você só pode ser feliz fazendo algo em que é realmente bom, sugeri que a programação pode não ser o que você deseja. Passei os primeiros 10 anos da minha vida adulta como microbiologista. Eu não era muito bom nisso e fiquei muito mais feliz quando mudei para programador.
Neil Butterworth

3
Um lembrete amigável para todos: se você não concorda com a resposta, sinta-se à vontade para usar votos negativos para expressar isso. Ataques pessoais de ambos os lados serão removidos.
Adam Lear

3
Por fim, sinto que a resposta sai bastante dura, mas os comentários me fazem sentir que não é tão duro assim. Talvez você deve editar esse no.
DeadMG
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.