Web geliştirme projelerinde arka ucu ve ön ucu iki konuma ayırmak yaygın mıdır?

Bir web başlangıcında, özelliğin ön ve arka ucunda çalışan bir mühendise sahip olmak daha mı yaygın (temelde tüm özelliğin sorumlusu)? Veya arka uç ile ön uç arasında mühendisler ayrılmış mı?

Hangileri daha faydalı ve hangi durumlar için?

Diyelim ki, tüm özelliğin sorumlusu bir mühendis sahibi olmakla ilgili olarak, kişinin sadece ön uç veya arka uç gelişiminde özellikle güçlü olabileceğini, ancak her ikisinin de değil, dolayısıyla bazen hız ve kalitede bir düşüş olabileceğini fark ettim.

Ön uç ve arka uç geliştiricilerin bir özellik üzerinde olması, özelliğin hızını ve kalitesini artırır VE işbirliğini teşvik eder. Ancak, bir mühendis üzerinde çalışmak için başka bir özelliğe yerleştirilebileceğinden, kaynakların zayıf kullanımı olabilecek bir özellik üzerinde çalışan 2 mühendisin olması konusunda endişeliyim.

Küçük bir erken aşama başlangıcında arka uç / ön uç mühendislik kaynaklarının tahsisi için ortak / en iyi uygulama nedir? Ve o zaman büyüdükçe nasıl değişecek?

İşte 14 yıllık tecrübemden beri bilgeliğim:

• eğer bir başlangıcınız varsa, rol atamayın. Umarım iyi bir kendini organize eden takım oluşturmuşsundur. Herkes birbirini tanıyorsa, en iyisini kimin yaptığını herkes bilir. Bir proje yöneticisi sadece yoluna devam edecektir.
• daha sonra, ön uç ile arka uç arasındaki ayrım mantıklı geliyor. Arka uçta kalite önceliklidir. Kod, güvenli, performans ve işlem güvenli olmak zorundadır. Ön uçta uygulama süresi önemlidir. Ve iyi bir sonuca güvenebilmelisin. Ön ve arka uçtaki farklı hedefler birlikte iyi çalışmaz.
• arka uç kodlayıcı çalışmaya başlamadan önce arka uç zaten mevcut olmalıdır. Aksi takdirde, ön uç kodlayıcı çok yavaşlar.
• arka uç yavaşlatmamak için ön uç gereksinimlerine hızlı tepki verebilmeli

En iyi cevap @Shark'tan, ancak sadece "Son derece bağlı." Tecrübelerime göre, ~ 16 yıl, her iki seçeneğin de farklı konfigürasyonlarda denenmesini gördüm. Kendimi tam bir yığın geliştirici olarak öğrenmeye geldiğim şey:

* (BE = Arka Uç, FE = Ön Uç)

Bölünmüş Yığın Geliştirmenin Genel Uyarıları:

1. Çevik geliştirme uygulamaları (bugünlerde ortak bir strateji), özelliğin müşteri bakış açısına göre tek bir değerli işlevsellik parçası olduğu özellik geliştirmeyi önerir. Bu açıdan bakıldığında geliştiricinizin ikisini de uygulaması gerekir.

2. Yığını sunucu sınırı boyunca bölmek, iki geliştirici arasında bir bütünleşme noktası oluşturur. Etkili iletişim kurmadıkları ve birlikte iyi çalışmadıkları sürece, bu iki özellik bir araya geldiğinde çok sayıda hataya neden olacaktır.

3. Mythical Man-Month'dan n (n-1) / 2 iletişim kuralını uygulayın ve iki kişi arasındaki özelliklerin iki kişi arasında bölünmesinin toplam iş yükünüzü artıracağını göreceksiniz. Bu kuralın, özellikler için de geçerli olduğu kabul edilir, ancak yığını bölmek iletişim miktarını iki katına çıkarır.

4. Bir tasarımcı, BE geliştiricilerin sıfırdan çekici arayüzler üretememe problemlerini çözecektir. Bu, en azından html & css'yi tanıdıklarını ve tasarımcı tarafından oluşturulan ekran görüntüleriyle eşleşen bir arabirim üretebileceklerini varsayar.

