Check-in do código “comentado” [fechado]

Ok, aqui está algo que causou algum atrito no meu trabalho atual e eu realmente não esperava. O desenvolvimento de software interno organizado é um novo conceito aqui e eu fiz um primeiro rascunho de algumas diretrizes de codificação.

Propus que o código "comentado" nunca deve ser verificado no repositório. Afirmei isso porque o repositório mantém um histórico completo dos arquivos. Se você estiver removendo o código funcional, remova-o completamente. O repositório mantém suas alterações para que seja fácil ver o que foi alterado.

Isso causou certo atrito, pois outro desenvolvedor acredita que seguir esse caminho é muito restritivo. Este desenvolvedor gostaria de poder comentar algum código no qual está trabalhando, mas está incompleto. Este código, então, nunca teria sido verificado antes e não seria salvo em nenhum lugar. Vamos usar o TFS, então sugeri que arquivar as alterações seria a solução mais correta. No entanto, ele não foi aceito porque ele gostaria de poder fazer o check-in de alterações parciais que podem ou não ser implantadas.

Queremos eventualmente chegar a um ponto em que estejamos aproveitando ao máximo a integração contínua e implantando automaticamente em um servidor web de desenvolvimento. Atualmente não existe uma versão de desenvolvimento de servidores web ou servidores de banco de dados, mas tudo será alterado em breve.

Enfim, quais são seus pensamentos? Você acredita que o código "comentado" é útil ter no repositório?

Estou muito interessado em ouvir outras pessoas sobre este assunto.

Edit: Para fins de clareza, não usamos ramos privados. Se o fizéssemos, eu diria para fazer o que quiser com seu branch privado, mas nunca mesclar código comentado com o tronco ou qualquer branch compartilhado.

Editar: Não há nenhuma razão válida para não usarmos ramos privados ou por usuário. Não é um conceito do qual eu discordo. Nós apenas não configuramos dessa forma ainda. Talvez esse seja o meio-termo eventual. Por enquanto, usamos prateleiras TFS.

Pode haver outras pessoas com experiências diferentes, mas, no meu caso, verificar o código incompleto é uma ideia horrível, ponto final.

Aqui estão os princípios que aprendi e tento seguir:

• Faça check-in com frequência - pelo menos uma vez, mas de preferência muitas vezes por dia
• Verifique apenas a funcionalidade completa
• Se o primeiro e o segundo conflito (por exemplo, leva mais de um dia para fazer a funcionalidade funcionar), a tarefa é muito grande - divida-a em tarefas menores que podem ser concluídas.

Isso significa:

• O código comentado nunca deve ser verificado, pois não é funcional
• Comentar não é uma estratégia de arquivamento válida, portanto, seja um código que ainda não foi concluído ou que está sendo retirado, comentar e verificar não faz nenhum sentido.

Então, em resumo, NÃO! Se o código não estiver pronto para ir para o próximo estágio (o que for para você: IntTest / QA / UAT / PreProd / Prod), ele não deve ser confirmado para um tronco ou branch de multi-desenvolvedor. Período.

Edit: Depois de ler as outras respostas e comentários, acrescentarei que não acho que seja necessariamente uma boa ideia banir o código comentado (não tenho certeza de como você aplicaria isso de qualquer maneira). O que direi é que você deve fazer com que todos em sua equipe aceitem a filosofia que descrevi acima. A equipe em que trabalho o abraça de todo o coração. Como resultado, o controle de origem é um membro da equipe sem fricção, que nos ajuda a fazer nosso trabalho.

Pessoas que não adotam essa filosofia geralmente causam janelas quebradas e muitas vezes ficam frustradas com o controle de origem. Eles vêem isso como um mal necessário, na melhor das hipóteses, e algo a evitar, na pior; o que leva a check-ins pouco frequentes, o que significa que os changesets são enormes e difíceis de mesclar, o que aumenta a frustração, torna os check-ins algo a serem evitados ainda mais, etc. Em última análise, isso é uma coisa de atitude, não realmente uma coisa de processo. É fácil colocar barreiras mentais contra ele; é fácil encontrar motivos pelos quais não funcionará, assim como é fácil encontrar motivos para não fazer dieta se você realmente não quiser. Mas quando as pessoas não querem fazê-lo e estão empenhados em mudar seus hábitos, os resultados são dramáticos. O ônus de vendê-lo com eficácia está sobre você.

