Regras não escritas de reescrever o código de outro membro da equipe [fechado]

39

Estamos praticando a propriedade de código coletivo. No meu entender, isso significa que qualquer desenvolvedor pode alterar qualquer linha de código para adicionar funcionalidade, refatorar, corrigir erros ou melhorar projetos.

Mas e uma reescrita completa do código de um desenvolvedor que ainda está na equipe? Devo perguntar primeiro a ele? Qual é a melhor prática?

    
por sglahn 06.08.2012 / 16:56
fonte

12 respostas

62

Eu acho que boa comunicação é sempre a melhor prática. Fale com o desenvolvedor e veja se há uma razão pela qual ele é codificado como está. Pode ser que eles tenham tido a intenção de voltar e refatorá-lo por muito tempo, pode ser que eles o tenham feito dessa forma por uma boa razão, ou pode ser que ambos possam aprender alguma coisa com a conversa.

Entrar e reescrever sem comunicação prévia é uma receita para má vontade.

    
por 06.08.2012 / 17:01
fonte
33
A própria premissa desta questão levanta uma série de preocupações para mim que eu não acho que qualquer uma das respostas existentes estão tentando resolver adequadamente. Deixe-me fazer algumas perguntas de acompanhamento aqui:

  1. Você está absolutamente certo de que está falando sobre reescrever e não refatorar? Por definição, mudanças no estilo de código ou estrutura que resultam em uma implementação melhorada (ou simplesmente diferente) sem mudanças no comportamento externo são um refator, não uma reescrita. Quebrar uma rotina monolítica de 500 linhas em um conjunto de 50 sub-rotinas pode envolver escrever um pouco de novo código, mas isso não é uma reescrita. O termo reescrita implica jogar fora todo um produto ou recurso e começar do zero; não é algo para ser tomado de ânimo leve.

  2. Se o comportamento do código original é tão errado, ou a implementação é tão problemática a ponto de exigir uma reescrita completa, por que ele não foi capturado pelo processo de sua equipe e tratado em seu contexto apropriado (ou seja, tecnicamente socialmente)? Código ruim ou questionável deve ser exposto rapidamente a uma equipe saudável por meio de testes, revisões de código, revisões de design, etc. Você tem isso?

  3. O gerente / responsável técnico está ciente do problema e, em caso negativo, por que não? Não importa que tipo de processo você tenha, a qualidade do código é normalmente de responsabilidade do gerente de desenvolvimento. Ele ou ela é a primeira pessoa que você deveria estar perguntando - obviamente não no contexto de "fulano escreveu um código" mas simplesmente "Acho que vejo um grande problema aqui, podemos falar sobre uma reescrita? " Se não justifica este tipo de discussão, então talvez não seja necessário reescrever?

  4. Se o tamanho e o escopo do código incorreto forem grandes o suficiente para justificar uma discussão séria de uma reescrita, por que ela é de propriedade exclusiva do um desenvolvedor? A maioria, se não todas as vezes em que vi código e pensei em "reescrever", tem sido pisoteada por uma dúzia de pessoas diferentes e a maldade é um resultado direto do acúmulo de inconsistências de estilo, suposições equivocadas ou alteradas, e o bom e velho Hackers antiquados. O código aumenta espinhos ao longo do tempo precisamente porque de sua propriedade compartilhada.

    Meu ponto aqui é que é estranho que uma pessoa possua uma faixa tão grande de código em um ambiente que supostamente pratica a propriedade coletiva. Há outras pessoas com medo de tocar no código desse desenvolvedor? Eles estão com medo de trazer o assunto? Talvez exista um problema subjacente com sua dinâmica de grupo ou especificamente com esse desenvolvedor; se houver, não ignore isso. Ou, alternativamente, talvez seja a primeira vez que você está trabalhando neste projeto e, em caso afirmativo, por que você está pensando em reescrever logo no início do jogo? Algo sobre a situação não parece somar para mim.

  5. A pergunta afirma, no primeiro parágrafo, any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs . Será que uma reescrita não fará essas coisas? Ou vai fazer algo extra - e se sim, o que? Fundamentalmente, quais são seus motivos para querer reescrever, e como você está certo de que eles irão beneficiar o produto ou a equipe? Você não precisa responder por mim, mas é melhor você ter alguns pontos objetivos a serem feitos se e quando você decidir discutir isso com a equipe.

Eu realmente sinto que esta questão envolve uma enorme quantidade de contexto e que não será respondida sem uma compreensão muito clara desse contexto. A resposta "correta" depende completamente de sua equipe, seu produto, sua organização, sua personalidade, seu processo, o escopo do código original, o escopo das alterações e assim por diante. Isso é, IMO, um problema que você absolutamente precisa abordar com sua equipe , não em um site de perguntas e respostas on-line.

    
por 06.08.2012 / 23:09
fonte
10

Por que você está editando o código?

Existem erros ou é uma falha de design mais fundamental?

No primeiro caso, eu me preocuparia com uma reescrita para consertar o que poderia ser apenas pequenos erros no código.