5. Özellikler tipik olarak, diğer özelliklerle çok az etkileşime giren izole bileşenlerdir. Bu her zaman böyle değildir, ancak genellikle etkileşim noktası bir veritabanı veya dosya sistemi gibi düşük bir seviyededir. Dolayısıyla, tam yığın geliştiricinin özelliklerini uygulamalarını engelleyen pek bir şey yoktur. Ancak bir FE geliştiricisinin bir görevi tamamlamak için BE geliştiricisini beklemesi gerekiyorsa, 3. noktadaki verimlilik kaybına daha da fazla gecikme ekleyecektir.

6. Web2.0, FE & BE arasındaki farkı daha da bulanıklaştırmaktadır. MVC çerçeveleri ve tüm uygulamalar müşteri tarafında inşa edildiğinde, artık güvenli ve verimli FE uygulamalarını uygulamak için iyi bir BE bilgisi gerekir.

7. Bu uygulamaya yönelik en büyük şikayetim, projeye dahil olan herkesin yeteneklerini sınırlamasıdır. Bu, 2000'li yılların başlarında yaygın bir uygulama olmasına rağmen, zorunluluktan çıkarıldı, çünkü her ikisini de yapabilecek geliştiriciler bulmak oldukça zordu (sadece yenilik yüzünden değil, her ikisinin de öğrenilmesindeki bazı gerçek zorluklardan dolayı). on yıl sonra hala CSS bilmeyen “web geliştiricileri” var.

8. İkinci en büyük yakınmam, bir geliştirme ekibini kolayca bölümlere ayırabilmesi. Bir FE geliştiricisi, BE kodunu değiştirdikten sonra bir hata yaratır ve ekip, yığınlar arası geliştirme toptan satışını kısıtlamak için oy kullanır. Kod incelemeleri ve eğitim problemi çözebilse de, insanlar bunun yerine bölgeselleşir.

Bölünmüş Yığın Geliştirmenin Yararları / Kullanım Alanları:

1. RESTful API'ler bu tanımlama için mükemmeldir çünkü FE yoktur. Genellikle bir şirket önce RESTful API üzerinde çalışacak ve daha sonra web uygulamalarını en üst düzeye çıkaracak. Bu durumda, FE takımının bir sonraki ana sürüme odaklanmasını sağlamak için FE başvurusunu bitirmek için güçlü bir durum söz konusudur. Ancak, kayıp tehlikesi hala mevcuttur - özellikle FE geliştirme aşamasında keşfedilen yeni bilgiler BE API'sinde önemsiz değişiklikler gerektiriyorsa.

2. FE & BE arasındaki dengesiz iş yükleri de FE sadece takım oluşturmak için iyi bir durumdur. Yine, bu durum belki de asıl gelişimin bir masaüstü uygulaması aracılığıyla yapıldığı ve şirketin bir 'lite' web arayüzü geliştirmeye çalıştığı durumlardır.

3. Yeni / küçük geliştiricilerin eğitimi. Bir stajyer veya küçük bir dev işe alıyorsanız ve onları bağımlılığa atmakla ilgileniyorsanız, bu iletişim / entegrasyon maliyetinin bir kısmını bir akran geliştirme sistemine yatırmak iyi bir seçenektir.

@ Ralf'in bu sayfada kabul ettiği cevabı hakkındaki endişeler:

1. İlk nokta oldukça cesur - ve bu "iyi organize edici takımlardan" biri yoksa hızlıca başarısız olacak. Bu takıma sahip olsanız bile, sınırlarını zorlamak sizin ve kendi çıkarlarınızdır. Ve iyi kendini organize eden takımlar bunu yapmak için her zaman kendi kendine motive olmazlar.

2. İkinci noktan sadece yanlış. Modern web geliştirme, performans gösteren, güvenli, asenkron güvenli, XSS korumalı, çapraz tarayıcı ve hızlı bir şekilde geliştirilen FE kodunu gerektirir. Hedefler basitçe BE ile rekabet etmiyorlarsa etkili bir şekilde eşit oluyorlar.

