एक परियोजना की कहानी: जब एक टीम में एक वरिष्ठ डेवलपर नहीं होता है

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

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

स्किलबॉक्स सलाह देता है: दो साल का व्यावहारिक कोर्स "मैं एक प्रो वेब डेवलपर हूं । "

हम आपको याद दिलाते हैं: "हैबर" के सभी पाठकों के लिए - "हैबर" प्रोमो कोड का उपयोग करके किसी भी स्किलबॉक्स कोर्स के लिए पंजीकरण करते समय 10,000 रूबल की छूट।

समय आपको बहुत कुछ सिखा सकता है। दुर्भाग्य से, हम न केवल सफल परियोजनाओं के साथ, बल्कि असफल लोगों के साथ काम करने के परिणामस्वरूप अनुभव प्राप्त करते हैं।

व्यक्तिगत अनुभव और नेतृत्व

अधिक ठीक है, इसकी कमी है। हमारी परियोजना में कोई लीड या वरिष्ठ डेवलपर नहीं था। सिद्धांत रूप में, यह पहले से ही स्पष्ट था कि हमारे काम का क्या होगा, लेकिन उस समय हमें यह समझ में नहीं आया।

टीम के पास कोई अनुभव नहीं था। लगभग हम सभी छात्र थे, और कोई भी ऐसा नहीं था जो हमें नेतृत्व कर सके। तब यह हमारे लिए जरूरी नहीं लगता था।

एक गर्मियों में, टीम के सदस्यों की संख्या में पाँच गुना की वृद्धि हुई। एक समस्या है? सभी एक ही पेशेवर स्तर के थे। सभी के पास अनुभव की कमी थी। हम कई समूहों में विभाजित हैं, जिनमें से प्रत्येक कुछ के लिए जिम्मेदार था।

इसके अलावा, लगभग सभी परियोजना प्रतिभागी अच्छे लोग थे। लेकिन यह हमारी पहली व्यावसायिक परियोजना थी। मेरी टीम बहुत अच्छी थी, हमने पूरी तरह से काम किया, लेकिन परिणाम असफल रहा।

उपकरण

किसी भी पेशेवर के काम का एक प्रमुख घटक उपकरण है। सही उपकरण के बिना, एक सामान्य प्रक्रिया प्रवाह असंभव है। एक अच्छी टीम में आमतौर पर एक नेता होता है, जो जानता है कि उन्हें कौन से उपकरण चाहिए और उन्हें कहां से प्राप्त करना चाहिए।



डेटाबेस

इस परियोजना में, हमारे पास वर्चुअल मशीन पर होस्ट किए गए साझा डेटाबेस तक पहुंच थी, जो सबसे धीमी गति से प्राप्त किया जा सकता था। स्वाभाविक रूप से, हमने इस तरह के काम के सभी "सुख" का अनुभव किया: डेटा हानि, गिरने वाले टेबल, एक ही तत्वों पर एक साथ कार्रवाई। यह सब महान हमारे काम को धीमा कर दिया।

हम बैकअप या रीस्टोर ऑपरेशन किए बिना डेटाबेस को स्थानीय या क्लाउड में पुन: पेश नहीं कर सकते थे। उसी राज्य में "स्वच्छ" डेटाबेस प्राप्त करने का कोई तरीका नहीं था जिसमें हम इसे विभिन्न वातावरणों में तैनात करना चाहते हैं। डेटाबेस केवल हमारे सर्वर के डेटाबेस से एक क्लोन के रूप में बनाया जा सकता है।

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

डेटाबेस माइग्रेशन और अपडेट मैन्युअल रूप से किया गया था। इसका मतलब था ... हाँ, हम फिर से समय बर्बाद कर रहे थे।

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

उत्पादकता

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

कई में बेहद धीमे उपकरण थे जिनका उपयोग कई वर्षों से किया जा रहा था। कीबोर्ड, ट्रैकपैड - यह सब समय की मुहर है।

