Bir projenin birden fazla alt projede ne zaman ayrılması gerektiği

Üzerinde çalıştığım projeyi bir yerine iki depoya bölmenin bir anlamı var mı bilmek istiyorum.

Söyleyebileceğim şeyden:

• Ön uç html + js ile yazılacaktır.
• Net olarak arka uç
• Arka uç ön uçta bağlı değil ve ön uç arka uçta bağlı değil
• Ön uç, arka uçta uygulanan huzurlu bir api kullanacaktır.
• Ön uç herhangi bir statik http sunucusunda barındırılabilirdi.

Şu an itibariyle, depo şu yapıya sahiptir:

kök:

• başlangıç ​​aşaması/*
• Arka uç / *

Her iki projeyi de aynı depoda tutmanın bir hata olduğunu düşünüyorum. Her iki projenin de birbirleri arasında bağımlılığı bulunmadığından, bireysel depolara ve gerekirse alt modüllere sahip bir ana depoya ait olmaları gerekir.

Bana bunun anlamsız olduğunu ve bundan faydalanamayacağımız söylendi.

İşte benim argümanlarımdan bazıları:

• Birbirimize bağlı olmayan iki modülümüz var.
• Her iki projenin de uzun vadede kaynak geçmişine sahip olmak, işleri karmaşık hale getirebilir (tarihte aradığınız hata ile tamamen ilgisiz olan taahhütlerin yarısına sahipken, tarihte aramayı deneyin)
• Çatışma ve birleşme (Bu olmamalı, ancak arka uçlara iten birisinin olması diğer geliştiriciyi ön uç değişikliklerini zorlamak için arka uç değişikliklerini yapmaya zorlayacaktır.)
• Bir geliştirici yalnızca arka uçta çalışabilir, ancak her zaman ön ucu veya başka bir yoldan çekmesi gerekir.
• Uzun vadede, konuşlandırma zamanı geldiğinde. Bir şekilde, ön uç bir arka uç sunucusuna sahipken birden çok statik sunucuya konuşlandırılabilir. Her durumda, insanlar tüm arka ucunu onunla klonlamak veya yalnızca tüm sunuculara yalnızca ön uç iletmek veya arka ucu kaldırmak için özel komut dosyası yapmak zorunda kalırlar. Sadece ön uç veya arka uca yalnızca bir defa ihtiyaç duyulduğundan daha kolay itip çekmek kolaydır.
• Karşı argüman (Bir kişi her iki projede de çalışabilir), Alt modül ile üçüncü bir repo oluşturun ve onunla geliştirin. Geçmiş ayrı modüllerde ayrı tutulur ve her zaman arka uç / ön uç sürümünün gerçekten senkronizasyonda birlikte çalıştığı etiketler oluşturabilirsiniz. Hem ön hem de arka ucun tek bir depoda olması, birlikte çalışacakları anlamına gelmez. Sadece her iki tarihi de büyük bir depoda birleştiriyor.
• Projeye bir freelancer eklemek istiyorsanız, frontend / backend'i alt modüller olarak kullanmak işleri kolaylaştırır. Bazı durumlarda, kod tabanına tam erişim vermek istemezsiniz. Büyük bir modülün olması, "yabancıların" görebilecek / düzenleyebilecek şeyleri sınırlandırmak istiyorsanız işleri zorlaştıracaktır.
• Hata tanıtımı ve hata düzeltme, ön uçta yeni bir hata ekledim. Sonra birisi arka uçtaki bir hatayı düzeltti. Tek bir depoda, yeni böceğin önüne geri dönmek, aynı zamanda düzeltmeyi zorlaştıracak olan arka ucu geri alır. Ön uçtaki hatayı düzeltirken arka ucun çalışmasını sağlamak için farklı bir klasörde arka klonu klonlamalıyım ... sonra işleri düzeltmeye çalışıyordum ... diğerini değiştirmeyin. Ve farklı arka uç sürümlerine karşı test yapmak ağrısız olacaktır.

Birileri beni ikna etmem için bana daha fazla argüman verebilir veya en azından projeyi iki alt modüle bölmenin neden anlamsız (daha karmaşık) olduğunu söyleyebilir mi? Proje yeni ve kod temeli birkaç günlük, bu yüzden düzeltmek için çok erken değil.

Şirketimde, sistemin her bileşeni için ayrı bir SVN deposu kullanıyoruz. Size son derece sinir bozucu olduğunu söyleyebilirim. Yapım sürecimizin çok fazla soyutlama katmanı var.

Bunu Java ile yapıyoruz, bu nedenle javac derlemesi, JibX ciltleme derlemesi, XML doğrulama vb.

Siteniz için, gerçekten "inşa etmeyin" (vanilya PHP gibi) yapmazsanız büyük bir anlaşma olmayabilir.

Bir ürünü çoklu havuzlara bölmenin olumsuz yanları

1. Yapı yönetimi - Sadece ödeme yapamıyorum, bağımsız bir yapı betiğini çalıştıramıyorum ve çalıştırılabilir / yüklenebilir / dağıtılabilir bir ürüne sahip olamıyorum. Birden fazla depoya giden, birden fazla iç derleme komut dosyası çalıştıran ve artefaktları bir araya getiren harici bir derleme sistemine ihtiyacım var.
2. Takibi değiştir - Neyin, ne zaman ve neden değiştiğini görmek. Ön uçtaki bir hata düzeltmesi bir arka uç değişikliği gerektiriyorsa, artık daha sonra başvurmam için 2 farklı yol var.
3. Yönetim - gerçekten yönetilmesi gereken kullanıcı hesabı, şifre politikası vb. Sayısını ikiye katlamak istiyor musunuz?
4. Birleştirme - Yeni özelliklerin çok fazla kod değiştirmesi olasıdır. Projenizi birden fazla havuza bölerek, gereken birleştirme sayısını çarpıyorsunuzdur.
5. Şube oluşturma - Şube oluşturma ile aynı anlaşma, bir şube oluşturmak için artık her depoda bir şube oluşturmanız gerekir.
6. Etiketleme - kodunuzu başarılı bir şekilde test ettikten sonra, sürümün sürümünü serbest bırakmak için etiketlemek istersiniz. Artık her depoda bir tane olmak üzere birden fazla etiketiniz var.
7. Bir şey bulmak zor - Belki ön uç / arka uç basit, ancak kaygan bir eğim haline gelir. Yeterli modüle bölünürseniz, geliştiricilerin bir kod parçasının kaynak kontrolünde nerede bulunduğunu araştırması gerekebilir.

Ürünüm 14 farklı depoya bölündüğü ve her bir depo 4 - 8 modüle bölündüğü için durumum biraz aşırı. Hatırlarsam, her birinin ayrı ayrı kontrol edilmesi ve ardından montajlanması gereken 80 civarında bir yerimiz veya bazı “paketlerimiz” var.

Sadece arka uç / ön uç ile ilgili durumunuz daha az karmaşık olabilir, ancak yine de bu konuda size tavsiyede bulunuyorum.

Aşırı örnekler, hemen hemen her şeye karşı veya bunlara karşı ikna edici argümanlar olabilir :)

Karar vermek için kullanacağım kriterler

Aşağıdaki faktörleri göz önünde bulundurarak bir ürünü birden fazla kaynak kodu havuzuna bölmeyi düşünürdüm:

1. Yapı - Her bir bileşenin oluşturulmasının sonuçları bir ürün oluşturmak için bir araya geliyor mu? Bir grup bileşenden .class dosyalarını bir dizi .jar veya .war dosyasına birleştirmek gibi.
2. Dağıtım - Bir birimle birlikte dağıtılan bileşenlerle mi yoksa farklı sunuculara giden farklı birimlerle mi çalışıyorsunuz? Örneğin, veritabanı komut dosyaları DB sunucunuza giderken javascript web sunucunuza gider.
3. Birlikte değişim - Sık sık mı yoksa birlikte mi değişim gösterecekler? Senin durumunda, ayrı ayrı değişebilirler ama yine de sık sık.
4. Dallanma / birleşme sıklığı - eğer herkes bagaja girerse ve dallar nadirse, ondan kurtulabilirsiniz. Sık sık dallanır ve birleşirseniz, bu kabusa dönüşebilir.
5. Çeviklik - bir an bildirimi üzerinde bir değişiklik geliştirmek, test etmek, serbest bırakmak ve dağıtmak gerekirse (büyük olasılıkla SaaS ile), dalları ve depoları değerli zaman harcamadan yapabilir misiniz?

Argümanların

Ayrıca, bu bölme konusundaki argümanlarınızın çoğuna katılmıyorum. Bunların hepsini tartışmayacağım çünkü bu uzun cevap daha da uzun sürecek, ancak birkaçı öne çıkıyor

Birbirimize bağlı olmayan iki modülümüz var.

Saçmalık. Eğer arka ucunu uzaklaştırırsan, ön tarafın işe yarar mı? Bende böyle düşünmüştüm.

Her iki projenin de uzun vadede kaynak geçmişine sahip olmak, işleri karmaşık hale getirebilir (tarihte aradığınız hata ile tamamen ilgisiz olan taahhütlerin yarısına sahipken, tarihte aramayı deneyin)

Eğer proje kökünüz ön uç ve / arka uç / içine bölünmüşse, o zaman bu hiyerarşilerin geçmişine bağımsız olarak bakabilirsiniz.

Çatışma ve birleşme (Bu olmamalı, ancak arka uçta iten birisinin olması, diğer geliştiriciyi ön uç değişikliklerini zorlamak için arka uç değişikliklerini yapmaya zorlayacaktır.) Bir geliştirici yalnızca arka uçta çalışabilir, ancak her zaman arka ucu veya diğer yolu çekmesi gerekir. etrafında.

Projenizi farklı depolara bölmek bunu çözmez. Bir ön uç çatışması ve bir arka uç çatışması hala 1 çatışma süresi 2 çatışma veya 2 depo süresi 1 çatışma olup olmadığını 2 çatışmadan kurtarıyor. Birinin hala onları çözmesi gerekiyor.

Buradaki kaygı, 2 deponun bir ön uç devinin ön uç kodunu birleştirebileceği anlamına gelirse, arka uç devinin arka uç kodunu birleştirmesi durumunda, bunu yine de SVN kullanarak tek bir depoda yapabilirsiniz. SVN herhangi bir düzeyde birleşebilir. Belki bu bir git veya mercurial sınırlamasıdır (ikisini de etiketlediniz, bu yüzden hangi SCM'yi kullandığınızdan emin değilsiniz)?

Diğer yandan

Tüm bunlara rağmen, bir projeyi çoklu modüllere veya havuzlara bölmenin işe yaradığı durumları gördüm. Solr'ı ürünümüze entegre ettiğimiz belirli bir proje için bir kez bile bunun için savundum. Elbette, Solr ayrı sunucularda çalışır, yalnızca bir değişiklik kümesi arama ile ilgili olduğunda değişir (ürünümüz aramadan çok daha fazlasını yapar), ayrı bir derleme işlemi vardır ve paylaşılan kod eserleri veya yapı eserleri yoktur.

Argümanlarınızın bazıları geçerli, bazıları ise geçerli değil.

Birbirimize bağlı olmayan iki modülümüz var.

Bu aslında tamamen doğru değil. İletişim kurabilmek için hem ön hem de arka ucun ortak bir arayüze sahip olması gerekir (açıklama). Bu, her ikisini de ortak bir havuzda tutmanın lehine zayıf bir argüman yapar. Ancak bu kadar fark yaratmadığı için sadece zayıf bir tartışma.

Her iki projenin de uzun vadede kaynak geçmişine sahip olmak, işleri karmaşık hale getirebilir (tarihte aradığınız hata ile tamamen ilgisiz olan taahhütlerin yarısına sahipken, tarihte aramayı deneyin)

Bu sahte bir argümandır. Belirli bir hatanın nasıl düzeltildiğine bakmak istiyorsanız, hangi düzeltmenin yapıldığını içeren hata izleyiciye bakın. Ve belirli bir kod parçasının nasıl geliştiğini bilmek istiyorsanız, tek bir dosyanın geçmişine (ya da en fazla bir avuç) bakarsınız. Her iki durumda da, depoda muhtemelen başka modüllerden diğer dosyaların olması, hiçbir şekilde işleri karmaşıklaştırmamalıdır.

Çatışma ve birleşme (Bu olmamalı, ancak arka uçlara iten birisinin olması diğer geliştiriciyi ön uç değişikliklerini zorlamak için arka uç değişikliklerini yapmaya zorlayacaktır.)

Bu sahte bir argümandır. Değişikliklerinizi yapmadan / zorlamadan önce tüm depoyu senkronize etmeniz gereken (yarı düzgün) herhangi bir VCS'nin farkında değilim. En fazla, değiştirilen dosyaları içeren klasörleri senkronize etmeniz gerekir (ve genellikle sadece dosyaların kendileri).

Bir geliştirici yalnızca arka uçta çalışabilir, ancak her zaman arka uç veya başka bir yoldan çekmek zorunda kalacaktır.

Bu önceki ile aynı sahte argümandır.

Uzun vadede, konuşlandırma zamanı geldiğinde. Bir şekilde, ön uç bir arka uç sunucusuna sahipken birden çok statik sunucuya konuşlandırılabilir. Her durumda, insanlar tüm arka ucunu onunla klonlamak veya yalnızca tüm sunuculara yalnızca ön uç iletmek veya arka ucu kaldırmak için özel komut dosyası yapmak zorunda kalırlar. Sadece ön uç veya arka uca yalnızca bir defa ihtiyaç duyulduğundan daha kolay itip çekmek kolaydır.

İnsanların konuşlandırmanın nasıl yapılacağını düşündüğüne bağlı olarak, bu geçerli bir argüman olabilir. Dağıtım, sunucudaki bir zip dosyasını / tarbal paketini açmak suretiyle yapılacaksa, depolarınızın nasıl organize edildiği önemli değildir. Dağıtım, sunucudaki bir havuza (bir kısmına) bakılarak yapılacaksa, ayrı olarak dağıtılan modüller için ayrı depolar kullanmak iyi bir fikir olabilir.

Karşı argüman (Bir kişi her iki projede de çalışabilir), Alt modül ile üçüncü bir repo oluşturun ve onunla geliştirin. Geçmiş ayrı modüllerde ayrı tutulur ve her zaman arka uç / ön uç sürümünün gerçekten senkronizasyonda birlikte çalıştığı etiketler oluşturabilirsiniz. Hem ön hem de arka ucun tek bir depoda olması, birlikte çalışacakları anlamına gelmez. Sadece her iki tarihi de büyük bir depoda birleştiriyor.

Bu geçerli bir argümandır, ancak o kadar güçlü değildir.

Projeye bir freelancer eklemek istiyorsanız, frontend / backend'i alt modüller olarak kullanmak işleri kolaylaştırır. Bazı durumlarda, kod tabanına tam erişim vermek istemezsiniz. Büyük bir modülün olması, "yabancıların" görebilecek / düzenleyebilecek şeyleri sınırlandırmak istiyorsanız işleri zorlaştıracaktır.

Bu geçerli bir argümandır.

Hata tanıtımı ve hata düzeltme, ön uçta yeni bir hata ekledim. Sonra birisi arka uçtaki bir hatayı düzeltti. Tek bir depoda, yeni böceğin önüne geri dönmek, aynı zamanda düzeltmeyi zorlaştıracak olan arka ucu geri alır.

Bu sahte bir argümandır, çünkü bu, bir modüle yapılan iki düzeltmeden sonra birincisini geri alamayacağınız anlamına gelir. Herhangi bir yarı-terbiyeli VCS, eski herhangi bir taahhüdün geri alınmasına izin verecektir (bu, genellikle HEAD'in tepesinde bile olsa, bu değişiklikleri tersine çeviren yeni bir taahhütte bulunmanız anlamına gelecektir).

Ön uçtaki hatayı düzeltirken arka ucun çalışmasını sağlamak için farklı bir klasörde arka klonu klonlamalıyım ... sonra işleri düzeltmeye çalışıyordum ... diğerini değiştirmeyin. Ve farklı arka uç sürümlerine karşı test yapmak ağrısız olacaktır.

Bu aslında oldukça iyi bir argümandır. İki havuza sahip olmak, konuşlandırılmış ön ve arka uçların senkronize olamayacağı (hafifçe) senaryoları test etmeyi kolaylaştırır.

Bu yazı biraz eski ama katkıda bulunmak istiyorum. Arka ucunuz ön ucu gerçekten bilmiyor olsa da, ön ucun arka ucun API'siyle eşleşen istekleri olması gerekir. Arka uç bir REST API olarak görürseniz, hızlı bir YAML arayüzü gibi bir arayüz dosyası tanımlayabilirsiniz. Şimdi, uygun gördüğünüz gibi farklı depolara ayırabileceğiniz gerçekten 3 proje var:

• API tanımı
• Arka uç
• Başlangıç ​​aşaması

API tanımı diğer iki projede bir bağımlılıktır, maven'i bir bağımlılık enjeksiyon aracı olarak kullandığınızı varsayalım. O zaman ne kadar sıkı bir şekilde versiyonlama yapmak istediğinize bağlı. Projelerin her zaman uyumlu bir durumda olmasını sağlamak için değişiklik yaptığınızda her seferinde API tanımı projesinin sürümünü arttırabilirsiniz, ancak daha fazla ek yük gerektirir, ya da SNAPSHOTS gibi bir şeyi maven'de kullanabilirsiniz ve yalnızca daha az ek yüke sahip olan arayüzden memnunuz, ancak çoğu zaman uyumsuzluklarınız olabilir. Ancak, API tanımını ön ve arka tarafınıza uyguladığınız sürece, projeleri farklı havuzlara bölüştüreceksiniz.

Bu konular bağımlılık yönetimi hakkında daha fazla. Projeler ayrılmasa ve aynı depoda olsalar bile, web sitesinin ön ve arka uçların senkronize olmadığı bir duruma getirilmesi oldukça kolaydır. Gerçekten bunu durdurmanın tek yolu, ikisi arasındaki sözleşmeyi fiilen tanımlamaktır, ancak ön ve arka uç uygulamalarını birleştirmeyecek şekilde yapmak istersiniz, tıpkı bir arayüze kod yazdığınız gibi OO programlamada bir uygulamanın.

Ayrıca, bunun, bu arayüz dosyasını korumaya yönelik bir ek yük oluşturduğu yönündeki eleştiriyi önceden ele almak için, örneğin swagger, farklı programlama dilleri ve JAX-RS gibi çerçeveler için kod saplamaları bile üretebilir. Böylece seçtiğiniz teknolojide bir arayüz oluşturabilir ve daha sonra bu arayüzü uygulayabilirsiniz. Ayrıca ön uç geliştiricilerin işlerini yapmasını kolaylaştırmak için arka uçunuza çok güzel belgeler ekler.