Como corrigir o padrão de copiar / colar?

Onde trabalho, as pessoas (consultores) se sentem pressionadas a liberar recursos o mais rápido possível. Portanto, em vez de gastar muito tempo pensando em como fazer as coisas da maneira certa ou porque elas não querem quebrar nada, o código é copiado de diferentes módulos e modificado.

Não é fácil evitar isso, pois a base de código está aberta a toda a empresa. Muitas pessoas trabalham nisso.

Agora que a bagunça já está lá, qual é a melhor maneira de remover esses despedimentos sem quebrar demais?

Uma parte da resposta é refatoração .

Primeiro, comece a escrever testes de unidade para garantir que você não interrompa acidentalmente nada com suas alterações. Em seguida, comece a melhorar o design, removendo duplicações etc. em pequenas etapas, executando seus testes de unidade após cada etapa, corrigindo quaisquer problemas se algum dos testes falhar ou revertendo imediatamente se você encontrar um problema maior do que pode resolver facilmente.

A outra parte é educação .

As pessoas devem ser ensinadas a não deixar códigos ruins para trás. Esta é certamente uma batalha de longo prazo, já que hábitos e processos de pensamento são difíceis (às vezes até impossíveis) de mudar . No entanto, sem ele, você continuará recebendo um suprimento infinito de códigos ruins gritando para ser refatorado.

Você pode optar por fazer análises de código de grupo para abrir uma discussão sobre bons e maus hábitos de codificação e espalhar os méritos dos primeiros. Não basta dizer "você deve (não) escrever um código como este", você precisa convencer as pessoas com lógica e fatos concretos. Como "se você duplicou esse pedaço de método pela base de código n vezes, quais são as chances de que, se um erro for encontrado nesse método, ele será corrigido em cada cópia do código do método?"

