Escrevendo minha abordagem de solução de problemas no papel? [fechadas]

Não há nada de errado em descobrir primeiro seus algoritmos no papel. Não tanto para a codificação diária, mas para algoritmos mais complexos, os programadores profissionais trabalham com eles em papel ou quadro branco o tempo todo, especialmente se um formato gráfico o torna mais claro. Para um aluno, todo programa é complexo.

Se você quiser melhorar a criação de algoritmos em um computador, existem algumas técnicas que você pode praticar. Não comece escrevendo o código, escreva as mesmas coisas que colocaria no papel como comentários e, em seguida, expanda-o em código real ou comentários mais detalhados um por um.

Por exemplo, se eu estiver excluindo um elemento do meio de uma lista vinculada, posso começar com algo como:

// find the element
// point the previous element to the next element
//    How do I get a pointer to the previous element?
//        doubly-linked list?
//        another find?
//        keep track during the first find?
// delete the element

Depois, posso substituir // find the element por uma função com mais pseudocódigo e continuar até ter uma solução completa. Não pense que o código deve ser escrito de maneira linear.

Vá em frente! Se chamarmos o que você está fazendo pensando e projetando sua solução, então faz sentido que seu processo seja muito mais rápido do que apenas explodir código.

As pessoas gostam de pensar (e os barulhentos gostam de nos dizer) que o seu jeito de fazer é melhor. Mas a habilidade de todos e o mix de habilidades são diferentes. Então faça o que funciona para você. À medida que você ganha prática, provavelmente mudará para fazer mais do trabalho de design em sua cabeça e usará papel para problemas maiores.

Uma coisa a observar é a forma que os exames serão realizados. Eles estarão no papel ou serão baseados em computador? Se eles são baseados em papel, então o seu caminho lhe dará uma vantagem. Se eles são baseados em computador, então tudo bem também: fazer qualquer projeto no papel e, em seguida, escrever o código. O que funciona melhor!

Eu não acho que haja algo de errado com a elaboração de código (pseudo ou não) no papel primeiro - não é realmente diferente de escrevê-lo em um quadro branco, o que muitas pessoas fazem quando discutem como lidar com um problema. / p>

Você escreve primeiro rascunhos de ensaios para classes não CS no papel antes de digitá-los? Na verdade, eu costumava fazer isso anos atrás quando eu ainda era um estudante universitário, mas depois do meu primeiro ano, eu me forcei a escrever todos os rascunhos em uma tela, já que facilitaria escrever rascunhos subseqüentes, e a mesma ideia se aplica. para escrever código.

Sugiro que você tente digitar seus algoritmos, mesmo que seja apenas em um editor de texto como o Word. Quanto mais você fizer isso, mais confortável você estará em não depender de papel e caneta. E se suas habilidades de digitação estão faltando um pouco e isso é de fato a fonte de sua frustração, faça um curso de digitação! Seria a melhor coisa que você poderia fazer pela sua futura carreira.

Eu não coloco código real no papel, mas para qualquer coisa não-trivial eu quase sempre começo em um quadro branco ou em um notebook. Eu costumo esboçar:

• Algoritmos / processo / fluxo de controle
• Estruturas de dados
• Relacionamentos
Componentes
• (como faço para quebrar esse problema)

Geralmente é uma combinação de esboços, pseudocódigo e inglês.

Acho que, ao fazer isso, é mais fácil visualizar quando começo a codificar. Eu também localizarei falhas antes eu começo no código porque eu posso ver tudo na minha frente (ao invés de rolagem incessante e janela-hopping). Não só isso, uma vez que está escrito, posso deixar as coisas se formarem no fundo da minha mente enquanto estou trabalhando em outras tarefas. Eu também posso trabalhar de forma não-linear, cometendo uma idéia para o papel quando ele me bate e depois voltar para ele quando eu chegar ao ponto onde eu preciso.

Enviar algo para o papel é uma ajuda tremenda para a retenção de memória. O slogan da marca de cadernos Field Notes é o seguinte:

I’m not writing it down to remember it later, I’m writing it down to remember it now.

