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

हम आपको डिनो के एक लेख के अनुवाद के साथ खुद को परिचित करने के लिए आमंत्रित करते हैं “कोड के साथ समस्याएं? टीम को सर्वश्रेष्ठ कोड लिखने में मदद करें। ”


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

सॉफ्टवेयर डेवलपमेंट के सात गुण

मैं कहता हूं कि सफल परियोजनाएं दो कारकों पर निर्भर करती हैं: नेतृत्व से जो नेतृत्व के बारे में बहुत कुछ जानता है, और डेवलपर्स जो समझते हैं कि गुणवत्ता कोड क्या है। यहाँ सात गुणों की एक सूची दी गई है जो वास्तव में एक डेवलपर स्वर्ग में एक टीम का नेतृत्व कर सकते हैं:

1. उपकरण को कोड लिखने में आपकी मदद करने दें

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

2. यदि कोई बुरा कोड लिखता है, तो उसे इसके बारे में बताएं

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

3. डेवलपर को बेहतर बनाने में मदद करें

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

4. परिवर्तनों की पुष्टि करने से पहले कोड का निरीक्षण करें।

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

5. हैप्पी वह प्रोजेक्ट है जिसमें हीरो की जरूरत नहीं होती

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

6. व्यायाम को प्रोत्साहित करें

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

7. निरंतर परिवर्तन लेनदेन का हिस्सा है।

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

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

यह मुख्य समस्या है।

कभी-कभी प्रबंधन इसे विकास लागतों में एक सरल कमी, कम-भुगतान करने वाले डेवलपर्स को काम पर रखने और परीक्षण और प्रलेखन की मात्रा को कम करने के लिए अनुरोध / आदेश देता है। वे लेखन कोड की लागत को कम करते हैं, परियोजना को होमवर्क में बदलते हैं। दुर्भाग्य से, ,code-कौन-सा-कार्य करना समस्या का सिर्फ एक पक्ष है। आज, आवश्यकताओं में लगातार परिवर्तन हो रहा है, जटिलता बढ़ रही है - और, सबसे बुरी बात, वास्तव में केवल जाने पर महसूस की जाती है। इस परिदृश्य में, कोड लिखना केवल एक लागत आइटम है। कोड रखरखाव और इसका विकास सबसे महंगे लेख हैं।
एक अच्छा वास्तुकार बहुत अच्छी तरह से जानता है कि एक कोड की स्थिरता सीधे उसकी गुणवत्ता, सॉफ्टवेयर विकास और भाषा सुविधाओं के सिद्धांतों की समझ, सही ढंग से लागू पैटर्न और प्रथाओं और परीक्षण क्षमता पर निर्भर करती है। यह कोडिंग को whichcode-who-just-works की तुलना में अधिक महंगी प्रक्रिया बनाता है, लेकिन justcode-which-just-works को बनाए रखने और विकसित करने की तुलना में बहुत सस्ता है।

मास्टर वर्ग डिनो एस्पोसिटो 25 अक्टूबर को मास्को में आयोजित किया जाएगा। इसके बारे में यहाँ और पढ़ें।