Sua empresa também pode precisar revisar os incentivos e os critérios de aceitação para os consultores - se eles conseguirem escrever código malfeito, certamente continuarão escolhendo o caminho mais fácil. Se a empresa continuar avaliando a "entrega rápida" e a manutenção a longo prazo, nada mudará :-( Portanto, talvez você precise discutir isso com a gerência. Uma maneira de fazê-los entender é o seguinte: refatorar significa manter o código limpo e fácil de entender e manter. Omissão refatoração é como dívida acumulando em seu cartão de crédito. Você pode se safar por um tempo, mas se você não estiver gerenciando ativamente seus hábitos de compra e dívidas, isso inevitavelmente desmoronará sobre seus ombros um dia. Na vida de um projeto de software, a falência ocorre quando o projeto se torna insustentável: fica mais fácil reescrevê-lo do zero do que adicionar um novo recurso à base de código existente. Ou os usuários ficam tão cansados ​​do nível inferior de suporte e recursos que simplesmente mudam para a concorrência.

Como parte da educação como a @Peter disse, você pode introduzir um detector de copiar e colar como o PMD e usá-lo como parte do seu ciclo de construção para ajudar a impor essa parte de seus padrões de codificação.

Certifique-se de que o padrão de codificação de seus projetos cubra esse padrão, para que você tenha uma linha de base para iniciar as discussões.

as pessoas (consultores) se sentem pressionadas a liberar recursos o mais rápido possível

Você não tem um problema técnico, você tem um problema social. Na verdade, você tem um problema de gerenciamento.

Não é fácil evitar isso, pois a base de código está aberta a toda a empresa. Muitas pessoas trabalham nisso.

A "base de código está aberta a toda a empresa" não é um problema. Não importa.

O que importa é que existe um sistema de recompensa de gerenciamento para copiar e colar. A causa raiz é que as pessoas são recompensadas (ou seja, pagas ou elogiadas, promovidas ou ampliadas) por copiar e colar.

Você não pode quebrar isso sem alterar fundamentalmente a cultura de "pressionado para liberar recursos o mais rápido possível" para "recompensado por fazer as alterações apropriadas e bem testadas na base de código".

Voce tem que

1. Comece no topo, com os gerentes que reforçam as recompensas. Você precisa expor a prática atual e documentar os custos e riscos. Você precisa propor uma alternativa que reduz custos e riscos.

2. Você precisa documentar e expor incansavelmente os custos e os riscos pelo restante de seu mandato nessa organização. Implacável. Baseado em fatos. Custo e risco. Toda semana, mais custos e mais riscos de copiar e colar.

3. Você terá que ajudar os gerentes a aceitarem a nova abordagem, que fará com que pareçam bons e você será ignorado.

É muito importante reduzir copiar e colar. Mas é difícil mudar a cultura de uma organização. Você precisa fornecer muitos fatos e deve defender o caso repetidamente com os gerentes que não concordam com você.

Eu tenho uma base de código agora que estava começando a apodrecer a partir disso. Eu tinha mais de 10 funções estáticas por módulo que eram basicamente idênticas às mesmas funções estáticas em outros módulos. Cada um comportado apenas diferente o suficiente para justificar uma nova encarnação em uma questão de fazer as coisas o mais rápido possível.

Hoje, tive que adicionar mais um recurso e não aguentava mais. Criei uma nova biblioteca, combinei as funções 100 + em 10 funções reentrantes que alteram levemente seu comportamento com base em sinalizadores de bits e, em seguida, escrevi uma série de testes para garantir que quaisquer alterações nessa biblioteca não quebrassem mais nada.

Tempo total gasto: 4 horas. Eu estava pronto para uma maratona de 20 horas, se necessário, e fiquei surpreso com a rapidez com que eu deixava uma bagunça crescente sob controle. Como bônus, foi mais fácil corrigir posteriormente vários problemas de dependência de cabeçalho. Além disso, como muitas das nossas coisas proprietárias estão agora em objetos estáticos para vinculação, podemos oferecer aos nossos clientes que têm acesso ao código-fonte mais do que anteriormente.

Meu conselho: morder a bala e re-fatorar essa bagunça agora antes de fazer isso realmente fica ruim . Provavelmente não vai demorar o tempo que você pensa, mas crie um novo ramo para você, apenas por precaução.

Além disso, você ainda pode copiar / colar para obter recursos disponíveis ao mesmo tempo em que corrige o problema fundamental. Quando terminar, basta extrair o material colado e usar a nova biblioteca.

Eu concordo com as respostas dadas até agora. Você deve:

• criar testes de unidade
• refatorar
• educar
• esforçar-se por padrões de codificação e detectar violações

Mas, por outro lado, você precisa analisar o que leva as pessoas a copiar e colar e corrigir isso.

• as pessoas podem não ser capazes de reutilizar o código de uma maneira boa, porque ele está associado a muitas
• as pessoas podem não saber que existe uma biblioteca que elas podem usar
• O código da biblioteca pode não ser genérico o suficiente e criar sua própria versão é muito mais fácil do que usar uma biblioteca existente
• Pode não haver uma boa estratégia de controle de versão (não controle de origem) e a alteração de uma biblioteca genérica pode fazer com que muitos outros aplicativos também sejam testados.

Então, acho que para interromper o padrão de copiar / colar, você precisa facilitar a reutilização.

• tornar as bibliotecas detectáveis ​​e bem documentadas
• tornar as bibliotecas independentes de tudo
• pense em uma boa estratégia de versionamento
• garantir compatibilidade com versões anteriores
• pense na fácil extensibilidade das bibliotecas

leia Diretrizes de design da estrutura

Espero que isto ajude.

Existe uma forte atitude de "colar de cópia considerada prejudicial". Eu acho que é bom, mas vai um pouco longe demais. Copie e cole como um exercício para descobrir as semelhanças e diferenças entre dois métodos ou classes - como um passo no processo de triangulação - acho saudável. Mas parar de triangular completamente - de eliminar a duplicação introduzida pela cópia e colar - é realmente prejudicial.

Se você puder encontrar maneiras de usar essa atitude mais sutil, para dizer aos desenvolvedores não "isso é ruim!", Mas sim "incompleto, você pode trabalhar comigo para concluir a refatoração?", Poderá encontrar conversas mais construtivas.

Estou preocupado com o mesmo problema aqui, e minha opinião é: não tente evitá-lo antecipadamente, apenas refatorar quando estiver muito ruim.

O módulo no qual estou trabalhando no startet como cópia de outro módulo, agora estou alterando tudo o que precisa ser diferente. Uma vez feito isso, e o novo módulo estiver concluído, vou compará-lo com o módulo original e descobrir quais partes estão mais ou menos inalteradas e devem ser movidas para uma biblioteca, classe pai abstrata etc.

Quem está no comando é o culpado. Não se pode esperar que uma pessoa revise todas as linhas de código, mas elas definem os padrões e os prazos.

Os contratados (ou qualquer pessoa que seja de curto prazo em um projeto) podem ser colocados na posição em que são compensados ​​apenas por fazê-lo funcionar pela primeira vez. Existe algum incentivo para fazê-lo o mais rápido possível. O código copiado pode nunca precisar ser modificado e, se for, não será por eles.

Você pode tentar forçá-los a corrigi-lo em seu próprio tempo. Então eles começarão a fazê-lo desde o início, mas depois levarão um tempo extraordinário para fazer as coisas. Eu acho que a AmmoQ tem a idéia certa de refatorar coisas que estão causando problemas.

A única maneira de eliminar o código de copiar / colar é (IMHO) as revisões de código, ter uma pessoa (ou de preferência mais) para verificar o código e, quando encontrarem o código que parece ser de uma ação de copiar / colar, deixe o programador refatorar.

Como sugerido, isso é principalmente um problema na organização. Tente começar educando as pessoas (não esqueça a camada de gerenciamento direto acima da sua posição). Ajuda muito começar a receber uma ou duas pessoas no seu trem e deixar o vírus se espalhar. Quando a maioria achar que é uma boa ideia, descreva-a e tente introduzir avaliações para garantir que continue assim. Este é um processo muito lento e tedioso, mas simplesmente não pode mudar rapidamente. No começo, custará tempo extra, por isso é importante que a gerência conheça e apoie a meta de longo prazo.

@ K. K. Comentários são um bom meio de manter a prática no lugar. Ao forçar as pessoas a escreverem códigos, elas não acreditam nisso, cria muito atrito. Eles voltarão ao antigo habbit assim que possível. Eu acredito firmemente que você deve começar com a educação para ganhar impulso.