Reconciliando conselhos de programação contraditórios: faça com que algo funcione e repita vs. realmente pense antes de codificar

Sou um programador intermediário, com alguns anos de experiência profissional, que está no meio do mestrado. Ao aprender a programar, muitas vezes ouvi dois conselhos aparentemente contraditórios.

O primeiro conselho foi obter algo funcionando rapidamente, ver como ele funciona (por meio de prototipagem ou teste informal), melhorar a versão, ver como funciona novamente, melhorar novamente ... e depois repetir o ciclo até terminar . Isso às vezes é chamado de "desenvolvimento em espiral" ou expresso como "liberação antecipada, liberação freqüente".

O segundo conselho foi: realmente pense em um projeto antes de escrever qualquer código.

Eu tive sucesso com os dois métodos e diria que concordo com cada filosofia.

Mas agora estou começando a lidar com projetos muito mais complexos que não tenho idéia de como concluir (como aplicativos distribuídos e programação gráfica orientada a desempenho).

Como faço para executar esses projetos?

Inicio a codificar ALGO e aprendo (plataformas / métodos / linguagens / arquiteturas) à medida que passo - ou paro de codificar e faço uma tonelada de pesquisa / leitura antes mesmo de abrir o IDE?

Como reconcilio esses conselhos contraditórios de programação?

Não tenho certeza de que pensar sobre um problema antes da abordagem versus a abordagem iterativa sejam contraditórios entre si. Assim como muitas outras coisas, acho que você deve se esforçar para alcançar o equilíbrio entre os dois. Como você encontra o equilíbrio? Isso é algo que você aprende com a experiência e, muitas vezes, as melhores lições (ou seja, coisas que lhe proporcionam experiência) é quando você não entende direito (ou uma lição ainda melhor: simplesmente entenda errado). Como você já apontou, há um ditado "libere rápido, libere com frequência". Há outro semelhante: "falhe cedo, falhe rápido, falhe frequentemente"

Pensar no futuro é ótimo e você deve absolutamente fazê-lo. Mas com a experiência, aprenda quando parar de pensar e criar algo, mesmo se você não tiver todos os dados. Ao construí-lo, você poderá obter mais informações sobre o domínio do problema e potencialmente encontrar uma solução muito melhor. Portanto, recomendo não excluir uma da outra, mas fazer da "cabeça pensante" parte de suas iterações e, com o tempo, acho que você encontrará a resposta certa para essa pergunta.

Apenas um pequeno exemplo. Outro dia, eu estava lutando com uma decisão de design de software. Em retrospectiva, foi relativamente trivial, mas eu tinha duas alternativas e parecia que as duas funcionariam. Continuei circulando de volta aos prós / contras de cada um e, em seguida, circulando de volta e reconsiderando minhas decisões. Olhando para trás, é um pouco embaraçoso quanto tempo passei pensando. Então eu disse para mim mesmo, f # @ k it! E, em vez de usar qualquer um dos designs, eu apenas fui em frente e hackeei alguns códigos juntos, ignorando completamente todas as coisas boas que você aprendeu sobre um bom design. O recurso funcionou em cerca de 45 minutos. Depois voltei, olhei para o meu código e o refatorei para algo sólido e algo que não me envergonharia de verificar o controle de origem. O engraçado é que, depois que o hack funcionou, surgiu "

Outra coisa que eu recomendaria especificamente para os problemas que você está enfrentando agora (ou seja, tarefas grandes e complexas à frente). Em vez de fazer coisas em série, faça-as em paralelo. Divida o seu dia em partes onde você pesquisa e depois para, troca de marcha e código por um tempo, pelo menos em partes do projeto que não são incógnitas completas. Dessa maneira, ficar próximo ao código fornecerá uma melhor perspectiva e você não se queimará ao tentar absorver informações demais rápido demais. Para mim, pelo menos, depois de algumas horas de pesquisa, é bom deixar o cérebro digerir coisas, alternar tarefas e fazer outra coisa por um tempo. Depois, volte para mais pesquisas.

Há certas decisões que precisam ser tomadas antes do tempo.

