नमस्कार। हाल ही में, मैंने छात्रों के लिए एक रिपोर्ट बनाई कि आधुनिक वेब विकास करने से क्या धक्कों को भरा जा सकता है। विकास संबंधी प्रक्रिया के दौरान हम विभिन्न निर्णय कैसे लेते हैं, प्रौद्योगिकी का चुनाव टीम के आकार को कैसे प्रभावित करता है, टीम का आकार परीक्षण के दृष्टिकोण को कैसे प्रभावित करता है, परीक्षण के दृष्टिकोण पूरी कंपनी की संरचना से कैसे संबंधित हैं ...।

यह एक वितरित पसंद के साथ एक खोज की तरह कुछ निकला: किस प्रोग्रामिंग भाषा से जिसे चुनना है और किसके लिए एक टीम को किराए पर लेना बेहतर है जो अब तक का सबसे उपयोगी उत्पाद बना देगा। मेरा सुझाव है कि आप इस पोस्ट को पढ़ें, अपने विकल्प चुनें, खोज पूरी करें और चर्चा करें कि क्या दर्दनाक हो गया है।

अपडेट - कुछ पाठ को कैट में जोड़ा।

विचार से लेकर प्रोटोटाइप तक

मान लीजिए कि मेरे दोस्त वलेरा और मैंने एक स्टार्टअप करने का फैसला किया। एक्स के लिए उबेर , या ऐसा कुछ और। एक बार में इकट्ठा, इस विचार पर चर्चा की, शांत विषय। करना ही चाहिए। तीन महीने सोया नहीं, खाना नहीं खाया, घर नहीं छोड़ा। विकसित की है। उन्होंने शुरू किया और महसूस किया कि किसी को भी इसकी आवश्यकता नहीं है।

उदासी। चलिए फिर कोशिश करते हैं। इस बार हमने बाजार का अध्ययन किया, इस बात पर ध्यान दिया कि उपयोगकर्ताओं की क्या समस्याएं हैं, क्या समस्याएं हैं। हमने घुटने पर पूरी तरह से कुछ प्रकार के प्रोटोटाइप बनाए, जल्दी और दो शामों में नि: शुल्क। प्रोटोटाइप उतार दिया। ठंडा करो, आगे बढ़ो।

प्रौद्योगिकी का चयन

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

भाषा

क्रम में। किस भाषा में लिखना है? आप फैशनेबल फंक्शनल ले सकते हैं: हास्केल, एर्लैंग, लिस्प (70 से अधिक दादाजी के बीच बहुत फैशनेबल)। या एक अन्य हत्यारा जेएस, जो बहुत ही शांत है, जेएस में संकलित है, सभी आवश्यक विशेषताएं हैं। लेकिन सबसे अधिक संभावना है, हमारे पास एक साल में किराए पर लेने के लिए कोई नहीं होगा, क्योंकि अगला हत्यारा जेएस बंद नहीं करेगा, और फिर से फिर से काम करना होगा या परियोजना को फिर से लिखना होगा।

नंबर दो का प्रयास। आप समय के हिसाब से कुछ चेक कर सकते हैं। उदाहरण के लिए, PHP। यह एक अच्छी भाषा है, यह कभी-कभी आलोचना करने के लिए फैशनेबल है, इसकी कमियां हैं, लेकिन इस पर व्यापार तर्क करना आसान है, यह काफी तेज है, अच्छी तरह से तराजू, आप कभी भी, कहीं भी लोगों को काम पर रख सकते हैं। लेकिन वह बहुत उत्पादक नहीं है। इसलिए, हमें या तो बहुत सारे लोहे की जरूरत है या अपने स्वयं के संकलक को लिखना है, जैसा कि फेसबुक या वीके ने किया था।

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

ठीक है, हमारे पास अभी भी पायथन है। सिद्धांत रूप में, सब कुछ ठीक है। लेकिन हम पायथन में एप्लिकेशन चलाते हैं, यह 56 में से एक कोर का उपयोग करता है, अन्यथा ... सब कुछ ठीक है। या आप कुछ आधुनिक ले सकते हैं: जाओ, जंग, कुछ और। लेकिन वे बहुत निम्न स्तर के हैं, और हम केवल लंबे समय तक सुविधाएँ करते हैं ... हमें अभी भी कुछ भाषा चुननी है। इसे जेएस अंत में आने दो, नीचे आओ।

डेटाबेस

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

ठीक है, चलो एक संबंधपरक आधार लेते हैं। यदि आपके पास पर्याप्त धन है तो MySQL, PostgreSQL या Oracle। संबंधपरक डेटाबेस के साथ, आप एक दिन काम पर आ सकते हैं और लेनदेन और भंडारण से खुद को नरक में पा सकते हैं। जरूरी नहीं कि यह हमारे प्रोजेक्ट के साथ ही हो। लेकिन अगर ऐसा होता है, तो तर्क की इन पेचीदगियों का परीक्षण करना असंभव होगा। और यहां तक ​​कि अगर अचानक हम अपने बड़े गोल्ड सर्वर की ऊर्ध्वाधर सीमा तक पहुंचते हैं, जिस पर हम डेटाबेस को होस्ट करते हैं, तो उन्हें अलग करना काफी मुश्किल होगा। हम लंबे समय तक सुविधाएँ करते हैं।

ठीक है। उन्होंने कुछ आधार लिया, ओआरएम ने एक एसक्यूएल से दूसरे में जाने के लिए इसे आसान बनाने के लिए इसके सामने धमाका किया। किसी दिन (बिगाड़ने वाला: कभी नहीं)।

आर्किटेक्चर

कौन सा आर्किटेक्चर लेना है? हैरेस पर लोग लिखते हैं कि माइक्रोसॉफ़्ट शांत हैं। ओलेग बुनिन कहते हैं: "माइक्रोसर्विस को लें।"

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

