Bir geliştirme ekibi neden Visual Studio'da birden fazla proje için tek bir çözüm kullanmanın “karşılıklı bağımlılık karmaşıklığını arttırdığını” ısrar ediyor?

Mevcut bazı ürünlerin yeni sürümlerini geliştirmeye başlayan harici bir ekibi yönetmeye yardım ediyorum. Tarihsel olarak, bu ekip her zaman konuşlandırılabilir bir yapı oluşturmak için bir araya gelen Visual Studio'da yaklaşık 30 modül için tek bir çözümde tek bir projenin modelini kullandı.

Bunun yapı güvenilirliği ve kalitesi üzerinde zararlı bir etkisi var, çünkü bize her zaman en güncel kaynak kodunu göndermiyorlar. Başvurulan kodları tek bir çözümde birleştirmek için bunlara basmaya çalışıyoruz, ancak biraz direnç alıyoruz - özellikle her şey yerleştirilirse artan modüller arasındaki (Visual Studio'daki "projeleri" oku) arasındaki karşılıklı bağımlılık hakkında konuşmaya devam ediyorlar tek bir çözüm dosyası. Ayrı çözümlerde kodun hiçbiri başka yerlerde kullanılmaz.

Bunun saçmalık olduğunu ve iyi gelişme kalıplarının böyle bir sorunu önleyeceğini ısrar ediyorum.

Söz konusu ekip aynı zamanda mevcut bir ürün üzerinde hata düzeltme ve yeni özellik geliştirme çalışmaları gerçekleştirmiştir. Deneyimi en az söylemek için suçlanmıştır ve aynı çözümde birden fazla çözümde bölünme problemi yaşanmaktadır. Kaynak kontrollerine ( TFS ) erişimimiz reddedildi ve kod tabanını birleştirmek için kullandığımız yaklaşım, en azından eksik güncelleme sayısını ve zaman zaman regresyonlardan daha fazlasını denemek ve azaltmaktır (evet, sabit hatalar yeniden -ürün ürüne girerek) "tüm çözüm klasörünün ZIP'ını bize gönderin, böylece sıkıştırmayı açabiliriz, Visual Studio'da açabilir veF5 test etmek için ". Genel yapı ve kalite bakımından, kod oldukça zayıf ve desteklenmesi zor. Bu deneyim, geliştirme sürecinin mümkün olan en erken aşamasında çalışma süreçlerini en doğru şekilde yapmaya niyetlendiğim için ortaya çıkıyor.

Kaçırdığım bir şey mi var? Tüm bu kodları ayrı tutmak için iyi bir neden var mı? Param için ortak bilgi olması için çok zorlayıcı bir sebep olmalıydı, ama her şeyi bilmediğimi kabul etmeye istekliyim.

Onlara projelerini nasıl yapılandıracaklarını anlatmanıza gerek yok. Bunun yerine, sistemi tek bir komut dosyasını çalıştırarak herhangi bir hata almadan, kaynaktan kaynaktan oluşturabilmenizi zorlaştırır. Bu komut dosyaları Visual Studio veya Msbuild veya başka bir araç çalıştırıyorsa ve bunlar bir kez çağrılırsa, 50 veya 100 kez önemli olmamalıdır.

Bu şekilde, her şeyi tek bir çözüme uyarak elde edeceğiniz gibi aynı kodun "eksiksizlik testi" ni alırsınız. Elbette, bu senaryo size takımın kaynak kontrolünden en son sürümü gerçekten kontrol edip etmediğini size söylemez, ancak kodun tamamını tek bir çözümde kullanmak da bunu kontrol etmez.

Cevap olarak "her şey tek çözüm dosyasında yerleştirilirse modülleri arasında karşılıklı bağımlılık arttı ediliyor" - bu proveable saçma, projeler arasında bağımlılıkları herhangi değiştirmeyen bir çözüm projeleri ekleyerek beri, bağımlılıklar bir projeden bir sonucudur diğerine atıfta bulunan dosya, hangi projeden hangi çözümün başvurduğundan tamamen bağımsızdır. Hiç kimse bu ekibin ikisine de sahip olmasını engellemiyor - tüm projelere referans veren tek bir çözüm ve ayrıca her birine yalnızca bir projeye referans veren bireysel çözümler.

Yine de bir derleme betiği eklemenizi öneririm. Bunun tek bir çözüm dosyası olsa bile yararları vardır. Örneğin, bir VS yapısını tercih edilen bir konfigürasyonla çalıştırmanıza izin verir, dağıtım için son dosyaları (ve daha fazlası değil) bir "konuşlandırma" klasörüne kopyalamanıza izin verir ve inşaatı tamamlamak için başka bazı araçları ve adımları çalıştırabilir. Ayrıca bkz. F5 bir yapım süreci değildir! ve Joel Testi .

Derlenmiş montajların ne kadarının kullanıldığına bağlı olacaktır. Montajların yeniden kullanımı yoksa, "modülleri" ayrı tutmak için gerçek bir sebep yoktur. Aslında benim deneyimlerime göre bu bir engeldir.

Geliştirme ekibinde, birden fazla üründe ayrı bir çözüm olarak kullandığımız, yazdığımız bağımsız kütüphanelerimizin bir parçasıyım, bu durumda B Uygulamasını güncel tutmak için A Uygulamasını derlememiz gerekir. Uygulama C'yi güncel tutmak için gerekli olabilir.

Ürünü oluşturan birden fazla proje olsa bile, her ürün kendi çözümünde tutulur. Bu şekilde, yalnızca geliştirilen tüm ürünlerdeki paylaşılan kodunu güncel tutmak için Kütüphane çözümünü oluşturmamız gerekir.

Çalıştığım her yazılım şirketinin, şirketin ürünlerinin temel kullanım durumlarını kapsayan baş kolunu sağlayan bir çekirdek geliştirme ekibi vardı.

Çekirdek depoyu kullanan şube geliştiricileri, gelişmeleri keşfetmekten ve inceleme için merkez şubesine çekme taleplerini iletmekten sorumludur. Bu genellikle kişinin temel bir geliştiricisi haline gelmesidir, birisinin bir mimari çatışmanın alevlerini havalandırmaktan daha iyi katkılar sağlayabileceğini göstermek.

Muhtemelen şirketiniz derhal "tüm referans kodunu tek bir çözümde birleştirmek" için kaynaklara sahip değildir. Bütçe kısıtlarını anlamadan bunu yapmalarını önermek (en azından) birinin temel mühendis olmasını engelleme olasılığı yüksektir.

Öyleyse büyük vizyonunuzu çekirdeğe birkaç yıkıcı çekme isteği olarak formüle edin ve gözden geçirme sırasında kendinizi savunmaya hazırlanın!

"Birden fazla proje için tek bir çözüm kullanılması karşılıklı bağımlılık karmaşıklığını arttırır" iddiasında bir doğruluk çekirdeği var.

Tek bir çözüm, bir projeyi başka bir projeden referans almayı kolaylaştırır (yani, bir projenin kodunu yeniden kullanmak, yani "bağımlılık karmaşıklığı sağlamak"):

• başvurulan derleme için tüm dosya sistemi / genel derleme önbelleğine göz atmak yerine, projedeki çözümdeki sınırlı sayıda ilgili proje arasından seçim yapabilirsiniz; ve,
• Kaynak kodu okurken, çözümdeki başvurulan bir projeye atlamak, rastgele (ikili) bir derlemeden ziyade daha kolaydır.

Bu yüzden disiplinsiz bir ekibin elinde birden fazla projeyi tek bir çözümde kullanmak dikkatsizce ortaya çıkan birçok bağımlılığa yol açabilir. Bununla birlikte, bir takım bağımlılıkları dikkatli bir şekilde yönetmek için gerekli disiplini öğrenmeye çalışabilir ve daha sonra çözümleri kullanarak yeniden kullanım kolaylığını kullanabilir.