क्या वेब विकास परियोजनाओं पर बैक-एंड और फ्रंट-एंड को दो स्थितियों में अलग करना आम है?


31

एक वेब स्टार्टअप पर, क्या किसी इंजीनियर के सामने के एंड-बैक-एंड (जो मूल रूप से पूरे फीचर का प्रभारी है) काम कर रहा है? या इंजीनियर बैक-एंड और फ्रंट-एंड के बीच अलग हो गए हैं?

कौन से अधिक फायदेमंद हैं और किन स्थितियों के लिए?

नकारात्मक पक्ष यह है कि मैंने देखा है कि पूरी सुविधा में एक अभियंता के पास होने के संबंध में यह है कि व्यक्ति विशेष रूप से केवल या तो बैकएंड या बैकएंड विकास में मजबूत हो सकता है, लेकिन दोनों में नहीं, इस प्रकार कभी-कभी गति और गुणवत्ता में कमी होती है।

एक फीचर पर फ्रंटएंड और बैकेंड डेवलपर्स होने से फीचर की गति और गुणवत्ता में वृद्धि होती है और यह सहयोग को प्रोत्साहित करता है। लेकिन मैं एक सुविधा पर काम करने वाले 2 इंजीनियरों के बारे में चिंतित हूं जो संसाधनों का खराब उपयोग हो सकता है क्योंकि 1 इंजीनियर को काम करने के लिए किसी अन्य सुविधा पर रखा जा सकता है।

एक छोटे प्रारंभिक चरण के स्टार्टअप पर बैकएंड / फ्रंटेंड इंजीनियरिंग संसाधनों के आवंटन के लिए सामान्य / सर्वोत्तम अभ्यास क्या है? और फिर जैसे-जैसे यह बढ़ेगा, यह कैसे बदलेगा?

जवाबों:


29

यहाँ 14 साल के अनुभव से मेरी बुद्धि है:

  • यदि आपके पास एक स्टार्टअप है, तो भूमिकाएँ न दें। बेहतर आशा है कि आपने एक अच्छी आत्म आयोजन टीम इकट्ठी की। अगर हर कोई एक दूसरे को जानता है, तो हर कोई जानता है कि कौन सबसे अच्छा करता है। एक परियोजना प्रबंधक केवल रास्ते में खड़ा होगा।
  • आगे चलकर, फ्रंट-एंड और बैक-एंड के बीच का अंतर समझ में आता है। बैकएंड में, गुणवत्ता बेशुमार है। कोड निष्पादित, सुरक्षित और लेनदेन सुरक्षित होना चाहिए। फ्रंट-एंड में, कार्यान्वयन समय मायने रखता है। और आपको एक अच्छे बैक-एंड पर भरोसा करने में सक्षम होना चाहिए। सामने और पीछे के अलग-अलग लक्ष्य एक साथ अच्छे काम नहीं करते हैं।
  • फ्रंट-एंड कोडर के काम करने से पहले ही बैक-एंड मौजूद होना चाहिए। अन्यथा, फ्रंट-एंड कोडर बहुत धीमा हो जाएगा।
  • बैकएंड को फ्रंट-एंड आवश्यकताओं पर तेजी से प्रतिक्रिया करने में सक्षम होना चाहिए ताकि उन्हें धीमा न करें

7
+1 के लिएif you have a startup, don't assign roles. Better hope that you assembled a good self organizing team. If everybody knows each other, everybody knows who does what the best.
क्वर्की

7
-1 गुणवत्ता सामने के छोर पर उतनी ही महत्वपूर्ण है।
फ्लोरियन मार्गाइन

2
हां, फ्रंट-एंड में गुणवत्ता भी महत्वपूर्ण है, लेकिन एक बग के बैक-एंड में बग के समान परिणाम नहीं होंगे। उदाहरण: बैक-एंड में आपको लेनदेन सुरक्षित होना है, फ्रंट-एंड में आप (उम्मीद है) ट्रांजेक्शन सेफ बैकेंड का उपयोग करें :-)
rdmueller

4
@ राल्फ और यदि आपके 40% उपयोगकर्ता लेन-देन की शुरुआत नहीं कर सकते हैं क्योंकि इंटरफ़ेस बाहर निकलता है, तो इससे कोई फर्क नहीं पड़ता कि यह लेनदेन सुरक्षित होगा या नहीं। गुणवत्ता फ्रंट छोर पर बिल्कुल महत्वपूर्ण है क्योंकि यह बैक एंड में है।
राचेट

