कैसे Bitrix पर एक परियोजना विकसित करने के लिए नहीं

बिट्रिक्स के साथ अपने काम के सभी समय के लिए, मुझे बहुत बड़ी संख्या में परियोजनाओं के साथ काम करने का अवसर मिला जो किसी ने मेरे सामने विकसित की। यहां मामूली सुधार, विभिन्न बगों को ठीक करना और तर्क की त्रुटियां, वेबसाइट की रीडिजाइन और मौजूदा कार्यक्षमता में वैश्विक बदलाव शामिल हैं। और, किसी भी अन्य डेवलपर की तरह, मुझे अन्य लोगों के कचरे, बैसाखी और "अस्थायी" पैच से नफरत है, जो वास्तव में उत्पाद के एक और 8 संस्करण द्वारा याद किए जाते हैं।

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

"कोड लिखें जैसे कि यह एक हिंसक मनोरोगी के साथ होगा जो जानता है कि आप कहाँ रहते हैं" (ग) जॉन एफ। वुड्स

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

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

Init.php फ़ाइल को लिट न करें । किसी वर्ग में एक विशिष्ट मॉड्यूल या कार्यात्मक के साथ काम करने के लिए कार्यों को मिलाएं, इस पूरी कक्षा को एक अलग फ़ाइल में लिखें, और init.php में केवल इन फ़ाइलों को शामिल करें और ईवेंट हैंडलर लिखें। मैं 500Kb की init.php फ़ाइलों से मिला, जहां फ़ंक्शंस, कांस्टेंट की परिभाषा, कक्षाएं और हैंडलर की इनिशियलाइज़ेशन को गड़बड़ किया गया। बेशक, जब मुझे इन फाइलों को समझना था, तो मैंने अपने पूर्ववर्तियों को शाप दिया।

अगला पैराग्राफ मार्केटप्लेस के लिए तैयार समाधानों के विकास के मामले की चिंता नहीं करता है, जब लक्ष्य अंतिम उपयोगकर्ता के लिए सार्वजनिक भाग से सबसे अनुकूलन योग्य कार्यक्षमता बनाना है। यदि आप किसी विशिष्ट TOR पर किसी विशिष्ट प्रोजेक्ट पर काम कर रहे हैं - सभी अवसरों के लिए घटक के लिए एक एकीकृत टेम्पलेट बनाने का प्रयास न करें । व्यक्तिगत रूप से, मैं एक दर्शन का पालन करता हूं - कुछ सरल टेम्पलेटों का उपयोग करना बेहतर होता है जो एक सार्वभौमिक एक से अलग उद्देश्यों के लिए उपयोग किए जाते हैं, लेकिन जिसमें शैतान बाद में अपना पैर तोड़ देगा। बेशक, प्रत्येक मामले में, आपको यह बनाने की आवश्यकता है कि क्या है - संदर्भ की शर्तें, कार्यान्वयन के विकल्प और पसंद, लेकिन आपको ओकाम के रेजर के बारे में नहीं भूलना चाहिए। एक उदाहरण के रूप में, मैं एक पट्टे पर देने वाली कंपनी का एक प्रोजेक्ट दूंगा, जिसे मैंने संपादित करने के लिए किया था। निश्चित रूप से, परियोजना को, वास्तव में, बुरी तरह से लागू किया गया था, यह सेवा कैटलॉग के एक भाग के पन्नों में था। पांच खंडों में से प्रत्येक का अपना लेआउट था, जिस पर पृष्ठ पर ब्लॉक की स्थिति और, सिद्धांत रूप में, उनमें से कुछ की उपस्थिति भिन्न थी। और सभी पांच पन्नों के लिए, एक-एक टेम्पलेट का उपयोग किया गया था, अगर-और, कॉल का दोहराव, कॉलिंग शैलियों और लिपियों को जोड़ना, जो, इसके अलावा, समय-समय पर एक-दूसरे के साथ संघर्ष करते थे। परिणामस्वरूप - एक बड़ी फ़ाइल जिसमें "बिना पिंट के" समझने के लिए मौत की तरह थी। हालाँकि, ऐसा प्रतीत होता है, जो आपको 5 अलग-अलग टेम्पलेट बनाने और नीले रंग से कठिनाइयों का निर्माण नहीं करने से रोकता है?