"Nunca" raramente é uma boa palavra para usar em diretrizes.

Seu colega tem um ótimo exemplo de quando pode ser apropriado fazer o check-in do código comentado: quando está incompleto e pode quebrar o aplicativo se o check-in estiver ativo.

Para a maior parte, comentar o código morto é desnecessário em um sistema bem gerenciado e controlado por mudanças. Mas nem todo código comentado está "morto".

O código comentado nunca deve ser verificado com o propósito de manter o histórico. Esse é o ponto de controle de origem.

As pessoas estão falando muito de ideais aqui. Talvez ao contrário de todo mundo, eu tenha que trabalhar em vários projetos com várias interrupções com o "mundo real" ocasionalmente interrompido meu dia de trabalho.

Às vezes, a realidade é que preciso fazer o check-in do código parcialmente completo. É o risco de perder o código ou o código incompleto do check-in. Nem sempre posso me dar ao luxo de "terminar" uma tarefa, por menor que seja. Mas eu não desligar meu laptop a partir da rede sem verificar-in todo o código.

Se necessário, criarei meu próprio branch de trabalho para confirmar alterações parciais.

Um caso em que deixo o código comentado:

// This approach doesn't work
// Blah, blah, blah

quando essa é a abordagem óbvia para o problema, mas contém algumas falhas sutis. Claro, o repositório teria, mas o repositório não alertaria ninguém no futuro para não seguir por esse caminho.

Eu certamente desencorajaria, fortemente, verificar o código comentado. Eu não iria, no entanto, bani-lo de forma absoluta. Às vezes (se raramente) é apropriado verificar o código comentado no controle de origem. Dizer "nunca faça isso" é muito restritivo.

Acho que todos concordamos com estes pontos:

• Nunca verifique o código morto no controle de origem
• Nunca verifique o código quebrado (não funcionando) no controle de origem, pelo menos nunca no tronco e apenas muito raramente em uma filial privada, YMMV
• Se você comentou temporariamente algo ou quebrou algo para fins de depuração, não faça o check-in do código até restaurá-lo à forma correta

Alguns estão dizendo que há outras categorias, como código removido temporariamente ou uma melhoria incremental, mas incompleta, que inclui uma pequena quantidade de código comentado como documentação do que vem a seguir, ou um trecho muito curto (idealmente de 1 linha) de comentado nosso código mostrando algo que deveria nunca ser adicionado novamente. Código comentado SEMPRE deve ser acompanhado por um comentário que diga por que ele foi comentado (e não apenas excluído) e fornece a vida útil esperada do código comentado. Por exemplo, "O código a seguir faz mais mal do que bem, por isso está comentado, mas precisa ser substituído antes do lançamento XXX."

Um comentário como o acima é apropriado se você estiver entregando um hotfix para interromper o sangramento de um cliente e não tiver a oportunidade imediata de encontrar a solução definitiva. Depois de entregar o hotfix, o código comentado é um lembrete de que você ainda tem algo que precisa ser consertado.

Quando faço check-in do código comentado? Um exemplo é quando estou removendo provisoriamente algo que acho que há uma grande probabilidade de ter que ser adicionado novamente em um futuro próximo, de alguma forma. O código comentado existe para servir como um lembrete direto de que está incompleto. Claro, a versão antiga está no controle de origem e você pode apenas usar um comentário FIXME como um sinalizador de que algo mais é necessário. No entanto, às vezes (se não frequentemente) o código é o melhor comentário.

Além disso, quando um bug é corrigido removendo uma linha (ou mais raramente, duas linhas) de código, às vezes apenas comento a linha com um comentário para nunca reativar o código com um motivo. Esse tipo de comentário é claro, direto e conciso.