Você está criando um aplicativo da web? Então você precisa saber como será a arquitetura geral. Arquiteturas como MVC já definem quais serão suas peças funcionais grandes (como roteamento, controladores, modelos, camadas de serviço, protocolos de comunicação e assim por diante); inventar tudo isso do zero será longo, desnecessário e provavelmente inferior ao que já foi inventado.

Você está escrevendo algum tipo de aplicativo que envolva coleções de objetos ou dados? Então, você precisará saber quais tipos de estruturas de dados são mais apropriados para o seu cenário específico e quais são suas características de desempenho. Você precisa de tempo de pesquisa rápido? E os conjuntos de dados ordenados? Uma coleção na memória será suficiente ou você precisa de algo mais industrial, como um banco de dados? Você não pode simplesmente começar a codificar sem pensar nessas decisões, porque se você fizer a escolha errada, terá que começar de novo.

Dito isto, uma vez que as decisões tecnológicas são tomadas, você tem liberdade dentro da estrutura que estabeleceu. O objetivo, então, é permanecer flexível, iterativo e (ouso dizer) ágil o suficiente para que, quando o cliente mudar de idéia sobre o que deseja, você possa acomodá-lo com um mínimo de barulho.

Como você faz isso? Experiência, principalmente. Como alguém disse uma vez, a experiência é o que você obtém logo após a necessidade. Mas se você seguir as decisões bem-sucedidas de design de outras pessoas (como incorporadas nas plataformas, bibliotecas e outras ferramentas do comércio), poderá aprender com elas e reduzir seu risco.

Não vejo os dois como mutuamente exclusivos.

Como qualquer tipo de gerenciamento de projetos, você precisa de uma visão de longo prazo e de objetivos de curto prazo.

Sem o primeiro, você acabará perdendo tempo, por exemplo, em recursos que nunca podem ser usados ​​e, sem o último, passará o dia todo pensando em como criar o aplicativo perfeito sem concluir o seu projeto.

Com que frequência você libera / etc. depende da metodologia específica que você está usando.

O que você precisa pesquisar depende do que você sabe e do que não se sente confortável.

"Iteração" e "reflexão" não são contraditórias, mas complementares.

Mesmo em seus extremos, eles refletem dois caminhos para chegar ao mesmo lugar.

• O extremo da iteração é de mil macacos batendo em mil teclados. Com tempo suficiente, talvez você obtenha algo que atenda aos requisitos.
• O extremo de "pensar bem" é uma abordagem em cascata. Se você tiver sorte, os requisitos não mudaram drasticamente desde o início do projeto até a entrega do código. Ou você acabará com a paralisia da análise e não entregou nada.

Você precisa ter alguma compreensão do domínio e do problema antes de começar a codificar. Esta é a parte "pense bem". Idealmente, você verá o caminho de alto nível do começo ao fim sobre como resolver o problema.

Mas você pode ver apenas partes importantes desse caminho, e certamente nem todas as paradas ao longo do caminho. É aí que a iteração entra em jogo. Você pode começar a iterar pelas versões do aplicativo e buscar feedback para:

• Identifique os obstáculos que surgem nos níveis mais baixos de detalhes
• Veja o feedback das partes interessadas para esclarecer essas áreas obscuras no caminho de alto nível.

A raiz latina de decidir significa "cortar". A iteração permite que você decida o que funciona na prática, em vez de apenas a teoria e a iteração, permitindo que você elimine as outras opções que não são viáveis.

Então você precisa pensar no problema para entender o que vai fazer. Mas você precisa percorrer as versões do aplicativo para realmente transformar a ideia em código real.

Minha regra de ouro: se você não entender completamente qualquer parte do problema, precisará recuar e refletir completamente (eu incluo prototipagem e código de descarte para entender APIs etc. como parte de "refletir") . Se é basicamente uma coleção de problemas que você resolveu antes e você só precisa descobrir a melhor maneira de encaixar tudo nessa instância específica, faça uma iteração.

Honestamente, porém, essa não é uma regra rígida. Eu realmente acho que você precisa fazer uma mistura de ambos para qualquer projeto. Quanto de cada um de vocês provavelmente dependerá principalmente da proximidade do projeto com o que você já concluiu no passado.