1
@ रैकेट: शायद मुझे इसे अलग तरीके से व्यक्त करना चाहिए था। मुझे लगता है कि मैं जो कहना चाहता था, वह यह है कि गुणवत्ता का दोष अलग है। बैकेंड को लेन-देन सुरक्षा जैसी कुछ समस्याओं से सामने वाले को ढाल देना चाहिए। यदि सही किया जाता है, तो आपको बस दृश्यपटल में लेनदेन के बारे में ध्यान रखना होगा, लेकिन आपको अभी भी कार्यक्षमता, प्रयोज्य, डिजाइन आदि के बारे में ध्यान रखना होगा। उपयोगिता और डिजाइन ऐसे पहलू हैं जो लगभग बैकएंड में मौजूद नहीं हैं - सिर्फ इसलिए कि यह कोई दृश्यपटल नहीं है: -)
rdmueller

26

सबसे अच्छा जवाब @Shark से है, लेकिन केवल अंतिम भाग "यह निर्भर करता है।" मेरे अनुभव में, ~ 16 साल या इसके बाद, मैंने दोनों विकल्पों को विभिन्न विन्यासों में देखा है। एक पूर्ण स्टैक डेवलपर होने के नाते, यहाँ मैं क्या सीखने आया हूँ:

* (BE = बैक एंड, FE = फ्रंट एंड)

स्प्लिट स्टैक विकास के सामान्य कैविट्स:

  1. चंचल विकास प्रथाओं (इन दिनों एक आम रणनीति) सुविधा विकास की सिफारिश करती है, जहां सुविधा ग्राहक के दृष्टिकोण से कार्यक्षमता का एक एकल मूल्यवान चक है। इस दृष्टिकोण से आपको अपने डेवलपर को दोनों को लागू करना चाहिए।

  2. सर्वर सीमा के साथ स्टैक को विभाजित करना दो डेवलपर्स के बीच एकीकरण बिंदु बनाता है। जब तक वे प्रभावी ढंग से संवाद नहीं करते हैं और एक साथ अच्छी तरह से काम करते हैं, इससे दोनों की एक साथ आने पर काफी संख्या में कीड़े हो जाएंगे।

  3. Mythical Man-Month के संचार का n (n-1) / 2 नियम लागू करें और आप देखेंगे कि दो लोगों के बीच दो भागों में बंटने से आपके संपूर्ण कार्यभार में वृद्धि होगी। माना कि नियम सुविधाओं पर भी लागू होता है, लेकिन स्टैक को विभाजित करने से संचार की मात्रा दोगुनी हो जाती है।

  4. एक डिजाइनर BE डेवलपर्स की समस्याओं को हल करेगा जो खरोंच से आकर्षक इंटरफेस का उत्पादन करने में सक्षम नहीं हैं। यह मानता है कि वे कम से कम html & css जानते हैं और एक ऐसे इंटरफ़ेस का निर्माण कर सकते हैं जो डिज़ाइनर द्वारा बनाए गए स्क्रीनशॉट से मेल खाता हो।

  5. विशेषताएं आम तौर पर अलग-थलग घटक होते हैं जो अन्य विशेषताओं के साथ बहुत कम बातचीत करते हैं। यह हमेशा मामला नहीं होता है, लेकिन आमतौर पर बातचीत का बिंदु एक डेटाबेस या फाइल सिस्टम की तरह निम्न स्तर पर होता है। तो एक पूर्ण-स्टैक डेवलपर को उनकी सुविधा को लागू करने से रोकने के लिए बहुत कुछ नहीं है। लेकिन अगर एक FE डेवलपर को किसी कार्य को पूरा करने के लिए BE डेवलपर पर इंतजार करना पड़ता है, तो यह पॉइंट 3 में उत्पादकता हानि के शीर्ष पर और भी अधिक देरी जोड़ देगा।

  6. Web2.0 आगे और भी FE & BE के बीच अंतर को धुंधला करता है। MVC चौखटे के साथ, और क्लाइंट-साइड पर पूरे अनुप्रयोगों का निर्माण किया जा रहा है, अब सुरक्षित और कुशल अनुप्रयोगों को लागू करने के लिए BE ज्ञान का एक अच्छा सौदा आवश्यक है।

  7. इस अभ्यास के प्रति मेरी सबसे बड़ी पकड़ यह है कि यह परियोजना में शामिल सभी की क्षमताओं को सीमित करता है। हालांकि यह 2000 के शुरुआती दिनों में एक सामान्य अभ्यास था, लेकिन यह आवश्यक रूप से किया गया था क्योंकि डेवलपर्स को ढूंढना दोनों ही काफी कठिन था (विशुद्ध रूप से दोनों के सीखने में कुछ आंतरिक कठिनाई के कारण नए-नेस के कारण नहीं।) अभ्यास का क्या अवशेष है। एक दशक बाद भी हमारे पास "वेब डेवलपर्स" हैं जो सीएसएस को नहीं जानते हैं।

  8. मेरी दूसरी सबसे बड़ी पकड़ यह है कि यह आसानी से एक विकास टीम को विभाजित कर सकता है। एक FE डेवलपर BE कोड को संशोधित करने के बाद बग बनाता है और टीम क्रॉस-स्टैक डेवलपमेंट होलसेल को प्रतिबंधित करने के लिए वोट करती है। जबकि कोड समीक्षाएं और शिक्षा समस्या का समाधान कर सकती थी, लोग इसके बजाय क्षेत्रीय बन गए।

