Como organizar um projeto individual? [fechadas]

De vez em quando (leia-se: todos os dias), tenho uma nova idéia, inicio um novo projeto no meu editor / IDE favorito, inicio a codificação e, no dia seguinte, o apago e inicio algo novo. Estou programando há cerca de seis anos e, nesses seis anos, concluí apenas um projeto muito pequeno (um widget do Dashboard para Pastebin.com). Embora isso possa ser ótimo para aprender a codificar, eu realmente quero concluir algo.

Quais são algumas das coisas que devo fazer antes, durante e após a codificação real? Quais são os bons recursos que me ensinam a organizar esses projetos individuais?

Se isso importa, eu quero fazer desenvolvimento na Web ou Mac.

Eu acho que o problema real, a longo prazo, é a motivação, e não a organização.

1. Encontre usuários e converse com eles. Veja seu projeto como uma espécie de presente (ou produto que pode ser vendido) para essas pessoas. (Alguém com quem trocar idéias também é ótimo, mesmo que não desenvolva código com você.)

   Ter essa motivação social será muito mais poderoso para manter o projeto interessante a longo prazo do que a mera curiosidade pessoal.

2. Seu objetivo deve ser pequenos pedaços de funcionalidade útil. Coloque-o no SourceForge ou no GitHub e trate o projeto como algo que precisa de uma chance de sobrevivência, mesmo que você seja atingido repentinamente por um meteoro.

   Isso leva a mais lançamentos (significando mais feedback e entusiasmo dos usuários) e também maior probabilidade de outra pessoa decidir contribuir com o projeto.

3. Escolha um objetivo de aprendizado específico para você. Que tecnologia ou técnica o projeto ajuda você a aprender? Se a técnica não for adequada para a área do problema, você estará interessado o suficiente para pelo menos concluir a versão 1.0 antes de colocá-la de lado?

   Exemplos de tais objetivos incluem analisadores de escrita, protocolos de rede, aspectos da IA ​​do jogo, estruturas de aprendizado ou kits de ferramentas, um novo idioma etc.

O pior cenário significa perder todos os três, onde você repetidamente faz uma "reescrita maciça" de uma ferramenta nunca lançada que envolve código que você não considera interessante para pessoas que não tem certeza de que existem.

Quando você tiver uma idéia para um novo projeto enquanto trabalha em um projeto, observe-o em uma lista de idéias do projeto. Em seguida, volte ao projeto atual. Se o projeto vale a pena, não se distraia com um novo projeto. Use as etapas a seguir apenas se for uma ideia excelente.

Antes de iniciar nosso projeto, planeje-o. O que isso fará? Quão difícil será fazer? Quais são os conhecidos e os desconhecidos? O que provavelmente dará errado? Quanto tempo vai demorar? [Agora você pode decidir se quer continuar ou parar agora.] Mantenha seu plano. [Se você estiver trabalhando em um projeto, deixe de lado o novo projeto e continue com o outro projeto original.]

Quando você iniciar o seu projeto, configure-o como um projeto separado no seu IDE. (Portanto, você não precisa excluí-lo para iniciar seu próximo projeto.) Verifique em algum software de controle de versão como um novo projeto. (Agora você pode excluí-lo se o impedir de outro projeto.) Faça check-in do seu projeto sempre que tiver que fazer algo corretamente. (Agora você pode voltar se sair da pista.)

Acompanhe os problemas que surgem no seu projeto. Isso pode ser feito com alguns arquivos de texto dentro do projeto. Arquivos como TODO, Changelog, README (podem incluir erros e problemas conhecidos) podem ser apropriados.

Quando o código estiver funcionando, marque-o no seu controle de versão. Se vale a pena compartilhar, faça-o.

Volte ao seu plano e veja como você se saiu. Faça um documento das lições aprendidas por si mesmo. O que você aprendeu, quão bem você estimou? Que problemas você perdeu? Que problemas você superestimou? Qualquer outra coisa que você considere importante.

Quando você abandonar um projeto, faça as lições aprendidas. Adicione uma observação sobre por que você abandonou o projeto.

Reveja suas lições aprendidas uma vez por mês aproximadamente. Conforme o tempo passa, você pode aumentar o intervalo entre as revisões.

Aqui está um link para " Fazendo Agile em uma equipe de um ". É uma leitura interessante!

