Devo planejar com antecedência ou descobrir programas enquanto os estou escrevendo? [duplicado]

Este é um exemplo perfeito da falácia do meio excluído. Sim, escrever o programa inteiro no papel antes de tocar no teclado é uma má ideia. Mas isso não faz o extremo oposto - imediatamente pular na codificação e começar a hackear - uma boa ideia. Na verdade, é ainda pior.

É muito importante entender o que você está tentando escrever antes de começar a escrevê-lo. Quando eu tenho um novo recurso para implementar no trabalho, tenho certeza de que tenho uma especificação que descreve o que precisa ser feito antes de começar. Eu procuro, e se há alguma coisa lá que não faz sentido, eu falo com as pessoas que escreveram a especificação e trabalharam sobre o assunto até que estivéssemos de acordo. Às vezes eu não tinha entendido os requisitos e eles podem me endireitar; outras vezes o pessoal do PM não entendeu os detalhes técnicos e acabaram modificando a especificação.

Qualquer pessoa que tenha feito isso pode lhe dizer, por experiência pessoal, que é muito mais fácil corrigir problemas na especificação do que encontrar um problema no seu código na metade da implementação, copiar tudo e substituí-lo. com outra coisa. Então, ter um plano para o que você escreve antes de começar a escrever o código é muito, muito importante.

Você acha que Michelangelo subiu ao topo da Capela Sistina e começou a desenhar? Desenhos de teste foram feitos. Aprovações do papa eram necessárias. Havia andaimes a serem construídos. Modelos criados para orientar o grupo de outros artistas. A restauração foi ainda mais complexa.

Se eu quiser criar um aplicativo e não precisar considerar as preferências de design na cabeça de outra pessoa, posso começar a codificar. Se você seguir o caminho errado, apenas mude de idéia. Eu não queria esse recurso de qualquer maneira.

Deixe o pintor ou escritor sentar em um comitê. "Oh, apenas vá em frente e torne a personagem principal uma mulher. Se mudarmos de ideia mais tarde, nós o informaremos. E WTF, vamos fazer 20 'de comprimento em vez de 30. Você pode adicionar um Galleon espanhol com 50? remadores únicos antes da inauguração amanhã? "

Eu acho que é tudo sobre formar um equilíbrio. É impossível pensar em tudo antes de digitar tudo, e é exatamente por isso que o modelo Waterfall está tão quebrado. Ao mesmo tempo, se você pensar muito pouco, poderá causar uma grande confusão quando passar das primeiras iterações. Afinal, você não pode bater todo o código em forma, e seria muito lamentável se você tivesse negligenciado um requisito básico desde o início que exigia uma reescrita a meio do projeto.

Um certo número de iterações é necessário no processo de desenvolvimento, que é o que a Waterfall ignora (ela assume 1 iteração perfeita). Agile (ou o amplo grupo de metodologias "Agile-like") às vezes ignora que cada iteração tem uma certa quantidade de overhead, e se não for ganho muito em cada iteração, o número total de iterações aumentará e essa sobrecarga a um custo significativo.

Dado que a analogia está errada, a resposta é sim - os programadores devem trabalhar como escritores, pintores e arquitetos.

Eu tive um colega na faculdade que era um major de arte dupla, fazendo pintura e web design. Ele e eu comparamos muito as anotações sobre nossos fluxos de trabalho. Quando ele pinta, ele não apenas descobre a pintura enquanto a pinta. Havia várias coisas que ele poderia fazer de antemão. Para um tipo de colagem de pintura, ele pode desenhar um esboço. Em uma pintura fotorrealista, ele desenhava as formas principais com lápis e depois pintava os detalhes. Mas se ele soubesse exatamente o que ele queria de antemão, ele não precisava desses auxílios. Ele acabou de pintar.

Tenho certeza que você vê as semelhanças. Usamos métodos diferentes para ajudar a encontrar uma boa solução para um problema. Se não conhecemos bem uma tecnologia, nós hackeamos um pouco para descobrir como será a solução final. Os produtos maiores geralmente se beneficiam de uma sessão de design de grande formato, com os detalhes sendo preenchidos posteriormente. E às vezes sabemos exatamente o que é necessário, então apenas codificamos. Não porque somos preguiçosos, mas porque através da experiência e do pensamento não precisamos das ferramentas extras.

Algumas vantagens em projetar de antemão:

• Você vê toda a grande figura.
• Você pode iterar vários designs sem se comprometer com nenhum. Se você já tem código escrito, não pode mudar de direção em larga escala.

Vantagens de entrar no código:

• Em um nível micro, você tem a capacidade de experimentar várias coisas rapidamente antes de escolher o One True Parser
• Pode ajudar a quebrar um bloco de design. Se você não puder decidir sobre um determinado modelo de objeto, digamos, poderá criar um pouco de código e ver como ele se encaixa.

A resposta a esta pergunta é como a resposta para muitos na programação: Depende. Depende do projeto - você precisa de uma trilha de auditoria de projeto, o processo ajuda você e seus colegas desenvolvedores a entender completamente as decisões que você precisa, eles o ajudam ativamente ou estão impedindo você de fazer as coisas acontecerem? É crítico que o projeto esteja absolutamente correto, ou algumas falhas podem ser descobertas e corrigidas posteriormente? Como é o seu tempo? Que experiência você pode trazer para o problema? E finalmente, você entende completamente qual problema você tem que resolver?

O que funciona para mim atualmente é fazer um projeto de imagem grande na frente no papel. Isso descreverá as principais partes do aplicativo e como elas se comunicarão. Normalmente desenho um diagrama de objeto e alguns fluxogramas / código psuedocode / real para as seções mais complicadas. Então eu pulo direto, uma seção por vez. Se uma falha no modelo estiver causando um problema, posso sempre voltar às especificações de design e revisá-las para essa área. E mudar um bom design inicial geralmente não significa que mais do que um pouco terá que mudar.

Eu fui ensinado a programar da mesma forma que você constrói uma ferrovia modelo.

Ao construir uma ferrovia modelo, você coloca um trecho da pista e coloca um motor na pista. Se ele se mover, você coloca o próximo trecho da pista e vê se o motor se move para a pista. Você continua até completar o loop, e o mecanismo completou o loop também.

A vantagem desse método de construir uma ferrovia modelo é que, se o motor parar de se mover, você tem certeza de qual trecho da pista é o problema. Aquele que você acabou de colocar.

A programação é semelhante. Você precisa fazer a análise e o design, mas em algum momento, você precisa começar a seguir o caminho. Sua primeira iteração pode ser nada além de módulos fictícios. Tudo bem, desde que seu projeto seja executado sem abortar.

Você adiciona um método de cada vez (idealmente) ou a quantidade mínima de métodos para obter algo para executar. A cada vez, você vê se o mecanismo se move (o projeto é executado sem abortar).

Você pode descobrir, ao perceber que precisa de um revestimento adicional (alguns métodos adicionais). Tudo bem, desde que você não esteja mudando radicalmente o design. Se você está mudando radicalmente o design, pare de codificar. Passe algum tempo pensando sobre o design e faça as alterações no design antes de retomar sua codificação.

Quando você colocou as últimas partes da faixa (terminou os últimos métodos), seu projeto deve ser executado sem abortar. Porque você tem testado o tempo todo. Assim como construtores de ferrovias modelo.

A proporção entre pensamento e ação depende de várias variáveis, desde a complexidade do problema até o domínio e as metas finais. Não existe uma única abordagem única para descobrir quanto pensamento e planejamento você precisa de antemão em relação a quando você pode simplesmente "atacar" em um programa.

Se você tem um problema complexo ou está trabalhando em algo que seja vital ou crítico, é preciso dedicar tempo para compreendê-lo e pensar em soluções e trade-offs iniciais. Se você quiser aprender rapidamente uma tecnologia, uma biblioteca ou uma estrutura, talvez se sobressair e fazer com que seus erros em um protótipo descartável funcionem melhor. Outras opções incluem prototipação evolucionária - pensamento e design suficientes para garantir que você possa evoluir seu trabalho em um produto acabado, mas não tanto que você fique restrito a uma única estrada.

Como observou o @Thomas, não existe uma solução de tamanho único para todos. Nesta era de poder computacional e memória abundantes, a maioria dos problemas com os quais estamos enfrentando não é difícil, então, quase qualquer abordagem fará com que haja alguma solução correta. No entanto, ainda existem áreas em que você pode falhar miseravelmente se tentar descobrir uma solução em tempo real, escrevendo o código imediatamente.

