Gerenciando projetos pessoais como desenvolvedor solo - Saindo de projetos em profundidade e com falha [fechado]

4

Preciso de alguns conselhos sobre gerenciamento de projetos.

Eu inicio um projeto e, muitas vezes, é um grande projeto para um desenvolvedor solo. Geralmente é um projeto da web. Eu cuido de tudo, desde a interface do usuário, para o JS, PHP, gerenciamento de servidores etc. Na metade do caminho eu me sinto fora da minha profundidade. Eu perco onde estou, então passo alguns dias longe do projeto para evitar o estresse e antes que você perceba, torna-se outro projeto inacabado.

Eu tento usar frameworks e bibliotecas de código para tornar meus desenvolvimentos mais fáceis para mim. Às vezes, eu concluo um projeto para que ele "funcione" e, em seguida, volte e lide com os erros, crie a interface do usuário corretamente e outras coisas. Mas sem falta eu sempre acabarei fora da minha profundidade.

Eu pensei em terceirizar tarefas como a interface do usuário e o comportamento, e focar apenas no PHP - o que eu sinto é o meu ponto strong. Mas então o orgulho entra em ação e eu não me sinto em sintonia com um projeto que não terminei. Isso faz sentido?

Tenho certeza de que há muitos outros que se sentiram assim em casa ou no trabalho e gostaria de receber alguns conselhos sobre como gerenciar melhor meus projetos.

    
por James Jeffery 05.11.2013 / 14:03
fonte

5 respostas

10

Tive exatamente o mesmo problema:

Se eu colocasse meu projeto fora por alguns dias, voltaria a ele e teria muita dificuldade em recuperá-lo. Eu tive que me familiarizar novamente com ele, tentar re-entender para onde meu trem de pensamento estava indo e às vezes me perguntar por que eu decidi codificar isso da maneira que eu fiz até agora. Mais frequentemente, isso simplesmente me faria abandonar o projeto ou reiniciá-lo do zero. Tudo isso se tornou um problema real quando percebi que a situação me forçou a:

  1. inicie apenas projetos pequenos e simples. Começar um grande projeto apenas me levaria além do limiar de confusão, onde eu não poderia mais retomar depois de deixá-lo sozinho por alguns dias

  2. Se eu realmente quisesse fazer algo mais complexo e complexo, eu teria que fazer tudo de uma vez, ou seja, trabalhá-lo todos os dias até que fosse feito sem pausas

Isso foi apenas estressante. Eu decidi que antes de continuar fazendo projetos pessoais individuais, teria que tentar resolver esse problema.

Eu comecei projetos complexos de propósito, só para ver exatamente porque eu estava tendo dificuldade em recomeçá-los depois de alguns dias de intervalo. Eu começaria a implementar um algoritmo com o qual eu não estava familiarizado até então (como A * ou Mini-max, etc), pare de codificar no meio disso tudo, e tente terminá-lo alguns dias depois.