सर्वर भी धीमे थे, जैसा कि मैंने ऊपर बताया है। परिणामस्वरूप, संपूर्ण विकास प्रक्रिया धीमी हो गई। टेस्ट भी धीरे-धीरे आगे बढ़ा।

निष्कर्ष सरल है, कॉर्पोरेट पहचान की शैली में, डेवलपर को उन उपकरणों और संसाधनों को देना है जो उन्हें सामान्य विकास प्रक्रिया के लिए आवश्यक हैं।

स्रोत नियंत्रण

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

एकीकरण और तैनाती

हमारे पास आमतौर पर कोई सीआई / सीडी समाधान नहीं था। तैनाती सरल थी: हमने संसाधनों को अंतर्निहित फ़ोल्डर से कॉपी किया और उन्हें दूरस्थ डेस्कटॉप का उपयोग करके सर्वर पर चिपकाया। अगर आपने भी कुछ ऐसा ही किया, तो आप मेरा दर्द समझ सकते हैं।

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

मेरी सलाह है कि अपने लिए एक CI / CD समाधान चुनें।

गुणवत्ता नियंत्रण

विकास प्रक्रिया का एक अन्य महत्वपूर्ण तत्व गुणवत्ता नियंत्रण है।



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

यदि टीम में एक वरिष्ठ डेवलपर होता, तो वह तुरंत हमें यह बताने में सक्षम होता है कि समस्याएं कहां हैं और उनसे कैसे निपटें। लेकिन वह वहां नहीं था, हमने स्वतंत्र रूप से काम किया।

परीक्षकों

हमारे पास भी नहीं है। हमने अपने दम पर परीक्षण किए। फिर बिना अनुभव के। नतीजतन, कीमती समय बिताया गया था कि हमने बग को पकड़ने और उन्हें खत्म करने पर खर्च किया।

यदि आप अच्छा कोड चाहते हैं, तो आपको परीक्षक, और पेशेवर चाहिए। डेवलपर्स हमेशा सॉफ़्टवेयर परीक्षण की समस्या का सामना नहीं करते हैं।

कोड की गुणवत्ता



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

मैं केवल एक चीज की सलाह दे सकता हूं: यदि आप कोड की नकल करते हैं, तो आपको इसे पूरी तरह से समझना चाहिए। इसके बिना, एक सामान्य परियोजना को साकार नहीं किया जा सकता है।

स्पेगेटी कोड

परियोजना की वास्तुकला की खराब समझ ने पूरी अराजकता पैदा कर दी। स्पेगेटी कोड एक नरम विवरण है जो अंत में हुआ।

कुछ खंड अलग-अलग हाथों से, अलग-अलग डेवलपर्स से, जिनमें से प्रत्येक ने कुछ अलग जोड़ा है। परियोजना का अंतिम कोड विचारों और "बैसाखी" का एक समूह था।

हमारे पास एक निर्भरता इंजेक्शन प्रणाली नहीं थी, और हमने किसी भी सामान्य डिज़ाइन पैटर्न का उपयोग नहीं किया था। इससे बहुत से बुरे कोड आए जो सिर्फ "सड़ने" के लिए शुरू हुए।

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

निष्कर्ष

हमारे अनुभव की कमी के कारण कई समस्याएं पैदा हुईं। हमें अभी नहीं पता था कि परियोजना पर कैसे काम करना है। हम पर्यावरण को ठीक से लागू नहीं कर सके। हमारे पास आवश्यक उपकरण और प्रौद्योगिकियां नहीं थीं।

एक अच्छा टीम लीडर इन सभी समस्याओं का समाधान करेगा। वह पहले से बहुत आगे होगा।

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

स्किलबॉक्स अनुशंसा करता है:

• प्रैक्टिकल कोर्स "मोबाइल डेवलपर प्रो"
• ऑनलाइन पाठ्यक्रम "वेब डेवलपर पेशे"
• ऑनलाइन कोर्स "प्रोफेशन फ्रंटेंड-डेवलपर । "