क्यों, बिट्रिक्स? या परी दुनिया 1 सी

एक दिन, सोमवार को, विचार मेरे पास हुआ - "लेकिन मैं नए कोर में खुदाई करता हूं" (अपेक्षाकृत नया, लेकिन बाद में उस पर अधिक)। यह विचार नीले रंग से बाहर नहीं आया, लेकिन इसके लिए आवश्यक शर्तें थीं:

• परीक्षण कार्य, मदर रूस के एक बड़े स्टूडियो से (जिसमें संक्षिप्त नाम ORM दिखाई दिया),
• एक साधारण मॉड्यूल लिखने का विचार है,
• एक ग्राहक की इच्छा, भविष्य में, एक स्टोर बनाने के लिए।

इसलिए, मैं घने उष्णकटिबंधीय जंगल में इस अभियान की कहानी साझा करना चाहता हूं।

एक छोटा परिचय

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

सिर के साथ पूल में

डेटा के साथ काम करने का पहलू मौलिक है और इसके बिना, कहीं नहीं, मैंने सोचा, और तुरंत जाने का फैसला किया करने के लिए गूगल प्रलेखन के माध्यम से देखें, एक विस्तृत विवरण और उदाहरणों की उपलब्धता के लिए उम्मीद है, और निश्चित रूप से पाठ्यक्रमों को देखें। हल्के हाथ से और स्वादिष्ट और नए कुछ के लिए उम्मीद है। चिंता का कोई कारण न देखकर, मैं शिविर में गया। बादल जमा हो रहे थे ...

आपको जंगल या अस्तित्व के नियमों के बारे में जानने की आवश्यकता है

नियम संख्या 1 - बेईमान ट्रैवल एजेंटों से सावधान रहें

मैंने पाठ्यक्रम के साथ शुरू करने का फैसला किया, मुझे (मॉड्यूल और ओआरएम) में रुचि रखने वाले मेनू आइटम को देखकर, मुझे लगा कि ग्रंथों और कोड आवेषण का एक गुच्छा - सब कुछ जल्दी होगा, चलो चलते हैं ... इसलिए मेरी अगली गलती हुई। वास्तव में, यह पता चला:

• पाठ्यक्रम खराब रूप से संरचित हैं - अध्ययन के क्रम के बारे में नहीं सोचा गया है, आप अध्यायों के बीच किसी भी संबंध के अभाव का पता लगा सकते हैं;

  
  

• पर्मलिंक - मैं दस्तावेज़ीकरण के लिंक के बारे में बात नहीं कर रहा हूं, लेकिन स्टैक ओवरफ्लो और अन्य अध्यायों के लिंक (पाठ्यक्रम के अंत में, जिसके बीच जानकारी का एक समुद्र है) बहुत विचलित कर रहे हैं, यह गंभीर नहीं है;

  
  

• पानी और आम शब्द - आप वर्णों की संख्या की जांच कर सकते हैं;

  
  

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

  
  

• अपने तरीके से अवधारणाओं की व्याख्या अभी भी एक पुराना विषय है (एपीआई - घटक - टेम्पलेट उर्फ ​​एमवीसी);

  
  

• प्रलेखन से आवेषण - पूरे टुकड़ों की कॉपी-पेस्ट, कभी-कभी सिर्फ एक जगह भरने के लिए;

  
  

• डेवलपर्स से उद्धरण - बस कोई शब्द नहीं हैं -_-, यह ब्लस्टर क्यों है;

  
  

• पुराने अध्याय - बस उन्हें हटाना असंभव लगता है, वे समय पर भ्रम को मजबूत करते हैं।

  
  

  इकाई (अप्रचलित) या उत्पाद छूट सेटिंग्स के बीच संबंध

  
  

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

नियम संख्या 2 - घने मोटे से सावधान रहें

का उपयोग कर सरल नमूने के एक जोड़े को बनाया है स्कॉच टेप प्रलेखन, मैंने माल पर छूट पाने की कोशिश करने का फैसला किया। और फिर बारिश शुरू हो गई। स्यूडॉन कोर और ईस्टर अंडे:

