PHP में कोड रिव्यू: क्या जाँचें और फीडबैक कैसे दें

परिचय: code review "बग ढूँढ़ने" के बारे में क्यों नहीं है

Code review (कोड रिव्यू) सॉफ्टवेयर उत्पाद की गुणवत्ता बढ़ाने के सबसे प्रभावी उपकरणों में से एक है। PHP समुदाय में, जहाँ अक्सर "स्पेगेटी-कोड" की विरासत और procedural तथा OOP शैलियों का मिश्रण पाया जाता है, एक सक्षम रिव्यू विशेष रूप से महत्वपूर्ण हो जाता है। हालाँकि, कई डेवलपर इसे "त्रुटियों का शिकार" या, इससे भी बदतर, खुद को साबित करने का एक तरीका मानते हैं। वास्तव में code review का उद्देश्य ज्ञान साझा करना, कोड बेस में एकरूपता सुनिश्चित करना और संभावित समस्याओं को प्रोडक्शन में जाने से पहले रोकना है।

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

1. PHP कोड में क्या जाँचें: रिव्यूअर की चेकलिस्ट

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

1.1. सुरक्षा (Security)

PHP एक ऐसी भाषा है जहाँ सुरक्षा संबंधी त्रुटियाँ महँगी पड़ती हैं। जाँचें:

• SQL-इंजेक्शन: क्या तैयार क्वेरी (PDO या MySQLi) का उपयोग किया गया है? क्वेरी में स्ट्रिंग कॉन्केटनेशन निषिद्ध है।
• XSS (Cross-Site Scripting): क्या सभी उपयोगकर्ता आउटपुट को htmlspecialchars() या टेम्पलेट इंजन (Twig, Blade) के माध्यम से एस्केप किया गया है।
• CSRF सुरक्षा: क्या फॉर्म में टोकन हैं?
• सर्वर-साइड वैलिडेशन: केवल क्लाइंट-साइड वैलिडेशन पर निर्भर न रहें।

<?php// बुरा: SQL-इंजेक्शन$query = "SELECT * FROM users WHERE id = " . $_GET['id'];

// अच्छा: PDO prepared statement के साथ$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");$stmt->execute(['id' => $_GET['id']]);?>

1.2. PSR मानकों का अनुपालन

PHP-FIG (Framework Interop Group) ने ऐसे मानक विकसित किए हैं जिनका अधिकांश आधुनिक प्रोजेक्ट पालन करते हैं। जाँचें:

• PSR-12: इंडेंटेशन (4 स्पेस), कर्ली ब्रेसेस, नेमिंग (मेथड के लिए camelCase, वेरिएबल के लिए snake_case)।
• PSR-4: क्लास ऑटोलोडिंग और नेमस्पेस।

फ़ॉर्मेटिंग पर मैन्युअल रूप से समय बर्बाद न करने के लिए स्वचालित टूल (PHP CodeSniffer, PHP-CS-Fixer) का उपयोग करें।

1.3. आर्किटेक्चर और SOLID

छोटे प्रोजेक्ट में भी, SOLID सिद्धांत "गंदगी के बड़े ढेर" से बचने में मदद करते हैं। इन पर ध्यान दें:

• Single Responsibility: एक मेथड/क्लास — एक कार्य। यदि कोई मेथड 3 काम करता है, तो यह रिफैक्टरिंग का संकेत है।
• Dependency Injection: क्लास के अंदर new का उपयोग न करें, कंस्ट्रक्टर के माध्यम से डिपेंडेंसी पास करें।
• "दैवीय ऑब्जेक्ट" का अभाव: क्लास को सिस्टम के बारे में सब कुछ नहीं जानना चाहिए।

1.4. प्रदर्शन

समय से पहले ऑप्टिमाइज़ न करें, लेकिन स्पष्ट एंटी-पैटर्न को उजागर करना उचित है:

• लूप में क्वेरी (N+1 समस्या)।
• mysql_* फ़ंक्शन का उपयोग (PHP 7+ में हटा दिए गए हैं)।
• बार-बार की जाने वाली क्वेरी के लिए DB में इंडेक्स का अभाव।

2. फीडबैक कैसे दें: रचनात्मक आलोचना की कला

सबसे सही टिप्पणियों की सूची भी बेकार होगी यदि फीडबैक "यह भयानक कोड है, इसे फिर से लिखो" जैसा लगता है। यहाँ कुछ नियम दिए गए हैं।

2.1. "सैंडविच" नियम

सकारात्मकता से शुरू करें, फिर टिप्पणी, फिर समर्थन।

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

2.2. आदेशों के बजाय प्रश्न

"इसे अलग तरीके से करो" कहने के बजाय पूछें: "क्या होगा अगर हम इस लॉजिक को बाहर निकाल दें