Rex M disse: 1) Verifique apenas a funcionalidade completa, 2) [Se] a tarefa for muito grande - divida-a em tarefas menores que podem ser concluídas.

Em resposta: Sim, este é o ideal. Às vezes, nenhuma das opções é alcançável quando você está trabalhando no código de produção e tem um problema crítico imediato para corrigir. Às vezes, para concluir uma tarefa, você precisa colocar uma versão do código no campo por um tempo. Isso é especialmente verdadeiro para alterações no código de coleta de dados, quando você está tentando encontrar a causa raiz de um problema.

Para a instância específica que está sendo questionada na questão mais geral ... contanto que o desenvolvedor esteja verificando o código comentado em um branch privado que ninguém verá, exceto aquele desenvolvedor (e talvez alguém com quem o desenvolvedor esteja colaborando), faz pouco mal. Mas esse desenvolvedor deve (quase) nunca entregar tal código no tronco ou equivalente. O tronco deve sempre ser construído e sempre funcionar. Entregar código inacabado ao tronco é quase sempre uma ideia muito ruim. Se você permitir que um desenvolvedor verifique o código inacabado ou temporário em um branch privado, você terá que contar com o desenvolvedor para não esquecer de limpar o código antes de entregá-lo no tronco.

Para esclarecer em resposta a comentários a outras respostas, se o código for comentado e verificado, minha expectativa de que o código funcionará se não for comentado diminui com o tempo que o código foi comentado. Obviamente, as ferramentas de refatoração nem sempre incluirão comentários em sua refatoração. Quase sempre, se coloco o código comentado na produção, o código está lá para servir como um comentário refinado, algo mais específico do que a prosa, de que algo precisa ser feito lá. Não é algo que deveria ter uma vida longa.

Finalmente, se você puder encontrar código comentado em cada arquivo de origem, então algo está errado. Entregar código comentado no tronco por qualquer motivo deve ser um evento raro. Se isso ocorrer com frequência, torna-se desordenado e perde seu valor.

Acho que nunca é uma condição muito forte.

Eu costumo comentar, fazer check-in, executar os testes, pensar e remover comentários após o próximo lançamento.

Em geral, fazer check-in do código comentado é errado, pois cria confusão entre aqueles que não são o autor original e precisam ler ou corrigir o código. Em qualquer caso, o autor original muitas vezes acaba confuso sobre o código depois de 3 meses.

Eu defendo a crença de que o código pertence à empresa, ou equipe, e que é sua responsabilidade facilitar as coisas para seus colegas. Verificar o código comentado sem também adicionar um comentário sobre por que ele está sendo retido é o mesmo que dizer:

Não me importo se você ficar confuso sobre por que essas coisas estão aqui. Minhas necessidades são mais importantes que as suas, por isso fiz isso. Não sinto necessidade de justificar a você, ou a qualquer outra pessoa, por que fiz isso.

Para mim, o código comentado é normalmente visto como um sinal de desrespeito de um colega de trabalho menos pensativo.

Eu concordo amplamente com o princípio de que o código comentado não deve ser verificado. O sistema de controle de origem é um recurso compartilhado e seu colega está, até certo ponto, usando-o como seu bloco de notas pessoal. Isso não é muito atencioso com os outros usuários, especialmente se você subscrever a ideia de propriedade compartilhada da base de código.

O próximo desenvolvedor a ver aquele código comentado não teria ideia de que é um trabalho em andamento. Ele está livre para mudar isso? É um código morto? Ele não sabe.

Se a alteração do seu colega não estiver em um estado em que possa ser verificada, ele precisa concluí-la e / ou aprender a fazer alterações menores e incrementais.

"Verificando mudanças parciais que podem ou não ser implantadas" - presumivelmente isso também significa que podem ou não ser testadas? Essa é uma ladeira escorregadia para uma base de código muito pegajosa.

