Bağımlılık alma korkusuyla nasıl baş edilir

54

İçinde bulunduğum takım, şirket ortakları tarafından platformumuzla bütünleşmek için kullanılabilecek bileşenler oluşturuyor.

Bu nedenle, (üçüncü taraf) bağımlılıkları getirirken çok dikkatli davranmamız gerektiğine katılıyorum. Şu anda üçüncü taraf bağımlılığımız yok ve çerçevenin en düşük API seviyesinde kalmak zorundayız.

Bazı örnekler:

Çerçevenin en düşük API seviyesinde kalmak zorundayız (.NET Standard). Bunun arkasındaki neden, bir gün sadece bu çok düşük API seviyesini destekleyen yeni bir platformun gelmesi olabilir.
JSON'u (de) serileştirmek için kendi bileşenlerimizi uyguladık ve JWT için de aynı şeyi yapıyoruz. Bu, çerçeve API'sinin daha yüksek bir düzeyinde kullanılabilir.
Standart kütüphanenin HTTP çerçevesi etrafına bir sarmalayıcı uyguladık, çünkü standart kütüphanenin HTTP uygulamasına bağımlı olmak istemiyoruz.
XML'den / XML'den eşleme için kullanılan kodun tümü aynı sebepten dolayı "elle" yazılır.

Çok uzaklara gittiğimizi hissediyorum. Bununla nasıl başa çıkacağımı merak ediyorum, çünkü bunun hızımızı çok etkilediğini düşünüyorum.

— Bertus
kaynak

20

Bunun bir gerekçesi var mı (örneğin, dış gereklilik) veya cehaletten mi kaynaklanıyor?

— Blrfl

6

CodeBase'in küçük bir kısmını denemek, genel bir kütüphane olmaya çalışmayan bir izolasyon katmanı oluşturmak, ancak ihtiyaçlarınızı modelleyen soyut bir arayüz tanımlamak; daha sonra hem kendi uygulamanızı hem de 3. tarafın bağımlılığını ardına koyun ve iki versiyonun nasıl çalıştığını / çalıştığını karşılaştırın. Artıları ve eksileri tartışın, uygulamaları değiştirmenin ne kadar kolay (veya ne kadar zor) olacağını değerlendirin, sonra bir karar verin. Kısacası, işleri nispeten düşük riskli bir şekilde test edin, ne olduğunu görün, sonra karar verin.

— Filip Milovanović

73

“Şu anda üçüncü taraf bağımlılığımız yok” Bu iddiada bulundukları zaman beni her zaman güldürüyor. Tabii ki. Kendi derleyicinizi, IDE'nizi, standart kütüphanelerin uygulamasını yazmadınız. Dolaylı olarak (veya doğrudan) kullandığınız shard nesne kütüphanelerinin hiçbirini yazmadınız. Ne kadar bağımlı olduğunuz 3. parti yazılım ve kütüphaneleri fark ettiğinizde, "bağımlılıklar kötüdür" fikrini düşürebilir ve tekerleği yeniden icat etmekten keyif almazsınız. Sadece sahip olduğunuz bağımlılıkları işaretler ve neden kabul edilebilir olduklarını sorardım, ama Jackson ayrıştırma değildir.

— UKMonkey

8

Bu, asla bitirme projeleri gibi alternatif geri çekilmeler olduğunu söyledi. Ama yazılım işlerini ve istihdamını teşvik ediyor :)

— marşal zanaat

5

Emtia yazılımını yeniden icat ederek çaba harcamanız konusunda haklısınız. Bunun, "tüm bağımlılıklardan kaçınmak" için hiçbir yere yakın olmadığı konusunda yanılıyorsunuz. Microsoft'ta Excel ekibi bir kez C takımda bir bağımlılık alarak önlemek için kendi C derleyicisi yazdı Microsoft'ta . İşletim sistemleri, üst düzey çerçeveler vb. Gibi büyük bağımlılıklar alıyorsunuz.

— Eric Lippert

94

... Çerçevenin en düşük API seviyesinde kalmak zorundayız (.NET Standard)…

Bu benim için, kendinizi potansiyel olarak çok fazla kısıtlamakla kalmayıp, yaklaşımınızla birlikte kötü bir düşüşe de yönelebileceğiniz gerçeğini vurguluyor.