ठीक है तो चलो एक मोनोलिथ बैंग। स्टार्टअप के लिए यह सही विचार है। आप एक महान मोनोलिथ के साथ बहुत लंबे समय तक रह सकते हैं और कोई समस्या नहीं है। लेकिन अगर हम टीम का विस्तार करने का फैसला करते हैं, तो हमें सावधान रहना चाहिए। आमतौर पर मोनोलिथ तराजू होता है, जबकि डेवलपर्स 20, 30, 50 हैं। इसके अलावा, सुविधाओं की डिलीवरी की गति तेजी से गिरती है, और हम उपयोगकर्ताओं को खो देते हैं।

कहां से शुरू करें प्रोजेक्ट?

इसे सभी को कहीं न कहीं लॉन्च करने की जरूरत है। 2018, क्लाउड में ऐसा करने का सबसे तार्किक विकल्प। इसे बादल में न चलाएं - लड़के हँसेंगे। लेकिन, सबसे पहले, संघीय कानून 152 है, जो कि क्लाउड प्रदाताओं की पसंद को सीमित करता है जिन्हें होस्ट किया जा सकता है। दूसरे, यह बहुत आसान है कि गलती से जीथब पर आपके अमेज़ॅन खाते में एक निजी कुंजी हो, और कोई निश्चित रूप से आएगा और अपने सारे पैसे खर्च करेगा। और अगर ऐसा नहीं होता है, तो कुछ बिंदु पर क्लाउड टैरिफ आपको तोड़ देगा।

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

टीम

डिज़ाइन

मान लें कि हमने परियोजना की मेजबानी करने के लिए भाषाओं, डेटाबेस और कहां से तैयार किया है। टीम में भर्ती होने का समय आ गया है। आप कुछ बहुत अच्छे लोगों को ले सकते हैं जो सभी समस्याओं को हल करेंगे: सौ गुना डेवलपर्स, बैकएंड निन्जा, आप समझते हैं। शायद यह एक सवारी देगा। लेकिन वास्तव में, यह संभावना है कि आमंत्रित सितारे होंगे:

• जहरीले दोस्तों जो कुछ भी नहीं करेंगे और टीम में खराब माहौल पैदा करेंगे,
• या आदर्शवादियों ने एक त्रुटिहीन वास्तुकला द्वारा बिट का निर्माण किया, ORM को उन ठिकानों के सामने रखा जिन्हें आपको कभी बदलना नहीं है ...

अंत में ... हाँ, हम लंबे समय से सुविधाएँ कर रहे हैं। एक और विकल्प साधारण लड़कियों और लड़कों को लेना है जो कोड लिखते हैं, ठीक सुविधाएँ करते हैं। लेकिन यदि आप विभिन्न पृष्ठभूमि वाले बहुत अनुभवी डेवलपर्स नहीं लेते हैं, तो वे एक अलग शैली में कोड लिख सकते हैं, चीजों को अलग तरीके से कर सकते हैं, और टीम के पर्याप्त आकार के साथ, हर कोई तंग हो जाएगा, हर किसी के पास एक-दूसरे की खींच-तान में घुंघराले ब्रेसिज़ होंगे। यह बहुत प्रभावी नहीं है। इसे कैसे हल किया जा सकता है? बॉस सभी कोड पढ़ सकता है। मैं सभी पुल-क्वैस्ट पढ़ सकता हूं, और मेरे दोस्त और सह-संस्थापक फाउंडर वलेरा फिर दूसरी बार इसे पढ़ेंगे (बस मामले में, आप कभी नहीं जानते हैं)। यह स्पष्ट है कि यह पैमाना नहीं है और सभी विशेषताएं धीरे-धीरे बना रही हैं।

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

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

गुणवत्ता आश्वासन

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

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

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

लेकिन वे अन्य समस्याएं पैदा करते हैं। चूंकि डेवलपर्स, परीक्षक, और क्रॉस-फ़ंक्शनल टीमों के अन्य सभी सदस्य अपनी टीमों के भीतर अधिक संवाद करना शुरू करते हैं और पिछली समस्याओं को हल करते हैं, इसलिए वे अपने कार्य में अपने सहयोगियों के साथ कम संवाद करते हैं: अन्य बैक-टेस्टर्स और परीक्षक, वे पहिया को सुदृढ़ करना शुरू करते हैं, समानांतर में समान चीजें करते हैं, टीमों के बीच अलगाव। साबुन के लिए अवल: एक अलगाववाद था, यह एक और हो गया।

इसका समाधान कैसे करें? शौक समूहों में सहयोगियों के साथ संवाद करें। कहीं इसे गिल्ड कहा जाता है, तो कहीं इसे समुदाय। यदि हम क्रॉस-फ़ंक्शनल टीमों के साथ टीम को स्केल करते हैं ताकि वे स्व-निहित न हों, हम बस बैकएंड, कार्यात्मक भाषाओं, सुरक्षा के प्रशंसकों का एक सर्कल व्यवस्थित करते हैं ...

परिणाम

वास्तव में, सब कुछ इतना बुरा नहीं है। आप किसी भी स्थिति से बाहर निकलने का रास्ता खोज सकते हैं, समाधान पा सकते हैं। शायद आदर्श नहीं, लेकिन इस स्थिति में न्यूनतम समस्याओं के साथ सबसे उपयुक्त। एक समझौता हमेशा संभव है।

और फिर भी - यह सब दिलचस्प है। उन समस्याओं को हल करना दिलचस्प है जो किसी ने पहले ही हल कर ली हैं, नई समस्याओं को हल करने के लिए और भी दिलचस्प हैं। ज्ञान बांटना दिलचस्प है।