Quais são algumas boas práticas antes de verificar o código-fonte? [fechadas]

Minha equipe usa o Team Foundation Server para controle de origem e hoje corrigi alguns bugs e teste de fumaça antes de fazer o check-in, mas esqueci de comentar algum código. (Esse código tornou a interface do usuário um pouco estranha.)

Quero saber quais são as boas práticas antes de fazer o check-in do código - não quero cometer esse tipo de erro novamente.

Uma coisa que eu tenho o hábito de fazer é sempre olhar as diferenças de todos os arquivos que estou prestes a fazer o check-in, imediatamente antes de fazer o check-in.

Você nunca deve fazer o check-in do código comentado. Se você possui um código que precisa ser comentado antes do check-in, está fazendo algo errado.

Quanto às regras:

1. Receber as últimas
2. Corrigir conflitos de mesclagem

3. Construir

   3.1 Corrigir erros de construção

4. Executar testes

   4.1 Corrigir testes quebrados

5. Vá para 1 (até que não haja nada novo para obter)

Somente faça check-in quando todas as etapas estiverem concluídas.

Veja a dança do check-in .

Outras boas práticas:

• Revise a lista de arquivos para fazer check-in para garantir que eles sejam os arquivos esperados.
• Revise as alterações para cada arquivo (exclusões / adições / diferenças)

Não estou tentando ser muito exigente aqui, mas a suposição nesta pergunta (e todas, exceto uma das respostas) se aplica principalmente ao VCS centralizado, como TFS, SVN, Perforce, etc. É
justo, é isso que o OP está usando.

Por outro lado, no entanto, ao usar o DVCS (como Mercurial e Git), você normalmente não deve esperar para fazer o check-in, e a maioria das coisas mencionadas nas respostas - como diffs, obter as últimas, mesclar etc. - não são necessárias . Mesmo coisas como revisões e testes de código são melhores após o check-in (embora talvez antes de enviar, dependendo ...)
A única exceção que vi aqui (até agora) é a associação a um item de trabalho. Claro, comentar sobre o check-in também é bom ...

Três coisas que não vi em outras respostas:

Incluir novos arquivos

• Procure novos arquivos que não fazem parte da sua lista de alterações
• Pode ser específico para SCMs como o Perforce - você precisa contar tudo o que está em sua alteração.

Reverter arquivos inalterados

• Eu odeio quando estou olhando para as mudanças de outras pessoas e há uma lista de alterações com nove arquivos, mas apenas três deles foram modificados.
• Também reverto arquivos com espaço em branco ou alterações sem sentido.

Verifique seu commit enviado

• Certifique-se de que a construção permaneça verde após o seu commit.
• Eu costumava ter uma segunda máquina que sincronizava, construía e executava após minhas confirmações, para que, se algo desse errado, eu pudesse entrar e consertar facilmente.

Duas coisas quando eu uso o Git:

Compromissos atômicos:

• Encene apenas alterações funcionais individuais para confirmação.
• Faça confirmações o menor possível. Facilite a correção, a reversão e a compreensão.
• Eu uso git add --patchpara dividir minha alteração em várias partes, se necessário.

Exibir diferenças ao resumir

• Eu sempre faço check-in git commit --verbosepara que eu possa ver um diff da minha alteração enquanto digito minha mensagem de confirmação. (Ou eu uso meu git-vim corrigido para mostrar a diferença.)
• Isso facilita muito as alterações e a descrição de todo o commit. Ocasionalmente, eu pego mudanças indesejadas nesta fase. A descrição de sua alteração ajuda você a pensar sobre isso.

Alguns itens de 'boas práticas' que eu aplico nos servidores da minha equipe são bastante simples. Primeiro, antes de fazer o check-in, você deve sempre obter as atualizações mais recentes e executar uma compilação local, para garantir que ninguém mais tenha verificado nada em que o seu código colidir. Além disso, cuide de qualquer conflito de código na sua máquina local, não no servidor. Depois que seu código, com o código mais recente baixado, tiver sido confirmado para compilar e funcionar corretamente, você estará pronto para a próxima etapa. Execute todos os testes automatizados e inicie o check-in para garantir que eles ainda funcionem corretamente. Então, só para ter certeza, obtenha as últimas novamente.

