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

Estamos praticando a propriedade coletiva do código. No meu entender, isso significa que qualquer desenvolvedor pode alterar qualquer linha de código para adicionar funcionalidade, refatorar, corrigir bugs ou melhorar os designs.

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

Eu acho que uma boa comunicação é sempre a melhor prática. Converse com o desenvolvedor e veja se há uma razão para que seja codificado da maneira que é. Pode ser que eles pretendam voltar e refatorá-lo por séculos, pode ser que eles tenham feito dessa maneira por uma boa razão, ou pode ser que vocês dois possam aprender algo com a conversa.

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

A própria premissa dessa pergunta suscita uma série de preocupações para mim que não acho que nenhuma das respostas existentes esteja tentando abordar 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, alterações no estilo ou na estrutura do código que resultam em uma implementação aprimorada (ou simplesmente diferente) sem alterações 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 a escrita de um pouco de código novo, mas não é uma reescrita. O termo reescrever implica jogar fora um produto ou recurso inteiro e começar do zero; não é algo que deva ser tomado de ânimo leve.

2. Se o comportamento do código original é tão errado ou a implementação é tão complicada que requer uma reescrita completa, por que não foi capturado pelo processo da sua equipe e tratado no seu contexto adequado (ou seja, tecnicamente, e não socialmente)? Código incorreto ou questionável deve ser exposto rapidamente em uma equipe saudável por meio de testes, revisões de código, revisões de design etc. Você possui?

3. O gerente / técnico está ciente do problema e, se não, por que não? Não importa que tipo de processo você tenha, a qualidade do código geralmente é de responsabilidade do gerente de desenvolvimento. Ele ou ela é a primeira pessoa que você deveria estar perguntando - obviamente não no contexto de "código de porcaria escrito assim e por isso", mas simplesmente "acho que vejo um grande problema aqui, podemos falar sobre uma reescrita?" Se não justifica esse tipo de discussão, talvez também não seja necessário reescrever?

4. Se o tamanho e o escopo do código incorreto são grandes o suficiente para garantir uma discussão séria sobre uma reescrita, por que ele pertence exclusivamente a um desenvolvedor? Na maioria das vezes, quando não vi o código e o pensamento "reescrevendo", ele foi pisoteado por uma dúzia de pessoas diferentes e a maldade é resultado direto do acúmulo de inconsistências de estilo, suposições erradas ou alteradas e bons velhos tempos. hacks antiquados. O código cresce espinhos ao longo do tempo precisamente por causa de sua propriedade compartilhada.

   Meu argumento aqui é que é estranho que uma pessoa possua uma faixa de código tão grande em um ambiente que supostamente pratica a propriedade coletiva. Outras pessoas têm medo de tocar no código deste desenvolvedor? Eles têm medo de abordar o assunto? Talvez haja um problema subjacente com a dinâmica do seu grupo ou com esse desenvolvedor especificamente; se houver, não o ignore. Ou, alternativamente, talvez seja a primeira vez que você trabalha neste projeto, e se sim, por que você está pensando em reescrever tão cedo no jogo? Algo sobre a situação não parece me adicionar.

5. A questão afirma, no primeiro parágrafo any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs,. Uma reescrita não fará essas coisas? Ou fará algo extra - e se sim, o que? Fundamentalmente, quais são seus motivos para querer reescrever e qual a certeza de que eles beneficiarão o produto ou a equipe? Você não precisa responder por mim, mas é melhor ter alguns pontos objetivos a fazer se e quando escolher discutir o assunto com a equipe.

Eu realmente sinto que essa pergunta envolve uma enorme quantidade de contexto e não deve 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. Este é, na IMO, um problema que você absolutamente precisa abordar com sua equipe , não em um site de perguntas e respostas on-line.

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

Existem bugs ou é uma falha de design mais fundamental?

No primeiro caso, eu me preocuparia com uma reescrita para corrigir o que poderia ser apenas um pequeno erro no código.

No último caso, enquanto eu esperava que um alerta de que "meu" código estivesse sendo potencialmente reescrito, eu ficaria perfeitamente feliz em que isso acontecesse.

Esse é o objetivo da propriedade coletiva do código - o código que você escreve está aí para ser modificado ou até substituído, se algo melhor surgir.

Geralmente, se todos concordam que são todos responsáveis ​​pelo código, não há problema em reescrever qualquer código, se for um aprimoramento. Discuta-o com o outro desenvolvedor primeiro como cortesia. Pode haver razões válidas para que seja escrito de uma certa maneira. No nível pessoal, muitos desenvolvedores são emocionalmente investidos no que produzem e, como outros já disseram, você não deseja 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) antes de simplesmente reescrevê-lo. Dessa forma, o desenvolvedor júnior pode aprender com a situação.

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