.NET Standard değildir ve asla " çerçevenin en düşük API seviyesi " olmayacaktır . .NET için en kısıtlayıcı API kümesi, Windows Phone ve Silverlight'ı hedef alan taşınabilir bir sınıf kitaplığı oluşturarak elde edilir.

Hangi .NET Standard sürümünü hedeflediğinize bağlı olarak, .NET Framework, .NET Core , Mono ve Xamarin ile uyumlu çok zengin bir API kümesiyle karşılaşabilirsiniz . Ve bu nedenle tüm bu platformlarda çalışacak .NET Standard uyumlu birçok üçüncü parti kitaplık var.

Daha sonra, 2019 Sonbaharında piyasaya sürülmesi muhtemel olan .NET Standard 2.1 var. .NET Core, Mono ve Xamarin tarafından desteklenecek. En azından öngörülebilir bir gelecek için ve her zaman büyük olasılıkla .NET Framework'ün herhangi bir sürümü tarafından desteklenmeyecektir . Bu nedenle yakın gelecekte, .NET Framework " çerçevenin en düşük API seviyesi " olmaktan çok , çerçevenin yerini alacak ve ikincisi tarafından desteklenmeyen API'lere sahip olacaktır.

Bu nedenle, " Bunun arkasındaki sebep, yeni platformların bir gün sadece bu çok düşük API seviyesini destekleyen bir platformun gelebileceği " konusunda çok dikkatli olun .

Sonra üçüncü taraf kütüphaneleri sorunu var. JSON.NET örneğin, .NET Standard ile uyumludur. .NET Standard ile uyumlu herhangi bir kütüphane garantilidir - API-bilge - .NET Standard'ın o sürümüyle uyumlu tüm .NET uygulamalarıyla çalışmak için. Böylece kullanmayarak ve JSON kütüphanenizi oluşturarak ek bir uyumluluk elde edemezsiniz. Siz sadece kendiniz için daha fazla iş yaratın ve şirketiniz için gereksiz masraflara maruz kalın.

Yani evet, kesinlikle benim görüşüme göre çok fazla alıyorsunuz.

— David Arno
kaynak

16

“Siz sadece kendiniz için daha fazla iş yaratıyorsunuz ve şirketiniz için gereksiz masraflara maruz kalıyorsunuz.” - ve güvenlik yükümlülükleri. Özyinelemeli bir nesne verirseniz JSON kodlayıcınız yığın taşmasıyla kilitleniyor mu? Ayrıştırıcınız kaçış karakterleri doğru işliyor mu? Çıkmayan karakterleri olması gerektiği gibi mi reddediyor? Eşleştirilmemiş yedek karakterler nasıl olur? JSON 2 ^ 64'ten daha büyük bir sayıyı kodladığında taşması olur mu? Yoksa sadece evalkolayca atlanan bazı sağlık kontrolleri ile küçük bir sarıcı mı?

— John Dvorak

4

".NET için en kısıtlayıcı API kümesi, Windows Phone ve Silverlight'ı hedef alan taşınabilir bir sınıf kitaplığı oluşturarak elde edilir." Bir uzuv üzerinde dışarı çıkacağım ve en azından bu alt kümede var olan tüm olası uygulamalar tarafından desteklenmeyen bazı API'lerin olduğunu iddia edeceğim (ve hiç kimse artık microsoft bile değil, WinPhone veya Silvernight'ı umursamıyor). .NetStandard 2.0'ı modern bir çerçeve için bir hedef olarak kullanmak çok basiretli ve özellikle sınırlayıcı görünmüyor. 2.1’e güncelleme yapmak farklı bir hikaye ancak bunun olacağına dair hiçbir gösterge yok.

— Voo

Gelecekteki platformların dışında, muhtemelen daha az değil, daha fazla destek vermenin yanı sıra, olabilecek her şeyi geliştirmek inanılmaz derecede pahalıdır (ve yine de bir şeyleri kaçırmanız muhtemeldir). Bunun yerine, tekerleği yeniden icat etmeden gelişen olacak mal olacak zaman ihtiyaç vardır bazı yeni duruma adapte daha zaman kazandırır.

— Jasper

51

Çerçevenin en düşük API seviyesinde kalmak zorundayız (.net standardı). Bunun arkasındaki neden, bir gün sadece bu çok düşük API seviyesini destekleyen yeni bir platformun gelmesi olabilir.

