Como devo planejar e iniciar um projeto?

Sempre que inicio um projeto, decido, em momentos cruciais, alterar completamente as classes principais e ser pego em erros obscuros. Tento planejar com antecedência e geralmente começo com um bom pé, mas depois vou para outro dia e decido que gostaria de fazê-lo 'de outra maneira'.

Existe algum tipo de padrão ao iniciar um projeto, como mapear classes e iniciar testes de unidade? O que é uma boa convenção ao planejar e iniciar um projeto de médio porte.

O último projeto iniciado foi um simulador de movimento de projétil - eu sei, previsível.

Ao planejar, não planeje todas as coisas possíveis sobre o aplicativo com antecedência. Planeje os passos do bebê. Qual é a funcionalidade mínima absoluta necessária para começar a usar o aplicativo? Comece por aí.

Quando você inicia seu projeto, codifique apenas a funcionalidade mínima absoluta. Ao codificá-lo, certifique-se de escrever um código bom e limpo com encapsulamento inteligente . Isso minimizará os erros resultantes das alterações posteriores.

Iter nessa funcionalidade mínima até que você esteja feliz com ela. Em seguida, comece a adicionar novas funcionalidades e aprimoramentos, um de cada vez. Mais uma vez, concentre-se em escrever código bom e limpo com encapsulamento inteligente.

Se você planeja etapas do bebê e escreve um código limpo, isso minimiza o número de alterações que você realmente precisa fazer. Quando você terminar de escrever o primeiro recurso, você deverá ter adotado os padrões nos quais a base do aplicativo permanecerá. Se houver problemas com essa base, seus próximos recursos deverão revelar rapidamente o problema. Será mais fácil ver como a peça se integra. As alterações que você fizer devem, nesse momento, causar interrupções mínimas.

Parece que seu planejamento não está ajudando. Isso não é surpresa, porque você não tem experiência suficiente para fazer um plano viável. A solução é simples. Pare de planejar tanto. Apenas aceite que você vai escrever e reescrever o código à medida que avança. Tudo bem, porque o código é gratuito, exceto pelo seu tempo. Se você estiver escrevendo um aplicativo de interface do usuário, comece com uma janela em branco e adicione um pouco de cada vez até terminar. Quando você tiver mais experiência, seus projetos serão mais rápidos. Preocupar-se porque você está mudando o código é como um estudante de música se preocupando com todas as notas desperdiçadas na prática.

Ninguém sabe realmente qual será o melhor design até que tenha codificado uma certa quantidade dele. Portanto, o segredo do bom design é reconhecer que seu primeiro rascunho é inevitavelmente abaixo do ideal e planejar reescrever porções menores mais cedo e com mais frequência . Em vez de desfazer um programa quase completo, reescreva linhas ou funções ou classes assim que reconhecer suas deficiências.

Geralmente, bons programadores experientes também não acertam no primeiro rascunho. O que vem com a experiência é a capacidade de reconhecer um design incorreto mais cedo e a capacidade de reescrever mais rapidamente.

Na minha experiência, esse problema desaparece quando você tem um pouco mais de experiência - você percebe o que funciona e o que não funciona. Além disso, um bom encapsulamento pode reduzir os custos de alteração de design. Quanto mais encapsulados forem seus módulos, mais barato será mudar mais tarde. Considere isso uma excelente motivação para manter suas aulas separadas.

http://nathanmarz.com/blog/suffering-oriented-programming.html

Isso resolve o seu problema. Ele começou simplesmente certificando-se de que o software era possível, criando e criando um protótipo. Então, ele começa a pegar o código e a dividir. Então, ele otimiza.

Existem dois aspectos no design de um aplicativo. O primeiro é decidir exatamente o que seu aplicativo pode fazer. O segundo é projetar como fazê-lo. As alterações no que ele faz são bastante significativas e, dependendo da maturidade do aplicativo (e da mudança de direção do aplicativo), é melhor abordá-lo como uma reescrita, em vez de re-trabalhar.

O segundo aspecto é o como. Usando testes de unidade e práticas de desenvolvimento ágil, você pode minimizar o impacto de alterar como uma função específica é realizada através da refatoração. Parte do aprendizado de como alavancar essas técnicas é a prática prática.

Vou dar o conselho que dei uma e outra vez. Escolha um projeto de estimação. Escreva da melhor maneira possível. Aprenda algo novo e aplique o que aprendeu para melhorar a maneira como aborda o desenvolvimento desse projeto.

Por exemplo, comece com uma lista de tarefas. Simplifique ... nem se preocupe com o armazenamento do banco de dados primeiro. Apenas faça funcionar. Agora comece a construir sobre essa base. Talvez você queira aprender MVVM e WPF ... você já sabe como implementar a lista de tarefas na memória, para ter menos um problema a resolver. Agora você deseja que vários usuários possam carregar suas listas de tarefas a partir de um banco de dados. Você resolveu na memória e na apresentação separada, para poder se concentrar em aprender o acesso a dados. A partir daí, você pode expandir o aplicativo para ter um modelo de domínio mais complexo (por exemplo, mudar de uma lista de tarefas para uma solução de gerenciamento de projetos), uma interface da Web ou até mesmo executá-lo em um dispositivo móvel. A chave para fazer esse trabalho é escolher algo que seja realizável por você, contra o qual você possa marcar o progresso e que possa crescer com o tempo.

Na minha experiência, o design do sistema geralmente leva tanto tempo quanto mais do que a codificação real. Quando você diz "planejar com antecedência", o que você realmente planeja? Talvez vá à velha escola e use uma das metodologias de design testadas e comprovadas. Ou vá para a velha escola e escreva o pseudo-código antes de escrever o código real.