Como administrador do TFS, é possível aplicar comentários em todos os check-ins. Eu recomendaria sempre colocar comentários de check-in para o seu trabalho, independentemente de ter sido aplicado ou não. Se você tiver a opção de fazê-lo, imponha-o. Certifique-se de que os comentários sejam, no mínimo, um resumo geral do que você alterou desde a última vez em que inseriu seu código. Dessa forma, se algo der errado, você poderá examinar os check-ins e ver, grosso modo, o que foi alterado nesse check-in. Isso torna a depuração de uma compilação quebrada muito mais fácil.

Além disso, se você tiver privilégios de administrador do TFS, imponha builds contínuos nos check-ins (para garantir que todos saibam imediatamente se o check-in deles quebra alguma coisa) e você pode configurar o servidor para realizar um check-in fechado ( se o código com check-in interrompe a compilação, o servidor a rejeita) ou você pode simplesmente criar um bug e atribuí-lo a quem quebrou a compilação.

Existem algumas outras opções que você pode ativar ou desativar para manter tudo bem em ordem ou sugerir ao administrador do TFS que mantenha as coisas boas e limpas ... mas elas são em grande parte preferência

Pesquise e substitua palavrões ;-)

Se você estiver fazendo check-in no Windows, verifique se o seu código não possui esses caracteres ^ M invisíveis - os editores do UNIX geralmente fornecem erros / avisos por causa disso.

Tente também substituir abas - usuários diferentes acabam vendo tabstops de maneira diferente, alguns com 4 espaços, outros 8 e não são bons para a legibilidade do código.

Melhor abordagem O IMHO é fazer com que um script predefinido verifique seu código em relação às diretrizes de codificação da sua organização. Cargas de sistemas de controle de origem têm essa funcionalidade.

Na minha empresa, usamos revisões de check-in. Isso não precisa ser detalhado, mas apenas mostrar a alguém as diferenças na lista de alterações e conversar com elas às vezes destacará o erro de digitação que você perdeu nos testes.

Nosso servidor de controle de origem não permitirá que você faça check-in, a menos que anote o nome do revisor nos comentários (no formato! Iniciais, por exemplo! BW, se Bruce Wayne fez sua revisão). O revisor recebe um email informando que ajudou na revisão. Isso está aberto à exploração óbvia, mas parece funcionar muito bem.

Sempre que possível, gosto de associar um check-in a um item de trabalho. Isso fornece algumas informações contextuais sobre por que isso foi alterado, e não apenas o que foi alterado. O TFS possui um sistema de rastreamento de itens de trabalho bastante decente, portanto, isso é bastante trivial no momento do check-in.

(além de revisar as diferenças das minhas alterações)

Uma coisa pequena que faço é não fazer check-in de arquivos que realmente não foram alterados. Esses arquivos podem ter sido modificados inadvertidamente, ou podem estar envolvidos em refatorações que foram revertidas ou que foram discutidas.

Dessa forma, seu conjunto de alterações (associado a um item de trabalho) contém exatamente os arquivos necessários para satisfazer o item de trabalho.

Para combinar todas as respostas aqui e fornecer uma lista de verificação completa

1. [check-in / check-out] você não deve fazer check-in diretamente no fluxo em que outras pessoas estão trabalhando. Você deve ter uma estratégia de fluxo: por exemplo, por desenvolvedor, um fluxo no qual você possa fazer check-in e check-out independentemente sem incomodar os outros: seu trabalho será esteja seguro, mas em seu próprio fluxo de desenvolvimento, portanto [somente em seu próprio fluxo de desenvolvimento]. A cada verificação, você o associa a um registro de alterações, para que suas alterações sejam atômicas em relação àquelas chamadas de conjunto de alterações (para que você possa distribuir rfc / bugs individuais etc ... sem precisar entregar 'tudo').