स्प्लिट स्टैक विकास के लाभ / उपयोग-मामले:

  1. रेस्टफुल एपीआई इस डीलिनेशन के लिए एकदम सही है क्योंकि इसमें कोई एफई नहीं है। अक्सर एक कंपनी पहले RESTful API पर काम करेगी, और फिर शीर्ष पर अपने वेब एप्लिकेशन विकसित करेगी। इस मामले में बीई टीम को अगले प्रमुख संस्करण पर केंद्रित रखने के लिए एक मजबूत मामला है जबकि एफई आवेदन को खत्म कर रहा है। लेकिन मंथन का खतरा अभी भी मौजूद है - खासकर अगर एफई देव चरण में खोजी गई नई जानकारी को बीई एपीआई के लिए गैर-तुच्छ संशोधनों की आवश्यकता है।

  2. FE & BE के बीच असंतुलित वर्कलोड भी केवल FE टीम बनाने के लिए एक अच्छा मामला है। फिर से यह स्थितिजन्य है जहां शायद मुख्य विकास एक डेस्कटॉप एप्लिकेशन के माध्यम से किया जाता है और कंपनी एक 'लाइट' वेब इंटरफेस विकसित करने की कोशिश कर रही है।

  3. नए / जूनियर डेवलपर्स को प्रशिक्षण देना। यदि आप एक प्रशिक्षु या कनिष्ठ देव को काम पर रख रहे हैं और उन्हें आश्रित में फेंकने के बारे में चिंतित हैं, तो यह सहकर्मी विकास प्रणाली में कुछ संचार / एकीकरण लागत का निवेश करने का एक अच्छा विकल्प है।

इस पृष्ठ पर @ राल्फ के स्वीकृत उत्तर के बारे में चिंता:

  1. पहला बिंदु बहुत बोल्ड है - और यह जल्दी से विफल हो जाएगा यदि आपके पास उन "अच्छे आत्म-आयोजन टीमों" में से एक नहीं है। यहां तक ​​कि अगर आपके पास वह टीम है, तो आपकी सीमाओं को धक्का देने के लिए यह आपके और उनके हितों में है। और अच्छे स्व-आयोजन दल हमेशा ऐसा करने के लिए स्व-प्रेरित नहीं होते हैं।

  2. आपका दूसरा बिंदु सिर्फ गलत है। आधुनिक वेब विकास के लिए FE कोड की आवश्यकता होती है जो कि निष्पादन योग्य, सुरक्षित, अतुल्यकालिक सुरक्षित, XSS- प्रूफ, क्रॉस-ब्राउज़र, और जल्दी से विकसित होता है। लक्ष्य केवल बीई के साथ प्रतिस्पर्धा नहीं करते हैं वे प्रभावी रूप से बराबर हैं।

  3. तीसरा बिंदु भी एक बुरी धारणा है - FE विकास किसी भी BE नींव के काम के बिना शुद्ध html / css / js से शुरू हो सकता है। वहां से यह केवल एक तुच्छ प्रयास है कि इसे बीई रेंडरिंग के लिए टेम्प्लेट में तोड़ दिया जाए। अक्सर बार यह FE काम के साथ शुरू करने के लिए सबसे अच्छा है क्योंकि यह दृश्य प्रगति को देखने के लिए हितधारकों को एक गर्म और फजी एहसास देगा।

निष्कर्ष:

यदि आप एक स्टार्टअप हैं और आपके पास जलने के लिए बहुत समय या पैसा नहीं है, तो FE या BE को केवल डेवलपर्स से न लें। वरिष्ठ स्तर के वेब डेवलपर्स और एक अच्छे ऑक्स / डिजाइनर को किराए पर लें, और वे आपके आवेदन को जल्द से जल्द जमीन पर उतार देंगे। उनकी लागत अधिक है, लेकिन वे बहुत अधिक उत्पादक हैं और आपको उनमें से कम की आवश्यकता होगी।


