कोड रिव्यू — यह क्या है, कोड रिव्यू और PR जांच कैसे काम करती है

कोड रिव्यू क्या है

कोड रिव्यू एकीकरण से पहले सहकर्मियों द्वारा कोड की व्यवस्थित जांच है। Git संदर्भ में, इसका मतलब है: एक डेवलपर बदलावों के साथ पुल रिक्वेस्ट बनाता है, समीक्षकों को नियुक्त करता है, और वे diff का अध्ययन करते हैं, टिप्पणियाँ छोड़ते हैं और निर्णय देते हैं। एक समीक्षक बदलाव का अनुरोध कर सकता है, PR को अनुमोदित कर सकता है या सामान्य टिप्पणी छोड़ सकता है।

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

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

कोड रिव्यू में क्या जांचें

कोड रिव्यू व्यवस्थित होना चाहिए, अव्यवस्थित नहीं। अनुभवी समीक्षक एक विशिष्ट क्रम में कोड की जाँच करते हैं: पहले आर्किटेक्चर और तर्क, फिर परीक्षण, फिर सुरक्षा और प्रदर्शन, और अंत में — शैली और नामकरण। यह क्रम सुनिश्चित करता है कि समीक्षक के थकने से पहले महत्वपूर्ण समस्याएँ देखी जाएँ।

आर्किटेक्चर और तर्क: क्या कोड कार्य को हल करता है, क्या अत्यधिक अमूर्तताएँ हैं, क्या SOLID और DRY सिद्धांतों का पालन किया गया है। जटिल कोड जिसे पहली बार पढ़ने पर समझना मुश्किल है, यह संकेत है कि रिफ़ैक्टरिंग की आवश्यकता है। समीक्षक को यह सुनिश्चित करना चाहिए कि कोड ठीक वही करता है जो कार्य निर्दिष्ट करता है और इसकी जिम्मेदारी से परे कोई दुष्प्रभाव नहीं है।

परीक्षण: क्या नए परीक्षण सभी परिदृश्यों को कवर करते हैं — सकारात्मक, नकारात्मक, सीमांत मामले। क्या बदलावों के बाद मौजूदा परीक्षण पास होते हैं। क्या कोई अस्थिर परीक्षण हैं जो असंगत रूप से विफल होते हैं। सुरक्षा: SQL इंजेक्शन, XSS, लॉग या API प्रतिक्रियाओं के माध्यम से संवेदनशील डेटा लीक का अभाव। प्रदर्शन: एल्गोरिदम दक्षता, अत्यधिक डेटाबेस क्वेरी, संसाधन लीक।

• आर्किटेक्चर — समाधान की शुद्धता, SOLID अनुपालन, ओवर-इंजीनियरिंग का अभाव।
• तर्क — त्रुटियों और सीमांत मामलों सहित सभी परिदृश्यों का संचालन।
• परीक्षण — नए बदलावों का कवरेज, कोई टूटे हुए मौजूदा परीक्षण नहीं।
• सुरक्षा — इंजेक्शन, XSS, CSRF, लॉग के माध्यम से डेटा लीक।
• प्रदर्शन — एल्गोरिदम जटिलता, N+1 क्वेरी, मेमोरी लीक।

रिव्यू का आकार: 400 पंक्तियाँ अधिकतम क्यों

PR आकार सीमा कोड रिव्यू प्रभावशीलता का सबसे महत्वपूर्ण मीट्रिक है। Cisco (2015) का अध्ययन और SmartBear और Google के बाद के प्रयोगों ने दिखाया कि जब समीक्षा की मात्रा 400 पंक्तियों से अधिक हो जाती है, तो समीक्षक की दोष खोजने की क्षमता तेजी से गिर जाती है। यदि PR 400 पंक्तियों से अधिक है, तो दोष यादृच्छिक संभावना से अधिक नहीं पाए जाते हैं।