2. [depois rebase com o fluxo da sua equipe] significa que você recebe as alterações de outras pessoas no seu próprio fluxo. Durante essa operação, você pode ver na caixa de diálogo de mesclagem todos os "diffs" e passar por eles ou ... se houver milhares e / ou você não estiver usando código, mas também, por exemplo, modelos de dados / projetos siebel etc. mesclagens não triviais, mesclas trivial-automáticas e triviais, a última categoria contém as difíceis. Lembre-se de que você ainda está trabalhando em seu próprio fluxo.

3. [rebase completo] Se estiver tudo bem, verifique todas as alterações que você acabou de receber do fluxo da equipe: seu próprio fluxo está atualizado

4. [entregar] agora entregue seu trabalho ao fluxo da equipe. Se você não deseja entregar tudo, também pode selecionar, por exemplo, 1 RFC específico com as versões específicas dos arquivos ou um conjunto de RFCs / defeitos resolvidos.

5. [entrega de teste] deve funcionar bem, mas como existe a chance de que alguém entregue alterações também: você pode testar se seu trabalho funciona com as alterações mais recentes no fluxo da equipe. Com as mesmas caixas de diálogo de mesclagem mostrando diferenças.

6. [entrega completa] conclua sua entrega e seu trabalho agora está no fluxo da equipe.

Para torná-lo mais complexo: Como ainda existe a chance de o trabalho que você entregou = ok, mas você já está trabalhando em uma versão adicional, você deve baseline sempre após a entrega e indicar qual baseline é a preferida para outros usuários. . Isso garante que outros desenvolvedores obtenham uma versão recomendada e não a versão mais recente no fluxo (se você estiver trabalhando nesse cenário). Essa também é uma verificação tripla, para que, mesmo que as versões mais recentes do fluxo da equipe sejam "ruins", elas ainda não sejam as que outras pessoas refazem ou visualizam, e seu gerente de configuração pode mesclar a versão anterior à próxima versão para desfazer sua entrega.