Buradaki sebep oldukça geriye doğrudur. Daha eski, daha düşük API seviyelerinin yeni olanlardan daha eskimiş ve desteklenmemiş olma olasılığı daha yüksektir. Bahsettiğim senaryoda makul düzeyde bir uyumluluk düzeyi sağlamak için "son teknolojinin" arkasında rahat bir yolun kalmasının makul olduğunu kabul ediyorum.

JSON'u serileştirmek için kendi bileşenlerimizi uyguladık ve JWT için de aynı şeyi yapma sürecindeyiz. Bu, çerçeve API'sinin daha yüksek bir seviyesinde bulunur. Standart kütüphanenin HTTP çerçevesi etrafına bir sarmalayıcı uyguladık çünkü standart kütüphanenin HTTP uygulamasına bağımlı olmak istemiyoruz. XML'den / XML'den eşleme için kullanılan kodun tümü aynı sebepten dolayı "elle" yazılır.

Bu delilik . Herhangi bir nedenle standart kütüphane işlevlerini kullanmak istemeseniz bile, açık kaynak kitaplıklar, yukarıdakilerin tümünü yapan ticari olarak uyumlu lisanslara sahiptir. Zaten yazılmıştı, bir işlevsellik, güvenlik ve API tasarım bakış açısından kapsamlı bir şekilde test edildiler ve birçok başka projede yaygın olarak kullanıldılar.

En kötüsü olursa ve bu proje ortadan kalkarsa veya devam etmeyi bırakırsa, yine de kütüphaneyi inşa etme kodunu aldınız ve bunu sürdürmesi için birisini atadınız. Ve olasıdır hala sen gerçekte daha sonra bakmak için, daha temiz, daha sürdürülebilir kodunu test ettik edeceğiz beri, kendi haddelenmiş olsaydın çok daha iyi bir konumda.

Projenin sürdürüldüğü ve bu kütüphanelerde böcek veya istismarların bulunduğu daha olası bir senaryoda, onlar hakkında bilgi sahibi olacaksınız, böylece daha yeni bir sürüme ücretsiz yükseltme veya sürümünüzü düzeltme gibi Bir kopyasını aldıysanız düzeltme ile.

— berry120
kaynak

3

Ve yapamasanız bile, başka bir kütüphaneye geçmek, kendinize ait kitaptan daha kolay ve daha iyidir.

— Monica ile Hafiflik Yarışları,

5

Düşük seviye malzemelerin daha hızlı öldüğü mükemmel noktası. Soyutlamalar yapmanın tek yolu bu.

— Monica ile Hafiflik Yarışları,

"Daha eski, daha düşük API seviyelerinin eskilerine göre eski ve desteksiz olma olasılığı daha yüksektir". Ha? NetSTandards bildiğim kadarıyla birbirlerinin üzerine kurulur (2.0 = 1.3 + X anlamına gelir). Ayrıca Standartlar basitçe .. standartlar, uygulamalar değil. Bir standardın desteklenmemesi hakkında konuşmanın bir anlamı yoktur, çoğu zaman o standardın spesifik uygulamaları gelecekte olabilir (ancak bunun neden endişe duymadığını daha önceki noktaya bakın). Kütüphaneniz NetStandard 1.3 dışında bir şeye ihtiyaç duymuyorsa, 2.0 olarak değiştirmeniz için hiçbir neden yoktur

— Voo

11

Bütün bunlar müşterileriniz için iyidir. Popüler bir açık kaynak kütüphanesi bile, bir nedenle kullanmaları imkansız olabilir.

Örneğin, müşterileri ile açık kaynaklı ürün kullanmamaya söz veren bir sözleşme imzalamış olabilirler.

Ancak, belirttiğiniz gibi, bu özellikler ücretsizdir.

Market zamanı
Paketin boyutu
Verim

Bu dezavantajları artıracağım ve sunduğunuz uber uyumluluk seviyesine gerçekten ihtiyaç duyup duymadıklarını öğrenmek için müşterilerle konuşacağım.

Örneğin, tüm müşteriler zaten örneğin Json.NET kullanıyorsa, kendi seri kaldırma kodunuz yerine ürününüzde kullanmak, boyutunu küçültür ve geliştirir.

