प्रोजेक्ट मैनेजर: थ्री टीम स्टेप्स टू परफेक्ट कोड

प्रस्तावना

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

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

और मेरा जवाब हां है। और यह आवश्यक है!

जागरूकता

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

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

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

याद रखें कि परियों की कहानियों में इवान Tsarevich, पुनर्जीवित, पहले मृत पानी से भरा था और उसके बाद ही जीवित था। संभवत: अंत में उन्होंने कुछ वसीला द वाइज़ से शादी की। सॉफ्टवेयर विकास में, यह उसी के बारे में है।

पहला कदम। घृणा

यह शायद सभी का सबसे विवादास्पद थीसिस है कि मैं यहां उद्धृत करूंगा। वे अक्सर मुझसे असहमत थे (यह कोने में व्यक्तित्वों और नाराज सूँघने के लिए स्विच करने के लिए आया था), लेकिन व्यवहार में इसकी प्रभावशीलता का परीक्षण किया गया है।

इसलिए, शुरुआत में, प्रोग्रामर्स को नफरत फैलाने की जरूरत है। बुरे और गंदे कोड के लिए नफरत, बेवकूफ गलतियों के लिए, एक घर के आकार में एक विधि से मिलकर पांच सौ लाइनों और वर्गों के मामलों के लिए।

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

इस तरह की कई समीक्षाओं के बाद, प्रोग्रामर सबसे पहले से ही समझ पाएंगे कि एक जादुई बटन क्या है और "रेंडरिंग विधि" को कैसे कहा जाए। एक बार फिर: मान लें कि कोई भी बुरा कोड लिखना पसंद नहीं करता है। बस बहुतों को समझ नहीं आता कि वह बुरा है।

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

चरण दो जोश

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

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

चरण तीन मानसिक स्वास्थ्य

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

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

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

निष्कर्ष में कुछ शब्द

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