• छूट के लिए दो मॉड्यूल - हाँ, हाँ, मैंने लंबे समय से सोचा था - मैंने छूट क्यों जोड़ी, यह उत्पाद में है, लेकिन मैं इसे DiscountTable इकाई वर्ग के माध्यम से प्राप्त नहीं कर सकता। मुझे समर्थन में लिखना पड़ा। इसका उत्तर यह था:

डिस्काउंटटेबल - माल पर छूट, मॉड्यूल ट्रेड कैटलॉग से संबंधित है, कार्यक्षमता पुरानी है और इसका उपयोग नहीं किया गया है। हम कार्ट नियमों का उपयोग करने की सलाह देते हैं।

• प्रलेखन की कमी - लेकिन आप प्रलेखन के लिए एक लिंक प्राप्त कर सकते हैं - पूछा
  मैं। उम्मीद है कि 2013-2015 से वह दिखाई दी। उत्तर है:

टोकरी नियम बनाने के लिए प्रलेखन अभी भी विकास में है।

• कार्य परिदृश्यों पर विचार नहीं किया गया था - मेरा अगला प्रश्न तार्किक था - मुझे छूट कैसे मिल सकती है? जिसके लिए मुझे एक करामाती जवाब मिला और समर्थन के साथ संचार समाप्त हो गया:

उत्पाद पर लागू होने वाले टोकरी नियम प्राप्त करने के लिए, आपको एक टोकरी ऑब्जेक्ट बनाने और उत्पाद के लिए गणना करने की आवश्यकता होगी।

• अपूर्ण कार्यक्षमता - कुछ वर्ग विधियाँ त्रुटि संदेश लौटा सकती हैं जैसे:

उत्पाद छूट जोड़ने के लिए, कॉल CCatalogDiscount का उपयोग करें :: जोड़ें ()

• जटिल वास्तुकला - कई तालिकाओं के एक जटिल चयन को बनाने के लिए, विशेष संबंध वस्तुओं का उपयोग किया जाता है, जिसे SomeTable::getMap() विधि में जोड़ा जाना चाहिए। यह हमेशा आसान नहीं होता है (कुछ इकाई विवरण कक्षाएं स्वचालित रूप से उत्पन्न होती हैं)। इसके अलावा, यह इस तथ्य को दुःख देता है कि एक बहुआयामी सरणी के प्रारूप में केवल एक जटिल नमूना प्राप्त करना असंभव है। और संबंधों के निर्माण में एक दर्जन से अधिक लाइनें लग सकती हैं।
• कार्यक्षमता के लेबिरिंथ - डी 7 में ऐसे स्थान हैं जो लगातार फिर से लिखे जाते हैं और एक ही समय में सभी विविधताओं का समर्थन किया जाता है। एक ही संबंध वस्तुओं के माध्यम से लागू किया जा सकता है: Entity\ReferenceField || Bitrix\Main\ORM\Fields\Relations || runtime (अनुरोध पर)

यह सब बहुत निराशाजनक है और आपको कम से कम कहने के लिए अशिष्ट बनाता है। और इसके अलावा, अन्य असुविधाएं हैं।

नियम 3 - लानत कीड़े

बिट्रिक्स में कई अजीब और दखल देने वाली विशेषताएं हैं जिनके बारे में आप लगातार भूल जाते हैं, लेकिन वे आपकी आंखों के सामने फिर से चमकते हैं:

• वर्ग और फ़ाइल नामकरण नियम - आपका स्वयं का फोर्कलिफ्ट जो निचले मामले, विभिन्न वर्ग और फ़ाइल नामों के लिए सब कुछ कम करता है;
• तीसरे पक्ष के समाधान को जोड़ने के तरीके - उदाहरण के लिए संगीतकार या पुए (जो बिना किसी स्पष्ट कारण और ऐड-ऑन के केवल BX लाइब्रेरी में समाहित है) ;