Acho que você deve se perguntar por que está mudando as coisas em momentos cruciais, em vez de seguir o plano original. O plano original foi falho? Ou você teve um momento perspicaz que mostrou uma maneira melhor de fazer as coisas. Foi realmente melhor ou apenas diferente?

À medida que você ganha exp, precisará reescrever / arranhar e começar de novo, com menos frequência. Anote o problema que você está tentando resolver. Escreva descrições vagas de classe que você acha que precisará, escreva como a vontade precisará interagir. Tenha uma idéia de como tudo vai funcionar e depois codifique. Não gaste muitas vezes escrevendo todas as propriedades e métodos de suas aulas. Nesta fase, você está tentando obter uma visão de 50K do que você deveria fazer. Depois de começar a codificar, se precisar anotar mais detalhes, vá em frente. Se não, basta começar a codificar.

A razão pela qual você está achando isso tão difícil é que tem uma ideia, mas na verdade não tem uma ideia completa do que deseja que ela faça. Se você estiver executando seu próprio projeto e não tiver um cliente para lhe dizer o que eles querem, é sua responsabilidade ser seu próprio cliente. Coloque-se no lugar do cliente e comece a criar uma lista de desejos impossível.

Em outras palavras, quando você começa, não cria nada !!! .

Depois de ter uma grande lista de coisas que você deseja que o sistema faça, priorize tudo e decida qual será a funcionalidade mínima para ter um sistema básico em execução. Pode ser uma função básica única ou uma tela inteira, mas precisa ser algo que você sinta - como o cliente - será útil o suficiente para testar.

Então, lista de desejos de recursos + prioridades básicas = Requisitos .

Depois de ter tudo isso, faça um design de nível muito alto. Apenas sente-se e pense sobre o que seu sistema precisará para colocar as primeiras prioridades em funcionamento. Mude de idéia, se desejar, mas é aqui que você pode adicionar algum código ou uma configuração do sistema para saber mais sobre o que é possível. Vá apenas o suficiente para validar sua ideia básica de design.

Ou seja: AGORA você pode satisfazer os desejos de seus designers .

Uma vez feito, você começa a implementar seus recursos. Crie para cada recurso uma especificação funcional básica. Isso pode ser tão simples quanto uma coleção de instruções de recursos. Cartas de história, se quiser. Isso permite que você desenvolva um pouco sua ideia e crie um conjunto de instruções que se tornará a especificação na qual você testará e desenvolverá sua implementação.

Cry Havoc, vamos escorregar os cachorros de ... Code !!

A partir daí, implemente seus testes para corresponder às suas especificações e, para cada teste, escreva seu código. Crie, "libere" e repita com o próximo recurso até decidir que o projeto está completo o suficiente.

Na verdade, tudo se resume à experiência, mas essa abordagem que encontrei é uma fórmula simples para ajudá-lo a focar sua mente no que precisa ser feito, em vez de ficar preso a um ciclo interminável de procrastinação devido à tentativa de fazer muito de tudo. uma vez.

Depois de fazer o básico, como estabelecer as metas do projeto, obter sua lista de requisitos e bloquear qualquer interface para sistemas externos.

Então você precisa criar um caso de uso ou "história" para cada interação do usuário. Foram escritos volumes sobre o que torna um "bom" caso ou história de uso e há muitas variações. Os casos de uso são a ferramenta de design mais eficaz que encontrei. Eles ajudam a captar a funcionalidade que falta, ao mesmo tempo em que elimina requisitos desnecessários e reduz o design ao essencial. Como eu disse, as metodologias variam, mas a maioria dos profissionais concorda em:

• texto conciso e simples em inglês.
• "Objetivo orientado" funciona melhor, ou seja, "Macaco adquire uma uva" é melhor que "Macaco aperta o botão vermelho".
• proibir terminologia técnica. Sem "pulldowns", "caixas de texto". Um bom caso de uso deve ser independente de qualquer tecnologia de interface. Você deve poder usar um caso de uso para um sistema baseado em HTML e usá-lo para um sistema ativado por voz sem nenhuma alteração no próprio caso de uso. (isso é muito difícil de fazer, mas vale a pena!).
• Procure reduzir em 50% a contagem de palavras do seu primeiro rascunho, livre-se de etapas desnecessárias e verborragia.

Do que você está pronto para especificar suas principais classes:

UML - Linguagem de Modelagem Universal. É a ferramenta padrão para projetar classes. Você especifica os membros e métodos públicos de cada classe e os vincula em um modelo gráfico claro e conciso.

Em conjunto com diagramas de sequência, modelos de dados, é possível verificar e melhorar seu design antes que qualquer codificação ocorra.

Mude seu foco para o resultado que você deseja obter e avalie os ganhos potenciais de aprender / experimentar novas implementações com o risco de seguir por uma estrada que o leva de volta à estaca zero.

No caso de você voltar à estaca zero, nem tudo está perdido porque você ganhou experiência.

Se você tem um prazo (parecia que você está programando por diversão), isso é realmente complicado. Se você seguir um caminho continuamente, corre o risco de usar métodos desatualizados à medida que o tempo passa. Se você seguir o outro caminho continuamente, corre o risco das conseqüências de produzir resultados a uma taxa mais lenta (uma taxa variavelmente mais lenta, dependendo dos resultados de suas aventuras de aprendizado).

Eu costumava brilhar no trabalho, fazendo as coisas rapidamente ano após ano, e então um dia percebi que estava me tornando não atual em minhas habilidades.