No último caso, enquanto eu esperaria um heads-up de que o "meu" código estava potencialmente sendo reescrito, eu ficaria perfeitamente feliz por isso acontecer.

Esse é o ponto de propriedade coletiva do código - o código que você escreve está lá para ser modificado ou mesmo substituído se algo melhor aparecer.

    
por 06.08.2012 / 17:06
fonte
6

Geralmente, se todos concordam que todos vocês são responsáveis pelo código, não há problema em reescrever qualquer código, se for uma melhoria. Discuta com o outro desenvolvedor primeiro como cortesia. Pode haver razões válidas que estão escritas de uma certa maneira. Em um nível pessoal, muitos desenvolvedores investem emocionalmente naquilo que produzem e, como outros disseram, você não quer má vontade.

Especificamente, depende um pouco da dinâmica da equipe. Um desenvolvedor sênior prestes a reescrever o código de um desenvolvedor júnior provavelmente deve realizar uma revisão de código (meu site) com eles antes de simplesmente reescrevê-lo. Dessa forma, o desenvolvedor júnior pode aprender com a situação.

    
por 06.08.2012 / 17:02
fonte
5

Realmente não importa se o desenvolvedor original está na equipe ou não, ou mesmo se você é o desenvolvedor original. A regravação completa de qualquer código compartilhado deve ser executada por sua equipe pelos seguintes motivos:

  • Demora um tempo significativo. Se alguém está trabalhando em uma mudança relacionada, você não quer perder tempo.
  • Outras pessoas têm uma perspectiva diferente. Mesmo se você estiver programando 20 anos, alguém pode saber coisas sobre interações com códigos que você raramente toca.
  • Outros desenvolvedores são o "cliente" do código-fonte. Código-fonte é escrito para outros desenvolvedores lerem. Eles podem ter requisitos de arquitetura, entrada no estilo ou solicitações de recursos que desejam nesse código, mas não tiveram tempo. Você não quer terminar um refatorador apenas para descobrir que outro desenvolvedor precisa refatorá-lo de uma maneira diferente.
por 06.08.2012 / 17:50
fonte
4

Como Matthew Flynn disse, é necessário conversar com o desenvolvedor primeiro. O desenvolvedor inicial pode dizer coisas importantes sobre a funcionalidade e explicar por que essa ou aquela solução foi fornecida.

Mas antes de refatorar ou reescrever o código, faça um backup ou uma ramificação contendo esse código. Se o código antigo funcionar bem, haverá uma chance de que ele possa ser recuperado.

Se você tem um sistema de controle de código-fonte (que eu suponho que você tenha), então, se possível, refatore o código inteiro e somente depois, quando tiver certeza de que funciona bem, verifique isso.

Não exclua o código antigo, pelo menos antes de ter certeza de que o novo código funciona bem. Mas deixar o antigo código lá para sempre também não é bom. Eu sugiro que você apague o código algum tempo depois, como em um mês depois que ele passou no teste.

    
por 06.08.2012 / 17:28
fonte
2

Qual é o escopo disso?

  • Se você estiver reformulando algumas linhas para ser mais eficiente, basta fazê-lo. Talvez pergunte se há algum perigo de você apagar o comportamento sutil. Relate a alteração durante o scrum ou via e-mail, uma vez que é feito, a menos que seja realmente trivial (corrigir um erro de digitação).

  • Se você estiver reformulando uma turma de tamanho decente, provavelmente deverá pedir para entender o design / comportamento. Informe as pessoas com antecedência para que qualquer pessoa que esteja trabalhando na mesma área possa estar ciente e coordenar com você.

  • Se você estiver reformulando um sistema maior, definitivamente deverá trabalhar com sua equipe para torná-los cientes das alterações e planejar o design.

por 06.08.2012 / 17:07
fonte
1

Se os escritores originais estiverem lá, comunique-se com eles. Não APENAS para ettiquette, mas para informações adicionais, caso haja casos ou circunstâncias que você não conhece. Às vezes, eles dizem algo valioso.

Temos um controle de código abismal. Atualmente tenho uma tonelada de coisas que precisam de revisão e manutenção, e não tenho ninguém para fazer uma revisão de código. Os escritores anteriores (além do moi) não se preocuparam em comentar qualquer código. E eles saíram da empresa. Não há ninguém para perguntar sobre o código.

Quando eu reescrevo, eu comento, com comentários que eu comentei, assim como data e nome / iniciais, e por que ele estava sendo comentado. Eu comento novo código, com nome ou iniciais, data, razão foi adicionado, etc.

Comentários adicionais são feitos no cabeçalho do pacote (er, geralmente), indicando quais funções / procs / SQL / etc. foram alterados, com data. Isso facilita a consulta de seções que foram alteradas e essas seções têm documentação completa.

Os comentários são baratos. As datas serão um indicador do que mudou e, após o número x de (dias / revisões / novas contratações / retiradas), o código pode ser limpo de comentários antigos e o restante é a nova linha de base.

    
por 06.08.2012 / 17:43
fonte
1

De minha observação, a prática geral é: nunca exclua o código. Apenas comente e guarde.