Quando você precisa adicionar um pequeno recurso ou correção de bug como AGORA, dentro dos próximos 3 minutos e você tem que consertar um arquivo que tem algum código desenvolvido pela metade, eu diria que está tudo bem, necessidades práticas prevalecem sobre ideais pragmáticos no campo de batalha.

Isso mostra uma diferença fundamental em duas escolas de pensamento: aqueles que só verificam o código em funcionamento com o qual estão satisfeitos e sentem que vale a pena salvar, e aqueles que verificam seu trabalho para que o controle de revisão esteja lá para protegê-los contra a perda de dados.

Eu caracterizaria o último como "aqueles que gostam de usar seu sistema de controle de revisão como um backup de fita do pobre", mas isso seria me dar uma dica sobre em que campo estou. :-)

Meu palpite é que você é do campo do "código bom" e ele do campo do "código de trabalho".

[EDITAR]

Pelos comentários, sim, acertei.

Como eu disse, estou com você, mas pelo que posso dizer, essa é uma opinião minoritária, tanto aqui no stackoverflow quanto onde trabalho. Como tal, não acho que você possa realmente consagrar isso em seus padrões de desenvolvimento como a única maneira de operar. Não se você quiser que os padrões sejam seguidos de qualquer maneira. Uma coisa que um bom líder sabe é nunca dar uma ordem que sabe que não será seguida.

btw: Bons editores ajudarão a manter as versões antigas. Por exemplo, no Emacs eu defini as versões antigas e as versões antigas mantidas como 10, o que significa que ele mantém as últimas 10 salvações dos meus arquivos. Você pode considerar isso como uma forma de ajudar em seu argumento contra a multidão de controle de revisão como backup. No entanto, você nunca vai ganhar a discussão.

Na minha experiência, as opções do desenvolvedor são código comentado

Às vezes, novos back-ends são construídos em paralelo, com as chaves de ativação comentadas no controle de origem.

Algum recurso bizarro de que precisamos uma vez na lua azul, mas nenhum cliente vai precisar, é frequentemente implementado dessa forma. Essas coisas geralmente apresentam um alto risco de ignorar a segurança ou a integridade dos dados, então não as queremos ativas fora do desenvolvimento. Exigir que um desenvolvedor o usasse para descomentar o código primeiro parece ser a maneira mais fácil de obtê-lo.

Outro motivo para o check-in do código comentado:

Você está modificando o código existente e encontrou um bug sutil, fácil de ignorar e talvez até pareça correto à primeira vista. Comente, coloque a correção em seu lugar e adicione comentários sobre o que está acontecendo e por que foi modificado. Verifique isso para que seus comentários sobre a correção estejam no repositório.

Talvez a verdadeira questão aqui seja se os desenvolvedores devem ter permissão para verificar o código incompleto?

Esta prática parece ser contraditória ao seu objetivo declarado de implementar integração contínua.

Depende. Se estiver sendo deixado lá para fins de ilustração, talvez. Pode ser útil durante a refatoração. Caso contrário, e geralmente, não. Além disso, comentar código inacabado está sujeito a falhas e desperdício de tempo. Melhor ele quebrar o código em partes menores e fazer o check-in quando funcionarem.

Minha visão: se os desenvolvedores estão trabalhando em seus próprios branches, ou em sua própria área de sandbox, eles devem ser capazes de fazer o check-in o que quiserem. É quando eles verificam o código em um branch compartilhado (um branch de recurso, ou um branch de equipe ou, claro, MAIN / trunk) que o código deve ser o mais puro possível (sem código comentado, sem mais FIXMEs, etc).

Acho que "Nunca" é uma regra muito forte. Eu votaria para deixar alguma margem de manobra pessoal em torno de se as pessoas verificam o código comentado no repositório. O objetivo final deve ser a produtividade do programador, não "um repositório puro".

Para equilibrar essa frouxidão, certifique-se de que todos saibam que o código comentado tem uma data de validade. Qualquer pessoa pode excluir o código comentado se ele já existir por uma semana inteira e nunca estiver ativo. (Substitua "uma semana" pelo que achar melhor para você.) Dessa forma, você se reserva o direito de eliminar a desordem quando a vir, sem interferir muito diretamente no estilo pessoal das pessoas.