Depois de ter uma abordagem mais focada para escrever as coisas no papel, mesmo que eu faça uma entrada no aplicativo ToDo no meu celular um momento depois, eu acho que o pensamento está cimentado na minha cabeça muito melhor do que apenas fazer Nota. IOW, planejando minha codificação em papel / quadro branco, as ideias ficam na minha cabeça melhor.

Ele também serve como uma referência útil quando é hora de documentar o que escrevi.

Resolver o problema e escrever o código que implementa sua solução são duas atividades diferentes.

Se você não estiver familiarizado com um idioma, gastará muito tempo com o código em si - e não o suficiente para encontrar uma boa solução. Se o papel, o quadro branco ou a partida no teto o ajudarem a esse respeito, então, por todos os meios, faça isso.

(Pessoalmente, eu me vejo saindo do computador e andando em círculos tentando construir uma solução em minha mente)

Você vai ace entrevistas! Eles fazem você escrever código no papel ou no quadro branco. Eu sou exatamente o oposto. Tentando escrever chaves ou cortar & Colar com uma caneta é tão tedioso!

Meu pai usou muito papel ao programar o COBOL. Eu acho que é apenas o seu estilo de pensar.

Nós costumávamos ter uma aula de dois semestres chamada The Basics of Programming. Ambos os testes e exames no final do semestre foram feitos em papel. Se você fez algum erro de compilação, perdeu uma quantidade significativa de pontos. Se você fez grandes erros de compilação, você falhou. No entanto, sinto que desenvolveu em nós a capacidade de analisar qualquer código e encontrar linhas com erros em um período de tempo relativamente curto.

Não há nada de errado com o que você está fazendo, aprendi a programar usando papel e caneta também.

Como outros sugeriram, faça o que funciona para você. Lembro que o primeiro programa em Java que escrevi foi principalmente em papel e depois passei duas horas digitando e quinze minutos chorando quando vi mais de 200 erros no compilador. Havia mais, mas o compilador mostrava apenas os primeiros 200! O ponto que estou fazendo é que, ao escrever o código no papel, consegui pensar no algoritmo básico e na funcionalidade do que o programa precisava fazer. O compilador apontou as razões pelas quais meu programa não seria executado. 90% dos problemas estavam fora das exceções com arrays.

À medida que você ganha mais experiência e confiança, você se verá usando menos papel e caneta. Você já saberá como usar conceitos básicos, como loops e assim por diante. Você terá exemplos em outros programas, que você pode reutilizar. Você usará o compilador e um IDE para encontrar bugs óbvios durante a gravação do programa. No momento, você não tem essa experiência.

Lendo sua pergunta Pergunto-me se alguns dos seus problemas podem se concentrar. Se usar uma caneta e papel em um ambiente silencioso ajuda você a se concentrar, então ótimo.

Você ainda está na faculdade e ainda está aprendendo. Em última análise, tudo o que você está fazendo é o que funciona para você. Se usando papel e caneta você está ordenando seus pensamentos e pensando com clareza e calma, então você está programando.

Meu código é muito melhor organizado quando escrevo notas e abordagens em um bloco de notas, livros de cheques, verifico a web e penso sobre isso. Eu também sou muito mais de uma pessoa visual, então desenhar figuras com estruturas de dados é muito útil. Eu não escrevo todas as linhas, mas rabisco o que considero fragmentos "importantes" ou funcionalidade chave. Para projetos maiores, inicio o Visio. Não sei ao certo por que alguém defenderia pular direto para o teclado, a menos que seja muito mais eficiente ou pago por hora.

Faça o que funciona para você. Eu não escreveria código no papel. Eu escrevo fluxogramas de pseudocódigo e desenho no papel, mas escrever o código completo parece uma perda de tempo.

Estou também enfrentando o mesmo problema no meu primeiro dia de aprender habilidades técnicas.

Mas esse tipo de prática não deve dar 100% de sucesso, porque se estamos escrevendo código no papel, então não há chance de correção de bugs, há chance de resolver os erros e exceções durante o trabalho de papel.

Portanto, o trabalho de papel não fornece nenhuma navegação para resolver os problemas. E podemos obter velocidade de digitação como bônus devido à prática do sistema.

I am also doing paper work but when before implementing my functionality just do rough estimation after this I will start My implementation on system.

Por favor, tente passar mais tempo na prática do sistema. Isso dará 100% de confiança e resultado.