Qual é a melhor maneira de anotar quem criou um arquivo e as alterações subsequentes que foram feitas?
Sou um empreiteiro em um novo projeto, um que está apenas começando, que está usando o Subversion. Outro dia eu notei que um membro da equipe atualizou um script escrito por um consultor externo, e ele atualizou o cabeçalho de "Escrito por X" para "Escrito por Y e X" (já que ele tinha feito um número decente de atualizações). / p>
Eu não achei que essa era uma boa ideia, porque outros depois de nós podem atualizar esse script com pequenas ou grandes alterações e não ficaria claro quando atualizar o cabeçalho "Escrito por" (ou como ordenar os nomes) . Eu fiz o mesmo que fiz na minha empresa anterior (com um log de edição no topo de cada arquivo - que era aplicado por quem quer que verificasse as alterações, estávamos usando o Clear Case para que as alterações não fossem feitas até serem verificadas ), mas ele mencionou que poderíamos apenas usar o comando "svn log" para ver as edições e seria difícil impor um log de edição.
Então, agora não tenho certeza de qual é a melhor maneira de anotar autoria e alterações. Os arquivos podem mudar completamente com o tempo, por isso não gosto da ideia de um cabeçalho "Escrito por" antigo. E um cabeçalho "Escrito por", que inclui apenas uma longa lista de pessoas sem contexto, não parece ser útil. Há remover o cabeçalho de autoria e simplesmente usar o log de alterações do subversion, mas o que você faz com os cabeçalhos "Escrito por" do código que é fornecido a você (de consultores, bases de código antigas, baixados da rede etc.)? Como as outras equipes lidam com isso?
Estou com você, documentos modernos de controle de código-fonte que fizeram o que no código-fonte é muito melhor do que alguns comentários aleatórios em um arquivo de cabeçalho.
Seu cliente está errado, ele está perdendo tempo e adicionando lixo aos seus arquivos. Mas ele ainda é o cliente.
Se você é um contratado, deve seguir os padrões de codificação do cliente.
Se isso é apenas uma coisa do ego, apenas esqueça os comentários do cabeçalho e faça o seu trabalho.
I don't like the idea of a stale "Written by" header.
Correto. É inútil.
And a "Written by" header that just includes a long list of people with no context doesn't seem useful.
Correto. Eles estão todos mortos, BTW. Ou ganhou na loteria. Eles estão no mar e não podem ser contatados. Por que listá-los?
Meu favorito é usar iniciais. %código%. Quem é aquele? E como você vai descobrir? Se eles fossem contratados, você teria que retirar todas as faturas da data anterior, ligar para todas as empresas contratantes que ainda estão no negócio, para que possam obter todos os registros de pessoal.
what do you do about "Written by" headers from code that's given to you (from consultants, old code bases, downloaded from the net, etc)?
Ignore-o.
Deixe o SCM lidar com isso. É a única maneira de garantir que as informações estejam sempre atualizadas, sejam granulares para o nível da linha de origem e também a maneira mais fácil, já que o subversion rastreia essas informações já. Mesmo que você não imponha mensagens de confirmação, é fácil extrair um número de revisão e as alterações que o acompanham, o que deve informar tudo o que você precisa saber.
A única razão que posso pensar para querer esta informação nos comentários é que svn blame ou svn log são um pouco mais lentos do que simplesmente olhar para os comentários, mas o preço que você paga pelo pequeno aumento de velocidade é que você tem sujar no seu código. A pior parte, no entanto, é que você está confiando em processos manuais para tarefas repetitivas.
Eu tenho que concordar com Jim.
Qualquer ferramenta de controle de versão fará um trabalho melhor que um blob de texto grande na parte superior de um arquivo. O sistema de controle de versão será preciso, atualizado e fornecerá diferenças desde a criação do arquivo. O método do cabeçalho diz:
11/01/98 - Redesigned file - KPR
04/15/05 - Patch to work around small bug - JSC
Os comentários devem descrever o que um arquivo / classe / função / linha faz AGORA . É uma história sem sentido gravar em linha. É uma retenção dos dias antes do controle de versão barata / impressionante.
Você deve explicar ao cliente que ele aumentará os custos para fazer isso dessa maneira e permitirá acelerar o desenvolvimento para permitir que as ferramentas façam o trabalho corretamente.
Tags version-control