इष्टतम आकार: प्रति PR 200–400 पंक्तियाँ। इस मात्रा की समीक्षा 30–60 मिनट में एकाग्रता बनाए रखते हुए की जा सकती है। Google पूर्ण एकाग्रता के साथ प्रति समीक्षा दौर में 200 पंक्तियों से अधिक नहीं की सिफारिश करता है। यदि बदलाव बड़े हैं, तो कार्य को कई अनुक्रमिक PR में विघटित किया जाना चाहिए, प्रत्येक तार्किक रूप से पूर्ण परिवर्तन प्रस्तुत करता है।

समीक्षा का समय: PR बनाने के 24 घंटों के भीतर। यदि समीक्षा कई दिनों तक खिंचती है, तो कार्य संदर्भ खो जाता है, और लेखक को टिप्पणियों का जवाब देते समय संदर्भ बहाल करने में समय बिताना पड़ता है। मजबूत कोड रिव्यू संस्कृति वाली टीमें समीक्षा पर SLA निर्धारित करती हैं: उदाहरण के लिए, महत्वपूर्ण बदलावों के लिए 4 घंटे और नियमित बदलावों के लिए 24 घंटे।

अच्छी रिव्यू टिप्पणियाँ कैसे लिखें

टिप्पणियों का लहजा कोड रिव्यू प्रभावशीलता के लिए महत्वपूर्ण है। “यह गलत है” जैसी टिप्पणी रक्षात्मक प्रतिक्रिया पैदा करती है और लेखक को उपयोगी जानकारी नहीं देती। बेहतर सूत्रीकरण एक प्रश्न-सुझाव है: “इस दृष्टिकोण के बारे में आप क्या सोचते हैं?”, “यह user == nil होने पर NPE का कारण बन सकता है। शायद एक guard जोड़ें?”। प्रश्न कम टकराव वाले होते हैं और चर्चा को प्रोत्साहित करते हैं।

एक अच्छी टिप्पणी में तीन भाग शामिल हैं: क्या गलत है, यह समस्या क्यों है, और इसे कैसे ठीक करें। उदाहरण: “यह लूप नेस्टेड contains के कारण O(n²) का उपयोग करता है, जो 10k+ रिकॉर्ड के साथ धीमा हो सकता है। O(1) लुकअप के लिए Set से बदलने का प्रयास करें।” यह सूत्रीकरण एक साथ समस्या की पहचान करता है, इसके महत्व की व्याख्या करता है और समाधान सुझाता है — लेखक को अनुमान लगाने की आवश्यकता नहीं है।

GitHub और GitLab सुझावों का समर्थन करते हैं — इनलाइन कोड परिवर्तन प्रस्ताव। एक समीक्षक लिख सकता है: “```suggestion Filter empty strings before processing```” और लेखक एक क्लिक से बदलाव लागू कर सकता है। यह छोटे सुधारों को गति देता है और समीक्षा दौरों की संख्या कम करता है। बड़े बदलावों के लिए, सुझाव में बड़े ब्लॉक एम्बेड करने के बजाय सामान्य टिप्पणी लिखना बेहतर है।

# अच्छी कोड रिव्यू टिप्पणी का टेम्पलेट

# खराब: "This code is wrong"
# अच्छा: "We may lose data on empty response.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# GitHub सुझाव सिंटैक्स:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

टीम में कोड रिव्यू वर्कफ़्लो

एक प्रभावी समीक्षा वर्कफ़्लो चार चरणों पर बनाया गया है। पहला — लेखक PR तैयार करता है: एक स्पष्ट शीर्षक लिखता है (जैसे, “feat: add password reset screen”), बदलावों का विवरण, ट्रैकर में कार्य के लिंक और परीक्षण निर्देश जोड़ता है। दूसरा — लेखक ऑटो-असाइन (CODEOWNERS के आधार पर) या मैन्युअल रूप से समीक्षकों को नियुक्त करता है।