• पुराने कोड के लिए समर्थन - अनावश्यक, अनावश्यक वर्गों और निरंतर भ्रम का एक गुच्छा;
• भूल गए घटक - केवल iblock मॉड्यूल घटक अपडेट किए गए थे;
• घटक टेम्पलेट - हर किसी के लिए कुख्यात और अच्छी तरह से जाना जाता है, तैयार में व्यापार तर्क के साथ;
• अनुकूलन के साथ तर्क और समस्याएँ - आदेश स्क्रिप्ट को बदलने के बाद, आप मॉड्यूल के साथ एक सूक्ष्म त्रुटि और समस्याओं को पकड़ सकते हैं;
• सर्वव्यापी स्थिर - आप सोचने लगते हैं कि यह सामान्य है;
• विवादास्पद व्यवस्थापक पैनल - कभी-कभी सुविधाजनक और अनुकूल नहीं, लेकिन इसके लिए मॉड्यूल विकसित करने के लिए ... मिमी;

Trifles, लेकिन वे हमेशा पास हैं।

नियम संख्या 4 - अजनबी और मूल निवासी खतरनाक हैं

बिट्रिक्स का एक और लाभ है (नहीं) - एक बड़ा समुदाय। आप कोई भी जानकारी पा सकते हैं, लेकिन इसकी शुद्धता और प्रासंगिकता एक बड़ा सवाल होगा। अक्सर, आप केवल यह सीख सकते हैं कि बैसाखी कैसे बनाई जाए या एक प्राचीन कोड का उपयोग करें जिसमें पहले से ही पर्याप्त प्रतिस्थापन है। लेकिन ऐसे मसीहा भी हैं जो उनके झुंड को रास्ता दिखा सकते हैं। इनमें से एक ने कहा:

Infoblocks के साथ काम करने के लिए, पुराने कर्नेल का उपयोग करें, जो अच्छी तरह से और stably काम करता है।

मुझे लगता है कि मैं ऐसा करूंगा।

नियम संख्या 5 - पास में कहीं पर शिकारी

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

नियम # 6 - पानी है

प्रत्येक नई समस्या और एक पर्याप्त समाधान की कमी के साथ, नैतिकता गिरती है और आप एक चाल छोड़ें विचार आते हैं, लेकिन क्या यह सब समय की बर्बादी के लिए आवश्यक है। इन आधे उपायों के बजाय ढांचा, कंटेनरीकरण और निरंतर एकीकरण बेहतर हो सकता है। ऐसे मामलों में, केवल एक मजबूत इच्छाशक्ति वाला निर्णय अच्छी तरह से, मांग स्थिति को बचाता है।

नियम संख्या 7 - उष्णकटिबंधीय वर्षा कठिन है

और यह एक अप्रिय तथ्य को समाप्त करता है, प्रोग्रामिंग, खोज और संरचना की जानकारी के प्रयासों के लिए, विशेषज्ञों के साथ संवाद करने और अतीत में लौटने, कुछ नया सीखने में, एक समझदार परिणाम की अनुपस्थिति में बहुत समय लगता है - यह लगातार निराशाजनक है।

सभ्यता उर्फ ​​निष्कर्ष

और यहाँ जंगल से बाहर आते हैं। जर्जर लेकिन जिंदा। टूटा हुआ लेकिन फिर भी टूटा नहीं। आपकी थकी आँखें खुली हैं और वे सब कुछ देखते हैं। एक ऐसा मार्ग जहां यह वास्तव में चलने और ट्रेल्स के लायक है जहां विशेष देखभाल की आवश्यकता होती है।

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

अपने लिए, मैंने फैसला किया, बिट्रिक्स - नहीं। एक पूर्ण विफलता, निश्चित रूप से काम नहीं करेगी, लेकिन एक ऐसे उत्पाद को विकसित करने के लिए जिसमें 5 साल तक बुनियादी कार्यक्षमता और समझदार प्रलेखन के लिए कोई समर्थन नहीं किया गया है, नए और घोषित कर्नेल के लिए - मुझे कोई कारण नहीं दिखता है। एक सरल समाधान लिखना बेहतर है जो परियोजना से पुराने कोर पर परियोजना के लिए उपयोग किया जाएगा और एक नया सीखने जाएगा।

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

पुनश्च लेख जल्दबाजी में लिखा गया है, यदि आप विचारों की एक सुसंगत श्रृंखला नहीं बना सकते हैं।