Projeleriniz için kullandığınız açık kaynak çerçevelerindeki değişiklikle nasıl başa çıkıyorsunuz?

Kişisel bir tuhaflığım olabilir, ancak kullandıkları kütüphaneler / çerçeveler dahil olmak üzere canlı projelerde kodları güncel tutmayı seviyorum. Bunun bir parçası, bir web uygulamasının tamamen yamalı ve güncel olması durumunda daha güvenli olduğuna inanıyorum. Bunun bir kısmı benim için takıntılı zorlama dokunuşudur.

Geçtiğimiz yedi ay boyunca, yazılımımızın büyük bir yeniden yazımını yaptık. Ürün olarak yavaş ve esasen ölü olan Xaraya çerçevesini bıraktık ve Cake PHP'ye dönüştürdük. (Cake'i seçtik, çünkü bize yazılımımızı çok hızlı bir şekilde yeniden yazma şansı verdi ve Xaraya üzerinde bunu yapmaya değer bir performans artışı sağladı.)

SimpleTest ile birim testi yaptık ve tüm dosya ve veritabanı adlandırma kurallarını takip ettik.

Cake şimdi 2.0 sürümüne güncelleniyor. Ayrıca, yükseltme için uygun bir geçiş yolu yok gibi görünüyor. Dosyalar için adlandırma kuralları kökten değişti ve SimpleTest'i PHPUnit lehine bıraktılar.

Bu bizi 1.3 şubede kalmaya zorlayacak, çünkü bir tür dönüştürme aracı yoksa, Cake'i güncellemek ve daha sonra yeni Kek çerçevesinin faydalarını elde etmek için eski kodumuzu yavaş yavaş geliştirmek mümkün olmayacak. . Yani, her zamanki gibi, Subversion depomuzda eski bir çerçeve oluşturacağız ve sadece gerektiğinde kendimiz yama yapacağız.

Ve bu beni her zaman yakalayan şey. Birçok açık kaynaklı ürün, projelere dayanarak projeleri güncel tutmayı yeterince kolay hale getirmez. Geliştiriciler yeni bir parlak oyuncakla oynamaya başladığında, eski dallara birkaç kritik yama yapılacak, ancak odaklarının çoğu yeni kod tabanında olacak.

Kullandığınız açık kaynaklı projelerde radikal değişikliklerle nasıl başa çıkıyorsunuz? Ve açık kaynaklı bir ürün geliştiriyorsanız, yeni sürümler geliştirirken yükseltme yollarını göz önünde bulunduruyor musunuz?

Sorun açık kaynak koduna özgü değil. Aynı konular ticari projeler için de geçerlidir. Belki daha da fazlası, kaynağınız olmadığı için şirket destek kaybederse kendinizi koruyabilirsiniz.

Son kullanıcı tipi açık kaynak projeleri hızlı yükseltme döngülerine sahiptir ve eski sürümler çok hızlı bir şekilde desteğini kaybeder. Öte yandan, kullanıcıların önemli ölçüde kodlama yapması için tasarlanan projeler, büyük bir yükseltmeden sonra eski şubenin uzun destek döngülerine sahip olma eğilimindedir . Önce stabilize ve olgunlaşmasını beklemek için zamanınızı alacak kadar uzun, daha sonra kendi kodunuzu geçirip iyice test edin.

En son ve en iyisine sahip olma arzusuna direnmek zor olabilir, ancak yazılımda kararlılık ve yeni özellikler arasında temel bir dengenin olduğunu fark edin. Birini diğerinden fedakarlık etmeden edemezsin. Bu yüzden bugfix dalları mevcuttur, böylece spektrumun hangi tarafının ihtiyaçlarınıza en uygun olduğunu seçebilirsiniz.

Bu sorunu kodumuzu modüle ederek ele aldık.

Birincil web sitemiz yaklaşık sekiz yıl önce oluşturuldu ve Spring Framework'e erken katkıda bulunanlardan biri tarafından inşa edilebilecek kadar şanslıydık, bu yüzden oldukça iyi inşa edilmiş bir temeldi. Ancak ne yazık ki, bu geliştiricinin Spring'i gittiği yön hakkında bir tartışmadan sonra kararlaştırmaya yetecek kadar şanssızdık, bu nedenle bu kod tabanı şimdi 1.1.4 Bahar'ın (veya bu vintage'in bir şeyinin) korunmayan bir çatalına yapıştı.

Spring'in yeni sürümlerine geçmek için kodu yeniden yazmaya çalıştık, ancak bu son derece zor oldu. Bu nedenle çözümümüz, Spring 3.x, Hibernate 3.6 vb.Gibi en yeni çerçeveleri kullanarak tamamen ayrı bir uygulamada sitenin yeni özelliklerini modül olarak oluşturmaya başlamaktı.

Şimdi aynı temel URL'de çalışan iki web uygulamamız var ve her yolu uygun uygulamaya tahsis etmek için Apache'nin mod_proxy modülünü kullanıyoruz. Örneğin, "/ members" eski uygulamaya, "/ directories" ise yeni uygulamaya gider. Ancak siteyi ziyaret edenlerin farklı uygulamalar kullandıkları konusunda hiçbir fikri yoktur; kullanıcıya tamamen aynı görünüyorlar.

İki uygulamanın iletişim kurması gerekir, örneğin bir üye siteye giriş yaptığında (yeni uygulamamızı kullanarak) şimdi giriş yaptıkları eski uygulamaya bildirmemiz gerekir. Bunu yalnızca localhost. İki uygulama arasında gereken entegrasyonun minimum düzeyde olduğu ortaya çıktı.

Bu çalışmanın önemli bir parçası, paylaşılan varlıkları tanımlamak ve paketlemekti. Böylece tüm statik metinler, grafikler, stil sayfaları, Javascript ve şablonlar orijinal uygulamadan hem yeni hem de eski uygulamaların kullandığı ayrı bir üçüncü projeye taşındı. Bu, her iki web uygulamasının tamamen ayrı olmalarına rağmen aynı şekilde görünmesini ve davranmasını sağlar.

Zamanla orijinal uygulamanın daha fazla ve sonunda tamamen gereksiz olana kadar değiştireceğimizi düşünüyorum. Bu teknikle ilgili güzel olan şey, bunu bir dizi küçük, düşük riskli değişiklikle yavaşça yapabilmemizdir - yeni bir sisteme büyük ve riskli ani bir geçişe gerek yoktur.

Ben her zaman yapmam. Birçok açık kaynaklı proje, önceki büyük sürümler için aktif bakım şubelerine sahiptir. Bazen bunlar, bu sürüme sahip olmak isteyen kişiler tarafından sağlanır. Birçok proje, kendileri büyük bir salıvermeye hazır olana kadar büyük bir sürümde kalır.

Ve bu beni her zaman yakalayan şey.

Her seferinde? Oldukça kötü seçimler yapmalısınız. Bunun gerçekleşmediği bir örnek olmalı.

Geliştiriciler yeni bir parlak oyuncakla oynamaya başladığında

Bu bir ipucu. Açık kaynaklı projeler kullanırken parlak yeni oyuncaklardan kaçının. 1.0 sürümünden kaçının.

Kullandığınız açık kaynaklı projelerde radikal değişikliklerle nasıl başa çıkıyorsunuz?

Adım 1. Açık kaynak projeleri çok ama çok dikkatli seçin. Her zaman iki veya daha fazla rakip projeyi karşılaştırın.

Adım 2. İki rakip projeyi karşılaştırırken, sunulan "temel" özelliği ve her ikisinin de bu projeye nasıl yaklaştığını anlamaya çalışın. Belirli bir API'yı çok erken "evlendirmekten" kaçının.

Adım 3. "Geç Bağlama" ve "Gevşek Bağlama" tasarım ilkelerini benimseyin. Açık kaynak proje değişikliklerinden yalıtmaya çalışın.

Adım 4. Açık kaynaklı projeler ile "kendi projelerinizi oluşturma" arasında açıkça maliyet / fayda karşılaştırmaları yapın. Arada bir, kendi çözümünüzü oluşturmak, açık kaynak bir çözümle baş etmekten daha iyi olabilir.

Dosya adlarını değiştirmek çok zor olmamalıdır. Evet, büyük, çirkin bir senaryo. Evet, dönüşüm yaparken birkaç hafta çalıştırılmalıdır. Ama bu sınırlı bir maliyet.

Her seferinde olursa , daha iyi başa çıkma stratejileri geliştirin. Gerçek dünyaya dair gözleminiz her zaman gerçekleşeceğinden, gerçek dünyanın değişmesini ummak gerçekten fazla yardımcı olmaz. Değişim konusunda zor kazanılan deneyimleriniz var. Bundan yararlanın. Bir enfeksiyon gibi düşünün ve kendi bağışıklık tepkinizi geliştirin.