Veja algumas das minhas conclusões sobre isso:

  • qualquer coisa monolítica é ruim . Faça pequenas funções / métodos concisos, classes, pacotes, módulos. Nunca, nem uma vez, faça isso, pensando "oh, vamos, só adicionarei o código draw.sprite à função updateGameState() desta vez apenas, quão ruim pode ser" ou "eu" Vou apenas adicionar essa função calculateArea na classe SelectButtonWidget , só desta vez, será muito mais rápido do que criar uma classe e uma instância separadas para ela ". Isso torna o código difícil de ser seguido e, portanto, difícil de retomar após alguns dias de pausa, quando você não se lembra mais de todos os "aliases mentais" que acabou de fazer como "todo o código de desenho está no pacote drawables exceto o de desenhando um sprite que está na função updateState() da classe X do pacote Y ".

  • testes de unidade tornam o código muito mais legível do que comentários Você, em desespero, adicionou "páginas e páginas" de comentários ao seu código na esperança de que ele seja mais legível na próxima semana, quando você retomar seu projeto depois de voltar de suas férias? Eu sei que fiz. Nunca ajudou. Não só não tornou o código mais legível (algumas vezes diminuiu, pois não me ajudou a re-entender o que meu código estava fazendo enquanto ao mesmo tempo confundia meu código), mas estava levando MUITO hora de adicionar comentários em todos os lugares. Além disso, isso leva a problemas como "comento no nível de classe, método / nível de função, para cada linha de código, apenas para os mais importantes, etc etc". Investir todo esse tempo de escrever comentários em testes de unidade foi muito melhor. Os testes de unidade verificam algo, e você pode dizer prontamente o que está verificando e, portanto, o que o código deve fazer. Além disso, o enigma "onde colocá-los comentários" se foi. Unidade teste tudo. Comece com o que você acha que é mais importante, mas faça um objetivo de testar qualquer coisa.

  • testes de unidade apenas rock Não apenas seu código é mais legível e mais fácil de (re) entender, você não precisará nem (re) entender tudo quando voltar para isso, mas apenas as áreas que você deseja trabalhar atualmente. Dê uma olhada nos testes unitários das partes do código que você quer modificar agora para ver exatamente o que eles devem fazer. Em seguida, modifique-os, adicione mais testes de unidade, se necessário, e apenas execute novamente a bateria de testes da unidade inteira para ter certeza de que você não quebrou nada. Se todos eles passarem, você sabe instantaneamente que tudo está bem com o seu código, sem ter que passar por tudo isso à mão.

  • nunca otimize até o final No grande esquema de tudo, este ponto é discutível . Meu código será executado com mais rapidez se eu atrasar as otimizações o máximo possível ou se fizer isso de forma incremental enquanto implemento as coisas? Eu sinceramente não sei. Mas estritamente do ponto de vista da legibilidade do código e de como é fácil retomar um projeto depois de deixá-lo de lado por algum tempo, tenho certeza de que a prática de adiar a otimização até o final é o melhor caminho a percorrer. O que quero dizer é: desde que sua implementação não esteja próxima de ser feita, concentre-se em ter código modular legível e agradável. Uma vez que a funcionalidade esteja toda, depurada, unitária e funcionalmente testada, você pode começar a otimizar o código. Você terá uma boa versão do seu código, a qual está certo de que tudo funciona bem, é claro e fácil de ler, e ao qual você sempre pode retornar se a refatoração para fins de otimização lhe causar problemas.

por 05.11.2013 / 16:43
fonte
5

Apenas da perspectiva do produto puro, eu perguntaria qual é a razão para criar tais projetos? Qual é o objetivo final que você tenta alcançar?

Se você está fazendo isso por hobby, então eu diria que provavelmente você não tem motivação muito boa e razão para fazer esses projetos (ficar entediado etc.). E se não há um entendimento claro de por que alguém faz algumas coisas, é muito difícil esperar que isso aconteça por um longo período de tempo.

Se você está fazendo isso por dinheiro, eu pessoalmente recomendo seriamente dar uma olhada em seu modelo de negócio e argumentar que existem ineficiências que precisam ser superadas. Toda empresa ou produto precisa de um conjunto de pessoas diferentes para ter sucesso, existem bons exércitos de um homem, mas muito raramente.

Eu sinto que o problema aqui é mais geral e não pode ser resolvido apenas com a adaptação a novas ferramentas ou metodologias de desenvolvimento.

    
por 05.11.2013 / 14:14
fonte
3

Algo sobre tangente, mas acho que ter projetos pessoais do mesmo tipo que faço no trabalho (por exemplo, desenvolvedor Rails por dia, projetos pessoais Rails à noite) pode levar a um risco muito maior de esgotamento, fadiga e apenas total relutância em trabalhar nisso.

Concentrar-se nas partes que são diferentes (por exemplo, a interface do usuário ou o material do servidor) pode ajudar na motivação, em vez de "apenas mais do mesmo".

    
por 05.11.2013 / 14:39
fonte
1

Para mim, a solução não é começar grandes projetos. Em vez disso, faço um pequeno projeto e o desenvolvo.

Pode não ser publicável após o primeiro passo, mas em cada passo que tem algum estado conhecido, lista de melhorias futuras, pode ser alguns planos.

A motivação pode afetar quanto tempo eu gasto, mas o código e outras coisas (planos, bugs, recursos) devem ser mantidos em um estado que permita continuar facilmente após um atraso de pelo menos um mês (o atraso do ano provavelmente exigirá ).

    
por 05.11.2013 / 17:23
fonte
0

But then pride kicks in, and I don't feel at one with a project I haven't completed myself. Does this make sense?

Qual sua motivação para esses projetos? Diversão? Aprendendo? Então, talvez faça sentido, pois você poderia argumentar que aprenderia a trabalhar com os outros. Realmente fazendo uma coisa acabada ou objetivos de negócio? Então absolutamente não faz sentido. Encontre uma maneira de superar isso.

    
por 05.11.2013 / 21:28
fonte