• a resposta da história acontece 2 vezes: nos passos 2 e 6
• a resposta de Oded na dança do check-in: idem, mas uma camada extra de entrega e rebase no check-in / check-out para garantir que você trabalhe isolado e os erros sempre possam ser facilmente eliminados, mesmo em estágios posteriores
• a resposta da guildsbounty respondida: o mais recente é a etapa 2. Para a compilação: realmente depende se você tem uma compilação ... no meu mundo, você tem entradas de modelos de dados, documentos do word, folhas de requisitos, dados de configuração da informatica, siebel, etc .., e sim também código java, código .net etc ... que todos devem se misturar. Portanto, não existe realmente "uma compilação" aqui, mas mais uma integração superior, dependendo se essa única, por exemplo, compilação a partir do seu "código" se integra com todo o restante, já que você não sabe ao certo se é uma integração e depende de nos ambientes de teste, pode ser necessário compilar coisas ou, em entregas mais altas, outra compilação, porque precisa de algo de outra equipe.
• a resposta da guildsbounty sobre comentários e requerida: acho que todos os ambientes nos quais você não possui integração de VERSÕES e alterações nos conjuntos de alterações (e tipo: defeitos, RFC, hotfi) não estão maduros. Eu acho que é um caos se você não puder, por exemplo, automatizar as notas de versão com a quantidade de bugs e rfcs enviados que podem ser clicados nas versões exatas que foram tocadas (uma vez que, por exemplo, a versão 1 e a versão 3 do hello.c podem muito bem ser entregues, mas a versão 2 não deveria ter sido entregue, porque esse material seria parte de uma versão posterior, mas alguns noob já o colocaram) (isso significa uma decisão manual SE você também quiser tirar a versão 3 do hello. c MAS tirar a versão 3 significa que você também precisa remover todas as outras versões tocadas por esse RFC / defeito, para que você possa ser capaz com facilidade e rapidez com uma ferramenta para remover a coisa completa) (mesmo que vários desenvolvedores trabalhem em partes de mesma RFC), mas pelo menos você precisa de coisas para decidir sobre isso etc ...). Documentação extra é sempre útil, mas ao associar conjuntos de alterações, você obtém o círculo completo: uma versão <- um conjunto de alterações <- itens de trabalho <- um ticket / rfc / defeito <- um requisito. Significado: você sabe quais requisitos são entregues total ou completamente: um requisito possui vários RFCs ou bugs ou qualquer outra coisa. O RFC possui vários itens de trabalho para várias pessoas. esse item de trabalho corresponde a um conjunto de alterações que existe em um conjunto de versões (por exemplo, versões 1 e 3 do hello.c no fluxo de integração que, é claro, NÃO são as versões 1,
• o comentário de luis.espinal: não quebre a compilação é verificado duas vezes em rebase e entrega ainda ... existem entregas mais altas para 'gerenciadores de lançamento e construtores' que devem ver conjuntos de alterações e linhas de base como informações. "Nunca trabalhe diretamente na ramificação principal" sim, a estrutura do fluxo pode ser grande ou simples, mas em essência: os desenvolvedores têm seu próprio fluxo, eles entregam para um fluxo de equipe que entrega para um fluxo de lançamento. -> para que as entregas de todas as equipes (por exemplo, equipe de documentação, equipe de requisitos, equipes de desenvolvimento,

No seu exemplo, você se esqueceu de comentar o código. Erros acontecem. O sistema de gerenciamento de configuração ao seu redor deve cuidar disso. Pode realmente ser que, por exemplo, milhares de mudanças ocorram e "compilações" e "integrações" ocorram em uma hierarquia de fluxos em diferentes servidores encadeados e processados ​​no tempo. Portanto, mesmo depois de cinco meses, seu código comentado é testado em um servidor de integração porque seu código precisa de integração com outros códigos e sistemas, ainda será possível executar atomicamente seu conjunto de alterações e continuar. Portanto, a melhor prática é mais ou menos em um nível superior. O design geral dos fluxos de gerenciamento de configuração deve cuidar disso. Para desenvolvedores individuais, a melhor prática é a validação / teste de unidade. Mas do quadro geral para "

Algumas das opções a seguir se aplicam mais que outras (ou de formas diferentes), dependendo do seu SCM, então aqui estão elas:

1. Não quebre a compilação - verifique apenas o código que é compilado.
2. Comente seus check-ins (e possivelmente seus check-outs, se o seu SCM lhe der essa opção.)
3. Não mantenha as coisas desmarcadas por longos períodos de tempo.
4. Faça check-in com frequência (várias vezes ao dia, se possível).
5. Rotular de forma significativa.
6. Rotule regularmente.
7. Nunca trabalhe diretamente na ramificação principal.
8. Toda liberação para produção deve ter seu próprio rótulo (e uma ramificação somente leitura da ramificação principal, se possível). Quando possível, faça o mesmo nas versões de teste do UAT / Integração / Pré-produção.
9. Você deve poder criar exatamente o que está em produção a partir do que está no seu SCM e de um rótulo.

NOTA : alguns dos itens acima parecem bastante óbvios, mas você não acreditaria em quantas pessoas realmente trabalham na ramificação principal ou faz alterações na produção primeiro e depois cria deltas manualmente para executar o controle de versão ... diretamente na ramificação principal. .. e com etiquetas. Doce como a bílis fermentada misturada com suco de axila não lavado ... sim, assim.

Tenha uma lista de verificação pessoal. Comece vazio quando você estragar, em uma entrada. Quando se tornar uma segunda natureza, remova-o da lista.

Execute os testes. Se eles passarem, verifique. Se você errar e alguma coisa passar nos testes, escreva um teste.

Fazemos o seguinte ...

1. Teste - Queremos ter certeza de que funciona. No mínimo, queremos saber que isso não quebra nada.

2. Revisão de código ou, pelo menos, uma verificação de amigos - Essa é uma ótima maneira de garantir que o conhecimento se espalhe e que as pessoas sejam atualizadas. Também ajuda a detectar bugs antes de fazer o check-in.

3. Enviar um aviso prévio - Um aviso prévio é enviado ao grupo antes do check-in. O objetivo não é apenas permitir que outras pessoas saibam quais arquivos ou áreas estão sendo alteradas, mas também os avisa (eles devem optar por tomar conhecimento), caso se espere que essas mudanças os afetem.

4. Algumas horas após o envio do aviso prévio, o check-in é realizado e o grupo é informado por e-mail. Todos no grupo podem saber quando o trabalho específico de um bug ou recurso é concluído.

5. Uma cópia do aviso de check-in é colada no registro de correção associado ao bug ou recurso. Ao pesquisar os registros, achamos muito útil ter uma idéia do que a correção / recurso implicava.

Execute seus testes de unidade em que você está trabalhando tão diligentemente. Verde é bom.

Verifique se seu código está formatado corretamente (por exemplo, para Java: selecione seu código e pressione Ctrl-Shift-F no Eclipse). Mas tenha cuidado ao fazer o mesmo para um documento inteiro.

Sempre, sempre, sempre , verifique se as alterações que você fez não quebram a compilação. Especialmente pequenas mudanças que podem parecer triviais.

Uma vez eu fiz uma alteração muito pequena que não achei que causaria nenhum problema antes de deixar o trabalho no fim de semana. Com certeza, essa pequena alteração quebrou a compilação e nenhuma execução noturna de teste foi executada para o nosso projeto. O chefe de perguntas e respostas não ficou muito feliz com isso, e com razão.

Procure por partes de suas alterações que possam ser inseridas como unidades independentes.

Muitas vezes, quando tenho uma correção ou aprimoramento funcional no código, há algumas alterações. Alguns deles são específicos para a mudança de comportamento que estou buscando; outros são refatorações que fiz para tornar essa mudança mais limpa.

Eu prefiro verificar cada refatoração separadamente, com sua própria descrição de alteração, assim:

REFACTORING: Renomeie X para Y

X fazia sentido antes porque ... mas agora deve ser Y. Isso está relacionado ao trabalho para a edição # 9.

Então, uma vez que cada boa refatoração é registrada, a mudança final de comportamento geralmente é trivial.

Além disso, algumas alterações afetam muitas linhas de código, mas não são muito interessantes, enquanto outras são muito localizadas, mas têm um impacto importante. Se essas alterações forem verificadas juntas, pode ser difícil ler as diferenças. Então, eu os mantenho separados.

Mais tarde, quando alguém está lendo o histórico de mudanças, é óbvio como as coisas chegaram ao estado atual das coisas e por que elas são assim. Também é trivial desfazer minha mudança de comportamento porque ela não está envolvida com muitas outras edições.

Faça o que faria ao devolver algo emprestado de alguém. Verifique se está limpo e em boa forma. Se você fez uma bagunça, limpe antes de devolver o código ao proprietário (na maioria dos casos, ao seu empregador).

Eu mantenho um repositório local de hg para o meu trabalho.

• Sempre que faço o check-in, olho o diff e certifico-me de que todas as alterações sejam aceitáveis.
• Eu tento observar o principal recurso do check-in.
• Eu tento manter cada tamanho de confirmação em um recurso principal.

Não reivindico que sejam os melhores, mas eles funcionam para mim.

Quando escrevo um código que sei que não deve ser registrado, adiciono uma linha antes dele contendo "// TEMP:" e depois com "// END TEMP". Isso, juntamente com o diff antes do check-in, promete que eu não irei verificar esse código por engano.

Teste completamente tudo o que você adicionou ou alterou. Tente todos os casos possíveis em que você possa pensar. Não deixe o teste para o controle de qualidade. Se eu tivesse um sanduíche para cada vez que fiz algumas pequenas alterações e tentei alguns casos de teste apenas para estar do lado seguro, e imediatamente vi problemas, eu teria muitos sanduíches. Costumo dizer em voz alta para mim mesma: "Estou muito feliz por ter tentado isso ..."

Você diz que a interface do usuário ficou estranha após a alteração. Se você tivesse executado o programa e analisado a interface do usuário antes de fazer o check-in, teria notado o problema?