Como manter os mesmos fragmentos de código em vários projetos [fechado]

Sou um desenvolvedor independente que trabalha em vários projetos Android. Estou com problemas para manter a mesma funcionalidade em diferentes projetos. Por exemplo, três dos meus aplicativos usam as mesmas 2 classes; como são projetos diferentes, quando preciso fazer uma alteração nessas classes, preciso fazer três vezes. Existe uma solução simples para esse tipo de problema comum?

Separe o código compartilhado em uma biblioteca e inclua a biblioteca nos projetos.

Como desenvolvedor Android, você provavelmente está usando Java. Considere usar uma ferramenta de gerenciamento de dependências como Maven ou Ivy .

Um efeito colateral é que isso ajudará a manter a separação de preocupações , reforçando a modularidade. O custo é que pode levar algum trabalho para separar; o benefício é melhor manutenção futura. Além disso, se você decidir, poderá liberar a biblioteca separadamente (comercialmente ou como código aberto) de seus aplicativos.

Controle de versão. Git. Sub-módulos Git.

Coloque seus projetos sob controle de versão, usando um dvcs como git ou mercurial etc. Coloque o código compartilhado em um submódulo no git. Use o submódulo nos projetos que precisam dele. Quando você atualiza o submódulo, pode extrair as alterações para outros projetos com um único comando.

Ninguém mais mencionou a faca de dois gumes ainda, então vou adicionar meus 2 centavos. Se você possui vários projetos e todos compartilham algum código reutilizável, de acordo com as boas práticas / princípios de programação (DRY, por exemplo), coloque o código em um local global e estruture-o de maneira a que possa ser compartilhado por todos seus projetos sem modificações. Em outras palavras, defina as interfaces como genéricas e comuns o suficiente para atender a todos.

Existem poucas opções para fazer isso: 1) Crie um projeto base do qual os outros dependem. Este projeto pode criar uma distribuição binária que outros projetos consomem. 2) Puxe um modelo de código aberto dentro da sua organização. Faça com que o código comum seja sua própria ramificação de código e faça com que outros projetos obtenham código da mesma maneira que você usaria o código-fonte de qualquer OSS online.

Agora é aqui que a espada entra ...

Colocar o código em um local comum do qual outros projetos / pessoas dependem pode se tornar bastante caro. Digamos que você tenha um pedaço de código e 4 outros projetos dependam dele. Um de seus clientes que usa o projeto A encontra um erro e é necessário fazer uma correção. Você apressa a solução e esse cliente está feliz. Mas você acabou de modificar algum código do qual outros 3 projetos dependem. Você testou novamente tudo isso para garantir que nenhuma condição de borda foi introduzida?

O código comum também deve ser criado com muito mais cuidado e as interfaces do módulo devem ser muito melhor projetadas, porque esse código deve acomodar não um, mas quatro clientes e cada um deles pode apenas usar esse código com uma diferença tão pequena.

Se seus projetos estão em diferentes ciclos de lançamento, você precisa ter ainda mais cuidado com o gerenciamento do código comum. Você não pode simplesmente fazer alterações no código comum porque o projeto B precisa de nova funcionalidade, se você estiver a três dias de cortar a imagem final do projeto C.

Não estou dizendo que biblioteca comum não é a solução certa. Sou um forte apoiador do DRY e já criei e apoiei códigos comuns antes e continuo a fazê-lo. Só queria divulgar que simplesmente tornar o código comum terá suas próprias despesas.

Se você é o único reutilizando esse código, isso não é tão ruim. Se você tem uma equipe de engenheiros e eles começam a usar o código comum, as despesas aumentam ainda mais. Se houver outras pessoas envolvidas, espere que a inserção de código em uma biblioteca comum leve três vezes mais tempo que o necessário para chegar a um ponto em que você acha que está "completo". Você precisará: a) tornar a biblioteca mais robusta para proteger contra todos os tipos de condições de borda e uso inválido, b) fornecer documentação para que outros possam usar a biblioteca ec) ajudar outras pessoas a depurar quando usarem a biblioteca de uma maneira que você não antecipou e sua documentação não cobriu o caso de uso específico.

Algumas sugestões que posso oferecer:

1. Ter um código comum coberto por testes de unidade automatizados pode percorrer um longo caminho e lembrar que, quando você faz uma alteração, não acaba apenas com outro projeto.
2. Eu colocaria apenas funcionalidades muito estáveis ​​no código comum. Se você escreveu uma turma no ano passado para gerenciar o cronômetro e não a mudou em 9 meses, e agora tem outros 3 projetos que precisam de cronômetros, certifique-se de que seja um bom candidato. Mas se você acabou de escrever algo na semana passada, bem ... você não tem muitas opções (e eu odeio copiar / colar código provavelmente mais que o próximo), mas eu pensaria duas vezes antes de torná-lo comum.
3. Se parte do código é trivial, mas você já o usou em vários lugares, talvez seja melhor morder a bala, deixe o DRY em paz e deixe várias cópias ao vivo.
4. Às vezes, vale a pena não simplesmente colocar o código comum em um local comum e fazer com que todos o façam referência. Mas, em vez disso, trate o código comum como seu próprio liberável com versões, datas de lançamento e tudo mais. Dessa forma, o projeto C pode dizer: "Eu uso a biblioteca comum v1.3" e, se o projeto D precisar de novas funcionalidades, você deixa a v1.3 em paz, libera a v1.4 e o projeto C não é afetado. Lembre-se de que é MUITO, MUITO mais caro tratar o código comum como seu próprio produto, em vez de simplesmente fazer o check-in em um local comum.

Essa é uma solução idealizada e pode levar algum esforço para começar a funcionar.

O princípio DRY afirma que deve haver uma única fonte autorizada da verdade. Isso determina o uso de um único repositório de origem para toda a lógica do programa, sem duplicação; arquivos organizados para promover o compartilhamento e a reutilização de documentos.

Os requisitos pragmáticos da comunicação em um ambiente distribuído e com várias equipes sugerem que deve haver vários repositórios independentes, um para cada projeto ou colaboração.

Eu abordaria esse problema enviando para o inevitável: você precisará adotar as duas abordagens simultaneamente e usaremos scripts e automação para atenuar o fato de que as abordagens são contraditórias.

:-)

O único repositório unificado será sua única fonte autorizada. O processo de criação de cada projeto copiará todos os arquivos usados ​​por esse projeto (e apenas esses arquivos) em um local intermediário e, a partir desse local intermediário, será compilado. (Unison ou alguma ferramenta similar pode ser usada para mover deltas em vez de arquivos inteiros).

Esses locais intermediários podem ser usados ​​como cópias de trabalho locais para o conjunto de repositórios secundários, derivados ou a jusante. Os scripts de gancho pós-confirmação no repositório autoritativo atualizarão todos os locais intermediários e, para cada um deles, verificarão se foram alterados e farão o mesmo commit no repositório secundário correspondente se uma alteração for detectada.

Dessa forma, os vários repositórios secundários são mantidos em sincronia com o único repositório de origem autoritativo e o processo de criação garante que os repositórios secundários contenham todos os documentos (possivelmente compartilhados) e outros arquivos necessários para o êxito da construção. Por fim, e mais importante, o processo de desenvolvimento e construção garante que os arquivos sejam editados em um só lugar e apenas em um local, e que todas as cópias sejam mantidas consistentes e atualizadas.