ZendFramework + Bitrix

शायद यह मेरे लिए हाल ही में सबसे अधिक डराने वाली चुनौतियों में से एक थी।

So. हम तकनीकी रूप से जटिल परियोजनाओं में लगे हुए हैं, जो संभवतः उच्च भार (हाईलोड) के लिए डिज़ाइन किए गए हैं। ऐसा हुआ कि सामग्री प्रबंधन प्रणालियों के बीच बिट्रिक्स ने अब तक जीत हासिल की है। ग्राहक उसे चाहते हैं। हमारे अनुभव को देखते हुए - यदि आप सब कुछ सावधानी से करते हैं, तो बिट्रिक्स पर हाईलोड एक बहुत ही वास्तविक कार्य है।



आमतौर पर परियोजनाओं में जहां कई रूप, व्यक्तिगत खाते या किसी प्रकार के जटिल तर्क होते हैं - हमने ग्राहक को Zend Framewok या Bitrix पर कार्यान्वयन का विकल्प प्रदान किया। ZendFramework का नकारात्मक पक्ष यह था कि आपको इस पर एक व्यवस्थापक पैनल लिखना होगा। माइनस बिट्रिक्स - यह जटिल व्यावसायिक तर्क वाली परियोजनाओं के लिए खराब रूप से अनुकूलित है: वास्तव में कोई एमवीसी नहीं है और कुछ स्थानों पर कोड और एपीआई को घृणित किया गया है। डी 7 कोर, जो पहले से ही 2 साल का है, के बारे में बालालाकिस का विपणन करते हैं - हम इस पर ध्यान नहीं देते हैं:

“बात सस्ती है। मुझे कोड दिखाएं ”(लिनस)

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

परिचय:

1. पायलट प्रोजेक्ट। हमने ZendFramework पर Scrumban करने का फैसला किया, क्योंकि हम संरचित कोड चाहते थे जो कि कृपया होगा। यह इस परियोजना पर था कि हमारे पास प्रयोगों के लिए समय था और एकीकरण के मुख्य बिंदुओं पर काम करने में सक्षम थे:

• संयुक्त सत्र।
• डेटाबेस के साथ संयुक्त संबंध (हाहा, पुराना बिट्रिक्स कोड MySQLi के साथ काम करने का तरीका नहीं जानता है, लेकिन पुराने MySQL ड्राइवर का उपयोग करता है। ZendFramework इस कबाड़ का समर्थन नहीं करता है, इसलिए मुझे इसे थोड़ा सा प्रोग्राम करना पड़ा)।
• मॉडल के साथ काम करने के लिए सूचना ब्लॉक में बांधना।
• रूटिंग।

2. सबसे अधिक संदेह के संदेह पर काबू पाएं। चूंकि हमारे पास पहले से ही हमारे हाथों में बंडल का एक कार्यशील प्रोटोटाइप था, इसलिए हम कोड पर चर्चा कर सकते थे। मैं अपनी कंपनी के एक दोस्त के उग्र प्रतिरोध से मिला। लगभग एक घंटे तक, उन्होंने हमारे कार्यान्वयन में दोष पाया, जिसने अंततः हमें कुछ गलतियाँ खोजने में मदद की और कई सुधार किए। उसके बाद, आलोचक के पास कोई तार्किक तर्क नहीं था और हम आगे बढ़ सकते थे।

3. प्रदर्शन प्रयोगों। हम वास्तव में डर रहे थे कि ZendFramework ढांचे को लोड करने में काफी समय सिस्टम खर्च होगा। अनुकूलन की एक श्रृंखला के बाद, हमने सावधानी से ऑटोलोड में लोडिंग किया। एक स्वच्छ बिट्रिक्स और हमारे बंडल को शुरू करने के बीच का अंतर 0.033 सेकंड था, जो जल्दी से अच्छी तरह से संरचित कोड विकसित करने की क्षमता की तुलना में एक पैसा है।

4. पायलट वाणिज्यिक परियोजनाएँ। उनमें से दो थे। हम बिट्रिक्स से जेडएफ के मानक तर्क को फिर से लिखने की कोशिश करने के लिए अपने हाथों को किस बिंदु पर हरा सकते हैं, यह स्पष्ट रूप से समझने में सक्षम थे।

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

6. रूट कारण विश्लेषण। मुझे स्पष्ट रूप से यह बताने के लिए कहा गया था कि ZF के साथ किस उद्देश्य के एकीकरण की आवश्यकता है। मैंने लगभग आधे दिन मूल कारणों का विश्लेषण करने में बिताए और एक कारण के पेड़ के साथ एक आधा दीवार प्रिंटआउट किया। सार्वजनिक प्रदर्शन पर कुछ हफ़्ते के लिए प्रिंटआउट लटका: बैनर ब्लाइंडनेस का एक बड़ा उदाहरण।

सबसे बुनियादी चीज जो मैं पाना चाहता था:

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

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

8. प्रशिक्षण ZF। यह कोई रहस्य नहीं है कि जेडएफ के ज्ञान को बिट्रिक्स पर विशुद्ध रूप से साइटों को चलाने की तुलना में अधिक कौशल की आवश्यकता होती है। हमने कई होलिवर्स का आयोजन किया, जहां हमने एमवीसी वास्तुकला को विस्तार से बताया और बुनियादी शब्दावली पेश की। उसके बाद, प्रत्येक डेवलपर्स को इसे हल करने के लिए एक परीक्षण कार्य और समय मिला। नियंत्रकों, रूपों, सहायकों, सत्यापनकर्ताओं को महसूस करने के लिए अभ्यास में यह आवश्यक था। मेरी राय में, यह एक अभियान था;) उस समय तक, पहले से ही 80% डेवलपर्स ने ZF पर वाणिज्यिक परियोजनाओं में भाग लिया था।

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

10. नियमित कोड समीक्षा प्रथाओं। यह एक कठिन अभ्यास है। दृढ़ता और विचारशीलता की आवश्यकता है। फ्रैंक गोवनोकॉड या अतिरिक्त रिक्त स्थान की तुलना में कुछ अधिक गंभीर खोजने के लिए - आपको अपना सिर काम करने की आवश्यकता है। कभी-कभी यह डेवलपर के साथ मिलकर एक कोड समीक्षा करने के लिए समझ में आता है। खासकर अगर सिस्टम का आर्किटेक्चर नैटिव है। मुझे लगता है कि कोड समीक्षा एक महत्वपूर्ण शिक्षण अभ्यास है। परियोजनाओं के वास्तविक कोड को पार्स करने से डेवलपर को प्रतिक्रिया मिलती है। और हम सभी के लिए यह समझना महत्वपूर्ण है कि हम सही तरीके से विकसित हो रहे हैं या नहीं।

मुझे लगता है कि हमने बीच में एक अच्छा संतुलन पाया:

• बिटकॉइन बायकोड में डिले होने से डेवलपर्स को डिमोटिनेट न करें।
• गुणवत्ता की वास्तुकला बनाते हैं।
• सीएमएस और एमवीसी ढांचे का अधिकतम उपयोग करके पहिया को सुदृढ़ न करें।
• स्पष्ट, संक्षिप्त और रखरखाव योग्य कोड के साथ ग्राहक को उच्च तकनीक वाले उत्पाद वितरित करें।

अधिक आशावाद, दोस्तों।