🈂️ 🐭 🧝🏿 ब्राउज़र विकास - कार्यात्मक स्तर 🆎 ⚒️ 🏳️‍🌈

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

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

पिछली बार की तरह, कहानी टीम के सदस्यों में से एक के दृष्टिकोण से आयोजित की जाएगी जो अपनी स्थापना के बाद से परियोजना का विकास कर रही है - प्रोग्रामर, अर्थात्, इस बार - मुझे।

पर्नात्स्क :: हत्यारे जेस

डेवलपर श्रम

मैं "हैबर" के पन्नों पर "हंतिम" से ब्लॉक को कितना भी देखता हूं, चाहे मैं परियोजनाओं में साझा भागीदारी के प्रस्तावों को पूरा करता हूं, लेकिन मुझे हमेशा उनके बारे में संदेह रहा है। आमतौर पर एक "पूरी टीम" होती है, लेकिन केवल डेवलपर गायब होता है, और प्रस्ताव एक छोटा अंश और काम का एक बड़ा हिस्सा है।

अब तक, मैं इस सवाल का जवाब नहीं दे सकता हूं - जब मैं हमारी परियोजना में भाग लेने के लिए सहमत हुआ तो मुझे क्या स्थानांतरित करना पड़ा? यह अभी स्पष्ट था - काम एक वर्ष के लिए नहीं, बल्कि वास्तविक रूप से मूर्त लाभ पर होगा। जाहिरा तौर पर, सितारों का गठन इसलिए हुआ कि मैं टीम के लिए अचानक वफादार था, और टीम ने मुझे स्वीकार कर लिया।

दूर के परिचितों ने करीबी और दूर के परिचितों को बुलाया, नतीजतन, टीम का गठन हुआ, परिणामस्वरूप, करीबी परिचितों ने टीम को छोड़ दिया, नतीजतन, दूर के परिचित करीबी दोस्त बन गए।

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

केवल एक ही काम करना बाकी था, इस उम्मीद के साथ कि मैं किसी दिन मुख्य बन जाऊंगा, और मैं अपने साथियों के साथ भावना से काम करूंगा। वैसे अनुभव का अर्थ है अनुभव।

पेट मत पालना, मैं तो बह गया

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

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

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

135 टेबल्स के डेटाबेस साइज़ के साथ, आप या तो मॉडल के साथ फ़ोल्डर में एक गुच्छा की व्यवस्था नहीं कर सकते हैं - प्रोजेक्ट की बहुत शुरुआत से, "मॉडल" को ट्रिपल नेस्टिंग के साथ निर्देशिका में रखा गया है ताकि अराजकता पैदा न हो (यहां तक कि वर्णानुक्रम में सॉर्ट करने से आप बर्ड के साथ शुरू होने वाली 30 फ़ाइलों में खोज करने से नहीं बचते हैं) ~)। कोई सोच सकता है कि संपादन के लिए वांछित फ़ाइल की खोज करते समय 2-4 क्लिक बहुत होते हैं, लेकिन मेरे लिए और परियोजना समन्वयक के लिए यह आदेश डेढ़ सौ से एक फ़ाइल की तलाश में माउस व्हील के साथ स्क्रॉल करने की कोशिश करने की तुलना में बहुत बेहतर निकला।

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

पर्नात्स्क :: फॉक्स जे

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

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

इसके अलावा, Yii में बहुभाषिकता का समर्थन करने के लिए तैयार तंत्र हैं - हमारी परियोजना में अभी तक कई भाषाएँ नहीं हैं, लेकिन इस तंत्र ने हमें "यांत्रिक" लोगों से त्रुटियों का वर्णन करने वाले साहित्यिक ग्रंथों को अलग करने में मदद की जिन्हें मैंने कार्यक्षमता बनाने की प्रक्रिया में लिखा था। और फिर से - त्रुटियों या सफल कार्यों के सभी ग्रंथों को कई फाइलों में एकत्र किया जाता है, और पूरे प्रोजेक्ट में ग्रंथों की खोज करने की कोई आवश्यकता नहीं है।

कोड से परे

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

पर्नात्स्क :: हॉब ब्र

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

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

