Yalnızca çalışma zamanında bilinen geçişli bağımlılık çatışmalarına nasıl yaklaşıyorsunuz? [kapalı]

Büyük yazılım projelerinde çalışma zamanında oluşan geçişli bağımlılık sorunlarına normal olarak nasıl yaklaşıyorsunuz?

Son üç haftadır, yazılımın başka bir bileşeninde büyük bir yazılımın bir bileşenini başlatmaya çalışıyorum, ancak yalnızca çalışma zamanında bilinen geçiş bağımlılığı sorunları nedeniyle zaman zaman ölüyor.

Geçişli bağımlılık sorunları ile, belirli bir projenin bağımlılıklarının belirli bağımlılıklarının çalışma zamanında diğer bağımlılıklarla çarpışarak kararsızlığa veya anlık başarısızlığa neden olduğunu kastediyorum.

Yüzlerce, kullanımda yüzlerce bağımlılık vardır ve araçla ilişkili, tüm modüllerin birbirleri arasında derinden iç içe bağımlılıklara sahip olduğu diğer ekipler tarafından ayrı ayrı çalışılan yaklaşık 50 alt proje vardır. Kimse, projenin ölçeği ve karmaşıklığı göz önüne alındığında, tüm alt projelerin ne için kullanıldığını bilmiyor.

Bu durumda, etkilenen bileşenin bağımlılıklarının her biri için DAG'ın görsel bir temsilini oluşturmaya ve çalışma zamanında çarpışmaların nerede meydana gelebileceğini belirlemeye çalışır mısınız? Bağımlılıkların diğer alt projelerde nasıl yönetileceği konusunda hiçbir denetimim yok ve diğer geliştiriciler tarafından yazılan Java kodlarını değiştiremiyorum

Ortaya koyduğum çözümler sadece bir ya da iki saat çalışıyor ve sonra yukarı akış bileşenlerindeki değişiklikler nedeniyle çalışmayı bırakıyorlar. Akış yukarı bir bileşene örnek olarak, üzerinde çalıştığım projenin CI boru hattında daha erken bir aşamada inşa edildiği, bağlı olduğu bir eser vardır.

Başkalarının taleplerine göre , hangi teknolojinin kullanıldığına dair, çok fazla bilgi sağlamak için soruyu kapatma riski veya vücudun çok uzun sürmesi riskiyle ilgili bilgileri ekleyeceğim:

• Maven bağımlılık yönetimi için kullanılır; ve
• Yay, bir DI kabı olarak kullanılır;
• Bağımlılık sorunlarının çoğu, diğer modüllerin bağlamlarının çalışma zamanında yüklenmesinin bir sonucu olarak çakışan fasulye bağlamlarını içerir.
• Ürün düzgün çalışıyor ve programın işlevsel doğruluğundan kaçınmak için birim testlerin ve entegrasyon testlerinin smorgasbordları var

Genel olarak, belirli bir projenin bağımlılıklarının tüm olası kombinasyonları ile numaralandırılmadan bağımlılık çatışmalarını çözmenin yollarını tanımlamak için dile agnostik bir yaklaşım arıyorum .

Projeyi yeniden tasarlayamıyorum, ek kaliteli kapılar ekleyemiyorum, şirket genelinde paradigma kaymaları için zorlayamıyorum veya dil olarak çözüm olarak değiştiremiyorum.

Uygulamadaki her bir modülü kendi yürütme ortamını vermek için özel sınıf yükleyiciler kullanarak sorununuzu çözmek mümkün olabilir.

Temel olarak, evrensel olarak üzerinde mutabık kalınan bağımlılıklar ve modüllerin birbirleriyle iletişim kurması için gerekli olan tüm arabirimlerle birlikte, uygulamanın küçük bir çekirdeğinden oluşan çekirdek bir ortam tanımlarsınız. Daha sonra, yüklediğiniz her modül, çalışma ortamından (1) sınıflara, uygulama çekirdeğinden (2) sınıflara ve bu modülden (3) sınıflara ve doğrudan bağımlılıklarına erişebilen kendi sınıf yükleyicisini alır. Tüm modüller arası iletişim çekirdekte tanımlanan arayüzlerden geçer, böylece hiçbir modül doğrudan diğerine bağımlı olmaz.

Bu teknik, uygulama sunucularında, uygulamaların aksi takdirde çakışacak bağımlılıklara sahip olmasına izin vermek için kullanılır, böylece tekniğin çalışan bir uygulamasını, örneğin Tomcat'te (ve eğer şanslıysanız, Tomcat'in küçük değişikliklerle uygulama).

Maven veya Spring ile hiç çalışmadım, ancak size genel bir soruya genel bir cevap vermek için: bağımlılık sorunları söz konusu olduğunda, sisteminiz bunları mümkün olan en erken zamanda ve bu sorunlar tespit edildiğinde algılayacak şekilde tasarlanmalıdır. , olası nedenleri de dahil olmak üzere hemen bildirilmelidir.

