Por que "copiar e colar" de código é perigoso? [fechadas]

Às vezes, meu chefe se queixa de nós:

Por que precisamos de tanto tempo para implementar um recurso?

Na verdade, o recurso foi implementado em outro aplicativo antes, basta copiar e colar códigos a partir daí. O custo deve ser baixo.

É realmente uma pergunta difícil, porque copiar e colar códigos não é uma coisa tão simples no meu ponto de vista.

Você tem boas razões para explicar isso ao seu chefe não técnico?

Se você encontrar um bug no seu código de copiar e colar, precisará corrigi-lo em todos os lugares que fez e espero poder lembrar de todos (isso também vale para requisitos alterados).

Se você mantiver a lógica em um local, será mais fácil alterar quando necessário (por isso, se você decidir que o aplicativo precisa ser atualizado, faça-o apenas em um local).

Peça ao seu chefe que leia o princípio DRY (não se repita).

O que você está descrevendo parece o uso perfeito para bibliotecas , onde você compartilha código e o mantém em um só lugar.

Eu apenas copiava e colava o código se pretendesse refatá- lo logo depois - certificando-me de que extraí mais tarde o código comum para poder reutilizar o máximo de lógica possível. E logo depois, quero dizer minutos e horas depois, não dias e semanas.

É muito melhor compartilhar o código construindo uma biblioteca em vez de copiar o código usando copiar e colar.

Você ainda obterá uma vantagem de velocidade em relação à reescrita (procure DRY), mas terá apenas um local para manter o código.

A razão óbvia é que você assume uma 'dívida' para o futuro: qualquer alteração que você precise fazer no código (não apenas correções de bugs, qualquer alteração) agora será duas vezes mais cara, porque você precisa atualizar dois locais - e mais arriscado porque você esquecerá um deles eventualmente. Em outras palavras, fazê-lo funcionar mais rápido agora tornará seu trabalho ainda mais lento no futuro, o que pode ser bom para os negócios, mas geralmente não é.

Mas a razão mais importante é que a suposição "é a mesma coisa" é mais do que sutilmente errada. Sempre que seu código depende de suposições não ditas para estar correto, copiá-lo para outro local resulta em erros, a menos que essas suposições também sejam mantidas no novo local. Portanto, o código colado geralmente está errado desde o início e não apenas após a próxima alteração.

O código de copiar e colar em termos de design é certamente um desastre, com o potencial de causar muitos problemas no futuro. Mas você está perguntando por que você exige muito trabalho agora , a resposta é: porque nunca é apenas copiar e colar.

Se o código original foi escrito para ser reutilizado, como uma biblioteca bastante independente, com flexibilidade e uso do cliente em mente - então ótimo, mas isso não é copiar e colar, é usar uma biblioteca de códigos. A cópia e colagem de código real geralmente é mais ou menos assim:

• "Claro, eu já tenho um código que faz exatamente isso!"
• "Espere, qual dessas cinco versões de código é a que eu quero usar como fonte?"
• "Hmmm, o que todas essas funções 'util_func_023' fazem? Não as documentei? De quais delas preciso agora?"
• "Ah, sim, este código usa a Base de Código Y. Acho que preciso [ escolher uma: copiar toda a Base de Código Y para o meu novo projeto / passar um dia extricando a única função que desejo da Base de Código Y / passar uma semana extricando o uma função que eu quero da Base de Código Y]. "
• "Eu copiei tudo, yay!"
• "Por que isso não está funcionando?"
• Este é o ponto em que você passa horas / dias / semanas depurando o código existente semelhante ao que você deseja, em vez de escrever o código com o qual realmente deseja começar.

Em resumo, o código existente que não pode ser usado diretamente pode, na melhor das hipóteses, servir como uma boa referência para escrever código semelhante. Certamente não pode ser levantado inteiro e espera-se que funcione em um sistema completamente diferente. Em geral, é uma suposição segura de que qualquer código que tenha sido escrito e completado deve sofrer o mínimo possível de alterações - mesmo quando é uma cópia e não o original.

Se você deseja basear seu projeto em copiar e colar, é necessário codificar para começar de uma maneira que permita uma reutilização fácil, sem copiar o código original e mexer com ele. Vale a pena fazer, e se é isso que seu chefe espera, então vocês dois precisam ter certeza de que é assim que projetam e trabalham em primeiro lugar.

copiar e colar é um desastre esperando para acontecer. Seu chefe deve avaliar o preço do envio antecipado em relação ao preço de ter o código quebrado enviado para o usuário final em breve.

Se você já implementou os recursos e precisa copiar e colar para reutilizá-los, parece que você fez algo errado. Você não pode colocar esses recursos em uma biblioteca para reutilizá-los sem copiar / colar?

O princípio DRY (não se repita): DRY na wikipedia .

"Todo conhecimento deve ter uma representação única, inequívoca e autoritária dentro de um sistema".

outro link .

Parece-me que o pior equívoco que seu chefe não técnico tem é que seu trabalho é predominantemente digitado. Eles acham que você pode economizar muito tempo eliminando a digitação.

Eu acho que a melhor educação que você poderia dar a essa pessoa é apontar todo o trabalho que você faz que não está digitando. Mesmo que a maior parte desse trabalho geralmente ocorra de forma invisível, na sua cabeça, ao mesmo tempo em que você digita.