Por exemplo, um aplicativo em que trabalhei analisava redes móveis. Se você precisa escrever código para analisar uma rede de alguns milhares de nós em mais de uma dúzia de camadas de rede diferentes, que devem rodar não em supercomputadores, mas em meros laptops dual-core, é melhor encontrar os melhores algoritmos gráficos conhecidos pela humanidade antes começando a escrever qualquer código. A alternativa poderia ser perceber, após meio ano de desenvolvimento ávido, que seu algoritmo, embora forneça resultados corretos para sua rede de teste de 10 nós, seja O (n <4> ) termina assim após dois anos no usuário. laptop, quando alimentado com o plano de rede da vida real, ele está trabalhando agora ...

Why don't more people just hack away and put a program together without having a preconceived idea of what it's going to look like?

Muitas pessoas fazem exatamente isso ao longo de suas carreiras. Este site está cheio de perguntas. Os outros sites afiliados estão cheios de perguntas de outras pessoas que tentam usar o software que eles escreveram.

O tipo de pessoa que simplesmente usa código, como você diz, costuma dizer algo como "O código é sua própria documentação". O código é a documentação não . Código não é uma demonstração de sua intenção, é alguma versão do que você lembra como intenção, além de um monte de coisas que você se interessou pelo caminho, algumas das quais acabaram não sendo úteis, mas você não teve tempo para remover. Ah, e essa idéia incrível que você teve depois de duas noites sem dormir, mas muita cafeína, que iria revolucionar todo o projeto, só sei que você nem sabe como compila, muito menos o que deveria fazer - ou precisamente que efeito terá se você removê-lo.

Sem algum tipo de documento de design, por mínimo que seja, como seus colaboradores (ou sucessores) informam quais bits devem ser extendidos e quais serão descartados? Esse documento não precisa ser escrito no começo, mas para um projeto de qualquer tamanho e valor, ele precisa acontecer em algum momento.

Spew-and-refactor trabalha para projetos solo, até certo ponto (e as pessoas que são boas juízas de onde é esse ponto valem a pena conhecer). É menos prático para as equipes; Como as pessoas trabalham de forma eficiente em paralelo sem algum consenso mínimo sobre a especificação? A metodologia ágil é, em grande parte, uma tentativa de resolver esse problema sem matar o entusiasmo nativo das pessoas pela codificação.

Geralmente, a programação é um exercício de abstração. Portanto, qualquer tentativa de atualizar uma solução em particular, indubitavelmente, levará você a julgar erroneamente o escopo de seu esforço.

Você não é tão bom em julgar a complexidade. Confie em mim, você simplesmente não é.

O melhor código começa com um esboço do que você deseja realizar e crescer de forma iterativa em partes. Com o código sucessivo construindo sobre si mesmo. Nos estágios de planejamento de um projeto, é muito mais útil sentar e listar o que seu programa NÃO irá fazer. Dessa forma, pelo menos você não sucumbe a tentar ferver o maldito oceano.

link

Eu sei que isso foi respondido, mas não estou convencido de que Graham tenha desconsiderado toda e qualquer visão geral de alto nível ou projeto antecipado. Eu penso sobre o problema antes da mão, tenho especificações, etc., mas ainda entendo completamente o que ele está dizendo, pois eu trabalho da mesma maneira.

Para mim, o "hacking away" vem não é o que você vai fazer, mas como você vai fazer isso. Na escola eu aprendi pseudocódigo e desenhei o código real na frente. Para mim, isso é bobo. Vou dar uma visão geral de alto nível, uma bússola e me afastar de lá. Eu não vou tentar pensar em todo o código porque eu não sou um compilador ou um computador e não consigo compreender as conseqüências de todo o meu código na frente. Eu vou cortar uma implementação ineficiente ou quebrada das especificações ou do design e, em seguida, "bater em forma" a partir daí.

Eu, pessoalmente, inclino-me mais para o estilo de programação exploratória e para o "descobrir como eu vou", mas, ao mesmo tempo, duas das minhas ferramentas de programação favoritas são um bloco de desenho de artistas e um conjunto de lápis de cor. Há definitivamente um tempo e lugar para sentar e esboçar relacionamentos de alto nível e visualizar as coisas para ajudar você a entender como as coisas se encaixam. Bem, existe para mim.

Novamente, acho que isso depende muito do indivíduo ... e também do domínio do problema e da complexidade inerente do programa. Ou seja, um simples programa de calculadora de linha de comando (pense em "pobre homem bc") provavelmente exigiria menos planejamento inicial do que um sistema ERP para uma empresa de 30.000 funcionários.