3. Üçüncü nokta, aynı zamanda kötü bir varsayımdır - FE geliştirme herhangi bir BE vakıf çalışması olmadan saf html / css / js ile başlayabilir. Oradan BE işleme için şablonlara ayırmak sadece önemsiz bir çabadır. Çoğu zaman FE çalışmasına başlamak en iyisidir, çünkü paydaşlara görsel ilerlemenin başını görmek için sıcak ve bulanık bir his verecektir.

Sonuç:

Eğer bir başlangıçsanız ve yakacak çok zamanınız veya paranız yoksa, FE veya BE sadece geliştiricileri işe almayın. Üst düzey web geliştiricileri ve iyi bir ux / tasarımcı kiralayın ve başvurunuzu mümkün olan en kısa sürede gerçekleştirin. Daha pahalıya mal olurlar, ancak çok daha üretkenler ve daha azına ihtiyacınız olacak.

Bence sorunun yanlış olduğunu.

Katıldığım tüm girişimler yalnızca FE-BE mimarisine sahip değildi.

Bildiğim çoğu girişim var:

• Çekirdek - bir arayüz ortaya çıkaran asıl ürün
• UI - BE ve FE. BE, Çekirdek API'sini kullanır.

API'ler, çekirdek geliştiriciye ihtiyaç duymadan bile vatansız ve kolayca alay ediyorlar. Cehennem, sıfırdan bir projeye başlamak zorunda olsaydım, sadece alaylarla çalışan tüm bir UI ile başlayabilirdim - bu sunumlar için harika olacak. Geri bildirimlerin çoğu UI'den kaynaklanıyor. Müşteriler daha fazlasına dikkat eder - (hedef kitlenize bağlıdır.)

Örneğin - Google Arama, web’i tarayan, dizine ekleyen vb. Çekirdek bir bileşene sahiptir ve Google UI tamamen farklı bir dünyadır. Bu çekirdek, kullanıcı arabirimi yapamazken, WWW dışı aramaları kolayca destekleyebilir.

Bu şekilde, kullanıcı arayüzünüz "takılabilir" ve endişelerin ayrılığına sahipsiniz.

Geliştirme bilgisine baktınız, ancak proje yönetimi konularını gözden kaçırıyorsunuz. Çekirdek ekibin 2 haftalık sprint süresine ihtiyacı olabilirken, UI ekibi CI'yi kullanacak - her şey her zaman yüklenir. Çekirdek ekibinin geriye dönük uyumluluk gerekirken UI gerekmeyecek.

Dil farklı. Muhtemelen Core bileşeni için C geliştiricileri isteyeceksiniz - ve kullanıcı arayüzü bir Cross OS dilinde yazılacağı gibi tek bir işletim sistemi üzerinde çalışıyorsa iyi olacaksınız.

Testler farklı. UI test dünyası, yazılım geliştirmede bildiğim en karmaşıklardan biri. Yeni başlayanların çoğu bunu ihmal ediyor ve bu kararı daha sonra pişman ediyor. Test yaparken BE ve FE'yi ayıramazsınız. Onu idare eden tek bir birim olmalı.

Açık Kaynak Kullanıcı Arabirimi - ikisini ayırmanın en büyük yararlarından biri, kullanıcı arabiriminizi kaynak açabilmenizdir. UI projesi açık kaynak desteğine ihtiyaç duyuyor.

Tüm session özelliği anlayamayan bir UI geliştiricisi düşünemiyorum . Bilirsiniz - farklı talepler arasında giriş yaptığınız ve giriş yaptığınız yerler. Doğru PHP'yi Java biliyor olabilirler .. ama BE kavramı açık olmalıdır (örneğin şifreli bir çerez kullanın). Özel dil engeli yanlıştır - her geliştirici herhangi bir dilde çalışmaya istekli olmalıdır. Birkaç yıl önce JavaScript’e BE yazacaklarını kim düşünebilirdi?

