Como é que um programador acha? [fechadas]

Question

Este pode ser um desesperadamente vaga pergunta. Mas estou interessado em ouvir o que quer que os processos de pensamento lógico pessoas passam por quando aprender um novo conceito ou tentar obter o seu cérebro em torno do código que pode não ter nunca visto antes.

Basicamente, o que passos geral é que uma pessoa tomar para quebrar problemas e o que é preciso para "pegar"? Se você fosse o diagrama de um fluxograma de como o seu processo mental funciona quando você olha para o código ou tentar resolver um problema que poderia parecer?

O que as referências comuns, dicas e suposições mentais que você achar útil na resolução de problemas?

Como isso é diferente entre os diferentes domínios? Por exemplo, em que forma é o processo de pensamento de um programador web semelhante ou diferente do processo tradicional de desenvolvedor de aplicações desktop?

Answer 1

Eu sou um grande crente que não importa o tipo de aplicação que você está olhando para a primeira vez, que seja um aplicativo web, um aplicativo de desktop, um driver de dispositivo, ou qualquer outra coisa, existem três passos um desenvolvedor geralmente segue a fim de compreender como funciona:

Obter a grande figura:

• Que tipo de aplicativo é este (web, desktop, ...)?
• Como é em camadas (standalone, cliente-servidor, n-tier, ...)?
• O que é o propósito do aplicativo? O que é que devo fazer?
• Quem é o aplicativo feito para?

Veja como funciona:

• O que língua (s) é (são) usado?
• Como está o código estruturado?
• Como é que os dados estruturados?

Entenda (ou pelo menos tentar) a forma como o aplicativo foi pensado:

• Tem sido pensado em tudo?
• é o aplicativo claramente otimizado? (Para performances? Para facilitar a leitura?)
• é o aplicativo terminou? Ou há espaço para evoluções?
• Existem sinais de vários lançamentos?
• etc ...

A 1ª e 2ª etapas são puramente técnico, enquanto o terceiro deve ser o não técnico quanto possível ... é mais sobre a psicologia ea compreensão de como o aplicativo foi construído. É, obviamente, requer experiência, mas contanto que você acha duro o suficiente e não desperdice o tempo do seu cérebro com detalhes técnicos, você vai finalmente obtê-lo.

Todo este processo não deve exigir o uso de um teclado. Você só deveria ler, pensar e tomar notas em um papel (não estou brincando: caneta e papel).

Answer 2

Ho ho, boa sorte com este. É uma grande pergunta e eu tenho certeza que você vai ter uma tonelada de respostas. Embora eu tenho que dizer que eu não posso dar uma resposta satisfatória a esta - a última coisa que eu descreveria meus processos de pensamento como é um fluxograma -. Eu não acho que haja qualquer fórmula de ouro para este

O único ponta na solução de problemas que posso recomendar é discuti-lo com outra pessoa. Naqueles momentos em que você bater em uma parede de tijolos, passando por isso com um colega é inestimável. Muitas vezes, bem, eles vão realmente nem mesmo acrescentar muito para a discussão -. No processo de obtenção de todos os seus pensamentos para fora no aberto, a solução pode se tornar clara

Answer 3

As pessoas são notoriamente ruim em examinar os seus próprios processos de pensamento, mas vou dar um giro. Eu testar muito elevado para a capacidade visuo-espacial em testes de QI, médio-alto para habilidades verbais, e moderado para habilidades matemáticas (explica o meu nível A grade Matemática, suponho). amd quando eu começar a projetar software, acho que em termos de formas e as conexões entre eles. Quando se trata de descrever esses pensamentos para os outros (ou esclarecendo-os para mim), eu uso simples diagramas de blocos ou os diagramas de objetos retirados do método Objectory de Jacobson - não o material mais complexo que UML sugere. Às vezes escrevo descrições textuais de coisas complexas, principalmente como lembretes para mim mesmo, mas nunca use números ou matemática.

Claro que isto é apenas me -. Eu já trabalhei com matemática gênios que estavam tão bom ou ainda melhores programadores que eu

Answer 4

Eu não acho que ... processo I.

Este é realmente menos aleta do que parece. Eu sempre quebrar tarefas em seus componentes e, em seguida, dividir esses padrões ainda mais, e isso não basta ir para escrever software! Muito parecido com @ Mark Pim U passar por coisas sequencialmente.

A minha mulher fica muito irritado quando eu fazer o jantar porque eu levar tanto tempo para começar.

Answer 5

Divide & Conquer

I começar por tentar compreender todo o problema como ele é, e, em seguida, começar a encontrar padrões que podem reconhecer, e fazer o mesmo para eles numa espécie de processo recursivo, até que eu tenha uma dividida solução que posso implementar e follow com mais facilidade.

Answer 6

Esta é uma das raras vezes que eu iria responder com "ele simplesmente funciona." I aprender coisas por steamrolling através deles. Eu não tenho truques, ou dispositivos para me ajudar. Levei algum tempo para aprender PHP, mas depois que o Javascript era muito mais fácil. Depois de enfrentar uma coisa, os próximos itens tornam-se cumulativamente-mais fácil.

Answer 7

Pessoalmente, eu conduzir um diálogo interno comigo mesmo 'OK por isso precisamos loop sobre esta lista de inteiros.' 'Mas nós podemos quebrar quando encontramos o valor que queremos.' 'OK, vai a lista definitivamente ser inicializado quando começamos?'

Eu estaria interessado para ver se alguma pesquisa psicológica tinha sido feito em técnicas de resolução de problemas.

Answer 8

Assim como Jonathan Sampson -. Que tipo de apenas obras

Quando eu estou atacando um problema real, I tentar e pensar da maneira mais lógica de obter através dele é. Então, quando tudo dá errado (como geralmente acontece), eu tenho que fazer centenas de Estribos para fazer as coisas. Basta manter focando esse objetivo final, que forma lógica e você vai chegar lá.

Eventualmente, porém, ele decide trabalhar para mim e eu acabar com um produto acabado que geralmente não é nada como eu planejei para fora para ser. Enquanto os clientes estão felizes, eu sou!

Answer 9

Pessoalmente, vejo código na minha cabeça pictorally ao invés de textualmente (como Neil Butterworth) - que é um pouco difícil de descrever uma vez que (citando STIV) "não há nenhum quadro comum de referência."

Answer 10

Meu habilidade principal é identificar semelhanças entre modelos ou sistemas que já conhecem e a tarefa em mãos. As conexões entre alguns destes podem parecer bastante abstrato; a chave é identificar as conexões. Isso leva à abstração de padrões e abordagens comuns que são amplamente aplicáveis. Relacionado a isso, a coisa mais importante que aprendi sobre algoritmos foi que o problema nunca é 'chegar a um algoritmo inteligente para resolver X'. É 'problema modelo X tal que ele pode ser resolvido pelo algoritmo inteligente existente Y'.