Geliştiricilerin gerçek programdan önce bir dahili kütüphane derlemeleri beklenmeli mi?

Son zamanlarda birlikte çalıştığım kıdemli bir geliştirici, geliştiricilerin en son sürümü almasını ve projelerinin bir parçası olarak büyük bir iç kütüphane derlemesini gerektiren bir durum ortaya koydu. Bu durum, proje ekiplerinin, geliştiricinin, kaynak kodların geliştirici makinelerinde kullanılabilir olmasını sağlamanın kütüphaneleri okuyabildiği için zaman kazandırdığını iddia ettiği dahili bir Maven deposundan almaları gereken kararlı bir sürüm üzerinde çalışması gerektiği yönündeki ters argümanın tersidir. gerekli işlevselliğin olup olmadığını belirlemek için kod.

Kıdemli geliştiricinin geçerli bir argümanı var mı? Ya da geliştiricilerin temel kapsülleme felsefesine karşı kütüphane kaynak kodunu çalıştırmasını ve hatta ilk etapta kütüphaneyi okumasını istemek mi?

Bu üst düzey geliştiricinin argümanı benim için hiçbir anlam ifade etmiyor.

Onlar sürekli bir dahili kütüphane alma ve derleme yükü eklemek istiyorum sadece devs bazen kaynak kodunu okuyabilir böylece? Bu, geliştiricilerin kaynak koduna yalnızca bir özelliğin olup olmadığını kontrol etmeleri gerektiğinde bakmaktan çok daha fazla zaman harcayacak.

Kütüphane ve müşteriler farklı gelişim grupları tarafından geliştiriliyorsa ve kütüphane aktif olarak geliştiriliyorsa bu özellikle kötü bir fikirdir. İstemci geliştiricilerin kütüphanede dengesizlikten izolasyonu olmayacaktır.

Kaynak kodun geliştiricilere normal yapılarının bir parçası olmaya zorlamadan neden erişilemediğini anlamıyorum.

Öneri

Gerekli işlevselliğin mevcut olup olmadığını belirlemek için kütüphanenin kaynak kodunu okuyan istemci tarafı geliştiriciler tarafından zamandan tasarruf edebiliriz

Alternatif bir öneride bulunabilirsiniz

Hangi işlevselliğin mevcut olduğunu belirtmek için kütüphaneyi belgeleyen biri tarafından zaman kazanabiliriz.

Kaynağı yerel olarak inceleme yeteneğine sahip olmanın bir fayda olduğunu iddia etmem, ancak kütüphane aktif geliştirme aşamasındaysa (muhtemelen projenizin ihtiyaçlarına destek eklemek için) o zaman geliştiricilere ihtiyaç duymanın mantıksız olduğunu düşünmüyorum Güncellemeleri sık sık indirin (muhtemelen günde birkaç kez). Yine de geliştiricilerin kaynaktan derleme yapmasını istemek yerine derlenmiş (ve birim testli) bir ikili dosya oluşturmak daha iyi bir iş mantıklıdır.

Projenizde, derlenen en son sürümün kullanılabileceği bir tür paylaşılan depo kurma olanağınız var mı? İdeal olarak, getirme ve oluşturma işlemini bir zamanlamaya göre yapan bir CI sunucusu istersiniz, ancak ekibin birisinin yönlendirdiği bir ağ kaynağı olsa da, periyodik olarak güncellemekten sorumlu olabilir. Tabii ki, bu kütüphane ekibinin plakasında olmalı, ama açıkçası ilgilenmiyorlar, bu yüzden gevşekliklerini almanız gerekecek.

Eskiden kendi yazılımlarını dahili iş sistemleriyle sürekli "dogfooding" yapan büyük bir yazılım şirketinde çalışıyordum.

Bunu başka bir test seviyesi olarak gördüler.

Bir şirket için hemfikir olduğum iyi bir şey.

Derleme adımı şirketinizin kitaplık satma, hatta dış kaynak sağlama konusunda önemli bir parçası olmadıkça , sizi en son sürümü indirmeye ve derlemeye zorlayan bir adım olduğunu düşünüyorum .

Kaynak kodun kullanılabilir olması bir fayda olabilir, ancak havuzu izleyen bir CI derleme ajanınız varsa, bu aracıyı bu kütüphaneyi derlemeli ve harici olarak bağımlı projelere kopyalamalısınız. kopyalarını oluştururken iki farklı derleme adımı çalıştırın.

