जेएच वर्षा जल "बिल्लियों को कैसे चराना है": विकास के दूसरी तरफ

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

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

आवश्यकताओं और विशिष्टताओं की परिभाषा

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

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

ऐसी बैठकों की अनुशंसित आवृत्ति सप्ताह में एक बार के बारे में है, हालांकि, निश्चित रूप से, आपको विकास की सामान्य गति और किसी विशेष कंपनी के लिए प्रक्रियाओं के संगठन की विशेषताओं में समायोजन करने की आवश्यकता है।

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

काम करने के लिए एक नया कार्य लेने के लिए सहमत होने से पहले, आपको अपने आप से कई सवाल पूछने चाहिए:

• प्रस्तावित बदलाव का लघु और दीर्घावधि में सिस्टम आर्किटेक्चर पर क्या प्रभाव पड़ेगा?
• प्रस्तावित परिवर्तन नेटवर्क के बुनियादी ढांचे को कैसे प्रभावित करेगा जिसमें यह लगेगा?
• प्रस्तावित परिवर्तन उपयोगकर्ता की क्षमता को प्रभावी ढंग से और इस उत्पाद के साथ सहभागिता करने के लिए कैसे प्रभावित करेगा?
• प्रस्तावित बदलाव का उन कर्मचारियों के कार्यों पर क्या प्रभाव पड़ेगा जिनके साथ मिलकर काम करना है - लागू करने के लिए, साथ देने के लिए?

इस तरह के प्रतिबिंब नुकसान की पहचान करने और अन्य समूहों के साथ बातचीत के लिए सामान्य दिशा निर्धारित करने में मदद करेंगे।

डिज़ाइन

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

आर्किटेक्चर पहले, फिर घटक।

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

भवन का वास्तु

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

शायद विकास में इस चरण को शायद सबसे अधिक जिम्मेदार कहा जा सकता है - विशेषज्ञों का कहना है कि यह वास्तुकला के मुद्दों की सटीक उपेक्षा है जो अक्सर परियोजनाओं के पतन की ओर जाता है। विफलता के सामान्य कारणों में, वे नाम देते हैं:

• विचार की कमी, मैला संगठन (या इसकी पूर्ण अनुपस्थिति)।
• प्रणाली की अत्यधिक कठोरता और सीधेपन, वाणिज्यिक जरूरतों के अनुसार इसके विस्तार को रोकना।
• घटकों की अत्यधिक इंटरकनेक्टिविटी, कॉन्फ़िगरेशन में लचीलापन की कमी।
• ऊपरी स्तरों पर अत्यधिक जटिलता, जिससे बुनियादी घटकों को संशोधित करना मुश्किल हो जाता है।

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

इस स्तर पर काम के अंत तक, आपको निम्नलिखित सवालों के जवाब देने के लिए तैयार रहना चाहिए:

• उपयोगकर्ता सिस्टम के साथ कैसे संपर्क करेगा?
• सिस्टम के कामकाज को सुनिश्चित करने के लिए किन घटकों को इकट्ठा करने की आवश्यकता है?
• घटकों के संपर्क के लिए तंत्र क्या होगा जो सिस्टम के कामकाज को सुनिश्चित करता है?
• इस एप्लिकेशन को बनाने के लिए कौन सी प्रौद्योगिकियां सबसे उपयुक्त हैं?
• सिस्टम को क्लाइंट तक कैसे पहुंचाया जाए?

घटक योजना

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

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

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

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

निरीक्षण के दौरान, एक तकनीकी नेता विभिन्न प्रकार की त्रुटियों का सामना कर सकता है। वर्षा जल पाठक को दो किस्मों पर केंद्रित करता है:

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

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

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

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

परीक्षण

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

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