कोड समीक्षा स्वाभाविक रूप से त्रुटिपूर्ण है। यहां बताया गया है कि इसे कैसे ठीक करें

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

मेरी पसंदीदा व्यापक रूप से फैली प्रोग्रामिंग प्रक्रिया जिसमें भारी मात्रा में खामियां हैं, कोड समीक्षा है। यह कहानी इसे विभिन्न दृष्टिकोणों से देखेगी और सुधार का प्रस्ताव देगी।

सॉफ़्टवेयर निरीक्षणों के बारे में मैंने जो पहला महत्वपूर्ण तथ्य पढ़ा, वह रॉबर्ट ग्लास द्वारा "तथ्य और सॉफ़्टवेयर इंजीनियरिंग के भ्रम" पुस्तक में था। यह निम्नलिखित का दावा करता है:

पहला परीक्षण केस चलाने से पहले कठोर निरीक्षण किसी सॉफ़्टवेयर उत्पाद से 90 प्रतिशत तक त्रुटियों को दूर कर सकता है।

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

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

मैंने वहां तीन प्रकार के निरीक्षणों की खोज की:

• डिजाइन निरीक्षण,
• यूनिट परीक्षण से पहले कोड निरीक्षण,
• यूनिट परीक्षण के बाद कोड निरीक्षण।

फगन का काम कोड के लिए एक नए दृष्टिकोण का प्रस्ताव नहीं करता है, लेकिन पहले से मौजूद घटनाओं का दस्तावेजीकरण करता है और इसके लिए तर्क देता है। हालाँकि, लेख मुझे मिले निरीक्षणों का सबसे पहला लिखित संकेत है।

कोड निरीक्षण हमारी आधुनिक कोड समीक्षाओं की तरह दिखते हैं। आज हम अन्य प्रकार के निरीक्षणों से क्यों चूक जाते हैं?

आज केवल कोड समीक्षाएं ही क्यों हैं: कुछ धारणाएं

कोड निरीक्षणों की लोकप्रियता और अन्य प्रकार के निरीक्षणों का लगभग अभाव आज हमारे उपकरणों से आता है। गिटहब, बिटबकेट, या गिटलैब सभी में अंतर्निहित कोड समीक्षा उपकरण हैं, और वे स्वाभाविक रूप से गिट प्रवाह, गिटहब प्रवाह और अन्य दृष्टिकोणों में फिट होते हैं।

डिजाइन गतिविधियों के लिए आप किस उपकरण का उपयोग करते हैं? यह UI/UX के बारे में नहीं है। यह आपके द्वारा बनाए जाने वाले कोड की संरचना के बारे में है। आपने CASE या UML टूल के बारे में सुना होगा। मैंने उन्हें किसी भी कंपनी में गंभीरता से इस्तेमाल करते नहीं देखा है, और मैंने सात के लिए काम किया है।

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

...अगर हम वही करते हैं जो उपकरण कर सकते हैं - तो हम हमेशा अपने उपकरणों की क्षमताओं तक ही सीमित रहेंगे।

मौजूदा कोड समीक्षाओं में क्या खामियां हैं?

आइए इस प्रक्रिया को विभिन्न दृष्टिकोणों से इसके शास्त्रीय रूप में देखें। उनमें से प्रत्येक महत्वपूर्ण समस्याओं को दर्शाता है।

बीपीएमएन परिप्रेक्ष्य

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

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

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

अगला चरण समीक्षक की सूचना है।

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

क्या हम अपने दैनिक कार्यों के हिस्से के रूप में संभावित अनंत लूप चाहते हैं? मुझे यकीन नहीं है, क्योंकि तेजी से वितरण आमतौर पर बेहतर होता है।

समाधान विजन परिप्रेक्ष्य

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

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

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

पारस्परिक परिप्रेक्ष्य

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

लीन मैन्युफैक्चरिंग ने अभी तक प्रोग्रामिंग को प्रभावित नहीं किया है। हालांकि, हमारे पास पहले से ही मैरी पॉपपेंडिक और टॉम पॉपपेन्डिएक की "लीन सॉफ्टवेयर डेवलपमेंट" पुस्तक का एक टूल है। यह उपकरण सात सॉफ्टवेयर विकास अपशिष्ट है:

• आंशिक रूप से किया गया कार्य,

• अतिरिक्त विशेषताएँ,

• पुनः सीखना,

• हैंडऑफ़,

• देरी,

• कार्य बदलना,

• दोष के।

  
  

क्लासिक कोड समीक्षा 7 में से 6 जीतती है!🎉

1. आंशिक रूप से किया गया कार्य । समीक्षा में किसी कार्य को अधिकांश समय छोड़ दिया जाता है। मैं आमतौर पर विकास के इस चरण को एक कतार के रूप में मानता हूं, न कि जहां कार्रवाई होती है। समीक्षा बनाने का एक दिलचस्प मनोवैज्ञानिक प्रभाव भी होता है: "कार्य तैयार है, और यह अब मेरा काम नहीं है!" कोड समीक्षा "किसी की जिम्मेदारी नहीं है" है, यही वजह है कि हम अक्सर इसे ऊपरी स्तरों तक बढ़ते हुए देखते हैं।
2. पुनः सीखना । आप ऊपर बीपीएमएन आरेख पर पुनः शिक्षण देख सकते हैं। संदर्भ को पुनर्स्थापित करना पुनः सीखना है।
3. हैंडऑफ़ । अगर हम ईमानदार हैं, तो यह यहाँ बेकार नहीं है। यह मुख्य यांत्रिकी है।
4. देरी । कोड समीक्षा डिज़ाइन में दो प्रकार के विलंब होते हैं जिन पर हम पहले चर्चा कर चुके हैं। जो चीज और भी डरावनी है वह है उनका लूप।
5. कार्य स्विचिंग । समीक्षा पर कुछ ध्यान देने के लिए लोग अपने कार्यों को रोक देते हैं।
6. दोष । कॉस्मेटिक समस्याओं का पता लगाने के लिए समीक्षा अच्छी है, लेकिन डिजाइन की खामियों के लिए नहीं, जो सबसे ज्यादा नुकसान पहुंचाती हैं। महत्वपूर्ण परिवर्तनों के लिए साथियों से पूछने की प्रेरणा की उपर्युक्त कमी से परियोजना में पर्याप्त दोष उत्पन्न होते हैं।

हमने कोड समीक्षाओं की समस्याओं को कई पक्षों से कवर किया है। इस प्रक्रिया को ठीक करने के लिए हम क्या कर सकते हैं?

कोड समीक्षा को नया स्वरूप देना

इस खंड में, हम पिछले वाले के समान विषयों को कवर करेंगे लेकिन निर्धारण के दृष्टिकोण से।

प्रक्रिया संरचना को ठीक करना

यहां हमारे पास एक कोड लेखक है जो समीक्षा पूरी होने की प्रतीक्षा कर रहा है और एक समीक्षक के अवलोकन के बाद एक जोड़ी प्रोग्रामिंग सत्र है।

प्रस्तावित प्रक्रिया में, हम पिछले एक की तुलना में कई महत्वपूर्ण परिवर्तन देख सकते हैं:

• कोई और संभावित अनंत समीक्षा लूप नहीं;

• अज्ञात अवधि का एकल प्रतीक्षा समय, हम इसे भी संभाल लेंगे;

• कोड लेखक के लिए संदर्भ को पुनर्स्थापित करने या प्रतिक्रिया की व्याख्या करने की कोई आवश्यकता नहीं है। टिप्पणियाँ अब जोड़ी के लिए अनुस्मारक के रूप में कार्य करती हैं।

  
  

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

दृष्टि विचलन को ठीक करना

कोड समीक्षाओं पर हम क्या चर्चा करते हैं? विकास के दौरान लिए गए निर्णय। हमने उनमें से कुछ को एक घंटे पहले और कुछ को एक हफ्ते पहले बनाया था। हमारी पसंद एक दूसरे के ऊपर खड़ी हैं और स्वतंत्र नहीं हैं।

आपको पहले निर्णयों में से एक पर सवाल उठाने का अवसर कितना सुखद लगता है, जिस पर अगले कई सौ खड़े होते हैं? आप अवसर को लेकर नाखुश हो सकते हैं।

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

एक प्रसिद्ध सैन्य कहावत है:

कोई युद्ध योजना दुश्मन के संपर्क में नहीं रहती है।

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

एडम थॉर्नहिल ने अपनी भारी "सॉफ़्टवेयर डिज़ाइन एक्स-रे" पुस्तक में, एक विधि प्रस्तावित की:

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

मैंने अपनी टीम के लिए सुविधाजनक भाषा के लिए एक शब्द गढ़ा है: कंकाल की समीक्षा। मुझे उम्मीद है कि यह गतिविधि के पीछे के विचार को प्रतिबिंबित करने में मदद करता है।

प्रस्तावित प्रक्रिया पर दुबला परिप्रेक्ष्य

प्रस्तावित प्रक्रिया खोजे गए कचरे को समाप्त या महत्वपूर्ण रूप से संबोधित करती है।

1. आंशिक रूप से किया गया कार्य । किसी कोड लेखक के लिए प्रत्याशा समय के दौरान किसी अन्य कार्य पर स्विच करने की अनुमति नहीं है, इसलिए कोई उपयोगकर्ता-महत्वपूर्ण आंशिक रूप से किया गया कार्य नहीं है। कम प्राथमिकता की आंशिक रूप से की गई गतिविधियां ट्रेड-ऑफ हैं।
2. पुनः सीखना । कोडिंग पूर्ण होने और जोड़ी प्रोग्रामिंग के बीच बहुत कम समय बीतने के कारण कोई पुनः शिक्षण नहीं होता है।
3. देरी । हमने कोड समीक्षक की देरी को काफी कम कर दिया है और लेखक की देरी को समाप्त कर दिया है।
4. कार्य स्विचिंग । अब लेखक के लिए अनुमति नहीं है और समीक्षक के लिए प्रबंधित है।
5. दोष । अब डिज़ाइन दोषों को ठीक करना सस्ता हो जाता है, और उनमें से सबसे महत्वपूर्ण, डिज़ाइन दोष, ठीक हो जाते हैं।

अतिरिक्त विचार

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

प्रस्तावित प्रक्रिया को शुरू करने का प्रयास करते समय मुझे जिन दो सबसे चुनौतीपूर्ण समस्याओं का सामना करना पड़ा, वे निम्नलिखित थीं:

डेवलपर्स समीक्षा चरण को एक काम के रूप में मानते हैं। दैनिक कार्य में अतिरेक को लागू करने का प्रस्ताव करते समय प्रबंधक भयभीत हो जाते हैं। यह बहुत अच्छा है कि वे अग्निशामकों की टीमों का प्रबंधन नहीं करते हैं।

पहली समस्या का इलाज दोहराव और गति है।

दूसरी समस्या अधिक जटिल है। यहाँ मैं डेनियल वाकांति की पुस्तक "एक्शनेबल एजाइल मेट्रिक्स फॉर प्रेडिक्टेबिलिटी" को उद्धृत करना चाहता हूं:

ऐसी बहुत सी रणनीतियाँ हैं जो FedEx नियोजित करती हैं, लेकिन जो शायद सबसे महत्वपूर्ण है वह यह है कि किसी भी समय FedEx के पास हवा में खाली विमान होते हैं। हां, मैंने कहा खाली विमान। इस तरह, यदि कोई स्थान अभिभूत हो जाता है, या यदि पैकेज पीछे छूट जाते हैं क्योंकि एक नियमित रूप से निर्धारित विमान भरा हुआ था तो एक खाली विमान को समस्या स्थल पर पुनर्निर्देशित किया जाता है (बस-समय पर इसे कहा जाना चाहिए)। किसी भी समय FedEx के पास "हवा में पुर्जे" होते हैं!

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

क्या हम अपडेट से संतुष्ट हैं? हां, यह अब हमारे पास जो है उससे बेहतर दिखता है।

क्या हम बेहतर कर सकते हैं? हाँ हम कर सकते हैं।

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

पढ़ने के लिए धन्यवाद! यदि आप वर्णित विचारों पर चर्चा करना चाहते हैं तो एक टिप्पणी लिखें।