Minha prática é comentá-lo enquanto o substituo. (Principalmente para referência). Em seguida, exclua-o na confirmação final da alteração de trabalho. (Isso requer controle de versão e uma compreensão de como reverter as alterações.)

Quando encontro um código antigo comentado, tento excluí-lo em um commit separado com comentários apropriados. Isso facilita a reversão ou a inspeção da alteração, se necessário.

Para todas as alterações, você deve poder usar o histórico de revisão para determinar o (s) desenvolvedor (es) que criou o código. (O histórico de revisões anotadas ajuda aqui.) Entre em contato, se possível, para ver por que o código está como está. Em muitos projetos, o tempo de limpeza não ocorre e as coisas ficam para trás. Verifique o rastreador de bugs para ver se há um registro da limpeza necessária. Algumas mudanças precisam ser limpas uma ou duas versões posteriores.

Se você estiver alterando o código, deve haver um motivo pelo qual você esteja trabalhando com esse código. Verifique com o desenvolvedor original para descobrir por que o código é como é. Se houver um motivo legítimo para não corrigi-lo, adicione um comentário explicando por que ele não foi corrigido ou por que não deve ser alterado. Isso salvará o próximo desenvolvedor algum tempo.

Tags como FixMe, ToDo, Bug e Hack podem ser usadas para indicar o código que pode ser alterado posteriormente. (É aceitável etiquetar as limitações como Bug e não corrigi-las se elas não forem acionadas sob as condições necessárias.) Pode ser um bug se um programa de contabilidade residencial estourar a 20 milhões de dólares, mas não perderia muito tempo consertando isto.

As alterações de revisão de código devem ser feitas pelo desenvolvedor original, se for apropriado modificar o código.

    
por 07.08.2012 / 06:35
fonte
1

Isso provavelmente depende do motivo pelo qual a reescrita é necessária. Se é porque existem problemas com o que está escrito, e tem sempre sido problemas com ele, então é necessário falar sobre isso, apenas para minimizar a frequência com que o código precisa ser corrigido no futuro. / p>

Minha sugestão nesse caso é parear ao consertar o código. Dessa forma, ele fornece um bom exemplo dos estados intermediários e (espero) algum contexto no porquê o código reescrito é melhor. Também (se apenas como um exercício pessoal), tente refatorar o código para ser melhor sem uma reescrita total. Vai ser mais difícil, mas é bom para você.

Por outro lado, há algumas outras ocasiões em que uma reescrita é necessária:

  • A equipe aprendeu muito desde que o código foi escrito e o (s) desenvolvedor (es) que o escreveram escreveriam de forma diferente agora, mesmo sem a sua contribuição.

  • Um novo requisito de recurso altera a situação de forma que uma mini-reescrita direcionada seja apropriada.

Nesses casos, provavelmente não me importaria em conversar.

Pensando nisso, parece-me que quanto mais tempo o código estiver lá, menor a probabilidade de uma conversa ser necessária.

    
por 07.01.2013 / 01:02
fonte
1
Eu acho que @aaronaught fez alguns pontos positivos, o que realmente leva à resposta que eu queria dar, que é que realmente depende de quem está fazendo a mudança (e por quê) e quem escreveu o código.

Na minha experiência pessoal, o código normalmente é alterado porque ou não funciona como esperado ou você simplesmente precisa estender o que realmente faz.

Em um ambiente de desenvolvimento de equipe, você não deveria ter que (e não ser capaz de) falar com o codificador original, tudo deve estar claro no código.

Isso leva à questão que consome a maior parte do meu tempo, que é o que o programador original pretendia, e é essa pergunta que mais frequentemente leva à exclusão de códigos, e é por isso que devemos comentar tudo, e onde inexperientes programadores juniores muitas vezes são prejudiciais.

Qualquer programador que esteja mudando o código de outra pessoa (refatoração) deve, por uma questão de cortesia e prática, copiar o mesmo estilo de codificação do código já em vigor, e primeiro dar passos para descobrir como o código original funcionava, e estava tentando, e realmente indo, alcançar. Muitas vezes isso identifica bugs, mas certamente força as pessoas a suportar a dor que a próxima pessoa terá olhando seu código.

Na minha equipe, qualquer um pode excluir, refatorar ou reescrever qualquer coisa, e eu vejo 'propriedade' como uma prática que gera preguiça, como se uma pessoa tivesse certeza de ser notificada de alguma mudança, por que precisaria tornar o código legível .

Então, resumindo, não, você não deveria ter que perguntar ao autor original do código, e se ao olhar para o código que você faz, então é um sinal de que ou o código dele não é legível o suficiente, ou você precisa melhorar suas habilidades. No entanto, acho bom deixar o código original no lugar, comentado, até que você tenha absoluta certeza de que, ao reescrever, você não removeu acidentalmente a funcionalidade necessária. Ninguém é perfeito.

    
por 07.01.2013 / 11:40
fonte
-2

Muitas vezes, o código é escrito de uma determinada maneira por um motivo. Comunicar a mudança para o autor sempre funciona melhor.

    
por 06.08.2012 / 22:37
fonte