Às vezes, olho fixamente para o espaço ou esboço idéias e escrevo alguns pseudocódigos no papel. Então eu começo e começo novamente, então quando eu acho que tenho a solução correta para o problema eu começo a escrever o código.
É normal pensar por dias sem escrever nenhum código? Isso é um sinal de que estou abordando o problema completamente errado? Isso me deixa nervoso por não ter nenhum código tangível escrito no meu IDE.
Dependendo do problema que você está tentando resolver, a fase de design pode levar semanas e meses (se não anos), não apenas dias.
É necessário ter experiência para não começar imediatamente o código. Pensar sobre a arquitetura e o design de alto nível deve demorar dias, se não mais - definitivamente algo que deve acontecer antes de você começar a escrever seu código.
Isso é comumente chamado de "Paralisia de análise"
É comum, mas errado. Em algum momento, você precisa testar as várias ideias para ver o que funcionará melhor para você e aprimorá-las gradativamente.
Leituras recomendadas o programador Pragmático Especificamente no Capítulo 2, a seção sobre "Marcadores Tracer"
Isso é completamente comum. No entanto, se você usar uma abordagem "Teste primeiro" ou TDD, ela será menos comum e poderá ajudá-lo a formular melhor suas ideias.
Depende do que o leva a isso e suas razões. Aqui estão alguns:
Espero que você tenha descoberto que, se projetar por mais tempo, seu código será melhor. Se você puder olhar para trás e ver que não importa quanto tempo você gasta no design, talvez queira mudar. Outra consideração é a frequência com que você está descobrindo problemas depois de ter escrito código em comparação com o trabalho com seus projetos. Se você não está encontrando problemas até depois de escrever algum código, você deve considerar um equilíbrio e começar a codificar algo mais cedo ou mais tarde. Talvez essa abordagem possa ser aplicada ao uso de tecnologias mais recentes ou a um recurso muito complexo.
Eu não sei se tenho disciplina para manter uma abordagem ou outra, mesmo quando descubro que uma funciona melhor que a outra. Às vezes sinto necessidade de ir ao quadro branco; outros o teclado.
É muito comum e eu sinto que é uma maneira melhor de lidar e entender as coisas. Ao trabalhar em um projeto, fico preso muitas vezes e levo um dia ou dois para entender como posso abordá-lo melhor. Mesmo depois de resolvido o problema, espero que passe um dia. Isso me deixa mais atualizada e vai em frente.
É um fenômeno natural e bom para um desenvolvedor interceptar sua mente e entre.
Quando fiz um curso de gerenciamento de projetos, uma das coisas que o instrutor nos relatou sobre planejamento, que ficou na minha cabeça, foi que a regra que eles ensinaram nas forças armadas era descobrir 1/3 do tempo para o planejamento. Então, se você tivesse uma operação que exigisse que você ficasse completo daqui a 3 meses, pense em gastar um mês no planejamento antes de começar a execução.
A meu ver, existem três abordagens, cada uma adequada para uma situação de codificação específica
Eu já vi um problema semelhante antes, então tenho uma boa ideia dos padrões a serem aplicados e está claro como a solução deve se comportar e responder.
= > Use BDD / TDD a partir das soluções desejadas e trabalhando no código. (Ok, às vezes eu faço batota e escrevo um pouco de código e depois o teste - meio que uma abordagem aninhada de 2. - > 1.).
Eu tenho uma boa ideia dos padrões a serem aplicados, mas não sei como deve ser a solução.
= > Protótipo para ver que tipos de coisas interessantes surgem. Mova para 1. quando eu descobrir quais coisas interessantes são desejadas.
Não sei quais padrões aplicar.
= > Pense no problema e em como as várias formas de abordar o problema influenciam o código. Mova para 2) ou 1) dependendo do resultado desse exercício.
Em outras palavras, a resposta é a favorita do engenheiro: Depende.
É melhor passar um mês pensando e projetando do que preparar um protótipo rápido baseado em um design abaixo do padrão que você tenha que ganhar em forma. Especialmente se você estiver em equipe; uma vez que os outros começam a depender do seu código, é muito mais difícil implementar um design melhor com uma API diferente.
Concordo com as outras respostas que, em princípio, ter tempo para pensar em um problema / solução é uma boa ideia. No entanto, se você sentir que está preso, tenho algumas recomendações para maneiras de tornar o processo de planejamento um pouco mais coerente:
Crie artefatos de design. Então, e se você não escrever código? Talvez você apenas escreva um diário de seus pensamentos. Ou um esboço de uma solução geral. Ou mesmo apenas um bom resumo do problema que você refinou com o tempo. Ao considerar ideias e aceitá-las / rejeitá-las, mantenha um registro de seu raciocínio sobre o assunto. Dessa forma, no final do dia, você ainda pode apontar para resultados reais como evidência de seu trabalho.
Fale com as pessoas! Não há nada como ter um ser humano vivo e respirando com quem discutir idéias. Se você acha que está preso, converse com alguém. Pegue alguém - qualquer um! - e explique o problema para eles. Esboce seus pensamentos sobre como resolver o problema. Mesmo que tudo o que eles façam seja inspirar, expirar e piscar por dez minutos enquanto você balbucia, as chances são de que você descobrirá um novo insight apenas no processo de explicar o problema .
Como Satchel Paige disse: "Às vezes eu me sento e penso, e às vezes eu apenas sento".
Acho que o que ele estava querendo dizer é que às vezes é bom limpar a mente, já que isso pode levar você a pensar em seu problema de uma maneira diferente. Então, se você não está batendo no código, você pode chegar a uma solução ou idéia que poderia ter evitado você de outra forma. Então, sim, é normal e uma boa prática não pular direto para a codificação.
Existem duas maneiras de eu mesmo fazer esse processo. Eu crio uma pasta onde tenho um arquivo de texto e qualquer desenho relacionado ao projeto. Anoto minhas idéias e tento salvar todo o processo de pensamento da melhor maneira possível. Também vou criar um projeto de bloco de notas onde posso testar rapidamente ideias simples de algoritmos para layouts de CSS.
Programa = algoritmo + estrutura de dados
IMHO, o processo de design (resolução de problemas) totalmente rege. Detalhes de implementação (emissão técnica) seguem e resolvem naturalmente.
Aqui está o meu caso de pensamento.
Começando do zero Primeiro, é necessária uma ideia aproximada do que você deseja. Tente obter uma lista de alguns requisitos ou crie-os. Deve demorar um pouco para descobrir as coisas aqui. Depois de ter pelo menos uma parte que você está confiante de que deseja, conhecendo a maior parte da interface dessa peça, comece a codificar.
Corrigindo um problema com o código existente Primeiro, acompanhe o problema. Isso pode exigir algum tempo para não escrever código real (algum código de depuração pode ser gravado, mas isso normalmente não será mantido). Depois de encontrar o problema, dependendo da complexidade, comece a escrever o código para tentar corrigi-lo. Pouco pensamento deve ser necessário uma vez que o bug é conhecido. Se o problema for uma grande falha de design, consulte a próxima seção.
Alterações no design / principais recursos Esse é provavelmente o que exigirá mais atenção. Pensamento sobre como preservar estrutura, compatibilidade com versões anteriores, etc. deve ser incluído. Pensar na melhor mudança pode economizar um tempo significativo, mas normalmente não é mais do que alguns dias.
Adicionando um recurso simples Se nenhuma alteração de design significativa for necessária, basta codificar no seu recurso, usando alguma tentativa / erro. Isso não deve exigir uma tonelada de tempo em geral.
Eu vou discordar do consenso sobre isso. Eu prefiro começar a prototipagem de algo assim que eu tiver a mais vaga ideia de escrever sobre um guardanapo de como eu quero que meu sistema funcione. É quase impossível pensar em todos os pequenos detalhes que podem causar problemas, a menos que eu esteja especificando as coisas de uma maneira muito precisa. Se eu estou apenas discutindo o design com as pessoas, é muito fácil simplesmente passar alguns dos problemas mais complexos. Uma vez que eu esteja especificando coisas como esta, pode muito bem estar diretamente no código-fonte ao invés de alguns outros meios de expressão que sejam tão precisos e formais, mas que não possam ser compilados e executados.
Depende do que você quer dizer com "normal" . Falando sobre mim mesmo, acho que o código é uma ótima ferramenta de aprendizado. Então, quando enfrento um problema complexo, faço esboços no papel, mas também faço algumas codificações orientadas por testes. Código me diz que um quadro branco não pode dizer e vice-versa, e talvez o resultado seja insight ou a necessidade de mais algumas perguntas para o especialista do domínio.
Assim, o verdadeiro conselho é: "Use todas as ferramentas de aprendizado necessárias para se aproximar da definição do problema" , mas também "lembre-se de que essas ferramentas são de aprendizado, por isso não caia amor com eles " ambos os códigos e esboços são feitos para serem descartados.
Nesta era da RAD e da programação ágil, você deve começar a desenvolver assim que puder identificar partes importantes do sistema, os detalhes aparecerão. Como os softwares estão ficando maiores, focar prematuramente em cada detalhe não leva você a lugar nenhum.
Tags design