PHP डेवलपर्स के लिए कुछ सुझाव

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



फास्ट PHP कोड में न्यूनतम PHP होता है।



शायद यह सलाह व्याख्या की गई भाषाओं में कई डेवलपर्स को पसंद आएगी। PHP में बड़ी संख्या में मूल (C में लिखे गए) कार्य शामिल हैं। उनकी गति PHP में किसी भी एनालॉग से अधिक है। PHP के एनालॉग्स के बजाय उनका उपयोग करने का प्रयास करें।



वास्तव में, निश्चित रूप से, सभी अंतर्निहित PHP कार्यों को ध्यान में रखना मुश्किल है। मैंने खुद के लिए एक नियम विकसित किया है: एक फ़ंक्शन लिखने से पहले, इसे दस्तावेज़ में ढूंढने का प्रयास करें। ज्यादातर मामलों में, एक देशी फ़ंक्शन पाया जाता है।



उदाहरण:

1. घटकों में url को पार्स करना आवश्यक था। मैं कोशिश करता हूं कि ऐसी चीजों के लिए नियमित अभिव्यक्ति का उपयोग न करें। फ़ंक्शन जल्दी से पाया गया: parse_url ।

2. Parse_url फ़ंक्शन url को सफलतापूर्वक पार्स करने में सक्षम था, अब url से GET के मापदंडों को पार्स करना आवश्यक था। और इसके लिए, एक फ़ंक्शन पाया गया: parse_str ।



PHP कोड की तुलना में एक्सटेंशन अधिक तेज़ हैं।



PHP के लिए एक एक्सटेंशन रिपोजिटरी है: PECL । वहां आपको बहुत सारी दिलचस्प चीजें मिल सकती हैं। एक्सटेंशन सी में भी लिखे गए हैं और PHP में अपने समकक्षों की तुलना में तेजी से काम करते हैं। उदाहरण के लिए, मैं एपीसी और याम्ल का उपयोग करता हूं । मुझे लगता है, और आप अपने लिए बहुत सारी दिलचस्प चीजें पा सकते हैं।



तृतीय-पक्ष कोड का सावधानीपूर्वक उपयोग करें।



PHP में कार्यान्वित उत्पादों में मुझे सबसे बड़ी समस्याओं में से एक तृतीय-पक्ष कोड के साथ उच्च कनेक्टिविटी है, जो दूसरे के साथ एक तृतीय-पक्ष उपकरण को बदलने की अनुमति नहीं देता है। वास्तव में, यह सलाह कनेक्टिविटी को कम करने के लिए एक सामान्य दृष्टिकोण से जुड़ी है, लेकिन समस्या विशेष रूप से तीसरे पक्ष के घटकों के साथ तीव्र है।



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



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



यदि आप एक ऐसे मामले से सामना कर रहे हैं जहां पुस्तकालयों को बदली जानी चाहिए, तो आपको इंटरफेस, प्रदाता या यहां तक ​​कि अमूर्त कारखानों को लिखना होगा।



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



नाशपाती



आप PEAR का उपयोग करते हैं या नहीं, आपको पता होना चाहिए कि यह वैसे भी क्या है। PEAR कई सामान्य कार्यों के लिए PHP कक्षाओं का भंडार है। यह इस पते पर स्थित है: pear.php.net/packages.php । मैं यह नहीं कहूंगा कि PEAR में कक्षाएं किसी विशेष गुणवत्ता, या समर्थन, या किसी अन्य चीज से प्रतिष्ठित हैं। यह मूल रूप से phpclasses.org की तुलना में सिर्फ एक उपयोगी वर्ग भंडार, क्लीनर है। PHP में PEAR पैकेजों को स्थापित करने और हटाने के लिए एक " नाशपाती " कमांड भी है, लेकिन उसी सफलता के साथ, PEAR पैकेजों को केवल एप्लिकेशन फ़ोल्डर में डाला जा सकता है और उपयोग किया जा सकता है।



PHP 5.3 का प्रयोग करें।



यदि आप उन परियोजनाओं पर काम नहीं कर रहे हैं जहां होस्टिंग आपके लिए चुनी गई है, तो PHP 5.3 पर स्विच करना सुनिश्चित करें।



इस PHP लाइन का सबसे महत्वपूर्ण नवाचार अनाम फ़ंक्शन है। अब इसके बजाय:

फ़ंक्शन my_temp_map ( $ x ) {

वापसी $ x + 1;

}

$ परिणाम = array_map ('my_temp_map', $ arr );

आप लिख सकते हैं:

$ परिणाम = array_map ( फ़ंक्शन ( $ x ) { $ $ x + 1;}, $ arr );

इसके अलावा, अब आप उप-कार्यों की घोषणा कर सकते हैं और उपयोग बंद कर सकते हैं:

सार्वजनिक समारोह myMethod ( $ डेटा ) {

$ सबफ़ंक्शन = फ़ंक्शन () उपयोग ( $ डेटा ) {...};

$ x = $ सबफ़ंक्शन ();

}

अनाम फ़ंक्शंस के अलावा, बहुत सी दिलचस्प चीज़ें जोड़ी गईं: php.net/ChangeLog-5.php



आगे मैं और बारीकियों पर जाऊंगा।



"@" ऑपरेटर का उपयोग न करें।



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



अक्सर "@" ऑपरेटर का उपयोग उन मामलों में साहचर्य सरणी तक पहुंचने के लिए किया जाता है जहां कुंजी के अस्तित्व के बारे में कोई निश्चितता नहीं है। इस मामले में, आप इस डिजाइन के साथ कर सकते हैं:

$ x = isset ( $ गिरफ्तारी [ 'x' ])? $ गिरफ्तार [ 'x' ]: अशक्त ;

Cp1251 का उपयोग न करें।



कामरेड जिन्होंने अभी तक utf8 पर स्विच नहीं किया है! चलो! जितनी जल्दी बेहतर होगा।



Utf8 के साथ काम करते समय, आपको mbstring एक्सटेंशन के साथ PHP संकलित करने की आवश्यकता होगी (संकलन करते समय नियमित सेट में शामिल)।



E_ALL मोड में काम करें | E_NOTICE | E_STRICT।



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



पुन: phpmanual पढ़ें।



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



कम से कम, आपको सभी php.ini सेटिंग्स और वे क्या प्रभावित करते हैं, यह जानने की जरूरत है।



आगे बढ़ें।



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



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



यह मेरी सलाह को समाप्त करता है, आपके ध्यान के लिए धन्यवाद।