फिलहाल, पृष्ठभूमि कार्यों की सूची में पैंतालीस प्रविष्टियों के आधार पर परियोजना काम कर रही है (कुछ दोहराव के साथ, लेकिन सार नहीं) - बहुत या थोड़ा, हर कोई खुद के लिए फैसला करेगा, लेकिन यह स्पष्ट रूप से सीमा नहीं है। यहाँ हमारी सूची है:

सबसे महत्वपूर्ण कार्य - लंबित उपयोगकर्ता क्रियाओं के परिणामों की गणना करना - जिन्हें टिक नामक एक एकल कार्य धारा में रखा जाता है, जो सर्वर के समय का 100% भाग होता है। बेशक, PHP में एक डेमन ऐसा कुछ नहीं है जिसे सामान्य रूप से पीएचपी डेवलपर की मानक सोच के साथ काम करने के लिए बनाया जा सकता है, जब यह विश्वास होता है कि इसके लॉन्च के बाद आवेदन मर जाना चाहिए, इसलिए टिक 10 मिनट के वर्गों में काम करता है, जिसके बाद कार्य को पुनः आरंभ करना। कुछ अप्रत्याशित परिस्थितियों से बचाने के लिए, म्यूटेक्स झंडे की स्थापना कार्य चक्रों में मौजूद है, और डाउनटाइम से बचने के लिए एक नई प्रक्रिया की शुरुआत पिछले एक के अंत में थोड़ी अधिक है।

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

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

पृष्ठभूमि कार्यों की सूची की संरचना और तैनाती के दौरान कुछ भी न खोने के लिए, सूची स्वचालित रूप से एक अलग कॉन्फ़िगरेशन से संकलित की जाती है, जहां प्रत्येक कार्य का डेटा बहुआयामी सरणी में संग्रहीत किया जाता है। कमांड की सूची अलग कंसोल कमांड "php yiic.php crontab" का उपयोग करके एक पठनीय रूप में उत्पन्न होती है, जिसे वास्तव में "php yiic.php crontab" के माध्यम से मैन्युअल रूप से एक कमांड के साथ तैनात किया जाता है। crontab -u उत्पादन - ", वांछित वातावरण के लिए सर्वर कार्यों की सूची को फिर से लिखना।

सब कुछ याद रखें

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

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

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

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

इस कैश ऑपरेशन स्कीम के साथ एक अतिरिक्त समस्या कैश के लिए प्रवेश बिंदु थी - CDBConnection कॉल मुख्य वांछित मॉडल के लिए और सभी मॉडल के लिए हुई जो कि संबंध बंडल में जाते हैं (यदि ऐसा अनुरोध में निर्दिष्ट किया गया है), और संबंधित कॉल से कॉल बाद में होती है, क्रमशः मुख्य एक से, अनिवार्य रूप से जुड़ने के सभी अनुरोध स्थायी कैश में गिर गए।

फॉर्म में कई बैसाखी स्थापित करने के बाद "मुझे पूरा यकीन है कि आपको स्थिर मॉडल के एक सम्मिलित मॉडल के साथ इस अद्भुत अनुरोध को कैश नहीं करना होगा", हमें एक व्यावहारिक समाधान मिला, लेकिन केवल एक शर्त पर - "स्थिर" का उपयोग करने वाले सभी नमूनों को बिना मिलावट के सख्ती से किया जाना चाहिए। जहाँ संभव हो। यही है, यदि पृष्ठ पर वर्ण आइटमों की सूची वाला कोई पृष्ठ प्रदर्शित होता है, तो इसका मतलब है कि एक अनुरोध Bird_id के एक समूह के पीछे "bird_item" तालिका के लिए किया गया था <-> item_id, और प्रत्येक आइटम के लिए व्यक्तिगत अनुरोधों का अंधकार जो जादुई रूप से पहले से ही झूठ है कैश में। संदर्भ के लिए, चरित्र के मुख्य पृष्ठ पर कैश "गर्म" होने से पहले 230 से अधिक अनुरोध डेटाबेस को भेजे जाते हैं। "वार्मिंग अप" के बाद - केवल 19।

कैश लेयर के कुछ अंश

