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


40

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?


5
Não consigo ver nenhum dano ao excluir o código, se necessário - desde que você use o controle de origem. As outras respostas a esta pergunta descrevem a ética de excluir o código de outra pessoa muito bem.
Anónimo

9
Eu não acho que isso seja mencionado especificamente em nenhuma das [excelentes] respostas: mesmo que o código existente mereça uma reescrita, se funcionar agora, é muito provável que seja uma perda de tempo [dinheiro] reescrita. Aprendi que, em muitos cenários, é fácil seguir em frente. Você é pago para escrever código, portanto deve ser o mais eficiente possível. Você não precisa de uma estrutura bem projetada para algo que será executado apenas algumas vezes. Você não quer levar uma semana para fazer algo que poderia ter sido feito em um dia usando práticas inadequadas de design. Muitas vezes os gerentes preferem essa abordagem.
taz

9
@taz - Esse é o fundamento do padrão Big Ball of Mud ( laputan.org/mud ).
Matthew Flynn

@MatthewFlynn - Ótimo artigo. A frase "Big Ball of Mud" apareceu tantas vezes que parecia uma experiência de déja vu na "Practice" de Allan Iverson ( youtube.com/watch?v=eGDBR2L5kzI ). ;-)
Happy Green Kid Naps

3
Precisa de mais contexto. Por que você está alterando o código, qual é o escopo da alteração - horas, dias, semanas, meses de trabalho? Quem está pagando pela mudança e ela é realmente necessária. Quem aprova a necessidade da mudança. O que você processa e como ele falhou tanto que você entrou nessa bagunça para começar.
mattnz

Respostas:


62

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.


11
Sim, eu aprendi com a experiência que alguns desenvolvedores podem ficar extremamente agitados se você mesmo corrigir bugs no código deles sem perguntar. Obviamente, este foi um projeto sem rastreamento de problemas ou planejamento de tarefas, e estou surpreso que ele tenha sido enviado.
fofo

+1 para "falar com o desenvolvedor" - temos um bug (bem, pelo menos um, provavelmente mais) que o cliente espera agora ... E está tão enterrado que eu fui o único que soube vagamente por que foi deixado sozinho.
Izkata 6/08/12

3
Não discordo de "boa comunicação" em princípio, mas acho que essa resposta é um pouco banal. Descontando todas as perguntas problemáticas sobre quais circunstâncias levaram a essa pergunta, realmente não deveria importar nem um pouco se um desenvolvedor responde "sim" ou "não" à pergunta "devo reescrever seu código?" , porque essa não será necessariamente a resposta melhor para a equipe ou para o produto. Certamente, devemos tentar descobrir tudo o que podemos sobre as suposições e decisões originais, mas como sabemos que o OP ainda não fez isso?
Aaronaught 6/08/12

2
@Aaronaught - A questão de perguntar primeiro ao desenvolvedor original implica que o OP ainda não falou com o desenvolvedor original e, portanto, não tentou descobrir tudo o que pode. Espero que a resposta seja o oposto de banal - é fundamental.
Matthew Flynn

11
Se você realmente pratica a propriedade coletiva do código, tem o direito de alterar, reescrever ou excluir qualquer código sempre que considerar apropriado. Isso é particularmente verdade se você estiver fazendo programação em pares. Agora, tendo dito que, antes de uma grande mudança (como uma reescrita) do código que uma pessoa em particular tenha escrito, seria sensato falar sobre isso com eles. Na maioria dos casos que eu vi (inclusive com meu próprio código), a resposta deles foi: "Sim, desculpe! Esse código é um desastre; eu simplesmente não fiz isso direito. Aqui estão algumas idéias sobre como melhorá-lo Por favor, corra com ele! "
Jeff Grigg

35

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.


3
+1 A única resposta correta nesta discussão.
mattnz

Na minha experiência em equipes do XP com propriedade coletiva de código (e programação em pares), as principais mudanças no design ou na "reescrita" de partes do sistema geralmente envolvem discussões com a maioria da equipe (todos que se importam). Com funcionalidade essencial, o design existente é o melhor que a equipe poderia fazer no momento. Se não puder ser facilmente alterado, é útil obter as idéias de todos sobre o que eles acham que deve fazer e várias maneiras de melhorar. Se você não conseguir obter consenso, tente alguns "picos" ou experiências para coletar informações.
precisa saber é o seguinte

11

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.


3
Esta é a única resposta até agora com a qual posso concordar. Se algo precisar ser reescrito, eu reescrito. Eu nem olho para ver quem era o autor original; por que eu deveria? Assumindo que existem testes (não são testes, certo?), E supondo que o seu objectivo é razoavelmente clara ou explicadas por comentários (se não, então ele definitivamente precisa de ir), então eu vou saber muito rapidamente se eu quebrei nada. É claro que estou falando de reescrever algumas classes, não uma estrutura inteira, mas se a reescrita for tão grande, será mais um problema de planejamento / projeto do que uma questão de propriedade compartilhada.
Aaronaught 6/08/12

6

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.


5

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.

4

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.


2
"Sugiro que você exclua o código algum tempo depois" - onde ele deve ficar enquanto isso? Em um bloco comentado? É para isso que serve o controle de origem: manter uma cópia de backup de todos os códigos alterados / excluídos para facilitar a recuperação, mantendo o código-fonte atual limpo.
dj18

@ dj18, costumo manter o código comentado por um tempo para torná-lo mais evidente, e para que todos que lidam com o código possam ver que ele foi modificado de uma só vez. Além disso, é mais fácil olhar para cima, desta forma quando o código é apenas editado
SuperM

11
Essa é outra função de um sistema de controle de versão adequado: você pode ver quando as alterações foram registradas, comparar versões para ver exatamente o que mudou de um check-in para o próximo e associar comentários a check-ins para explicar por que uma modificação foi feita. Se for tão importante para outras pessoas saberem imediatamente que um trecho de código foi alterado, talvez envie uma notificação por email em vez de esperar que os outros desenvolvedores tenham chance de comentar seus comentários.
dj18

2
O conhecimento que as respostas desta resposta devem ser obtidas do desenvolvedor original deve estar no código , ou pelo menos nos comentários ou na documentação que o acompanha. Se essa é uma informação importante, ela não deve ser silenciada no cérebro de alguém, e as políticas de desenvolvimento não devem encorajá-la. Além disso, por que não excluir o código antigo? Você pode recuperá-lo se realmente precisar; é isso que o controle de revisão é para .
Aaronaught 6/08/12

11
@Aaronaught: Eu acho que o superM quis dizer foi do tipo "aqui seja dragões", ou "lições aprendidas". Embora as armadilhas devam ser bastante óbvias para um programador experiente, escolhas sutis são menos óbvias e podem não estar bem documentadas. (Concordo que esses são sinais ruins que precisam ser abordadas.)
rwong

2

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.


1

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.


1

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.


2
Quase diminuiu a votação, até que vi "Em seguida, exclua-o no commit final".
21712 Joshua Drake

1

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.


1

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.


-2

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

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.