5

मुझे लगता है कि प्रश्न गलत है।

सभी startups मैं भाग लिया था एक FE-BE केवल वास्तुकला नहीं था।

मेरे द्वारा ज्ञात अधिकांश स्टार्टअप:

  • कोर - वास्तविक उत्पाद जो एक इंटरफ़ेस को उजागर करता है
  • UI - BE और FE। बीई कोर के एपीआई का उपयोग करता है।

एपीआई बिना स्टेट की जरूरत के भी स्टेटलेस और आसानी से नकली हो जाते हैं। नरक, अगर मुझे खरोंच से एक परियोजना शुरू करनी थी, तो मैं पूरे यूआई के साथ शुरू कर सकता हूं जो शुद्ध रूप से मॉक पर काम करता है - जो प्रस्तुतियों के लिए बहुत अच्छा होगा। अधिकांश प्रतिक्रिया UI के कारण है। ग्राहक ध्यान दें कि अधिक - (आपके लक्षित दर्शकों पर निर्भर करता है।)

उदाहरण के लिए - Google खोज में मुख्य घटक है जो वेब को क्रॉल करता है, उसे अनुक्रमित करता है .. और Google UI पूरी तरह से अलग दुनिया है। यह कोर आसानी से गैर डब्ल्यूडब्ल्यूडब्ल्यू खोजों का समर्थन कर सकता है, जबकि यूआई नहीं कर सकता है।

इस तरह से आपका UI "प्लग करने योग्य" है और आपके पास चिंताओं का पृथक्करण है।

आपने विकास ज्ञान का उल्लेख किया है, हालाँकि आप परियोजना प्रबंधन पहलुओं को देख रहे हैं। जबकि कोर टीम को 2 सप्ताह स्प्रिंट अवधि की आवश्यकता हो सकती है, यूआई टीम सीआई का उपयोग करेगी - सब कुछ हर समय अपलोड किया जाता है। कोर टीम को बैकवर्ड संगतता की आवश्यकता होगी जबकि यूआई नहीं करेगा।

भाषा अलग है। आप शायद कोर कंपोनेंट के लिए सी डेवलपर्स चाहेंगे - और यह ठीक होगा यदि यह एक एकल ओएस पर चलता है, जहां यूआई को क्रॉस ओएस भाषा में लिखा जाएगा।

टेस्ट अलग। UI परीक्षण दुनिया सॉफ्टवेयर विकास में मेरे द्वारा ज्ञात सबसे जटिल में से एक है। अधिकांश स्टार्टअप इसकी उपेक्षा करते हैं और बाद में इस निर्णय पर पछतावा करते हैं। परीक्षण करते समय आप BE और FE को अलग नहीं कर सकते। यह एक एकल इकाई है जो इसे संभालती है।

ओपन सोर्स यूआई - दो को अलग करने का सबसे बड़ा लाभ यह है कि आप अपने यूआई को स्रोत खोल सकते हैं। यूआई प्रोजेक्ट को ओपन सोर्स सपोर्ट की जरूरत है।

मैं एक यूआई डेवलपर कि नहीं समझ सकता कल्पना नहीं कर सकते पूरी session सुविधा। आप जानते हैं - जहां आप लॉगिन करते हैं और विभिन्न अनुरोधों के बीच लॉग इन रहते हैं। सच है कि वे PHP को जानते हैं और जावा को नहीं .. लेकिन बीई की अवधारणा स्पष्ट होनी चाहिए (जैसे एक एन्क्रिप्टेड कुकी का उपयोग करें)। विशिष्ट भाषा अवरोध गलत है - प्रत्येक डेवलपर को किसी भी भाषा में काम करने के लिए तैयार होना चाहिए। किसने सोचा होगा कि वे कुछ साल पहले जावास्क्रिप्ट में बीई लिखेंगे।

यदि आप 3 टीम रखते हैं: कोर, बीई और एफई, तो यह संसाधनों की बर्बादी है। DB के बारे में क्या? क्या आपके पास डीबीए होना चाहिए? एक BE डेवलपर को DB और FE डेवलपर को BE और DB को क्यों नहीं जानना चाहिए? कोई सीमा नहीं है।

यदि आपको विशेषज्ञों की आवश्यकता है, और आप करेंगे, तो आउटसोर्सिंग उन्हें बहुत अच्छी तरह से काम करती है। वे आमतौर पर गुणवत्ता कोड वितरित करते हैं और वे इसे काफी तेज करते हैं। आप जरूरी नहीं कि उन्हें घर में रखना चाहते हैं क्योंकि अगर वे चले गए तो आप खो जाएंगे। इसके अलावा आप आज ऑनलाइन सलाह ले सकते हैं। अत्याधुनिक सामग्री को अलग-अलग दृष्टिकोण की आवश्यकता हो सकती है।