/** * Permanent cache for models * * Component "dbParam" is storring active parameters in database * Config parameter "staticModelList" consists of model names should be in permanent cache * */ class ActiveRecord extends CActiveRecord { /** * Flag are cache setings already setted */ private $_cacheUpdated = false; /** * Setting cache for static data * * @return CDbConnection */ public function getDbConnection() { if (!empty($this->_cacheUpdated)) { return parent::getDbConnection(); } $className = get_class($this); if (in_array($className, Yii::app()->params->staticModelList) !== false) { $dependency = new CExpressionDependency('Yii::app()->dbParam->staticDataLastUpdateTime . "_' . $className . '_" . Yii::app()->dbParam->schemaLastUpdate'); return parent::getDbConnection()->cache(Yii::app()->db->schemaCachingDuration, $dependency); } return parent::getDbConnection()->cache(0); } /** * Setting flag as updated cache * * @param int $duration * @param null $dependency * @param int $queryCount * @return CActiveRecord */ public function cache($duration, $dependency = null, $queryCount = 1) { $className = get_class($this); if (in_array($className, Yii::app()->params->staticModelList) === false) { $this->_cacheUpdated = true; } return parent::cache($duration, $dependency, $queryCount); } /** * Save model and drop static-model cache condition * * @param bool $runValidation * @param null $attributes * @return bool */ public function save($runValidation = true, $attributes = null) { if (in_array(get_class($this), Yii::app()->params->staticModelList) !== false) { Yii::app()->dbParam->staticDataLastUpdateTime = time(); } return parent::save($runValidation, $attributes); } /** * Drop model and drop static-model cache condition * * @return bool */ public function delete() { if (in_array(get_class($this), Yii::app()->params->staticModelList) !== false) { Yii::app()->dbParam->staticDataLastUpdateTime = time(); } return parent::delete(); } }

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

पर्नात्स्क :: स्काउट शिविर

पैटर्न कोड

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

हालांकि, जैसा कि यह थोड़ा बाद में निकला, यदि आप अपने आप को "मजबूत" करते हैं, तो यह लगातार परियोजना से परियोजना के लिए भटकता रहेगा, लेकिन यह इस तथ्य से बहुत दूर है कि कुछ समय में यह समझ में आ जाएगा कि यह वास्तव में "वह" है - यह बस "अच्छा" होगा निर्णय ”, जो एक आदत बन जाएगा।

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

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

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

सबसे पहले, एक आधार व्यवहार वर्ग की आवश्यकता होती है, जो डिफ़ॉल्ट रूप से हमेशा उस मॉडल से जुड़ा होगा जो चालू किया जा रहा है (यह संभव नहीं है कि मॉडल के लिए, लेकिन वर्तमान कार्य के लिए - यह), जिसमें वांछित अंतिम व्यवहार और विधियों का चयन करने के तरीके शामिल होने चाहिए। अंतिम व्यवहार का उपयोग नहीं किए जाने पर डिफॉल्ट को वापस करने के लिए स्टब्स। दूसरे, आपको व्यवहार वर्गों का एक समूह चाहिए जो वास्तव में आवश्यक कार्य करता है।

पर्नेत्स्क :: गिलहरी बिजली

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

वास्तव में, एक निश्चित टॉगल स्विच काम करता है, वस्तु की स्थिति के आधार पर वांछित वर्ग को जोड़ता है।

