Quais são as melhores práticas ao alternar entre projetos / voltar a projetos com frequência?

A natureza do meu trabalho é que eu tenho que alternar entre projetos a cada poucas semanas. Acho que um dos maiores impedimentos à minha produtividade é o tempo de recuperação de todos os trechos de código relevantes "de volta à minha cabeça" novamente depois de não vê-lo por um período. Isso acontece em menor e maior extensão para pausas mais breves / pausas mais longas.

Obviamente, um bom design, documentação, comentários e estrutura física ajudam nisso (para não mencionar a alternância de projetos com a menor frequência possível). Mas estou me perguntando se existem práticas / ferramentas que posso estar perdendo. Quais são as suas práticas específicas para melhorar isso?

Também troco de projetos diferentes (técnicos e não técnicos) com frequência. Organização ou "facilidade de recuperação" tem sido fundamental para mim. Antes de sair de um projeto, certifique-se de colocar as coisas em ordem, para que seja fácil recuperar o contexto em minha cabeça. Para mim, isso significa colocar todas as coisas relevantes (marcadores, arquivos, documentos, e-mails etc.) ou links em uma pasta para que eu não precise procurar fontes de informação.

Uma coisa que comecei a fazer recentemente é usar uma máquina virtual para cada projeto grande. Quando preciso mudar para outro projeto, mantenho todos os aplicativos relevantes abertos e suspendo a máquina virtual. Portanto, quando precisar voltar ao projeto, posso iniciar a VM e ela me apresentará todas as informações já exibidas na tela.

Algumas coisas que ajudam:

• Otimize ao máximo o seu código para facilitar a leitura e a clareza.
• Deixe sugestões e dicas para você no código, na forma de comentários.
• Siga KISS e DRY.
• Seja consistente, dentro de cada projeto e entre projetos.
• Seja religioso sobre refatoração.
• Documente tudo; considere o seu eu futuro uma pessoa diferente, sem nenhuma maneira de perguntar ao seu eu atual.
• Evite código "inteligente" que interrompa seu IDE / editor.
• Use o controle de origem, com mensagens de confirmação que informam exatamente onde você deixou as coisas; identifique as versões que você considera entregáveis ​​e mire por curtos períodos entre as versões entregáveis.
• Se você escolher a linguagem de programação, escolha uma que possa ajudá-lo a fazer as coisas corretamente.
• Essa é uma questão de gosto pessoal, mas funciona bem para mim; portanto, eu a recomendarei de qualquer maneira: mantenha um documento de texto simples e conciso contendo as tarefas futuras e atualize-o sempre que terminar uma tarefa. Use também este documento para notas em nível de design que não cabem nos comentários do código. Basicamente, este documento de texto deve conter todo o seu design, apenas na forma condensada (informações suficientes para você entender, mas suficientemente curto para voltar à sela em 10 minutos). Um rastreador de bugs também funciona, mas o documento de texto tem várias vantagens: obriga a cortar o cotão e a se concentrar nas coisas relevantes, e pode estar comprometido com o controle de origem ao lado do código real, o que significa que está naturalmente vinculado a Versões SCM.

Faço algo semelhante ao que RonE faz.

Ter um projeto fácil de ler, com um bom design ajuda, mas antes de sair de um projeto, verifique se todo o contexto e as informações que você tem em sua cabeça estão escritos ou armazenados em algum lugar. Por exemplo, notas sobre as funções da biblioteca de terceiros que você estava usando, se era uma nova que você nunca usou antes. Eu sempre escrevo notas sobre as coisas que aprendo ou penso, em minhas próprias palavras.

Além disso, o que eu acho mais importante para escrever em um arquivo é se você escrever comentários TODO no seu código, copiar o último em que estava trabalhando e colá-lo em um novo arquivo de texto e chamá-lo TODO. Escreva nele informações de contexto sobre onde a tag TODO pertence e escreva o que você tinha em mente ou o que acha que gostaria de saber sobre essa tarefa.

Duas coisas foram fundamentais para mim: consistência e especificação.

Consistência é a chave para o código. Não preciso me lembrar onde está tudo e como tudo interage se eu puder extrapolar o que eu teria feito. Se é um projeto com outras pessoas que se torna mais problemático, mas os padrões de código ajudam bastante. Saber o que é algo olhando para ele e fazendo algumas suposições seguras diminui um pouco o tempo de embarque.

A especificação é mais útil para o projeto. Pelo menos para mim, acho que tenho a tendência de esquecer algumas das nuances do design de produto após um intervalo. Ou quando eu volto, é por causa dessa ideia incrível que rapidamente aparece assustadoramente no projeto. Se o seu projeto não tiver bons requisitos (em uma especificação em cascata ou em uma lista de pendências de produtos), você precisará basicamente reinventá-los sempre que voltar ao projeto. Quase todas as práticas recomendadas para desenvolvimento de software ainda são práticas recomendadas quando se trata de um projeto pessoal; não economize neles.

a IMO principal é uma API inteligente de todos os seus projetos. O upload do código para um repositório como o GIT ou outros permite que você "viaje no tempo" através de suas confirmações no código.

Como presto suporte ao desenvolvimento e à produção de vários clientes, troco de projeto várias vezes por dia. As duas coisas que mais me ajudam nunca saem de um projeto até que eu salvei tudo (e me comprometa com uma ramificação local, se não estiver no estado, quero colocá-la de volta na ramificação principal do meu controle de origem) e eu definir um ponto de interrupção no local de onde eu parei. Ser capaz de encontrar rapidamente a linha exata de onde parei me ajuda a voltar ao andamento de um projeto muito mais rapidamente. Também costumo criar uma lista de tarefas para cada projeto principal e marcar as coisas à medida que são concluídas. Portanto, uma rápida revisão me diz onde estou e me lembra o meu processo de raciocínio no projeto. Geralmente, também escrevo uma nota rápida para mim mesma sobre as coisas em que estava pensando, mas ainda não tinha feito se necessário (coisas como: