एक जूनियर सॉफ्टवेयर इंजीनियर के रूप में, मुझे हमेशा कोड कोड की टिप्पणियों से अवगत कराया गया जो मुझे एक बेहतर कोडर बनने के लिए सीखने के लिए मिला। लेकिन जब मेरे लिए अपनी पहली कोड समीक्षा का प्रयास करने का समय आया, तो मैंने महसूस किया कि मेरे अनुभव ने मुझे दूसरी तरफ होने के लिए तैयार नहीं किया था।
मैंने इम्पोस्टर सिंड्रोम का एक गंभीर मामला विकसित किया है, जो सवालों के साथ नीचे की ओर घूम रहा है : क्या मुझे इस लाइन की कोड पर टिप्पणी करनी चाहिए या क्या यह इसके लायक नहीं है? क्या मुझे हर टिप्पणी का समर्थन करने के लिए लेख ढूंढने चाहिए? क्या मैं इसे अनुमोदित करके साइट को क्रैश कर दूंगा? क्या वे मुझसे नफरत करेंगे? ठीक है, मैं मानता हूँ मैं बहुत जल्दी सर्पिल। लेकिन कुछ सहकर्मियों से बात करने के बाद, मुझे पता था कि मैं अपनी चिंताओं में अकेला नहीं था।
GitHub के एक अनुभव इंजीनियर जेसिका रूडर कहते हैं, "जूनियर सॉफ्टवेयर इंजीनियरों को एक धारणा के अनुरूप कोड में फेंक दिया जा सकता है, " आप जानते हैं कि एक किताब को कैसे पढ़ना है, ताकि आप जान सकें कि किताब कैसे लिखनी है, जो सच नहीं है।
ऐसी उम्मीदें हैं जो कोड की समीक्षा के साथ आती हैं, और प्रक्रिया तंत्रिका-रैकिंग हो सकती है। इसलिए मैंने सात अन्य सॉफ्टवेयर इंजीनियरों का साक्षात्कार लिया कि कैसे एक समीक्षात्मक मानसिकता का निर्माण करने के लिए सुझाव एकत्र करें।
1. समग्र प्रभाव के बारे में सोचो
आम तौर पर, एक अच्छा पुल अनुरोध (पीआर) केवल कोडबेस के एक सीमित हिस्से को प्रभावित करना चाहिए। हालाँकि, सीमित दायरा आपको बड़े कोडबेस के संदर्भ में कोड परिवर्तन के बारे में सोचने से नहीं रोक सकता है।
निगेल मुनोज़, द मेज़र में एक पूर्व पूर्ण-स्टैक इंजीनियर और एक वर्तमान फ्रीलांस सॉफ़्टवेयर इंजीनियर, समीक्षक को "यह परिवर्तन बड़े और छोटे चित्र को कैसे प्रभावित करता है" के बारे में सोचने के लिए प्रोत्साहित करता है। यह दोहराया जाता है, गैर-मॉड्यूलर, या सबसे हाल के मानक सम्मेलनों का पालन नहीं करता है - साथ ही कोडबेस की वास्तुकला में संशोधनों का विश्लेषण भी करता है।
हडसन रिवर ट्रेडिंग के एक प्रमुख डेवलपर सैम डोनो का मानना है कि "टिप्पणी करने के लिए बहुत बड़ा या बहुत छोटा नहीं है। छोटे सुधारों के सुझाव से कोडबेस के कई हिस्सों में बड़े सुधार हो सकते हैं। ”
आप GitHub पर एक पीआर टिप्पणी का उपयोग सकारात्मक प्रतिक्रिया प्रदान करने के लिए कर सकते हैं और साथ ही यह भी इंगित कर सकते हैं कि कोड कहां से हो सकता है फ्रेमवर्क रिएक्ट के मानक सम्मेलनों से अलग हो सकता है।
उदाहरण के लिए, अपने स्वयं के कोड समीक्षाओं में से, मुझे एक टिप्पणी मिली कि एक रिएक्ट घटक पर कुछ गुण भ्रमित थे, जिसने इस सवाल को व्यापक कर दिया कि घटक का उपयोग कैसे किया जा रहा था। अंततः, मैंने मूल घटक से गुणों को हटा दिया और प्रत्येक के व्यवहार को स्पष्ट करने के लिए एक अलग घटक बनाया और यह सुनिश्चित किया कि दोनों का उपयोग अधिक स्थानों पर किया जा सके।
2. सुरक्षा पर विचार करें
यह मत भूलो कि कुछ बदलाव सिर्फ कोडबेस से ज्यादा असर डाल सकते हैं। रूडर मूल्यांकन की सिफारिश करता है कि क्या कोई उपयोगकर्ता "इस कार्यक्षमता का उपयोग किसी को परेशान करने या सिस्टम का दुरुपयोग करने के लिए कर सकता है।" उदाहरण के लिए, यदि पुल अनुरोध में नई सुविधा में उपयोगकर्ता प्रविष्टि, SQL इंजेक्शन, डेटा एक्सेस, क्रॉस-साइट स्क्रिप्टिंग और अन्य सुरक्षा कमजोरियां।
3. बग्स पर ध्यान दें
आपके साथी कोड योगदानकर्ता - चाहे वे कितने भी रोबोट क्यों न लगें - मानव हैं, और मनुष्य कार्यात्मकताओं को तोड़ या भूल सकते हैं। इसलिए सुनिश्चित करें कि आप "बाकी कोड के समान महत्व के साथ परीक्षणों की समीक्षा करें", शिक्षक वेतन शिक्षकों के तकनीकी नेतृत्व अभिषेक पिल्लई को सलाह देते हैं। "वे नए कीड़ों को रोकेंगे और भविष्य में इस पर काम करने वाले किसी अन्य व्यक्ति को दस्तावेज के रूप में काम करेंगे।"
परीक्षणों को पढ़ना आपको एक नई सुविधा की कार्यक्षमता को समझने में मदद कर सकता है और विभिन्न मामलों को यह पेश करेगा, जबकि परीक्षणों का विश्लेषण आपको लापता मामलों को इंगित करने और इस पीआर में निहित विशेषताओं को खोजने में मदद कर सकता है। यदि कोड परिवर्तन में कोई परीक्षण शामिल नहीं हैं और वे प्रासंगिक लगते हैं, तो समीक्षा के भीतर उनसे अनुरोध करना उचित है।
लेकिन परीक्षण सब कुछ नहीं हैं। "प्रणाली में बहुत अधिक विश्वास मत करो, " डोनो चेतावनी देता है। "सिर्फ इसलिए कि परीक्षण किए गए का मतलब यह नहीं है कि कोई कीड़े नहीं हैं।"
आप यह भी चाहते हैं कि "एप्लिकेशन को स्थानीय रूप से चलाने के लिए इसे कार्यात्मक रूप से परीक्षण करें और सुनिश्चित करें कि यह काम करता है। अगर यह काम नहीं करता है, तो आगे की समीक्षा करने का कोई मतलब नहीं है, ”रेयान वर्नर, 8 वें लाइट में एक सॉफ्टवेयर डेवलपर कहते हैं। हालांकि कुछ समीक्षकों को नहीं लगता है कि मैन्युअल परीक्षण को कोड समीक्षा प्रक्रिया का हिस्सा होना चाहिए - क्योंकि इसमें लगने वाले समय का हिस्सा है - वर्नर का मानना है कि यह निर्धारित करने का एक त्वरित तरीका है कि क्या आपको अधिक समय की समीक्षा के साथ-साथ एक रणनीति बनाने में मदद करनी चाहिए। एक बैकलॉग की वृद्धि।
4. एक टीम प्लेयर बनें
जब कोड की समीक्षा करने की बात आती है, तो क्लिच नए अर्थ लेता है। "सामूहिक स्वामित्व के कारण वकालत करने वाले" कहते हैं, "समय की समीक्षा करें क्योंकि यह हर किसी का कोडबेस है।" आप, समीक्षक के रूप में, बग के बैकलॉग को अपने लक्ष्य को देने से बड़े होने से बचाने की दिशा में काम करना चाहिए। टीम कम लाइन के नीचे काम करती है।
पिल्लई अपने साथियों के स्वीकृत और रेडी-टू-मर्ज PRs को मनाने के लिए gif का उपयोग करता है।
इसी समय, द लेज़र में एक टेक लीड, चार्ल्स लुक्सटन, समीक्षक को टीम की प्राथमिकताओं को समझने और याद रखने के लिए प्रोत्साहित करता है। तेजी से समय-सीमा और असहमति के साथ, कभी-कभी बैकलॉग के लिए एक टू-डू आइटम बनाने से जो भविष्य में सुधार सुनिश्चित करेगा और कोड पर एक टिप्पणी डाल सकता है इस बीच बैंड-एड आपको क्रम में चाहिए अपनी टीम को खुश रखो।
अंत में, अपने आप से पूछें कि क्या यह कोड किसी ऐसे व्यक्ति के लिए समझ में आएगा जो अभी-अभी टीम में शामिल हुआ था और अपने पहले कुछ हफ्तों में इसे पढ़ रहा था, जो आपके कोड को पठनीय और समझने में मदद करेगा।
5. सीखने और ज्ञान साझा करने के लिए प्रक्रिया का उपयोग करें
समीक्षा प्रक्रिया में सभी को कोडबेस, भाषाओं, रूपरेखाओं और सर्वोत्तम प्रथाओं में अधिक जानकारी प्राप्त करने के लिए एक जगह मिलती है।
मैट जेफ़री, द मेज़र पर एक टेक लीड, समीक्षक को सलाह देता है कि "परिवर्तनों को वास्तुशिल्प रूप से समझें। एक तरीका फ़ाइल नाम पढ़ना है क्योंकि वे संदर्भ देने में मदद करते हैं। उदाहरण के लिए, यदि आप डेटा एक्सेस लेयर में बदलाव देख रहे हैं। आप जानते हैं कि आप व्यावसायिक तर्क या UI के साथ काम नहीं कर रहे हैं। "
आप प्रलेखन साझा करने के लिए GitHub पर PR टिप्पणी का उपयोग कर सकते हैं।
जब आप कोड परिवर्तन से सीखते हैं, तो आपके पास ज्ञान साझा करने का अवसर भी होता है। "यह आपकी राय को समझाने और प्रलेखन के साथ इसे वापस करने के लिए सबसे अच्छा है, " लक्सटन कहते हैं। लिंक जो आप साक्ष्य और भरोसेमंद लेखों का समर्थन करने के लिए प्रदान करते हैं, न केवल समीक्षक और कोड लेखक को विभिन्न दृष्टिकोणों का पता लगाने में मदद करते हैं क्योंकि वे एक अंतिम निर्णय लेते हैं, बल्कि प्रोग्रामिंग के अपने ज्ञान को भी बढ़ाते हैं।
जब आप इन युक्तियों को ध्यान में रखते हैं, तो यह भी याद रखें कि समीक्षा करना आपके लोगों के कौशल का अभ्यास करने का समय है। "लोगों को संदेह का लाभ दें जो उन्होंने अपने दृष्टिकोण के बारे में सोचा था और रक्षात्मकता को दूर करने की कोशिश करते समय विभिन्न संभावनाओं को इंगित करते हैं, " रूडर कहते हैं। "मैं टिप्पणियों को भर में छोड़ देता हूं और एक रैप अप टिप्पणी करता हूं - यहां क्या शानदार है, यहां क्या सुधार किया जा सकता है, यहां विलय से पहले क्या बदलने की जरूरत है।"
इस तरह के दृष्टिकोण से, आप न केवल अपने कोड आधार को तकनीकी ऋण, सुरक्षा खतरों और बग से बचाएंगे, बल्कि आप अपनी टीम का निर्माण भी करेंगे।
