Birden çok dilde sabitler nasıl yönetilmelidir?

Birden çok dilde işlevsel olarak aynı kütüphanenin neyi desteklediğini bildiğim bir durum var. Bunlar arasında paylaşılması gereken sabitler vardır (örneğin, json alan adı anahtarları veya hata kodları).

Şu anda bunu yapmak için her dilde sabitleri tanımlayan kodu olması.

Sorun bakımda geliyor. Yeni bir hata kodu eklersem, her kitaplıkta manuel olarak güncellemem gerekir. Bu birkaç için iyi olsa da ben güncellemek için 5 sdks söyledim sıkıcı olur. Bunlar için de tek bir hakikat kaynağına sahip olmak güzel olurdu.

Ben yapılandırma gibi bir tür dosya düşündüm ama sonra bizim inşa / yayın sürecine karmaşıklık ekler her dağıtılmış pakete dahil edilmesi gerekir .

Birden çok dil arasında paylaşılan sabitlerin bakımını yapmanın daha iyi bir yolu var mı?

Mevcut yaklaşımınızın muhtemelen en basit ve en basit olduğunu düşünüyorum, ancak burada birkaç alternatif fikir var:

• Sabitlerinizi (ve belki de modelleri) tüm dilleriniz için çapraz derlenmiş farklı bir pakete çıkarın. Kitaplığın tamamını çapraz olarak derleyebilirsiniz, ancak bu önemli miktarda sorunla birlikte gelebilir. Sadece çapraz derleme sabitleri o kadar fazla sorun olmayacak kadar basit olmalıdır. Sabitler paketinizi yayınlayabilir ve dile özgü kütüphanelerinizde ona bağlı olabilirsiniz. Haxe muhtemelen yapabilir. Bu yaklaşım iyidir çünkü derleme zamanı kontrolüne sahip olursunuz (derlenmiş diller için)
• Yapılandırmayı merkezi bir serviste saklayın. Örneğin, sabun web servislerinde Web Servis Açıklama Dili (WSDL) ve REST servislerinde servis işlemlerini ve mesajlarını açıklayan Web Uygulama Açıklama Dili (WADL) bulunur. Ayrıca Spring Cloud Config gibi genel merkezi yapılandırma hizmetleri de vardır
• Yapılandırma dosyası. Bunu zaten önerdiğini biliyorum, ancak derleme / bırakma sürecini çok karmaşık hale getirmesi gerektiğini düşünmüyorum. Yapılandırma dosyanızı ayrı bir derleme projesine yerleştirin (burada sürümleyebilirsiniz). Projeyi tüm dile özgü paket depolarınızda (Maven, Nuget, NPM, vb.) Yayınlayın, sonra dile özgü kitaplıklarınızda pakete güvenebilirsiniz. Bu, inşa hattınızda ek bir projeye sahip olmaktan daha karmaşık olmamalıdır.
• RubberDuck'un önerdiği gibi, kod üretimi çapraz derlemeye iyi bir alternatiftir. Ortak bir yapılandırma kullanarak her dil için sabit tanımlar oluşturabilirsiniz.

Harika bir soru! Bende aynı sorun var; sabitlerim aslında: uygulamalarımda hangi diller destekleniyor ve uygulamadaki işlevsellik ile ilgili oldukları için bu diller hakkında ek bilgiler var.

Ne yazık ki, bulduğum en iyi şey (sizin gibi) şu anda yaptığınız gibi her dil için sabitleri yeniden tanımlamaktır (biliyorum, kesinlikle bunu duymak istediniz ).

Açıkçası yanlış geliyor çünkü DRY ( WET ?? ) 'in tam tersi . Ancak, sabitler o kadar seyrek değişmelidir ki, her dil için 5-10 dakikalık yeniden tanımlamak beni gerçekten rahatsız etmiyor. Günün sonunda, paylaşılan yapılandırma veya kod oluşturma gibi bazı 'zarif' çözümlerle ilgili küçük sorunların çözülmesi saatler veya günler alabilir, bu yüzden gerçekten ne kazanılır? Düzeltmek için ek çaba harcayabilecek bir şeylerin yanlış gitme riski ile birlikte karmaşıklık da ele almak istediğim bir şey değil.

Ayrıca, uygulamanızda eklediğinizde veya değiştirdiğinizde bunları dil başına yeniden tanımlayan çok fazla sabit varsa, çok zaman alırsa, başa çıkmak için daha önemli bir kod kokunuz olabilir ve bu noktada, daha karmaşık bir şeye.

Kısacası, bunları her dil için yeniden tanımlamak en iyi çözümüm oldu ve başa çıkmak istediğimden daha fazla risk faktörü olmayan daha fazla KURU şey düşünmedim.

Bir şey için kesinlikle yapmak olsa da, sizin sabitleri olduğundan emin olmaktır iyi belgelenmiş (biz tutmak nereye, docs 'tahta çizim', vb özellikleri, çeşitli dokümanlar ile bir şirket documentarion repo var genelleştirilmiş (ve Dil Agnostik) biçimini bu belge). Ayrıca tanımlarını senkronize tutmak için mekanizma (lar) ın bulunduğundan emin olun. Bu, kasıtlı kod çoğaltmasından kaynaklanan az miktarda psikolojik sıkıntı dışında, çoğaltma yaklaşımıyla ilgili olarak büyük bir sorun. Ama sonunda, sürekli değişikliklerin çok kasıtlı ve seyrek olmalı, bu nedenle eşzamanlılık sorunları esasen sıfır olmalıdır.

Yıllar boyunca, aynı kütüphanede her zaman dillerin kendisinde tanımlanmış sabitleri olan çok sayıda kütüphanenin (şu anda ne olduklarını hatırlamak için çok yorgun) çok dilli portları gördüğümü de belirtmeliyim. Paylaşılan yapılandırma yok, kod oluşturma yok (Google API istemci kitaplıkları hariç ... ancak hadi, Google bu karmaşıklığı sağlayacak kaynaklara sahip). Sanırım bunun üzerine bir tuğla duvara çarptık. Belki birisi sonunda bu problemle başa çıkmak için bir kütüphane bulur;)

Umarım kütüphanenizin çekirdeği bir dilde yazılır ve diğer kütüphaneler çekirdek kütüphaneyi çağırmak için FFI ( https://en.wikipedia.org/wiki/Foreign_function_interface ) kullanır. Bu, sabitleri ve tanımları yayınlamak için bir API sağlamak için merkezi bir konum sağlayacaktır. Bu şekilde her şey kendi içinde kütüphanede bulunur. Bunu sadece Samuel'in cevabına dahil olmadığı anlaşılıyor.

Bence bu gerçekten kullanıcı tabanınızın ne kadar yetenekli olduğuna bağlı. Başka bir yapılandırma dosyasının etrafından geçmeyi başarabilecek kadar yetenekli mi? Yeni bir hizmet kurabilirler mi? Desteklediğim kullanıcıların büyük çoğunluğu için, her şeyin kendi içinde olmasını isterdim - bu şekilde kullanıcıların düşünmesi gerekmez.