Şu anda, ana uygulamayı oluşturmadan önce bir alt uygulama oluşturmayı gerektiren bir yapı aracısına bağlı olmayan bir proje üzerinde çalışıyorum. Posteriorumda ciddi bir ağrı var; alt uygulamada bir değişiklik yapmak için önce tüm projeyi oluşturmalı, sonra bir alt derleme klasörüne gitmeli, derlenen ürünü bundan çıkarmalı ve tüm projeyi yeniden oluşturmadan önce farklı bir alt klasöre kopyalamalıyım alt uygulamanın en son sürümünün ana uygulamanın yapısına dahil edildiğinden emin olmak için. Bu nasıl yapılması gerektiği DEĞİLDİR; en azından bu işlemi otomatikleştirecek bir MSBuild komut dosyası olmalıdır ve ben her yeni kod gövdeye adanmış olduğunda yapı ajan dışları güncellemek tercih ederdim.

Pek çok insan, herkesin dahili bir kütüphane inşa etmesinin bir anlamı olmadığını söylediğinden, nedenlerini haklı çıkarabilecek zıt görüşü sunacağım:

1. Kütüphaneyi çok kullanıyorsunuz ve hiçbir belge yok. Bu yüzden herkes referans için kaynağa sahip olmalıdır. Bu çok sık kullanılan bir kitaplıksa, referansın kullanışlı olması yararlı olabilir

   • Elbette, belgeler üzerinde çalışması gerektiğini söyleyebiliriz ve büyük olasılıkla kıdemli geliştiriciniz bu gerçeğin farkındadır. Ancak gerçekle yüzleşelim, geliştirme ekiplerinin çoğu zaman bir ton belgelenmemiş kodla sonuçlandığından, nasıl çalıştığını bilmeniz gerektiğinde, kaynağa gidersiniz. Bunu yapmak zorunda kalmamalısınız, ancak kısa vadede bu en iyi alternatiftir.
   • Genellikle dokümantasyonu koymak için en iyi insanlar kütüphaneyi en iyi bilenlerdir. Ne yazık ki, bunlar genellikle en yoğun olan kişilerdir, bu yüzden her şeyi bırakıp belgelemeye başlamak genellikle o kadar kolay değildir.

2. İnsanlar kütüphaneye bağlı kendi kodlarını yazmaya başladığında ve kütüphanede bir şey çalışmadığında, kollarını havaya atmak yerine, kütüphane yerel olarak inşa edilmişse, kütüphane kodunun içine adım atmak çok kolay hale gelir

   • Bunun nedeni, birçok kitaplığın mükemmel olmaktan uzak olması ve hepimizin "kararlı" bir sürümle çalışmak istemesine rağmen, yine de sorunlar olabilir.
   • Belki bir API'nin nasıl kullanılması gerektiğini yanlış anladığınızdan dolayı kötü sonuçlar alıyorsunuzdur. Belgelerle bile, insanlar genellikle yanlış varsayımlar yaparlar
   • Kıdemli adam muhtemelen yeni insanlardan bıkmış (ve bazen projeyi içte ve dışta bilenlerden çok daha fazla yeni insan var) bir çarpışma / başka bir hata bir kütüphane kodundan geldiğinde kollarını havaya atıyor. Bu yüzden, makinenize ve sonra yanınızda oturan adama gelmek yerine, şu soruları yanıtlama seçeneği istiyorlar: 1) kaza tam olarak nerede? hangi modül / dosya / hat? 2) Hata ayıkladınız mı? SİZ ne buldun?
   • Büyük adamlarınız bu kod tabanı (uygulama ve büyük kütüphaneniz) ile yeterince uzun süre çalıştı ve potansiyel olarak kod zaten makinede olduğunda ve hata ayıklamaya ve adım atmaya hazır olduğunda, hayatını kolaylaştırdığını ve insanları aldığını fark etmiş olabilir. kod tabanını daha hızlı öğrenmek. Bu nedenle sizi kütüphanenizde makinenizi inşa etmenin en yüksek maliyetini almaya zorlar.

Kararının haklı olduğunu söylemiyorum, sadece a) hikayenin bir tarafını sundu ve b) makul nedenler olabileceğine dikkat çekti.