Além disso, você pode considerar por que as disciplinas de desenvolvimento de software que realizamos "no trabalho" são importantes. Eles são importantes apenas se houver 10 pessoas na equipe? Não, eles são importantes porque ajudam você a pensar em seu projeto.

Quem é seu público alvo? (Se é você, então ótimo - mas lembre-se do que você queria originalmente para o aplicativo)

Se você estiver fazendo uma interface do usuário, pense nas necessidades do seu público-alvo e faça algumas maquetes antes de iniciar o desenvolvimento da interface do usuário.

Se você estiver olhando para a lógica de negócios, tente TDD ou BDD. Pense em como você deseja que seu aplicativo funcione antes de atacá-lo. Considere envolvê-lo em um cinto, como Fitnesse ou similar. Se você deseja testar seu aplicativo, o lugar mais fácil para começar é no início .

Dado o seu comentário, pare de excluir seus projetos!

Normalmente, não mantenho projetos que não estou desenvolvendo ativamente (ou prevejo desenvolver ativamente em um futuro próximo) no meu computador, mas os arquivos de origem existem em um repositório SVN e tudo (incluindo os arquivos de configuração IDE) é feito em backup um disco rígido externo. Ele não responde à sua pergunta, excluindo seu trabalho, e se concentra em se motivar.

Se você estiver procurando por um repositório hospedado, consulte o Google Code, SourceForge, GitHub e BitBucket. Carregue seus arquivos, mantenha-os em algum lugar e, quando você tiver um interesse renovado, puxe-os para baixo. Embora você possa torná-los privados, você pode torná-los públicos se não tiver vergonha deles. Talvez alguém esteja interessado em reiniciar seu trabalho ou aprender com seus exemplos (especialmente se você estiver usando uma biblioteca ou estrutura interessante).

Com o tempo, trabalhe em sua motivação. Tente se concentrar em uma coisa de cada vez. Você pode não obter seu código com qualidade de produção, mas talvez com exemplo de qualidade ou algo que outras pessoas possam ver para ver seu conjunto de habilidades, conhecimentos ou para aprender sobre uma maneira específica de fazer as coisas.

Primeiro de tudo, existem projetos e projetos. Se você experimentar alguma tecnologia ou biblioteca, ou algo mais, provavelmente criará um projeto em seu IDE, descobrirá se isso é interessante ou não e excluir o projeto. Tudo bem, todo mundo faz isso.

Outro tipo de projeto são softwares / sites / etc. Reais, que são negócios, onde esses 'projetos', arquivos, programas são apenas ferramentas, e desenvolver coisas tão complexas exige motivação e objetivos :

• o que você desenvolve (site / editor de texto / aplicativo móvel / ...)
• para que você precisa (ganhar dinheiro, adquirir alguma nova tecnologia / contribuir com código aberto / ...)
• quando você faria (quanto tempo dedica seu projeto, quanto tempo planeja fazer isso)

O que você desenvolve deve ser novo . Se você deseja criar apenas outro editor de texto porque acha que falta algum recurso exigido, provavelmente não precisa fazer isso. Existem centenas de ferramentas de código aberto, contribuem para uma delas.

Mesmo se você criar uma pequena ferramenta de uso único como um script, deve indicar as coisas listadas, seria mais fácil resolver o problema.

Se você está preso ao escrever um código (por exemplo, reescreva-o massivamente), provavelmente não possui experiência suficiente para fazer isso. Faça um bom livro sobre engenharia de software, sua plataforma (mac / web / etc), leia o código escrito por desenvolvedores mais experientes que faz coisas semelhantes. Existem muitos lugares para fazer isso agora (github, código do google, blogs de programação, stackoverflow).

Não tente resolver um problema muito complexo (por exemplo, escreva um compilador ou um sistema operacional) do zero, primeiro decomponha-o em tarefas menores, na maioria das vezes, alguém já criou bibliotecas que o ajudam a resolver seu problema.

Você já pensou em perguntar a um ente querido o que ele realmente precisa para uma ferramenta da web e, em seguida, realmente faz isso para ele ou ela?

Isso deve fornecer a motivação para realmente terminar e entregar qual é a parte mais difícil disso. Além disso, você obtém o benefício de apoiar e manter o aplicativo, se ele for útil para sua amada. Se não for útil, você pode aprender com a experiência o que pode dar errado.