Eu concordo totalmente que o código comentado não deve ser verificado no repositório, é para isso que serve o controle do código-fonte.

Em minha experiência, quando um programador verifica o código comentado, é porque ele não tem certeza de qual é a solução certa e fica mais feliz em deixar a solução alternativa no código-fonte na esperança de que outra pessoa tome essa decisão.

Acho que isso complica o código e torna difícil de ler.

Não tenho nenhum problema em verificar o código pela metade (para que você obtenha o benefício do controle de origem) que não é chamado pelo sistema ativo. Meu problema é encontrar seções de código comentado sem nenhuma explicação. O dilema resultou na exclusão do código.

Acho que o check-in do código comentado em um sistema de controle de código-fonte deve ser feito com extrema cautela, especialmente se as tags de linguagem usadas para comentar o código forem escritas por blocos, ou seja:

/* My commented code start here
My commented code line 1
My commented code line 2
*/

Em vez de uma linha individual, como:

// My commented code start here
// My commented code line 1
// My commented code line 2

(Você entendeu a ideia)

O motivo pelo qual eu usaria muito cuidado é que, dependendo da tecnologia, você deve ter muito cuidado com a ferramenta diff / merge que está usando. Com certo sistema de controle de código-fonte e certa linguagem, a ferramenta diff / merge pode ser facilmente confundida. O diff / merge padrão do ClearCase, por exemplo, é notoriamente ruim para mesclar arquivos .xml.

Se acontecer de as linhas dos blocos de comentários não se fundirem corretamente, pronto, seu código se tornará ativo no sistema quando não deveria. Se o código estiver incompleto e quebrar a compilação, isso é provavelmente o menos maléfico, pois você o verá imediatamente.

Mas se o código passar na construção, ele pode se tornar ativo quando não deveria estar lá e, da perspectiva do CM, isso pode ser um cenário de pesadelo. O controle de qualidade geralmente testa o que deveria estar lá, eles não testam o código que não deveria estar lá, então seu código pode acabar em produção antes que você perceba, e quando for realizado, o código estará lá quando for não deveria, o custo de manutenção se multiplicou muitas vezes (já que o "bug" será descoberto na produção ou pelo cliente, pior lugar ou hora de todos os tempos).

A ideia de permitir que o histórico de controle da fonte ilustre a "maneira antiga" de fazer algo em vez de comentá-la e verificar o comentário junto com uma explicação é uma boa ideia em teoria.

No mundo real, no entanto, ninguém nunca olha o histórico de controle de origem nos arquivos em que está trabalhando, a menos que seja parte de um processo de revisão oficial de algum tipo (feito apenas periodicamente) ou se algo não funcionar, e o desenvolvedor não consigo descobrir o porquê.

Mesmo assim, olhar para trás mais do que cerca de 3 versões basicamente nunca acontece.

Em parte, isso ocorre porque os sistemas de controle de origem não facilitam esse tipo de revisão casual. Normalmente você tem que verificar uma versão antiga ou diff contra uma versão antiga, você apenas vê duas versões, e não há uma boa visão concisa do que mudou que pode lhe dar uma ideia rápida do que mudou.

Em parte, é a combinação da natureza humana e das necessidades da equipe. Se eu tenho que consertar algo, e posso consertar em algumas horas, não é provável que eu gaste uma hora investigando versões antigas do código que não estão "ativas" em um mês (que, com cada desenvolvedor verificando em muitas vezes significa voltar muitas revisões), a menos que eu saiba que há algo lá (como se eu me lembrasse de uma discussão sobre mudar algo relacionado ao que estou fazendo agora).

Se o código for excluído e devolvido, então, para todos os intentos e propósitos (exceto para o propósito limitado de uma reversão completa), ele deixará de existir. Sim, ele está lá para fins de backup, mas sem uma pessoa no papel de bibliotecário de código, ele vai se perder.