स्विटचेबल वेदर बिहेवियर के अंश

 /** * This class is appended as behavior to WeatherHistoryEffect and provides * real effect actions for current effect * * Class WeatherEffectBehavior */ class WeatherEffectBehavior extends CBehavior { /** * Is weather enabled in admin settings * * @return bool */ private function isWeatherEnabled() { $isWeatherDisabledByEvent = GlobalEvent::model()->getValue(GlobalEvent::ACTION_WEATHER); return empty($isWeatherDisabledByEvent) && (!empty(Yii::app()->par->weatherEnabled)); } /** * Activate weather effect * * @return bool */ public function activate() { $owner = $this->getOwner(); if ($this->isWeatherEnabled() && $this->checkEnabledBehavior()) { return $owner->activate(); } return false; } /** * Checking if building is disabled during weather effect * * @param int $building * @return bool */ public function isBuildingDisabled($building) { $owner = $this->getOwner(); if ($this->isWeatherEnabled() && $this->checkEnabledBehavior()) { /** * @var WeatherEffectBehavior $owner */ return $owner->isBuildingDisabled($building); } return false; } /** * Checking if action is disabled during weather effect * * @param int $action * @return bool */ public function isActionDisabled($action) { $owner = $this->getOwner(); if ($this->isWeatherEnabled() && $this->checkEnabledBehavior()) { /** * @var WeatherEffectBehavior $owner */ return $owner->isActionDisabled($action); } return false; } /** * Checking if building is disabled during weather effect * * @param $type * @return bool */ public function getCoefficient($type) { $owner = $this->getOwner(); if ($this->isWeatherEnabled() && $this->checkEnabledBehavior()) { /** * @var WeatherEffectBehavior $owner */ return $owner->getCoefficient($type); } return 1; } /** * Generating text value of effect * * @return null|string */ public function getTextValue() { $owner = $this->getOwner(); if ($this->isWeatherEnabled() && $this->checkEnabledBehavior()) { /** * @var WeatherEffectBehavior $owner */ return $owner->getTextValue(); } return null; } /** * Generated weather effect description * * @return null|string */ public function getPublicText() { $owner = $this->getOwner(); if ($this->isWeatherEnabled() && $this->checkEnabledBehavior()) { /** * @var WeatherEffectBehavior $owner */ return $owner->getPublicText(); } return null; } /** * Switching behaviors for effect model * * @return bool */ public function checkEnabledBehavior() { $behavior = $this->getOwner()->asa('weatherFinalEffectBehavior'); if (empty($behavior)){ if (!empty($this->getOwner()->effect)) { $behaviorName = false; switch ($this->getOwner()->effect->effect_id) { case WeatherEffect::TYPE_CONES_SEARCH_MAX_CHANCE_COEFFICIENT: $behaviorName = 'ConesSearchMaxChanceCoefficientBehavior'; break; case WeatherEffect::TYPE_CONES_SEARCH_TIME_COEFFICIENT: $behaviorName = 'ConesSearchTimeCoefficientBehavior'; break; case WeatherEffect::TYPE_COINS_HUNT_TIME_COEFFICIENT: $behaviorName = 'CoinsHuntTimeCoefficientBehavior'; break; case WeatherEffect::TYPE_COINS_HUNT_BONUS_COEFFICIENT: $behaviorName = 'CoinsHuntBonusCoefficientBehavior'; break; case WeatherEffect::TYPE_DEFENCE_IDOLS_DO_NOT_WORK: $behaviorName = 'DefenceIdolsDoNotWorkBehavior'; break; case WeatherEffect::TYPE_ATTACK_IDOLS_DO_NOT_WORK: $behaviorName = 'AttackIdolsDoNotWorkBehavior'; break; case WeatherEffect::TYPE_ATTACK_TIMER_COEFFICIENT: $behaviorName = 'AttackTimerCoefficientBehavior'; break; case WeatherEffect::TYPE_BATTLE_WIN_COEFFICIENT: $behaviorName = 'BattleWinCoefficientBehavior'; break; case WeatherEffect::TYPE_CAN_NOT_SELL_ON_FLEAMARKET: $behaviorName = 'CanNotSellOnFleamarketBehavior'; break; case WeatherEffect::TYPE_CAN_NOT_COINS_HUNT: $behaviorName = 'CanNotCoinsHuntBehavior'; break; case WeatherEffect::TYPE_CAN_NOT_CONES_SEARCH: $behaviorName = 'CanNotConesSearchBehavior'; break; case WeatherEffect::TYPE_NO_DELAY_BETWEEN_ATTACK: $behaviorName = 'NoDelayBetweenAttackBehavior'; break; case WeatherEffect::TYPE_BATTLE_STATS_BONUS_COEFFICIENT: $behaviorName = 'BattleStatsBonusCoefficientBehavior'; break; case WeatherEffect::TYPE_BATTLE_FEATHERING_CHANCE_COEFFICIENT: $behaviorName = 'BattleFeatheringChanceCoefficientBehavior'; break; case WeatherEffect::TYPE_STAT_COST_COEFFICIENT: $behaviorName = 'StatCostCoefficientBehavior'; break; case WeatherEffect::TYPE_SHOP_PRICE_COEFFICIENT: $behaviorName = 'ShopPriceCoefficientBehavior'; break; case WeatherEffect::TYPE_WORK_TIMER_COEFFICIENT: $behaviorName = 'WorkTimerCoefficientBehavior'; break; case WeatherEffect::TYPE_BATTLE_CONES_WIN_MAX_CHANCE_COEFFICIENT: $behaviorName = 'BattleConesWinMaxChanceCoefficientBehavior'; break; case WeatherEffect::TYPE_STORM_RATION: $behaviorName = 'StormRationBehavior'; break; case WeatherEffect::TYPE_COINS_LEVEL_REWARD: $behaviorName = 'CoinsLevelRewardBehavior'; break; case WeatherEffect::TYPE_COINS_PERCENT_REWARD: $behaviorName = 'CoinsPercentRewardBehavior'; break; case WeatherEffect::TYPE_IDOLS_DO_NOT_WORK: $behaviorName = 'IdolsDoNotWorkBehavior'; break; case WeatherEffect::TYPE_FOLIAGE_DO_NOT_WORK: $behaviorName = 'FoliageDoNotWorkBehavior'; break; case WeatherEffect::TYPE_POLE_DO_NOT_WORK: $behaviorName = 'PoleDoNotWorkBehavior'; break; case WeatherEffect::TYPE_NECKLACE_CONES_UPGRADE_COST_COEFFICIENT: $behaviorName = 'NecklaceConesUpgradeCostCoefficientBehavior'; break; case WeatherEffect::TYPE_RARE_ITEM_FOUND_CHANCE_COEFFICIENT: $behaviorName = 'RareItemFoundChanceCoefficientBehavior'; break; } if (!empty($behaviorName)) { $this->getOwner()->attachBehavior('weatherFinalEffectBehavior', $behaviorName); $this->getOwner()->detachBehavior('weatherEffect'); return true; } } } return false; } } class CoinsHuntTimeCoefficientBehavior extends WeatherEffectBehavior { public function getCoefficient($type) { if ($type == WeatherEffect::TYPE_COINS_HUNT_TIME_COEFFICIENT) { return $this->getOwner()->value; } return 1; } public function getTextValue() { return ($this->getOwner()->value * 100) . '%'; } public function getPublicText() { return CHtml::tag('b', array(), '') . ',       ' . CHtml::tag('b', array('class' => 'g18_icons i_hunt', 'title' => ' '), '') . CHtml::link(' ', '/location/coinshunt') . ', ' . CHtml::tag('b', array(), ($this->getOwner()->value < 1 ? '' : '')) . Yii::app()->formatter->percentCoefficient($this->getOwner()->value); } }