Eu acho que o fluxo de trabalho é muito individual para cada programador. Use o método que funciona melhor para você.

Eu, pessoalmente, geralmente começo com um papel em branco e um lápis (ou um quadro branco muito grande se eu tiver um). Estou primeiro desenhando diagramas de classes e relações. Então eu refino até ter uma estrutura básica. Eu também faço as máquinas de estado neste estágio. Neste ponto, nenhum código foi escrito ou pensado, apenas classes e relações.

Agora, este é apenas um esboço perdido e, enquanto eu começo a programar minhas aulas, vou me deparar com mais questões de design. Eu então volto para o meu quadro (ou papel) e decompino os novos problemas, às vezes significando rasgar um pouco do design original.

Isso também é semelhante a como o design Agile funciona (note SIMILAR para todos vocês que irão reclamar sobre isso). Há toda uma ciência sobre como acompanhar o progresso do projeto usando esse método, porque o número de novas tarefas será acelerado no começo e deve desaparecer até o final do projeto.

A ideia é iterar código e design. Usamos esse processo na minha antiga empresa (com 130 desenvolvedores) e funciona muito bem. Também usamos o Doxygen para produzir diagramas de classes e relações a partir do código. Esta foi uma maneira rápida de obter uma boa visão geral do design realmente codificado, para identificar falhas e relações ausentes.

Se isso funcionar para você ou não, não sei dizer. Você tem que tentar e ver o que funciona melhor para você.

Eu vou falar com meus dois centavos também.

Escrever um programa completo em papel antes de começar é um exercício "CS 101" que funciona para o Hello World. Mas cuspir código sem gastar tempo para pensar sobre o que você quer alcançar é uma perda de tempo também.

Entre esses dois extremos, você tem toda a gama de metodologias de software, desde o hard Waterfall (conjunto expansivo de especificações, praticamente uma saída no final) até ágil (especificações "light" com retorno muito rápido entre lançamentos e constantes " cliente "diálogo".

Em qualquer caso, você precisa saber o que está construindo antes de começar, seja qual for a metodologia. Isso ajudará a enquadrar a arquitetura do programa. A Waterfall irá enfatizar que todo o sistema seja arquitetado antes de começar a codificação, para que você saiba com o que vai acabar. Agile colocará ênfase em "especificar a funcionalidade mínima a ser alcançada para a próxima iteração", e irá adverti-lo a estar preparado para re-arquitectar constantemente (criando suítes de teste adequadas e similares, de modo que você possa realmente executar tal trabalho ).

Note que a metodologia NO lhe dirá para começar a codificar sem pensar, e de fato, você deve ter uma boa idéia do que você está tentando fazer (seja a coisa toda com Waterfall, ou uma área menor com Agile ). Você improvisa um pouco em "COMO" você faz algo, não em "O QUE" você está tentando fazer.

Eu posso traçar um paralelo com o que você aprende ao tomar aulas de atuação. Uma grande parte é "improvisação". Ao iniciar uma improvisação, você precisa entrar com o menor conjunto de pedras possível e estar preparado para abandonar sua ideia se alguém tomar a cena em outra direção. Você precisa de grandes habilidades de escuta e precisa aceitar as proposições dos outros. O principal é subir ao palco com um personagem, uma situação, talvez um sentimento que você queira transmitir e, potencialmente, uma finalização na qual você quer levar a cena. Mas quanto mais longe a ideia está na cena, mais provável é que você acabe em outro lugar. No final, é um modo de pensar muito "ágil", que pode ser o que você está enfrentando aqui.

Agora, se você estiver falando no nível "vamos escrever código" (especificações, histórias ou o que estiver disponível), então você decide. Algumas pessoas escrevem pseudocódigo, algumas escrevem comentários antes do código real (em um "preencha o formulário em branco") e algumas começam a escrever testes (consulte Test Driven Development). Em qualquer caso, o objetivo é estruturar sua ideia para que você alcançar o que você se propôs a fazer em seu método particular. Nesse nível, a maioria das pessoas pensa um pouco antes de escrever o código real. Mas ir tão longe a ponto de escrever o código antes da mão no papel me parece um exagero ...

Citação obrigatória do Hunter S. Thomson mas sempre funciona para mim

Se você tem uma ideia clara do que deseja alcançar, saiba como estruturar seu código e é um bom codificador, então é mais rápido escrever o código.