Ürününüzün ikinci bir sürümünü tanıtırsanız, üçüncü taraf kütüphanelerini ve bununla uyumlu bir sürümünü kullanan bir ürünü satın almayı yargılayabilirsiniz. Müşteriler, en son özellikleri biraz daha erken almak için üçüncü tarafları mı kullanacaklar veya 'uyumlu' sürümlere sadık kalacaklar mı?

— Ewan
kaynak

11

Evet açıkça katılıyorum ve listenize "güvenlik" eklerdim. İyi test edilmiş çerçevelere ve kesinlikle standart kütüphaneye kıyasla, özellikle JSON / JWT gibi şeylerle kodunuzda bir güvenlik açığı oluşturabileceğiniz bazı potansiyeller vardır.

— Bertus

Evet, listeyi yapmak zor, çünkü güvenlik ve performans gibi şeyler her iki yöne de gidebilir. Ancak, bitirme özellikleri ile iç bileşenlerin tam özellikli olmasını / anlaşılmasını sağlama arasında bariz bir çıkar çatışması var

— Ewan

12

"Müşterileriyle açık kaynaklı ürün kullanmamaya söz veren bir sözleşme imzalamış olabilirler" - açık kaynak kodlu .NET Standard kullanıyorlar. Ürününüzü açık kaynaklı bir çerçeveye dayandırırken bu sözleşmeyi imzalamak kötü bir fikirdir.

— Stephen

Ve hala insanlar bunu yapıyor

— Ewan

7

Kısa cevap, üçüncü taraf bağımlılıklarını tanıtmaya başlamanız gerektiğidir. Bir sonraki stand-up toplantınız sırasında herkese işte bir sonraki haftanın yıllar içinde yaşadıkları en eğlenceli zaman olacağını söyleyin - JSON ve XML bileşenlerini açık kaynaklı, standart kütüphane çözümleriyle değiştirecekler. Herkese JSON bileşenini değiştirmek için üç günleri olduğunu söyleyin. Yaptıktan sonra kutlayın. Party vermek. Bu kutlamaya değer.

— Çift Görme Şişman Ağır
kaynak

2

Bu yanakta dil olabilir, ancak gerçekçi değildir. Bir "kıdemli" geliştiricinin (sadece eğitim ile kıdemli) bir devlet makine kütüphanesi yazmakla küçük bir devi görevlendirdiği bir şirkete katıldım. İçinde beş tane geliştirici ayı vardı ve hala can sıkıcıydı, bu yüzden söküp birkaç gün içinde anahtar teslimi bir çözümle değiştirdim.

— No U,

0

Temel olarak hepsi risk ve çabaya dayanıyor.

Ek bir bağımlılık ekleyerek veya çerçevenizi güncelleyerek veya daha yüksek seviyeli API kullanarak, çabanızı düşürürsünüz ancak risk alırsınız. Bu yüzden bir SWOT analizi yapmayı öneririm .

Güçlü Yönler: Daha az çaba, çünkü kendiniz kodlamanız gerekmez.
Zayıf Yönler: El yapımı bir çözüm kadar özel ihtiyaçlarınız için özel olarak tasarlanmamıştır.
Fırsatlar: Pazarlanma süresi daha küçüktür. Dış gelişmelerden kar edebilirsiniz.
Tehditler: Müşterileri ek bağımlılıklar ile rahatsız edebilirsiniz.

El yapımı bir çözüm geliştirmek için ek bir çaba görebileceğiniz gibi, tehditlerinizi azaltmaya yönelik bir yatırımdır. Şimdi stratejik bir karar verebilirsiniz.

— Dominic Hofer
kaynak

-2

Bileşen kütüphanelerinizi, bağımlılıkları olmayan (esasen şu anda ne yaptığınız) olmayan bir “Çekirdek” kümesine ve “Çekirdek” ve 3. parti kütüphanelerinize bağımlı olan bir “Ortak” kümeye bölün.

Bu şekilde biri yalnızca "Çekirdek" işlevsellik isterse, buna sahip olabilir.

Birisi "Ortak" işlevsellik isterse, buna sahip olabilir.

Ve "Ortak" yerine "Çekirdek" olanı yönetebilirsiniz. "Common" uygulamasına daha hızlı bir şekilde işlevsellik ekleyebilir ve kendi uygulamanızı sağlamanın mantıklı olması durumunda kendi "Core" uygulamanıza taşıyabilirsiniz.

— Turtle1363
kaynak