हां, यह मॉडल की संरचना को जटिल बनाता है, कक्षाओं की अतिरिक्त जांच, कनेक्शन और डिस्कनेक्ट जोड़ता है (और निश्चित रूप से, यह दुभाषिया पर अधिक भार देता है), लेकिन यह एक ही प्रकार के कोड की हैंडलिंग को बहुत सरल करता है, जो तकनीकी रूप से भिन्न होता है और संरचनात्मक रूप से दोहराता है।

सिस्टम ध्वस्त

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

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

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

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

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

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

डेटा को रिपॉजिटरी में बिना किसी ट्रिक के स्टोर किया जाता है - ये सीरीज़ के साथ साधारण फाइलें हैं () - मॉडल की सामग्री, जहाँ प्रति फ़ाइल एक टेबल एंट्री होती है (फिलहाल डेटा की मात्रा ऐसी है कि एक फ़ाइल सभी डेटा के लिए पर्याप्त नहीं है कि यह उत्पन्न नहीं होती है। क्रमिक-विचलन के दौरान स्मृति की कमी के साथ समस्याएं)।

पर्नात्स्क :: लैंडफिल

पुनर्स्थापित करने के लिए विभाजित करें

जब तक टीम में एक सिस्टम प्रशासक नहीं था, तब तक किसी को अप्रत्याशित परिस्थितियों के दौरान बैकअप बनाने, भंडारण और बहाल करने के मामले में केवल अपनी ताकत और ज्ञान पर निर्भर रहना पड़ता था।
पर्नात्स्क :: तस्करी

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

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

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

प्रारंभिक अनुमानों के अनुसार, दो ठिकानों के आकार का अनुपात 1 से 70 था - अर्थात्, परियोजना पर लड़ाई, पत्र और अन्य बड़े पैमाने पर "भूसी" का इतिहास महत्वपूर्ण डेटा से कई गुना अधिक था।

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