• Demora uma quantidade significativa de tempo. Se outra pessoa estiver trabalhando em uma alteração relacionada, você não quer perder tempo.
• Outras pessoas têm uma perspectiva diferente. Mesmo se você estiver programando há 20 anos, alguém poderá saber coisas sobre interações com o código que você raramente toca.
• Outros desenvolvedores são o "cliente" do código fonte. O código fonte foi escrito para outros desenvolvedores lerem. Eles podem ter requisitos de arquitetura, entrada no estilo ou solicitações de recursos que estavam desejando nesse código, mas não tiveram tempo. Você não deseja concluir um refatorador apenas para descobrir que outro desenvolvedor precisa dele refatorado de uma maneira diferente.

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

Porém, antes de refatorar ou reescrever o código, faça um backup ou ramificação que contenha esse código. Se o código antigo funcionar bem, haverá uma chance de recuperação.

Se você possui um sistema de controle de origem (que eu assumo que você possui), se possível, refatorar 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 código antigo lá para sempre também não é uma coisa boa. Sugiro que você exclua o código algum tempo depois, como em um mês após a aprovação no teste.

Qual é o escopo disso?

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

• Se você estiver refazendo uma classe 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 estiver reformulando um sistema maior, você definitivamente deve trabalhar com sua equipe para conscientizá-la das mudanças e planejar o design.

Se seus escritores originais estiverem lá, comunique-se com eles. Não APENAS para ettiquette, mas para obter 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 um monte de coisas que precisam de revisão e manutenção e nem sequer tenho alguém com quem fazer a revisão de código. Os escritores anteriores (além do moi) não se deram ao trabalho de comentar nenhum código. E eles se foram da empresa. Não há ninguém para perguntar sobre o código.

Quando reescrevo, comento com comentários que comentei, assim como data e nome / iniciais, e por que estava sendo comentado. Comento novo código, com nome ou iniciais, data, motivo foi adicionado, etc.

Comentários adicionais são feitos no cabeçalho do pacote (normalmente), indicando quais funções / procs / SQL / etc. foram alterados, com data. Facilita a busca de seções que foram alteradas e essas seções possuem documentação completa.

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 / aposentadorias), o código poderá ser limpo de comentários antigos e o restante será a nova linha de base.

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

Minha prática é comentar ao substituí-lo. (Principalmente para referência.) Em seguida, exclua-o no commit final da alteração de trabalho. (Isso requer controle de versão e entendimento de como reverter alterações.)

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

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

Se você estiver alterando o código, deve haver um motivo para trabalhar 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 não foi corrigido ou por que não deve ser alterado. Isso economizará o próximo desenvolvedor algum tempo.

Marcas como FixMe, ToDo, Bug e Hack podem ser usadas para indicar código que pode ser alterado posteriormente. (É aceitável marcar as limitações como Bug e não corrigi-las se não forem acionadas nas condições necessárias.) Pode ser um erro se um programa de contabilidade residencial ultrapassar os 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.

Provavelmente depende de por que a reescrita é necessária. Se é porque há problemas com o que está escrito, e sempre houve problemas com ele, é necessário falar sobre isso, apenas para minimizar a frequência com que o código precisa ser corrigido no futuro.

Minha sugestão neste caso é emparelhar ao corrigir o código. Dessa forma, fornece um bom exemplo dos estados intermediários e (esperançosamente), algum contexto sobre por que o código reescrito é melhor. Além disso (apenas como exercício pessoal), tente refatorar o código para melhorar, sem uma reescrita total. Vai ser mais difícil, mas é bom para você.

Por outro lado, há outros momentos em que é necessário reescrever:

• A equipe aprendeu muito desde que o código foi escrito, e os desenvolvedores que o escreveriam o escreveriam de maneira diferente agora, mesmo sem a sua entrada.

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

Nesses casos, eu provavelmente não me incomodaria com uma conversa.

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

Acho que o @aaronaught fez alguns pontos positivos, o que realmente leva à resposta que eu queria dar, que é que realmente depende de quem está fazendo a alteração (e por que) e quem escreveu o código.

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

Em um ambiente de desenvolvimento de equipe, não é necessário (e talvez não seja possível) conversar com o codificador original; tudo deve ficar claro no código.

Isso então leva à pergunta que consome a maior parte do meu tempo, que é o que o programador original pretendia, e é a pergunta que mais frequentemente leva à exclusão do código, e é por isso que devemos comentar tudo, e onde os programadores juniores inexperientes mais freqüentemente caem em desgraça.

Qualquer programador que esteja alterando o código de outra pessoa (refatoração) realmente deve, por questão de cortesia e prática, copiar o mesmo estilo de codificação do código já existente e primeiro tomar medidas para descobrir como o código original funcionava e o que estava tentando para realmente alcançar. Muitas vezes, isso por si só identifica bugs, mas certamente força as pessoas a suportar a dor que a próxima pessoa terá ao examinar seu código.

Na minha equipe, qualquer pessoa 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 quaisquer alterações, por que elas precisariam tornar o código legível.

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

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