PHP कोड समीक्षा: 10 गलतियाँ जो सीनियर डेवलपर्स को परेशान करती हैं

परिचय: आपका PHP कोड क्यों दोबारा लिखवाया जाता है?

आपने पूरे आत्मविश्वास के साथ एक Pull Request भेजा कि आपने परफेक्ट कोड लिखा है। एक घंटा बीतता है, और आपको एक सीनियर डेवलपर से 15 कमेंट दिखते हैं। परिचित लग रहा है? PHP पर Code review सिर्फ एक औपचारिकता नहीं है, बल्कि परिपक्वता की एक वास्तविक परीक्षा है। सीनियर कोड को निर्देशों के सेट के रूप में नहीं, बल्कि एक ऐसी प्रणाली के रूप में देखते हैं जो जीवित रहेगी और विकसित होगी।

इस लेख में, हम उन सबसे सामान्य टिप्पणियों पर चर्चा करेंगे जो आपको समीक्षा में मिलती हैं। हम आपको सिंटैक्स नहीं सिखाएंगे - आप पहले से ही जानते हैं कि वेरिएबल कैसे घोषित करना है। हम कोड संस्कृति, आर्किटेक्चर और उन खतरों के बारे में बात करेंगे जो काम करने वाले कोड को रखरखाव के लिए एक दुःस्वप्न में बदल देते हैं। तैयार रहें: यह दर्दनाक होगा, लेकिन उपयोगी।

1. मैजिक नंबर और स्ट्रिंग्स: "42 का क्या मतलब है?"

सबसे आम और सबसे कष्टप्रद गलती। सीनियर कोड में if ($status == 3) देखता है और तुरंत नकारात्मक अंक देता है। संख्या 3 एक मैजिक कॉन्स्टेंट है। एक महीने बाद, आपको खुद याद नहीं रहेगा कि इसका क्या मतलब है। और एक नया डेवलपर अनुमान लगाएगा: क्या यह स्थिति "प्रकाशित", "ड्राफ्ट" या "हटाया गया" है?

खराब:

if ($order->getStatus() == 3) {\n    $order->sendNotification();\n}

अच्छा:

class OrderStatus {\n    const PENDING = 1;\n    const CONFIRMED = 2;\n    const SHIPPED = 3;\n    const DELIVERED = 4;\n}\n\nif ($order->getStatus() === OrderStatus::SHIPPED) {\n    $order->sendNotification();\n}

नामित कॉन्स्टेंट का उपयोग कोड को स्व-दस्तावेजीकरण बनाता है। आप सिर्फ कोड नहीं लिख रहे हैं - आप एक कहानी कह रहे हैं। यह मुख्य php best practices में से एक है जिसे जूनियर अक्सर अनदेखा करते हैं।

2. God-ऑब्जेक्ट और 500 लाइनों के राक्षस

"यह क्लास सब कुछ करता है!" - एक वाक्यांश जो सीनियर को कांपने पर मजबूर कर देता है। जब एक क्लास ईमेल भेजने, PDF जनरेट करने और डेटाबेस के साथ काम करने के लिए जिम्मेदार होती है - तो यह एकल जिम्मेदारी सिद्धांत (SRP) का उल्लंघन है। ऐसी क्लास का परीक्षण करना असंभव है, इसे बदलना मुश्किल है, और यह मामूली रिफैक्टरिंग पर भी टूटने की गारंटी है।

God-ऑब्जेक्ट के संकेत:

\n
• क्लास में 200-300 से अधिक लाइनें हैं
\n
• एक मेथड में 20-30 से अधिक लाइनें हैं
\n
• क्लास का नाम "Manager" या "Helper" पर समाप्त होता है
\n
• मेथड 5+ पैरामीटर लेते हैं
\n

समाधान सरल है: विभाजित करें! लॉजिक को सर्विसेज, रिपॉजिटरी, हैंडलर्स में निकालें। PHP रिफैक्टरिंग छोटी चीजों से शुरू होती है - एक ऐसी क्लास बनाएं जो केवल एक काम करती है, लेकिन उसे अच्छी तरह से करती है।

3. PDO के माध्यम से "नंगा" SQL काम

हाँ, यदि आप prepared statements का उपयोग करते हैं तो PDO इंजेक्शन से बचाता है। लेकिन सीनियर कंट्रोलर में कच्चा SQL नहीं, बल्कि एक एब्स्ट्रैक्शन देखना चाहता है। Eloquent या Doctrine जैसा ORM एक मानक है। यदि प्रोजेक्ट छोटा है, तो कम से कम Query Builder का उपयोग करें।

एंटीपैटर्न:

$pdo = new PDO('mysql:host=localhost;dbname=test', 'user', 'pass');\n$stmt = $pdo->prepare('SELECT * FROM users WHERE email = ?');\n$stmt->execute([$email]);\n$user = $stmt->fetch();

सही तरीका:

class UserRepository {\n    public function findByEmail(string $email): ?User {\n        return User::where('email', $email)->first();\n    }\n}

रिपॉजिटरी के माध्यम से काम करने से पूरे प्रोजेक्ट को दोबारा लिखे बिना डेटा स्रोत (जैसे, Redis कैश पर स्विच करना) को आसानी से बदला जा सकता है। यह PHP कोड गुणवत्ता है जिसे सोने के वजन के बराबर महत्व दिया जाता है।

4. strict_types को अनदेखा करना

PHP एक डायनामिक टाइपिंग वाली भाषा है, लेकिन यह 2005 की तरह कोड लिखने का बहाना नहीं है। प्रत्येक फ़ाइल की शुरुआत में declare(strict_types=1); घोषित करना व्यावसायिकता का प्रतीक है। सीनियर को नफरत है जब कोई फंक्शन int की उम्मीद करता है, लेकिन स्ट्रिंग "42" प्राप्त करता है और चुपचाप इसे कन्वर्ट कर लेता है।

declare(strict_types=1);\n\nfunction calculateTotal(int $price, int $quantity): int {\n    return $price * $quantity;\n}\n\n// यह TypeError उत्पन्न करेगा, चुपचाप कन्वर्ट नहीं\necho calculateTotal('100', 2); /