पृथक्करण की परत से दो आधारों में अंश

 <?php class ActiveRecord extends CActiveRecord { static private $_tableCheckedPrefix = array(); /** * Table names with DB name prefix * * @param $tableName * @return string */ public function tableNameWithPrefix($tableName) { if (empty(self::$_tableCheckedPrefix[$tableName])) { $matches = array(); preg_match("/dbname=([^;]*)/", $this->getDbConnection()->connectionString, $matches); return $this->getCheckedTableName($matches[1], $tableName); } return self::$_tableCheckedPrefix[$tableName] . '.' . $tableName; } /** * Creating static var cache of table names * * @param $tableName * @param $dbName */ public function setCheckedTablePrefix($tableName, $dbName) { self::$_tableCheckedPrefix[$tableName] = $dbName; } /** * Creating static var cache of table names * * @param $dbName * @param $tableName * @return string */ public function getCheckedTableName($dbName, $tableName) { $this->setCheckedTablePrefix($tableName, $dbName); return $dbName . '.' . $tableName; } } class LogActiveRecord extends ActiveRecord { static private $_dbLog; static private $_dbEnabled = null; /** * Checking DB available or resetting to main DB * * @return CDbConnection */ public function getDbConnection() { if (self::$_dbEnabled === false) { return Yii::app()->db; } if (self::$_dbLog !== null) { return self::$_dbLog; } else { try { self::$_dbLog = Yii::app()->dbLog; if (self::$_dbLog instanceof CDbConnection) { return self::$_dbLog; } else { throw new CDbException(Yii::t('yii','Active Record requires a "db" CDbConnection application component.')); } } catch (Exception $e) { self::$_dbEnabled = false; return Yii::app()->db; } } } /** * Table name with DB name prefix * * @param $dbName * @param $tableName * @return string */ public function getCheckedTableName($dbName, $tableName) { if ($this->getDbConnection()->getSchema()->getTable($tableName) === null) { self::$_dbEnabled = false; self::$_dbLog = Yii::app()->db; return parent::tableNameWithPrefix($tableName); } self::$_dbEnabled = true; $this->setCheckedTablePrefix($tableName, $dbName); return $dbName . '.' . $tableName; } }

साइकिल या किसी और की चप्पल

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

क्या वास्तव में परियोजना पर इस्तेमाल किया गया था, किसी भी तरह से यह केवल newfangled डीबग टूलबार पूरा नहीं किया गया था, ध्यान से Yii2 के नए संस्करण से फ्रेमवर्क के सदस्य द्वारा संस्करण कोड Yii1.1 में स्थानांतरित किया गया था। बाकी सब या तो सतही तौर पर "नोटिस" से छुटकारा पाने के लिए जोड़ा गया था जो एक्सटेंशन के संचालन के दौरान दिखाई दिया (जैसे कि स्विफ्टमेलर, जहां चर को समय-समय पर आरंभीकृत नहीं किया गया था या सरणी तत्वों की जांच नहीं की गई थी), या लगभग पूरी तरह से लिखा गया था (एक्सडबपराम, ईमुटेक्स के मामले में) जहां, सिद्धांत रूप में, कोड सामग्री और गुणवत्ता के अनुरूप नहीं था, लेकिन कम से कम इसे सामान्य विचारों के संदर्भ में आधारित होने की अनुमति दी गई थी)।

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

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

सिस्टम के अन्य सभी तत्व चयन के समान दृष्टिकोण से गुजरते हैं। किसी और के विकास को एक आधार के रूप में लिया जा सकता है, आपको स्वयं कुछ करना होगा, लेकिन हमारे पास ऐसे कारक हैं जो हमें त्वरित विकास के लिए कम से कम प्रतिरोध के साथ मार्ग निर्धारित करने में मदद करते हैं।

:: ,

आदिमों को शक्ति

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

