Como você lida com as mudanças nas estruturas de código aberto que você usa para seus projetos?

Pode ser uma peculiaridade pessoal minha, mas eu gosto de manter o código em projetos atuais - incluindo as bibliotecas / estruturas que eles usam. Parte disso é que acredito que um aplicativo Web é mais seguro se estiver totalmente corrigido e atualizado. Parte disso é apenas um toque de compulsão obsessiva da minha parte.

Nos últimos sete meses, fizemos uma grande reescrita em nosso software. Descontinuamos o framework Xaraya, que era lento e essencialmente morto como produto, e convertido para Cake PHP. (Escolhemos o Cake porque nos deu a chance de fazer uma reescrita muito rápida do nosso software e um aumento de desempenho suficiente sobre o Xaraya para fazer valer a pena.)

Implementamos o teste de unidade com o SimpleTest e seguimos todas as convenções de nomenclatura de arquivos e bancos de dados, etc.

O bolo agora está sendo atualizado para 2.0. E, não parece haver um caminho de migração viável para uma atualização. As convenções de nomenclatura para arquivos mudaram radicalmente e descartaram o SimpleTest em favor do PHPUnit.

Isso nos forçará a permanecer no ramo 1.3 porque, a menos que haja algum tipo de ferramenta de conversão, não será possível atualizar o Cake e, gradualmente, melhorar nosso código legado para colher os benefícios da nova estrutura do Cake . Então, como sempre, vamos acabar com uma estrutura antiga em nosso repositório Subversion e corrigi-la conforme necessário.

E é isso que me emociona toda vez. Muitos produtos de código aberto não facilitam o suficiente para manter os projetos baseados neles atualizados. Quando os desenvolvedores começarem a brincar com um novo brinquedo brilhante, alguns patches críticos serão feitos para ramificações mais antigas, mas a maior parte do foco será na nova base de código.

Como você lida com mudanças radicais nos projetos de código aberto que você usa? E, se você estiver desenvolvendo um produto de código aberto, mantenha os caminhos de atualização em mente ao desenvolver novas versões?

O problema não é exclusivo do código aberto. Os mesmos problemas ocorrem com projetos comerciais. Talvez ainda mais porque você não tem fonte, pode se manter se a empresa deixar de apoiar.

Projetos de código aberto do tipo usuário final têm ciclos rápidos de atualização e versões antigas perdem o suporte muito rapidamente. Por outro lado, os projetos projetados para os usuários colocarem um esforço significativo de codificação no topo tendem a ter longos ciclos de suporte da ramificação antiga após uma grande atualização. Tempo suficiente para você levar o seu tempo primeiro, esperando que ele se estabilize e amadureça, depois migrando e testando completamente seu próprio código.

Pode ser difícil resistir à tentação de obter o melhor e o mais recente, mas perceba que existe uma troca fundamental em software entre estabilidade e novos recursos. Você não pode ter um sem sacrificar o outro. É por isso que existem ramificações de correções de erros, para que você possa escolher qual lado do espectro melhor se adapta às suas necessidades.

Lidamos com esse problema modularizando nosso código.

Nosso site principal foi construído há cerca de oito anos e tivemos a sorte de ser construído por um dos primeiros colaboradores do Spring Framework, por isso era uma base bem construída. Mas, infelizmente, também tivemos a má sorte de que esse desenvolvedor decidiu bifurcar o Spring após uma discussão sobre a direção que estava seguindo; portanto, essa base de código agora está presa em um fork não mantido do Spring 1.1.4 (ou algo desse vintage).

Tentamos reescrever o código para passar para novas versões do Spring, mas isso se mostrou extremamente difícil. Portanto, nossa solução foi começar a criar novos recursos do site como módulos em um aplicativo completamente separado, usando as estruturas mais recentes, como Spring 3.x, Hibernate 3.6, etc.

Agora, temos dois aplicativos da Web em execução na mesma URL base e usamos o módulo mod_proxy do Apache para alocar cada caminho para o aplicativo apropriado. Por exemplo, "/ members" vai para o aplicativo antigo e "/ directory" vai para o novo aplicativo. No entanto, um visitante do site não tem idéia de que está usando aplicativos diferentes; eles parecem exatamente iguais para o usuário.

Os dois aplicativos precisam se comunicar, por exemplo, quando um membro efetua login no site (usando nosso novo aplicativo), precisamos notificar o aplicativo antigo de que agora está logado. Fazemos isso usando um serviço da Web simples, exposto apenas a localhost. A quantidade de integração necessária entre os dois aplicativos acabou sendo mínima.

Uma parte importante de fazer esse trabalho foi identificar e empacotar ativos compartilhados. Portanto, todo o texto estático, gráficos, folhas de estilo, Javascript e modelos foram movidos para fora do aplicativo original em um terceiro projeto separado, usado pelos aplicativos novos e antigos. Isso garante que os dois aplicativos da Web tenham a aparência e a ação da mesma maneira, mesmo estando completamente separados.

Imagino que, com o tempo, substituiremos mais e mais o aplicativo original até que, eventualmente, ele seja completamente desnecessário. O bom dessa técnica é que podemos fazê-la lentamente por meio de uma série de pequenas mudanças de baixo risco - não há necessidade de uma mudança repentina maciça e arriscada para um novo sistema.

Eu nem sempre faço isso. Muitos projetos de código aberto têm ramificações de manutenção ativas mantidas para versões principais anteriores. Às vezes, eles são mantidos por pessoas que precisam dessa versão. Muitos projetos permanecem em uma versão principal até que eles próprios estejam prontos para uma versão principal.

E é isso que me emociona toda vez.

Toda vez? Você deve estar fazendo escolhas notavelmente ruins. Deve haver um exemplo em que isso não aconteceu.

Quando os desenvolvedores começam a brincar com um novo brinquedo brilhante

Essa é uma dica. Evite brinquedos novos e brilhantes ao usar projetos de código aberto. Evite a versão 1.0.

Como você lida com mudanças radicais nos projetos de código aberto que você usa?

Etapa 1. Escolha projetos de código aberto com muito, muito cuidado. Sempre compare dois ou mais projetos concorrentes.

Etapa 2. Ao comparar dois projetos concorrentes, tente entender o recurso "essencial" oferecido e como eles o abordam. Evite "casar" uma API específica muito cedo.

Etapa 3. Adote os princípios de design de "Late Binding" e "Loose Coupling". Tente isolar as alterações do projeto de código aberto.

Etapa 4. Faça explicitamente comparações de custo / benefício entre projetos de código aberto e "rolando por conta própria". De vez em quando, criar sua própria solução pode ser melhor do que lidar com uma solução de código aberto.

Alterar os nomes dos arquivos não deve ser muito difícil. Sim, é um script grande e feio. Sim, ele deve ser executado por várias semanas durante a conversão. Mas é um custo finito.

Se acontecer sempre , desenvolva melhores estratégias de enfrentamento. Como sua observação do mundo real é que isso sempre acontece, esperar que o mundo real mude não ajuda muito. Você tem alguma experiência conquistada com muito esforço. Alavancar isso. Considere isso como uma infecção e desenvolva sua própria resposta imune.