Minha árvore de controle de origem em meu projeto atual tem cerca de 10 semanas, em uma equipe de apenas cerca de 4 engenheiros, e há cerca de 200 listas de alterações confirmadas. Sei que minha equipe não faz um trabalho tão bom quanto deveria de check-in assim que há algo sólido e pronto para começar. Isso torna bastante difícil confiar na leitura do histórico do código para cada parte do código para capturar todas as alterações importantes.

No momento, estou trabalhando em um projeto em modo de desenvolvimento inicial, que é muito diferente de um projeto em modo de manutenção. Muitas das mesmas ferramentas são usadas em ambos os ambientes, mas as necessidades diferem um pouco. Por exemplo, muitas vezes há uma tarefa que exige que dois ou mais engenheiros trabalhem juntos para construir algo (digamos, um cliente e um servidor de algum tipo).

Se estou escrevendo o servidor, posso escrever o código para a interface de rascunho que o cliente usará e verificá-la como completamente não funcional, para que o engenheiro que está escrevendo o cliente possa atualizar. Isso ocorre porque temos a política que diz que a única maneira de enviar código de um engenheiro para outro é por meio do sistema de controle de origem.

Se a tarefa vai demorar muito, talvez valha a pena criar um branch para nós dois trabalharmos (embora isso seja contra a política em minha organização - engenheiros e líderes de equipe individuais não têm as permissões necessárias em servidor de controle de origem). Em última análise, é uma troca, e é por isso que tentamos não instituir muitas políticas do tipo "sempre" ou "nunca".

Eu provavelmente responderia a essa política de nenhum código comentado dizendo que ela era um pouco ingênua. Bem intencionado, talvez, mas no final das contas improvável de atingir seu propósito.

Embora ver este post vá fazer você voltar ao código que verifiquei na semana passada e remover a parte comentada que nunca foi final (embora funcionou) e também provavelmente nunca será desejada novamente.

Acho que o código comentado é considerado "desperdício".

Presumo que você esteja trabalhando em um ambiente de equipe. Se você estiver trabalhando por conta própria e comentar o código com um 'todo' e voltar a ele, então é diferente. Mas em um ambiente de equipe, você pode assumir com segurança que, uma vez que o código comentado seja verificado, ele estará lá para ficar e provavelmente causará mais dor do que satisfação.

Se você estiver fazendo revisões de código de pares, isso pode responder à sua pergunta. Se outro desenvolvedor revisar seu código e disser "por que esse código comentado está tentando fazer 'blá'", então seu código falhou na revisão de código e você não deveria verificá-lo de qualquer maneira.

O código comentado apenas levantará questões com outros desenvolvedores - portanto, desperdiçando tempo e energia.

Você precisa fazer a pergunta " por que " o código está comentado. Algumas sugestões:

Se você está comentando o código porque está "inseguro quanto às regras de negócios", então provavelmente você tem um problema com "aumento de escopo" - melhor não sujar sua base de código com requisitos que "seria bom ter, mas não temos tempo para implementar "- mantenha-o limpo com código claro e testes em torno do que realmente está lá.

Se você está comentando o código porque "não tem certeza se é a melhor maneira de fazê-lo", faça uma revisão do código por pares! Os tempos estão mudando, você vai olhar para o código que escreve hoje em 2 anos e achar que é horrível! Mas você não pode sair por aí comentando coisas que você "sabe" que podem ser feitas melhor, mas simplesmente não consegue encontrar uma maneira agora. Deixe quem mantém a base de código a longo prazo determinar se existe uma maneira melhor - basta escrever, testar e trabalhar o código e seguir em frente.

Se você está comentando o código porque "algo não funciona", então FIX IT ! Um cenário comum é "testes interrompidos" ou "tarefas" . Se você os tiver, economizará muito tempo consertando-os ou simplesmente se livrando deles. Se eles podem ser "quebrados" por um período de tempo, provavelmente podem ser quebrados para sempre.