अल्फा परीक्षण के लिए, हमने Hetzner में दो आभासी मशीनें स्थापित कीं - vq7 और vq12, जिसके बीच डेटाबेस की प्रतिकृति और "मास्टर-मास्टर" प्रकार का एक ज्ञापन था। मुख्य मशीन से दूसरे में, रिपॉजिटरी में संग्रहित नहीं की गई परियोजना फाइलें अतिरिक्त रूप से सिंक्रनाइज़ की गई थीं। इस प्रकार, हम अपने सिस्टम की "हॉट-स्वैप" की संभावना को "निकट-युद्ध" स्थितियों में परखने में सक्षम थे - दोनों "वर्चुअल मशीन" ने पूरे परीक्षण के दौरान विफलताओं के बिना काम किया। उसी समय, दोनों "वर्चुअल मशीन" का उपयोग पूरी तरह से किया गया था - दोनों आईपी पते डोमेन के DNS रिकॉर्ड्स में इंगित किए गए थे, और दो सर्वरों पर उपयोगकर्ताओं को बिखेर दिया था।

परियोजना की शुरुआत तक, एक EX6S "लोहा" सर्वर उसी हेट्जनेर में किराए पर लिया गया था। एक वेब सर्वर के रूप में, nginx php-fpm मॉड्यूल के साथ काम करता है (शुरुआत में PHP संस्करण 5.4 था, थोड़ी देर बाद 5.5 पर स्विच किया गया), डेटाबेस Percona सर्वर है (हालांकि यह सिर्फ MySQL का उपयोग करना चाहिए था, क्योंकि "चिप्स" "भत्तों" के प्रत्यक्ष अनुभव के साथ) मैं अभी भी मेम्चे पर कैशिंग नहीं करता हूं। निष्पादन योग्य कोड को कैशिंग करने के लिए, APC कैश का उपयोग पहले किया गया था, लेकिन नए साल के लिए PHP 5.5 में संक्रमण के साथ हमें पूरी तरह से अपरिचित OPcache का उपयोग करना पड़ा - हालांकि हमें गति में बहुत ही असंवेदनशील वृद्धि को छोड़कर, प्रदर्शन में बहुत अंतर नहीं दिखाई दिया।

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

अनुरोध समयरेखा पर, 2.5 सेकंड से अधिक की चोटियों का अर्थ है व्यवस्थापक पैनल में लॉग पेज खोलना, 1 सेकंड मतलब उपयोगकर्ता पंजीकरण की चोटियां (इसके साथ बहुत अधिक डेटा उत्पन्न होता है), लगभग 500 एमएस के अनुरोध बड़े पेजों के साथ भारी पृष्ठ हैं (जैसे खिलाड़ियों के बीच लड़ाई की गणना। )।

व्यवस्थापक के कार्य से संबंधित एक और बिंदु बढ़ते भार के साथ प्रणाली का विस्तार है। ऐसा करने के लिए, हमारे पास हमारे शस्त्रागार में CActiveRecord के लिए एक ऐड-ऑन है जो हमें "मास्टर-दास" प्रकार की प्रतिकृति का समर्थन करने की अनुमति देता है - पढ़ने और लिखने के लिए एक डेटाबेस का एक अतिरिक्त विकल्प। और इसके अलावा, हमने पहले से ही दो-तरफ़ा प्रतिकृति का उपयोग करने की संभावना का परीक्षण किया है, जो हमें लोड संतुलन सुनिश्चित करने के लिए अंततः कई सर्वरों का उपयोग करने की अनुमति देगा।

नोस्कल डेटाबेस में संक्रमण की योजना अभी तक नहीं बनाई गई है - इस तरह के वैश्विक परिवर्तनों के लिए इस क्षेत्र में बहुत कम अनुभव है और इतने बड़े पैमाने पर पाठ्यक्रम सुधार के लिए समय की पूरी कमी है। लेकिन अगर परियोजना सफल होती है, तो यह कदम लोड को कम करने में मदद कर सकता है।

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

कोड में जीवन

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

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

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

एक परियोजना को खत्म करना मुश्किल नहीं है - मुख्य बात यह है कि इसमें संभावनाओं को देखना है और पक्ष में एक प्रेरक कारक है। मेरा प्रेरक कारक परियोजना समन्वयक है, जो पूरी टीम को आगे बढ़ाता है, और हमारी परियोजना में खिलाड़ियों का छोटा समुदाय जो पिछले दो महीनों में बना है।

ब्राउज़र विकास - कार्यात्मक स्तर