Ao desenvolver algoritmos, pular a fase de caneta e papel é um mau hábito? [fechadas]

Ouvi muitas pessoas dizendo que, ao desenvolver algoritmos, você deve primeiro usar papel e caneta, fluxogramas e o que não, para que você possa se concentrar no próprio algoritmo, sem se preocupar com a implementação do referido algoritmo (ou seja, você lida com um problema de cada vez). Tempo).

No entanto, na maioria das vezes, acho mais fácil desenvolver meu algoritmo rapidamente. Ou seja, penso um pouco sobre o problema até saber a direção geral a seguir e depois começo a escrever o código e a fazer alterações até que o algoritmo surja e funcione.

Esse é um mau hábito que eu deveria tentar mudar?

Algum desenvolvimento algorítmico pode exigir muitos testes e ajustes de tentativa e erro, pois pode-se descobrir que as suposições que entrariam em um design estritamente em papel acabam não sendo precisas o suficiente quando dados dados e restrições de desempenho reais.

Talvez iteração (pense-teste-código-pense-teste-código ...), em vez de apenas uma opção de escolha ou escolha do "hábito" ideal.

Também existe um meio termo que eu costumo usar. Não pensando muito com antecedência e não me perdendo nos detalhes do meu código ...

TDD (Test driven development) permite que você pense um pouco e faça com que funcione; depois pense um pouco mais sobre o que você precisa e faça com que ele funcione, com a rede de segurança que o seu Caso de Uso anterior continua funcionando o tempo todo ... As etapas são:

1. Escreva um teste (ou seja, um caso de uso).
2. Veja como falhar, torne a falha compreensível.
3. Escreva o código.
4. Refatorar o código e o teste.

Isso depende dos seus hábitos de pensamento e complexidade do algoritmo.

Caneta e papel oferecem pensamento "de forma livre" sem um compilador gritando com cada caractere digitado.

Alguns de nós que usamos papel e caneta, reservamos um tempo para ajustar os limites do loop, tentar valores diferentes etc.

Então, acho que escrever o código encoraja diretamente a abordagem do teste primeiro, onde a caneta e o papel promovem a abordagem do pensamento em primeiro lugar. É definitivo que, se a tarefa for trivial, você poderá codificá-la rapidamente (se você tiver experiência suficiente), mas algoritmos complexos provavelmente precisariam de uma abordagem de desenvolvimento diferente.

Os diagramas ajudam em alguns casos, mas isso requer que você esteja familiarizado com eles e os tenha usado antes.

Eu acho que a sua é a abordagem mais comum. Se o algoritmo é especialmente complicado ou difícil, pode ser difícil descobrir o algoritmo e implementar ao mesmo tempo, mas, em geral, duvido que ajude a maioria das pessoas.

Mas eu não diria, por exemplo, que invente regras para uma gramática e implemente um analisador para ela sem escrever as regras no papel (ou talvez com alguma ferramenta especial que eu não possua) primeiro, ou que implemente uma árvore B sem pseudo- código disponível.

Eu não diria que você tem um mau hábito, a menos que esteja lhe causando algum dano, e acho que você notaria se fosse.

Quem são essas "muitas pessoas"? E eles estão programando para viver? O que você está fazendo é exatamente o que a maioria dos programadores faz, pelo menos a maioria que eu conheço. Há pouco uso para papel quando é mais rápido para digitar e pouco uso para pseudo-código ao programar em uma linguagem de alto nível. Ocasionalmente, uso caneta e papel para visualizar um algoritmo complicado (por exemplo, girar uma árvore), mas geralmente começo com código de alto nível e preencho gradualmente os espaços em branco.

Como o KLE, acho que isso funciona melhor após o desenvolvimento orientado a testes. Supondo que você esteja escrevendo testes de qualquer maneira, você também pode escrevê-los primeiro.

você pode criar um design enquanto cria classes, métodos e testes de stub, mas pode ficar atolado ao criar os detalhes

para coisas realmente complexas (compiladores e afins), um design de caneta e papel (ou pelo menos em uma ferramenta de design) ajudará a manter você no caminho certo e de olho em toda a imagem, além de evitar más escolhas de design e até mesmo escolher certos padrões de design desde o início

mas, em última análise, depende de quão bem você pode continuar vendo o quadro geral

Eu recomendo esboçar as instruções gerais (a fase "caneta e papel") antes de ir para a implementação para economizar tempo, eliminando os requisitos / restrições mais óbvios .

Depois, você pode ajustá-lo no caminho, desde que você nunca possa adivinhar tudo no início, porque outras restrições podem / aparecerão mais tarde no desenvolvimento, por várias razões.

Dessa forma, você sabe para onde está indo, mas ainda pode se adaptar às mudanças.

1. A quantidade de preparação necessária é geralmente proporcional à complexidade do que você está fazendo. Não faz sentido escrever e escrever 2 dias inteiros para um algoritmo usado uma vez em um quarto, que executa uma hora em uma única leitura em uma única máquina. Faz sentido escrever e escrever três semanas-homem (se necessário) para projetar o novo módulo compensador de fluxo de alto desempenho, capaz de processar meio milhão de solicitações por hora e executar 24/7/365 sem tempo de inatividade.

2. Você pode dizer se é um mau hábito em 30 segundos se observar as soluções que está codificando. Você perguntou se é um hábito bom ou ruim. Bem, isso depende de você. Se você é um aluno lento no início de sua carreira em programação, provavelmente é uma boa idéia escrever um papel e um papel para detalhar todos os detalhes. Se você tem alguns anos de experiência, basta pensar por 5 minutos e depois fazê-lo. Claro que ainda em relação ao 1. acima.

Bottom line

Somente seu código diz a verdade se você precisa de mais ou menos caneta e papel. Não deixe que ninguém dite isso para você, mas descubra por si mesmo. Isso mantém você aprendendo.

_{Isenção de responsabilidade: Pode não ser o que se chama pensamento convencional e bom senso. Isso está ok. Basta definir um marcador e lê-lo novamente em cinco anos ou mais.}