Claro, eliminar a digitação economizará algum tempo. Porém, a parte muito maior, sem digitação, de seu trabalho aumenta e consome menos tempo e muito mais.

Tem certeza de que seu chefe quer ouvir sobre o princípio DRY, bugs e outras coisas de tecnologia?

Esse tipo de comentário você costuma ouvir quando seu chefe ou empresa subestima o tempo necessário para concluir um projeto. E com base em estimativas erradas, um contrato foi assinado etc. Na maioria dos casos, os programadores não estavam envolvidos em estimativas.

Por que isso acontece? Às vezes, o patrocinador do projeto tem um orçamento muito pequeno. Talvez um processo comercial que você esteja automatizando usando software não valha o esforço da equipe. Os gerentes geralmente tendem a ser muito fechados para receber más notícias nesses casos. No início do projeto, há ilusões. Em seguida, os gerentes tentam culpar os programadores. No seu caso, indiretamente, via copiar e colar. Em casos extremos, isso é chamado de marcha da morte .

Copiar e colar código geralmente leva à Programação por Coincidência

Eu acho que " outro aplicativo " é fundamental aqui, se o outro aplicativo já estiver testado e em uso, não deverá ser alterado para usar uma biblioteca comum, portanto, você não poderá compartilhar código com ele.

Dentro do mesmo aplicativo , “copiar e colar” é ruim, mas entre bases de código desenvolvidas por equipes diferentes ou com diferentes ciclos de lançamento, “copiar e colar” pode ser a melhor opção.

Eu trabalhei para uma empresa semelhante. Como trainee, eu não conhecia melhor, então, quando iniciei um novo projeto, meu chefe também sugeriu colar o código de outro lugar. Bem, como você pode pensar, todo o software estava uma bagunça, até o ponto em que quando você tentou consertar um bug, dois novos erros apareceram.

Mesmo que o outro aplicativo já possua o recurso de que você precisa, o código para esse recurso pode simplesmente não se encaixar no seu aplicativo atual sem uma grande reescrita. É como pegar o motor de um Ford e tentar encaixá-lo em um Toyota. Geralmente, existe uma regra geral de que, se você precisar modificar mais de 25% do código que copiar, é melhor (mais barato) reescrevê-lo do zero.

A extração do código em questão em uma biblioteca parece atraente, mas pode ser mais difícil do que parece, dependendo de como o outro sistema é construído. Por exemplo, o código para esse recurso pode ser difícil de extrair porque ele interage com muitos outros códigos de maneiras impuras (por exemplo, acessando muitas variáveis ​​globais etc.)

Diga ao seu chefe que a parte do nome de todas as variáveis ​​inclui o nome do projeto antigo e agora você deve alterar todas elas manualmente. Se seu chefe não sabe (ou quer saber) por que copiar / colar é ruim, ele também pode acreditar nisso :)

Sim, o maior problema é que não se trata apenas de copiar e colar - sua cópia é colada e modificada levemente.

Mais tarde, quando uma das variantes coladas tiver um problema, ela será alterada. Mais tarde, outra variante é alterada.

Em seguida, você descobre que todas as variantes precisam ser alteradas porque a cópia original teve erros. Agora você está bem e verdadeiramente ferrado, porque todas as áreas coladas agora não são as mesmas.

E você não sabia, esse tipo de codificação ruim geralmente é quase totalmente sem comentários.

Para mim, a diferença é que, quando você tem várias cópias de código fazendo a mesma coisa, o que você tem é um monte de código. Quando você tem apenas um pedaço de código fazendo cada coisa específica, você tem um sistema.

Comportamentos de um sistema podem ser alterados com modificações de ponto único com bastante facilidade - alterar o comportamento de um monte de código requer um monte de código.

Eu gosto de sistemas, não um monte de código.

Existem vantagens e desvantagens entre a velocidade de desenvolvimento da funcionalidade imediata à sua frente (especialmente quando o aplicativo é pequeno) e os custos de manutenção de longo prazo à medida que o aplicativo cresce.

Copiar e colar é mais rápido para a funcionalidade imediata, mas vai custar caro à medida que o aplicativo aumenta de tamanho, em termos de correção de bugs e alterações no sistema e manutenção de fluxos de trabalho entre os diferentes componentes do aplicativo.

Esse é o argumento que os empresários precisam ouvir. É semelhante aos custos aceitos de manter uma frota de veículos; no entanto, com o software, os aspectos quebrados da arquitetura do software geralmente ficam ocultos para os negócios e só podem ser vistos pelos desenvolvedores.

Ele está certo que, se a equipe já implementou uma funcionalidade semelhante antes, repeti-la será muito mais fácil na segunda vez.

No entanto, você provavelmente deve explicar que cada aplicativo é diferente. Só porque você instalou uma porta em uma casa não significa que você pode instalar outra porta em outra casa em pouco tempo - você será mais rápido por causa da experiência (# portas instaladas), mas ainda levará tempo para você adquirir o equipamento , monte a porta, verifique se está bem presa e aperte-a na armação.

na minha empresa, sempre trabalhamos com classes e métodos e fazemos documentação técnica para eles. Eu acho que é a melhor prática se você puder usar seus próprios aplicativos de pesquisa svn com boas chaves para encontrar a classe de método usada antes :)