एपीआई का उपयोग करें । जहां जरूरत नहीं है, वहां पहिए को दोबारा न लगाएं। प्रलेखन का उपयोग करें - पूरे उत्पाद को अच्छी तरह से वर्णित किया गया है, और प्रत्येक फ़ंक्शन को bxapi.ru पर विस्तार से देखा जा सकता है।

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

साइट के मूल से सीएनसी घटकों का उपयोग न करें । परिणाम, एक नियम के रूप में, बल्कि दुखद हैं, क्योंकि सीएनसी एक एड्रेस हैंडलर फ़ाइल का उपयोग करता है, इसे रूट से उपयोग करने का प्रयास आसानी से अन्य घटकों के पते को तोड़ता है, साथ ही साथ 404 पृष्ठ भी। यदि आपके द्वारा / लेख / फ़ोल्डर को संबोधित किए गए लेख और उत्पाद / कैटलॉग / के सापेक्ष उत्पाद हैं, तो कुछ भी गलत नहीं होगा।

एपीआई का उपयोग करके सीएसएस और जेएस कनेक्ट करें। मुझे अभी भी हर जगह html टैग का उपयोग करके स्क्रिप्ट और स्टाइलशीट दिखाई देती हैं। वर्ग ऑब्जेक्ट \ Bitrix \ Main \ Page \ Asset और फ़ंक्शन addJs () और addCss () का उपयोग करें। यह फ़ाइलों को संयोजित करने की अनुमति देगा और बाद में, मुख्य मॉड्यूल की सेटिंग्स में चेकबॉक्स के एक क्लिक के साथ उन्हें कैशिंग करेगा

और अंत में, त्रुटि न केवल बिट्रिक्स की चिंता करती है, बल्कि इससे जुड़ी समस्याओं का सामना करने के लिए मेरे लिए पहले से ही बहुत दर्दनाक थी। चयन के परिणामों के साथ सरणी शून्य के लिए जाँच करें । एक उदाहरण के रूप में, पिछली बार जब मैं एक ऑनलाइन स्टोर के साथ काम कर रहा था तब यह समस्या आई थी। शिकायत: पृष्ठ कभी-कभी 16 सेकंड के लिए लोड होते हैं। किससे जुड़ा है यह स्पष्ट नहीं है। परीक्षण और त्रुटि के द्वारा, मुझे पता चला कि पृष्ठ केवल खाली होने पर ही लोड किए जाते हैं। ऐसा लगता था, क्यों? जैसा कि यह निकला, हॉवरिंग में टोकरी में एक पॉप-अप विंडो दिखाई दी, जिसमें टोकरी में डाले गए सामानों की छवियां प्रदर्शित की गईं। खैर, पिछले डेवलपर ने क्या किया? मैंने "छोटी टोकरी" घटक का परिणाम लिया और result_modifier.php फ़ाइल में मैंने उत्पाद आईडी के सरणी से फिल्टर के साथ छवियों का चयन करने के लिए सामान के लिए एक गेटलिस्ट () कॉल किया, फिर चयन के परिणाम से संबंधित उत्पाद के सरणी में src छवियों को जोड़ा। नतीजतन, जब टोकरी में कोई सामान नहीं था, तो फिल्टर खाली रह गया, और माल की WHOLE सूची चयन में गिर गई। खैर, फिर प्रत्येक के लिए एक चक्र और ... हमारे पास जो हमारे पास है। यह स्पष्ट है कि परीक्षण 15 उत्पादों के साथ विकास के चरण में यह अगोचर था, और पहले से ही युद्ध की स्थिति में समस्याएं पैदा हुईं। हालांकि ऐसा लगता है कि यह चेक को खाली ($ arResult ['ITEMS']) पर डालने लायक था ...

यह वह जगह है जहां मैं अपने व्यक्तिगत शीर्ष "सबसे खराब अभ्यास" को समाप्त करता हूं बिट्रिक्स विकास। यदि कम से कम यह जानकारी भविष्य में गलतियों से बचने और उनकी विकास शैली में सुधार करने में मदद करेगी, तो यह व्यर्थ नहीं था।