Todos esses cenários potenciais (e aqueles que não mencionei aqui) são perda de tempo e esforço. O código comentado pode parecer um pequeno problema, mas pode ser um indicador de um problema maior em sua equipe.

Repositórios são backup de código. Se estou trabalhando no código, mas ele não está concluído, por que não comentar e fazer o check-in no final do dia. Assim, se meu disco rígido morrer durante a noite, não perderei nenhum trabalho. Posso verificar o código pela manhã, descomentar e continuar.

A única razão pela qual eu comentaria isso é porque eu não gostaria de quebrar a compilação noturna.

Há claramente uma tensão entre 1) fazer check-in antecipado e 2) sempre manter o repositório em um estado de funcionamento. Se você tiver mais do que alguns desenvolvedores, o último terá cada vez mais precedência, porque você não pode ter um desenvolvedor cagando sobre todo mundo em seu próprio fluxo de trabalho pessoal. Dito isto , você não deve subestimar o valor da primeira diretriz. Os desenvolvedores usam todos os tipos diferentes de barreiras mentais, e fluxos de trabalho individualizados são uma forma de os grandes desenvolvedores espremerem esses Xs extras. Como gerente, seu trabalho não é tentar entender todas essas nuances - nas quais você falhará, a menos que seja um gênio e todos os seus desenvolvedores sejam idiotas -, mas sim permitir que seus desenvolvedores sejam o melhor que podem por meio de suas próprias tomadas de decisão.

Você menciona no comentário que não usa agências privadas. Minha pergunta para você é por que não? Ok, não sei nada sobre o TFS, então talvez haja bons motivos. Porém, depois de usar o git por um ano, devo dizer que um bom DVCS dispersa totalmente essa tensão. Há casos em que acho útil comentar o código enquanto estou construindo um substituto, mas perderei o sono com isso se estiver aplicando isso a outras pessoas. Ser capaz de ramificar localmente significa que posso manter commits significativos para meu processo individual sem ter que me preocupar (ou mesmo notificar) desenvolvedores downstream sobre problemas temporários.

Apenas ecoando o refrão. Desencoraje isso a todo custo. Isso torna o código mais difícil de ler e deixa as pessoas se perguntando o que há de bom / ruim naquele código que nem mesmo faz parte do aplicativo no momento. Você sempre pode encontrar mudanças comparando revisões. Se houve alguma cirurgia importante e o código foi comentado em massa, o desenvolvedor deve ter anotado nas notas de revisão sobre check-in / mesclagem.

o código incompleto / experimental deve estar em um branch a ser desenvolvido até a conclusão. a cabeça / tronco deve ser a linha principal que sempre compila e é o que está sendo enviado. assim que o branch experimental for concluído / aceito, ele deve ser mesclado no cabeçalho / linha principal. Existe até um padrão IEEE (IEEE 1042) que descreve isso se você precisar de documentação de suporte.

Eu preferiria ver o código possivelmente quebrado e acessível que não está sendo usado, mas com check-in sobre o mesmo código, estando completamente indisponível. Já que todo software de controle de versão permite algum tipo de 'cópia de trabalho' separada do tronco, é realmente uma ideia muito melhor usar esses recursos.

Código novo e não funcional está bem no porta-malas, porque é novo. Provavelmente não quebra nada que já funcione. Se ele quebrar o código de trabalho, então ele deve ir para um branch, para que outros desenvolvedores possam (se necessário) verificar esse branch e ver o que está quebrado.

" Tecido cicatricial " é o que chamo de código comentado. Nos dias anteriores ao uso generalizado de sistemas de controle de versão, o Code Monkeys deixava o código comentado no arquivo caso precisassem reverter a funcionalidade.

A única vez em que é aceitável verificar o "tecido cicatricial" é

1. Se você tem uma agência privada e
2. Você não tem tempo para fazer o código compilar sem erros e
3. Você está saindo de férias longas e
4. Você não confia em seu VCS, como se você usasse o Visual Source Safe OU .
   [EDITAR]