Bu tür testler gerçekten daha iyi olur. Aslında , geliştiriciler tarafından değil, test ediciler tarafından yapılmalıdır . Bu anlamda ne sizin ne de kütüphane geliştiricinizin işi değil.

_{Açıkladığınızdan, projede test kullanıcısı yok gibi görünüyor - eğer durum buysa, bu bir yönetim problemi ve oldukça ciddi bir problem.}

... gerekli işlevselliğin mevcut olup olmadığını belirlemek için kütüphanelerin kaynak kodunu okuyabildikleri için zaman kazandırır

Oldukça topal akıl yürütme. En son sürüm kitaplığı en son sürüm projesiyle derlenemediğinde, bunun çeşitli nedenleri olabilir - sadece lib kaynak koduna girmek zaman kaybı olabilir.

• Kitaplık uygunsa ve derleme hatası proje kodundaki hatadan kaynaklanıyorsa ne olur? Ya da, derleme hatasına bir veya iki gün sonra düzeltilmesi gereken geçici uyumsuz değişiklik neden olsaydı? Bir derleme hatası, ele alınması bir hafta veya ay sürecek karmaşık bir entegrasyon sorununu gösteriyorsa ne olur? Entegrasyon sorunu için, önceki bir sürüm kitaplığının kullanılması geçici bir çözüm olabilir mi, değil mi?
   
  Nedeni ne olursa olsun, başarısızlığın ön analizini yapmak, geliştiricinin test kullanıcıları tarafından yapılması gereken bir iş için zaman harcamak anlamına gelir.

Akıl yürütmenin üstündeki bir başka şey de, kalkınma ve KG faaliyetleri arasında geçiş yaparak akışı kırmak zorunda kaldığında ortaya çıkan kaçınılmaz (ve tecrübelerimde oldukça acı verici) verimlilik kayıplarıdır .

Takımda test uzmanları olduğunda, bu tür şeyler gerçekten basittir ve daha kolay ele alınabilir. "Kıdemli" geliştiricinizin size sunduğu şey temelde bir taslak test gereksinimidir.

Proje veya kitaplıkta yapılan her değişiklikten sonra derlemenin başarılı olduğundan emin olun.

Bundan sonra atılacak adımlar tipik KG faaliyetleridir: gereksinim ayrıntılarını netleştirin, resmi bir test senaryosu tasarlayın, test hatalarını nasıl ele alacağınız konusunda müzakere edin.

• Gönderen SQA perspektifinden, bu kurma ve oldukça basit koruyarak tasarımı oldukça rutin bir iştir regresyon test muhtemelen noktaya kadar sadece manuel etkinlik biletleri oluşturmak ve sürdürmek olacağını - yüksek otomasyonlu olabilir prosedürü sorun izleyicide ve doğrulama düzeltmeleri.

Sr Dev'in önerdiği şey benim için en azından çok mantıklı değil. Kaynaklara göz atmak güzel ama bunu yapmanın daha iyi yolları var.

Hangi Eser Deposunu kullanıyorsunuz? Derlenen kitaplığın yanında yaşamak için her sürüm için bir kaynak kavanoz dağıtabiliyor olmalısınız. Çoğu IDE, kaynak taraması için bunu derlenmiş kitaplığa eklemenize izin verir. Maven Eklentisi ile tutulma bunu otomatik olarak yapacaktır.

En son koda ihtiyacınız varsa, sürüm anlık görüntülerini dağıtabilirsiniz.

Bu sadece derleme betiğinizde gerçekleşmelidir:

1. yeni bir sürümün mevcut olup olmadığını kontrol edin. aksi takdirde 2'yi atlayın.
2. kaynak koddan yerel olarak bir API referansı oluşturmak için ihtiyacınız olan araçları indirin ve derleyin. değişiklik günlüğünü göster.
3. uygulamanızı oluşturun

Bunun neden veya nasıl bir problem olduğunu anlamıyorum. Ayrıca referansta bir şey eksik olduğunda, onu kaynaklara ekleyebilir ve değişiklikleri itebilirsiniz. Tabii ki kütüphanenin ayaklarınızın altında değişmesi biraz korkutucu görünebilir, ancak kütüphane görevlileri işlerini düzgün yaparsa, bu iyi bir şeydir.