कोड आधार की भलाई के लिए आवश्यक कॉर्पोरेट संस्कृति की एक विशेषता

शब्दों में कॉर्पोरेट संस्कृति को बनाए रखना आसान है। हालांकि, केवल कुछ कंपनियां सक्रिय रूप से कॉर्पोरेट संस्कृति की कुछ विशेषताओं की खोज कर रही हैं जो उत्पादकता पर महत्वपूर्ण प्रभाव डालती हैं - क्योंकि यह सबसे कठिन है।

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

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

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

इस स्थिति से बचने के लिए, विकास दल रॉबर्ट एस। मार्टिन के कई महान सुझावों ("अंकल बॉब"), अर्थात् " बॉय स्काउट नियम " का पालन करने का प्रयास करते हैं: कोड को पहले से बेहतर स्थिति में रखें । यहाँ VSCode के लिए एक मुफ्त एक्सटेंशन है जो आपको इसे बहुत आसान बनाने में मदद करता है ।

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

शायद यह सब अनुशासन की कमी के लिए आता है?

तो मैंने पहले सोचा। और फिर मैं गेयर विज्जी से मिले, जो Snyk.io के मुख्य वास्तुकार थे, और उन्होंने मुझे निम्न वाक्यांश के साथ मारा:

स्वामित्व इंजीनियरिंग भलाई का मुख्य संकेतक है।

उसका क्या मतलब था? और वह इस तरह का बयान कैसे दे सकता है?

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

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

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

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

स्रोत: Microsoft अध्ययन

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

मेरी बात अंत तक सुनिए।

कोड स्वामित्व प्रपत्र

विभिन्न परिस्थितियों के लिए उपयुक्त कोड स्वामित्व के विभिन्न रूप हैं।

सामूहिक स्वामित्व और स्वामित्व की कमी

सामूहिक स्वामित्व [...] स्वामित्व है जिसमें कोड संयुक्त रूप से स्वामित्व में है, लेकिन जिम्मेदारियों और अनुसूचियों को स्पष्ट रूप से परिभाषित किया गया है। यदि आवश्यक हो तो प्रत्येक टीम का सदस्य किसी भी सबसिस्टम या सेवा पर काम कर सकता है।

गैर-स्वामित्व - [...] एक ऐसी स्थिति जिसमें कई डेवलपर्स एक ही सबसिस्टम में बदलाव करते हैं, लेकिन कार्यों का समन्वय, गुणवत्ता या इंट्रा-टीम संचार के लिए जिम्मेदारी न्यूनतम है। ऐसी प्रणालियों में, किसी को उच्च गुणवत्ता वाले काम की उम्मीद नहीं करनी चाहिए।

स्रोत: Microsoft अध्ययन

आप इस विभाजन को आगे मालिक के कोड और एकमात्र स्वामित्व को जोड़कर जारी रख सकते हैं, लेकिन मैं मुख्य बात को याद नहीं करना चाहता, इसलिए यहां एक ग्राफ है जो कोड के स्वामित्व के रूपों का स्पेक्ट्रम दिखा रहा है:

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

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

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

अनाथ कोड

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

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

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

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

एकमात्र स्वामित्व (पूर्ण स्वामित्व)

यह कोड स्वामित्व के स्पेक्ट्रम का दूसरा छोर है। उसके साथ, सब कुछ अद्भुत और बहुत मुश्किल दोनों हो सकता है।

कोड को केवल स्वामित्व में माना जाता है जब मालिक एकमात्र डेवलपर होता है जो कोड में बदलाव कर सकता है या अनुमोदन कर सकता है, या जब मालिक है, संक्षेप में, केवल वही व्यक्ति जिसने कभी अतीत में कोड में परिवर्तन किया है।

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

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

अपने साथ ऐसा न होने दें।

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

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

परिणाम

अपने कोड बेस में फ़ाइलों के विशाल बहुमत के सामूहिक स्वामित्व के लिए प्रयास करें (किसी भी फ़ाइल के लिए कोड स्वामित्व का 50% -90%), और आवश्यक होने पर कोड स्वामित्व बढ़ाने और तकनीकी ऋण को कम करने के लिए अधिक अनुशासित रहें।

लाभ इस प्रकार हैं:

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

सब कुछ सही मायने में सार्थक की तरह, कोड स्वामित्व का एक इंजीनियरिंग संस्कृति बनाना (और इसके बाद!) समय और प्रयास लेता है, लेकिन यह ब्याज के साथ भुगतान करेगा। यह कारक लगभग किसी भी KPI इंजीनियरिंग को सीधे प्रभावित करता है, जिसकी आप कल्पना कर सकते हैं। अपनी कंपनी की संस्कृति में इसे एम्बेड करें, और लंबे समय में यह आपका बहुत बड़ा प्रतिस्पर्धी लाभ बन जाएगा।