Considero essa a regra de ouro do controle de fontes:
Faça o check-in antecipadamente, faça o check-in com frequência.
Os desenvolvedores que trabalham por longos períodos – e por longo Quero dizer, mais de um dia – sem verificar nada no controle de origem – estão se preparando para sérias dores de cabeça de integração no futuro. Damon Poole concorda:
Os desenvolvedores geralmente adiam o check-in. Eles o adiam porque não querem afetar outras pessoas muito cedo e não querem ser culpados por interromper a compilação. Mas isso leva a outros problemas, como a perda de trabalho ou a impossibilidade de voltar a versões anteriores.
Minha regra geral é “fazer check-in cedo e com frequência”, mas com a ressalva de que o senhor tem acesso ao controle de versão privado. Se um check-in for imediatamente visível para outros usuários, o senhor corre o risco de introduzir alterações imaturas e/ou quebrar a compilação.
Prefiro que pequenos fragmentos sejam verificados periodicamente do que passar longos períodos sem saber o que meus colegas de trabalho estão escrevendo. No que me diz respeito, se o código não for verificado no controle de origem, ele não existe. Suponho que essa seja mais uma forma de Não fique no escuro; o código é invisível até que exista no repositório de alguma forma.
Não estou propondo que os desenvolvedores verifiquem o código quebrado, mas também defendo que há uma grande diferença entre quebrado código e incompleto incompleto. Não é possível, talvez até desejável, escrever seu código e estruturar sua árvore de controle de código-fonte de forma que o senhor possa verificar seu código periodicamente à medida que o estiver criando? Prefiro muito mais ter stubs vazios e esqueletos básicos de API do que nada. Posso integrar meu código aos stubs. Posso fazer a revisão do código em stubs. Posso até ajudar o senhor a criar os stubs!
Mas quando não há nada no controle de código-fonte por dias ou semanas e, de repente, uma grande quantidade de código cai na porta da equipe, nada disso é possível.
Os desenvolvedores que nem sequer considerariam a adoção da tecnologia antiga método em cascata de desenvolvimento de software, de alguma forma não têm problemas em adotar essencialmente o mesmo modelo quando se trata de seus hábitos de controle de código-fonte.
Talvez o que precisemos seja de um modelo de acreção de software. Comece com um pequeno fragmento de código que não faz quase nada. Veja o lado positivo: um código que não faz nada não pode ter muitos bugs! Teste-o e faça o check-in. Adicione mais um pequeno recurso. Teste esse recurso e faça o check-in. Adicione outro pequeno recurso. Teste quee verifique. Diariamente. De hora em hora, inclusive. O senhor sempre tem um software funcional. Ele pode não fazer muita coisa, mas funciona. E a cada check-in, ele se torna infinitamente mais funcional.
Se o senhor aprender a fazer check-in antecipadamente e com frequência, terá tempo suficiente para feedback, integração e revisão ao longo do caminho. E, quem sabe, o senhor poderá até mesmo conseguir acrescentar aquela pérola de código final que estava procurando.