İdeal olarak, zaman içindeki bu nokta "üretim çalışma zamanında" değildir. Zamanın en iyi noktası "inşa süresi" dir, ancak bu sizin durumunuzda imkansız görünmektedir. İkinci en iyi seçenek çalışma süresi testleridir. Bize "entegrasyon testleri" olduğunu söylediniz, ancak bağımlılık sorunlarını tespit etmedikleri için eksik görünüyorlar veya genel olarak bağımlılık çarpışmalarını test etmiyorlar. Sorunu çözmeye çalışmanız gereken yer burasıdır.

Ayrıca, testleri daha etkili hale getirmek için, bir bağımlılık sorunu ortaya çıktığında bileşenlerinizin "hızlı başarısız olması " gerekir . Bu, bir bağımlılık giderilir çözülmez ve bir bileşen yüklenir yüklenmez, potansiyel bağımlılık çarpışmaları derhal kontrol edilmeli ve bildirilmelidir. Bir çarpışma tespit edilmeden önce sistem ilk olarak bir saat çalışırsa, sorunun nedenini tespit etmek çok zorlaşır. Maven / Spring'in zaten yerleşik bir "hızlı başarısız" stratejisi sağlayıp sağlamadığını bilmiyorum, ancak durum böyle değilse, bu yönde düşünmeye çalışın.

Üretimdeki sorunları azaltmak için, daha az önemli bir alt bileşenle bir bağımlılık çarpışması meydana geldiğinde sisteminiz tamamen ölmeyecek şekilde tasarlanmalıdır. Hata elbette maskelenmemelidir, ancak sistem ideal olarak bu bileşenin yüklenmesini reddetmeli, problemi günlüğe kaydetmeli ve / veya sinyal vermeli ve kararlı bir durumda kalmalıdır. Bileşen ilk yüklendiğinde, sistem kararsız hale gelir ve sorunu ancak daha sonra tespit ederseniz, muhtemelen sistemi tamamen kapatıp yeniden başlatmanız gerekir, bu da kaçınmak istediğiniz daha iyi bir şeydir.

Örneğin, sisteminiz bir Web mağazasıysa ve "bülten aboneliği" alt modülünüz birkaç saat boyunca yüklenemezse, bu, tüm mağaza artık çalışmıyormuş gibi daha kolay tolere edilebilen bir şeydir.

Son olarak, bu sizin durumunuzda bir seçenek olmayabilir, ancak bileşenler birbirine karşı daha iyi bir şekilde çalıştırılabilirse ve bu bağımlılık çarpışmalarını önleyebilirse, bu düşünmeye değer bir yaklaşım olabilir.

Beni burada yüksek sesle düşünerek düşün. Gereksinimlere / zaman kısıtlamalarına bağlı olarak şunu düşünebilirim:

1) arayüzlerin ve uygulamalarının bir listesini oluşturun (varsa yansımayı kullanarak)

2) DI'nizin etrafında bir tür sarıcı oluşturun. Bir DI'den somut uygulama sağlaması istendiğinde, yürürlükte olan bir DI kuralı olup olmadığına bakın; kural varsa - DI'nizin sağladığını döndürmeniz yeterlidir; aksi halde bir arabirimin tek bir uygulaması varsa ve bir örnek - günlük oluşturabilir ve bir örneği döndürebiliyorsanız; aksi halde oturum açın ve başarısız olun.

Ne kadar dahil olmak istediğinize bağlı, sanırım, ama nihayetinde neyin gerektirdiğinin tam bir listesine sahip olmak istiyorsunuz - bu çözüm sonunda bu listeyi oluşturacaktır.

Ancak, tartışmasız bu çok fazla iş ve güvenilir değil - mavi ayda bir kez bağımlılık gerektiren garip bir durumunuz varsa?

"Akış yukarı bileşenlerde değişiklikler" dediğinde ne demek istiyorsun?

Seni doğru bir şekilde takip edersem sorun, kullanmanız gereken kodun Spring XML'de ifade edilen modüllere çalışma zamanı bağımlılıkları olması, ancak maven bunlardan bahsedilmemesi. Bu yüzden onları kullandığınızda ihtiyaç duydukları şeyler (geçişli bağımlılıklar) sınıf yolunuzda değildir ve yapmaları gerekeni yapmazlar.

Meslektaşlarınıza 'bunu nasıl çalıştırabilirim?' Diye sorduğunuzda tahmin ediyorum, '35 modül ve sürümün bu listesine ihtiyacınız var , bunu nasıl bilemezsiniz?'

Muhtemelen entegrasyon testi yapıldığında, gerekli modüller test bağımlılıkları olarak ilan edilir. Bu nedenle sistematik çözüm, test bağımlılığı olarak ilan edilen 3. taraf test araçlarından başka bir şeyleri olmadığından emin olmak için entegrasyon testi pom'larının denetimlerini ayarlamaktır. Bu, maven uygulayıcı eklentisi tarafından otomatikleştirilebilir .

Görünüşe göre bunu yapamazsınız, bu yüzden en iyi seçeneğiniz muhtemelen burada bulunur .