तीसरा चरण — समीक्षक कोड की जाँच करता है और टिप्पणियाँ छोड़ता है। चौथा — लेखक सुधार करता है, टिप्पणियों का जवाब देता है और पुनः समीक्षा का अनुरोध करता है। अनुमोदन प्राप्त होने तक चक्र दोहराया जाता है। अनुमोदन के बाद, लेखक मर्ज करता है (या बॉट करता है)। Mergify या GitHub Auto-merge के माध्यम से स्वचालन अंतिम चरण को गति देता है।

एक महत्वपूर्ण वर्कफ़्लो तत्व — पुराने PR प्रबंधन। यदि PR बिना समीक्षा के 3 दिनों से अधिक रहता है, तो प्रक्रिया अवरुद्ध हो जाती है। समाधान: समीक्षक रोटेशन (यदि नियुक्त समीक्षक अनुपलब्ध है), Slack/Teams के माध्यम से सूचनाएँ, समीक्षा समय सीमा (SLA)। कुछ टीमों में, 7 दिनों से अधिक बिना समीक्षा वाला PR स्वचालित रूप से बंद हो जाता है, और लेखक main के साथ सिंक करने के बाद एक नया बनाता है।

• PR निर्माण — स्पष्ट शीर्षक, विवरण, कार्य लिंक, UI बदलावों के लिए स्क्रीनशॉट।
• नियुक्ति — CODEOWNERS के माध्यम से ऑटो-असाइन या 1–2 समीक्षकों का मैन्युअल चयन।
• समीक्षा — क्रम में जाँच: आर्किटेक्चर → तर्क → परीक्षण → सुरक्षा → शैली।
• सुधार — लेखक सभी टिप्पणियों का जवाब देता है, अवरोधक मुद्दों को ठीक करता है, पुनः समीक्षा का अनुरोध करता है।
• मर्ज — अनुमोदन और हरी CI के बाद, लेखक या बॉट मर्ज करता है।

सामान्य कोड रिव्यू गलतियाँ

पहली गलती — सतही समीक्षा। समीक्षक तर्क में गहराई से जाए बिना diff को जल्दी से स्कैन करता है और Approve पर क्लिक करता है। कारण: बड़ा PR, समय सीमा, थकान। परिणाम: बग प्रोडक्शन तक पहुँचते हैं। समाधान: यदि गुणवत्ता समीक्षा के लिए समय नहीं है — औपचारिक अनुमोदन के बजाय ईमानदारी से लिखें “मैं आज समीक्षा नहीं कर सकता, इसे कल के लिए स्थानांतरित करें”।

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

तीसरी गलती — बिना प्रश्नों के समीक्षा। यदि समीक्षक केवल Request Changes और Approve पोस्ट करता है लेकिन प्रश्न नहीं पूछता, तो वह कुछ नया सीखने का अवसर चूक जाता है। स्वस्थ कोड रिव्यू का सबसे अच्छा संकेतक चर्चाओं की उपस्थिति है जिसमें दोनों पक्ष कुछ नया सीखते हैं। यदि समीक्षा एक प्रतिभागी का एकालाप है, तो प्रक्रिया टूट गई है।

• सतही समीक्षा — गहन विश्लेषण के बिना Approve। समाधान: यदि समय नहीं है तो समीक्षा न करें।
• निटपिकिंग — लिंट-जाँच की जाने वाली शैली की आलोचना। समाधान: शैली जाँच को स्वचालित करें।
• व्यक्तिगत पसंद — “मैं इसे अलग तरीके से लिखता”। समाधान: कोड को काम करना चाहिए, समीक्षक को खुश नहीं करना चाहिए।
• देरी — 24 घंटे से अधिक लंबी समीक्षा। समाधान: समीक्षा पर SLA, उल्लंघन पर एस्केलेशन।
• संदर्भ को अनदेखा करना — कार्य को समझे बिना कोड की समीक्षा। समाधान: diff से पहले PR विवरण पढ़ें।