5. Você tem um bug sutil que pode ser reintroduzido se o código incorreto não for deixado como um lembrete. (bom ponto de outras respostas).

Quase não há desculpa para o nº 4, porque há uma abundância de sistemas VCS robustos e disponíveis gratuitamente, Git sendo o melhor exemplo .

Caso contrário, deixe o VCS ser seu arquivo e distribuidor de código. Se outro desenvolvedor quiser examinar o seu código, envie-lhe um e-mail com as diferenças e deixe-o aplicar o que deseja diretamente. Em qualquer caso, a fusão não importa por que ou como a codificação de dois arquivos divergiu.

Por ser um código, o tecido cicatricial pode distrair mais até do que um comentário bem escrito. Por sua própria natureza como código, você faz o programador de manutenção gastar ciclos de CPU mentais para descobrir se o tecido cicatricial tem algo a ver com suas alterações. Não importa se a cicatriz tem uma semana ou 10 anos, deixar tecido cicatricial no código impõe um fardo sobre aqueles que precisam decifrar o código posteriormente.

[EDIT] Eu acrescentaria que existem dois cenários principais que precisam ser distinguidos:

• desenvolvimento privado, seja codificando um projeto pessoal ou fazendo check-in em uma agência privada
• Desenvolvimento de manutenção, onde o código que está sendo verificado se destina a ser colocado em produção.

Basta dizer "NÃO" ao tecido cicatricial!

Não sei - sempre comento as linhas originais antes de fazer alterações - isso me ajuda a revertê-las se eu mudar de ideia. E sim, eu faço o check-in.

No entanto, retiro qualquer código comentado antigo do check-in anterior.

Eu sei que poderia olhar os logs de diff para ver o que mudou, mas é uma dor - é bom ver as últimas alterações ali mesmo no código.

Um bom compromisso é escrever uma pequena ferramenta que despeja seus arquivos retirados / modificados em uma unidade de backup de rede. Dessa forma, você pode modificar o conteúdo do seu coração e ter seu trabalho de backup, mas você nunca tem que verificar o código experimental ou inacabado.

Acho que fazer check-in do código comentado deve ser válido porque, só porque a nova alteração passou nos testes, pode ser mais útil ver o que estava lá antes e ver se a nova alteração é realmente uma melhoria.

Se eu tivesse que voltar várias versões para ver uma mudança anterior que agora leva a uma queda de desempenho, isso seria muito chato.

Às vezes, o código comentado é um bom histórico, mas coloque datas de quando o código foi comentado. Mais tarde, alguém que esteja trabalhando perto de lá pode simplesmente excluir o código comentado, pois foi provado que ele não é necessário.

Também seria bom saber quem comentou esse código para que, se alguma justificativa for necessária, eles possam ser questionados.

Eu prefiro escrever uma nova funcionalidade, garantir que os testes de unidade sejam aprovados, fazer o check-in e permitir que outros a usem e ver como funciona.

Se o desenvolvedor comentou algum código porque ele ainda não está completo, a maneira correta de "controle de origem" para lidar com isso seria mantê-lo em um branch separado, até que o código esteja pronto para verificar no.

Com um DVCS (como git, bazaar ou mercurial), isso é muito fácil, pois não requer alterações no repositório central. Caso contrário, talvez você possa falar sobre dar aos desenvolvedores seus próprios branches no servidor se eles estiverem trabalhando em recursos específicos que irão demorar bastante (ou seja, dias).

Não há nada de errado em fazer check-in do código comentado em algumas situações, é apenas que esta é uma situação em que pode haver uma maneira melhor de fazer isso, para que o desenvolvedor possa rastrear as alterações em sua fonte mesmo que não esteja pronto para ser fez check-in no repositório principal.

Claramente, o desenvolvedor que está fazendo check-in do código comentado deve estar trabalhando em um branch separado, mesclando as alterações do branch do tronco conforme necessário.

Cabe ao sistema VCS auxiliar o desenvolvedor neste fluxo de trabalho (git é um excelente sistema VCS que funciona muito bem com isso).