इसलिए परिणाम मूल रूप से यूआई में एक बहुत पतली बीई है जिसे हर एफई डेवलपर विकसित कर सकता है। यदि आपके पास यूआई में एक मोटी बीई है, तो संभवतः आपके पास कोर में आवश्यक कुछ एपीआई कार्यक्षमता है।

हमेशा कम से कम एक डेवलपर होता है जो बाकी से बाहर रहता है। ऐसे पतले FE को देखते हुए, वह BE कोड में अन्य डेवलपर्स को समर्थन (विकास नहीं) देने का प्रबंधन कर सकता है। मेरी राय है कि यह डेवलपर बहुत अच्छी स्थिति में है और इसे उचित रूप से सम्मानित किया जाना चाहिए (हालांकि वेतन में, कुछ और)। मुझे यह भी भरोसा है कि वे निर्माण प्रक्रिया को संभालने और ठीक से निर्माण करने में सक्षम होंगे।

यह मॉडल आपको बीई विकास के बारे में एक शानदार लचीलापन देता है। बीई दुनिया ने पिछले कुछ वर्षों में कई बदलावों को जाना है, इसलिए मैं किसी भी तरह बीई स्थिरता पर भरोसा करने की सलाह नहीं देता। कोर एक अलग कहानी है।

अभी भी सवाल है - क्या FE और BE एक ही प्रोजेक्ट होना चाहिए ? आपको निम्नलिखित पर ध्यान देना चाहिए

  • स्टेटिक-सर्वर से स्थैतिक संसाधनों को सबसे अच्छा काम किया जाता है। चूंकि फ्रंट-एंड सर्वर (उदाहरण के लिए नेग्नेक्स) बहुत शक्तिशाली हैं और चूंकि आप स्थिर संसाधनों के लिए कैश का उपयोग कर सकते हैं, आप अपने स्थिर संसाधनों (जो सभी HTML सामग्री, जेएस, सीएसएस, छवियां होनी चाहिए) की एकल तैनाती के साथ प्रबंधन कर सकते हैं।
  • बैकएंड कोड में समान विलासिता नहीं है, इसलिए आपके पास एक वितरित प्रणाली होनी चाहिए - जो कि एक फ्रंट-सर्वर द्वारा भी प्रबंधित की जाती है।
  • जावास्क्रिप्ट का समर्थन करने वाली सभी नई तकनीकों के साथ FE कोड का अत्यधिक उपयोग किया जाना है। अब आप जावास्क्रिप्ट के साथ डेस्कटॉप और मोबाइल एप्लिकेशन लिख सकते हैं।
  • निर्माण प्रक्रिया पूरी तरह से अलग है - और इसमें पैच डिलीवरी, अपग्रेड, इंस्टॉलेशन आदि शामिल हो सकते हैं।

मैं आगे बढ़ सकता हूं, लेकिन मुझे उम्मीद है कि यह स्पष्ट है कि मुझे लगता है कि बीई और एफई एक ही टीम होनी चाहिए, लेकिन शायद अलग-अलग परियोजनाएं।


0

मुझे लगता है कि सफल कार्यान्वयन कुछ चीजें हो सकती हैं। यदि कोई एकमात्र डेवलपर है जिसके पास एक मजबूत बैकएंड है, लेकिन उपयोगकर्ता इंटरफ़ेस और सभी "फ्रंट-एंड" टुकड़ों पर एक सभ्य समझ है, तो यह संभवतः सफल हो सकता है। यह आमतौर पर मामला नहीं है, हालांकि (मेरे व्यक्तिगत अनुभव में)। उदाहरण के लिए, मैं खुद को बैक-एंड डेवलपर मानता हूं। लेकिन मैं खुद से बहुत सारे प्रोजेक्ट पर काम करता हूं। क्या मैं प्रस्तुति और क्लाइंट-साइड टुकड़ों पर काम कर सकता हूं? ज़रूर। क्या वे एक वास्तविक प्रतिभाशाली डिजाइनर और क्लाइंट-साइड डेवलपर के रूप में अच्छे दिखेंगे? बिलकुल नहीं।

यह सब देना और लेना है। लेकिन दो डेवलपर्स की मिलीभगत से आपको संकोच नहीं होने देना चाहिए। एक डेवलपर और एक डिजाइनर के बीच उत्पादन को अधिकतम करने के लिए सच्चे और सच्चे तरीके हैं।

दूसरे शब्दों में ... यह निर्भर करता है

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.