Eğer 3 takıma devam edersen: Core, BE ve FE, bu bir kaynak israfıdır. DB ne olacak? DBA’lar olmalı mı? Bir BE geliştiricisi neden DB'yi ve bir FE geliştiricisi BE ve DB'yi tanımıyor olmalıdır? Sınır yok.

Uzmanlara ihtiyacınız varsa ve yapacaksınız, dış kaynak kullanımı oldukça iyi çalışıyor. Genellikle kalite kodu sağlarlar ve oldukça hızlı yaparlar. Onları kurum içinde istemezsin çünkü ayrılırlarsa kaybolursun. Ayrıca bugün çevrimiçi olarak harika tavsiyeler alabilirsiniz. Son teknoloji malzeme farklı yaklaşımlar gerektirebilir.

Bu nedenle sonuç, temelde, her FE geliştiricisinin geliştirebileceği UI'de çok ince bir BE'dir. Kullanıcı Arabiriminde kalın bir BE varsa, Çekirdek'te gerekli olan bazı API işlevlerine sahipsiniz.

Her zaman geri kalanın dışında kalan en az bir geliştirici vardır. Bu kadar ince bir FE verildiğinde, BE kodundaki diğer geliştiricilere destek vermeyi (geliştirmeyi değil) başarabilir. Benim düşüncem bu geliştiricinin çok iyi bir konumda olduğu ve uygun şekilde verilmesi gerektiğidir (maaşla değil, başka bir şeyle). İnşa sürecini idare edip doğru bir şekilde yapabileceklerine de inanıyorum.

Bu model BE gelişimi konusunda size büyük bir esneklik verir. BE dünyası son birkaç yıl içinde birkaç dönüş bildi, bu yüzden yine de BE stabilitesine güvenmeyi önermiyorum. Çekirdek farklı bir hikaye.

Hala soru var - FE ve BE aynı proje mi olmalı ? Aşağıdakilere dikkat etmelisiniz

• Statik kaynaklar en iyi ön sunucudan sunulur. Ön Uç sunucular (örn. Nginx) çok güçlü olduğundan ve statik kaynaklar için Önbellek kullanabildiğinizden, statik kaynaklarınızın (tüm HTML içeriği, JS, CSS, Görüntüler olmalı) tek bir dağıtımını yönetebilirsiniz.
• Arka uç kodu aynı lükslüklere sahip değil, bu nedenle bir ön sunucu tarafından da yönetilen dağıtık bir sisteme sahip olmalısınız.
• FE kodu, JavaScript'i destekleyen tüm yeni teknolojilerle yeniden kullanılmaya yöneliktir. Artık Masaüstü ve Mobil uygulamalarını JavaScript ile yazabilirsiniz.
• Derleme işlemi tamamen farklıdır - ve bu da yamalar teslim, yükseltme, kurulum vb. İçerebilir.

Devam edebilirim, ancak umarım BE ve FE'nin aynı ekip, ama belki de farklı projeler olması gerektiğini düşünüyorum.

Başarılı uygulamanın birkaç şey olabileceğini düşünüyorum. Güçlü bir arka uca sahip olan, ancak kullanıcı arayüzü ve tüm "ön uç" parçalarını iyi kavrayan tek bir geliştirici varsa, muhtemelen başarılı olabilir. Yine de, tipik olarak durum böyle değil (benim kişisel deneyimime göre). Mesela kendimi bir arka uç geliştiricisi olarak görüyorum. Ama tek başıma birçok proje üzerinde çalışıyorum. Sunum ve müşteri tarafı eserleri üzerinde mi çalışıyorum? Emin. Gerçek bir yetenekli tasarımcı ve müşteri tarafı geliştiricinin yapabileceği kadar iyi görünüyorlar mı? Kesinlikle hayır.

Her şey al ve al. Ancak iki geliştiricinin iş birliği içinde tereddüt etmesine izin verme. Bir geliştirici ve tasarımcı arasındaki üretimi en üst düzeye çıkarmak için denenmiş ve gerçek yollar vardır.

Diğer bir deyişle ... Duruma göre