वेब परियोजना के विकास के बुनियादी ढांचे और जीवन चक्र

जब परियोजना छोटी होती है, तो इसके साथ कोई विशेष समस्याएं नहीं होती हैं। कार्यों की सूची एक पाठ फ़ाइल (TODO), संस्करण नियंत्रण प्रणाली, में रखी जा सकती है, और बड़ी, को छोड़ा जा सकता है, आप बस उन्हें (cp / scp / rsync) फ़ाइलों को लाइव सर्वर पर अपलोड करने के लिए कॉपी कर सकते हैं, और आप हमेशा त्रुटियाँ देख सकते हैं लॉग फ़ाइल में। यह मूर्खतापूर्ण होगा, उदाहरण के लिए, एक पूर्ण सेवा के लिए प्रति दिन दो लिपियों और तीन आगंतुकों के साथ एक पूर्ण सर्वर कॉन्फ़िगरेशन प्रणाली को बढ़ाने के लिए।

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

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


कोई भी कार्य समस्या के कथन से शुरू होता है, चाहे वह एक योजनाबद्ध सुविधा हो या त्रुटि संदेश।

परियोजना और कार्य प्रबंधन

सिस्टम "इश्यू एंड प्रोजेक्ट ट्रैकिंग" के रूप में, हम Mail.ru पर, एटलसियन जीरा का उपयोग करते हैं, जो बड़े संगठनों के बीच वास्तविक मानक है। यहाँ जीरा का उपयोग करने वाली कंपनियों की पूरी सूची से बहुत दूर है: en.wikipedia.org/wiki/Atlassian_JIRA । इस प्रणाली की कार्यक्षमता, लचीलापन, विस्तार और उपयोगिता में कोई समानता नहीं है, और मुझे कोई विकल्प नहीं दिखता है, हालांकि मेरे पास उपलब्ध जानकारी के अनुसार, हजारों कर्मचारियों वाली कुछ सबसे बड़ी आईटी कंपनियां सफलतापूर्वक (उनके आश्वासन के अनुसार) बग ट्रैकर के रूप में बुगज़ल का उपयोग करती हैं।

छोटी टीमों और परियोजनाओं के लिए, कम परिष्कृत और अधिक मुफ्त एनालॉग्स का उपयोग करने की सलाह दी जाती है जैसे कि बुग्जिला , फाब्रिकेटर या रेडमाइन । वैकल्पिक रूप से, यदि आप प्रोजेक्ट होस्टिंग ( GitHub , BitBucket और अन्य) का उपयोग करते हैं, तो आप उनमें निर्मित त्रुटि ट्रैकिंग सिस्टम का उपयोग कर सकते हैं।

वर्तमान में, जीरा में कैलेंडर परियोजना में 1816 कार्य हैं, जिनमें से 1386 को सफलतापूर्वक बंद कर दिया गया है। उनमें से लगभग 500 कीड़े थे =)

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

संस्करण नियंत्रण प्रणाली

आज तक, सबसे सामान्य संस्करण नियंत्रण प्रणाली Git और Mercurial हैं । दोनों के पास, बड़ी और समान कार्यक्षमता (वितरित सिस्टम) है, हालांकि वे विवरणों में भिन्न हैं। लगभग सभी Mail.ru प्रोजेक्ट्स को Git में स्विच किया गया (कुछ SVN के साथ, कुछ सामान्य रूप से CVS के साथ), और कैलेंडर कोई अपवाद नहीं है।

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

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

तिथि करने के लिए, हमारे पास कैलेंडर रिपॉजिटरी में 7175 कमिट हैं, और हर समय लगभग 300 शाखाएं बनाई गई हैं। पूरे प्रोजेक्ट का आकार 60 एमबी है।

किसी प्रोजेक्ट को विकसित करने के लिए, आपको पहले इसे शुरू करना होगा, इसके लिए आपके पास उपयुक्त सॉफ्टवेयर और लाइब्रेरी होना चाहिए।

विकास पर्यावरण

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

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

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

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

  पाइप स्थापित -r आवश्यकताओं / development.txt 

एक क्लोन रिपोजिटरी से। क्लाइंट (फ्रंट-एंड) भाग npm का उपयोग करता है और सभी निर्भरताएं आसानी से और स्वाभाविक रूप से स्थापित की जाती हैं।

कैलेंडर वर्तमान में 33 तृतीय-पक्ष पायथन पुस्तकालयों का उपयोग करता है।

खसखस पर सभी आवश्यक सॉफ्टवेयर काढ़ा से स्थापित किया गया है, और डेवलपर के कंप्यूटर पर परियोजना की प्रारंभिक स्थापना के लिए, बस चलाएं

  काढ़ा स्थापित करें ... 

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

परियोजना प्रलेखन

ज्ञान शक्ति है। ज्ञान अपने सहयोगियों के साथ साझा करने के लायक है, उन्हें रिकॉर्ड करने की आवश्यकता है ताकि खुद को न भूलें। विकी सिस्टम सूचना स्टोर करने के लिए एक आदर्श स्थान है, और Mail.ru पर हम Atlassian Confluence का उपयोग करते हैं। मुझे कंफ्लुएंस (वास्तव में, उनकी कार्यक्षमता समान है) पर अन्य विकी-प्रणालियों पर कोई विशेष लाभ दिखाई नहीं देता है, लेकिन ऐसा हुआ कि एटलसियन उत्पादों ने हमारी कंपनी में जड़ें जमा लीं और लोकप्रिय हैं। हालांकि एक लाभ अभी भी मौजूद है: एक कंपनी के उत्पादों को एक दूसरे के साथ एकीकृत करना आसान है, और किसी भी बड़ी कंपनी में, सभी आंतरिक सेवाएं किसी न किसी तरह एक दूसरे से जुड़ी हुई हैं।

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

कॉन्फ्लुएंस में कैलेंडर प्रोजेक्ट में 122 प्रलेखन पृष्ठ हैं।

किसी भी उत्पाद को गुणवत्ता नियंत्रण की आवश्यकता होती है और हमारा कैलेंडर कोई अपवाद नहीं है।

कोड की समीक्षा

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

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

औसतन, कमिटमेंट के प्रत्येक ऑडिट में तीन से चार टिप्पणियां दिखाई देती हैं।

सहकर्मियों की टिप्पणियों को सही करने के बाद, कोड गुणवत्ता नियंत्रण के अगले चरणों में जाता है।

पार्सिंग और परीक्षण

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

कैलेंडर पर pep8 और pyflake नियमों के कोई अपवाद नहीं हैं।

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

आज तक, हमारे पास परियोजना में 580 स्वचालित परीक्षण हैं।

विभिन्न कार्यों को चलाने के लिए, हम ओपन-सोर्स जेनकिंस CI (कंटीन्यूअस इंटीग्रेशन) सिस्टम का उपयोग करते हैं, जिसमें कैलेंडर के लिए तीन कार्य हैं:

1. परीक्षण शाखाओं के लिए: कोड का सिंटैक्स नियंत्रण (लिंट), सभी परीक्षणों का शुभारंभ, कोड कवरेज रिपोर्ट तैयार करना
2. प्रीलेरेज शाखा के लिए: कोड का सिंटैक्स नियंत्रण (लिंट), सभी परीक्षणों का शुभारंभ, परियोजना के परीक्षण पैकेज (आरपीएम) की असेंबली और हमारे प्रीलेइज (परीक्षण) सर्वर पर इसका लेआउट
3. मास्टर शाखा के लिए: परीक्षण परीक्षण और प्रोजेक्ट पैकेज का निर्माण (RPM)

सभी कार्यों को लॉन्च किया जाता है जब संबंधित शाखा को गिट रिपॉजिटरी में हुक द्वारा धकेल दिया जाता है।

एक परियोजना के संयोजन के बारे में पाँच मिनट लगते हैं।

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

आउटपुट एक (या कई, प्रोजेक्ट पर निर्भर करता है) RPM फाइल है जिसमें वर्चुअन, सभी आवश्यक निर्भरताएं (लाइब्रेरी) और फाइलें (स्टेटिक्स) के साथ पूरी परियोजना शामिल है।

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

युद्ध में परियोजना का लेआउट

अड्मिन स्मार्ट और आलसी लोग हैं। यदि आपको अक्सर नियमित संचालन करना पड़ता है, तो उन्हें स्वचालित क्यों नहीं किया जाता है?

Mail.ru में कई हजारों सर्वर हैं, प्रत्येक की अपनी भूमिका और अपनी सेटिंग्स हैं। हम सर्वर कॉन्फ़िगरेशन को प्रबंधित करने के लिए कठपुतली का उपयोग करते हैं। प्रत्येक सर्वर समूह के लिए सेटिंग्स को सरल फ़ाइलों में वर्णित किया गया है जो संस्करण नियंत्रण प्रणाली में निहित हैं। इस प्रकार, पिछली फ़ाइलों में से किसी में भी वापस रोल करने की क्षमता के साथ कॉन्फ़िगरेशन फ़ाइलों में परिवर्तन का इतिहास है। केवल सिस्टम प्रशासक के पास रिपॉजिटरी तक पहुंच है और संपूर्ण के रूप में पपेट।

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

परियोजना के लेआउट में लगभग एक मिनट का समय लगता है।

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

लॉग करने में त्रुटि

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

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

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

संतरी कैलेंडर को प्रति घंटे औसतन लगभग 100 संदेश मिलते हैं। संतरी प्रति मिनट हजारों त्रुटियों का सामना कर सकता है (क्षेत्र सिद्ध =)।

लॉगिंग अच्छा है, लेकिन यह पर्याप्त नहीं है, परियोजना के महत्वपूर्ण आँकड़े।

सांख्यिकी और रेखांकन

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

ग्राफिक्स किस लिए हैं? जैसा कि मैंने पहले ही कहा है, आप हमेशा रेखांकन द्वारा किसी परियोजना की स्थिति का न्याय कर सकते हैं: रीडायरेक्ट की संख्या में अचानक वृद्धि हुई है, डेटाबेस को क्वेरी करने का औसत समय दोगुना हो गया है, या किसी एक सर्वर पर I / O संचालन की संख्या में वृद्धि हुई है। यह सब आपको समस्या का पता लगाने की अनुमति देता है, और इतिहास की उपस्थिति (महीनों और वर्षों के लिए ग्राफिक्स संग्रहीत किए जाते हैं) परियोजना के साथ अचानक परेशानियों के विश्लेषण की सुविधा प्रदान करते हैं।

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

सर्वर प्रदर्शन रेखांकन (हम इसके लिए डायमंड का उपयोग करते हैं) हमें समय पर लोड और पूर्व-आदेश की अतिरिक्त मशीनों का आकलन करने या कार्यक्रम के प्रदर्शन में भाग लेने की अनुमति देते हैं।

हर मिनट कैलेंडर के ग्रेफाइट में लगभग 25 हजार अलग-अलग मीट्रिक लिखे जाते हैं।

कोई भी परियोजना लॉग के लिए नहीं लिखी गई है और ग्राफ़ के लिए नहीं: यह लोगों के लिए, हमारे प्यारे उपयोगकर्ताओं के लिए लिखी गई है। और उपयोगकर्ता कभी-कभी किसी परियोजना से नाखुश होते हैं।

उपयोगकर्ताओं के साथ संचार

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

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

हमें एक दिन में लगभग दस संदेश मिलते हैं। उनमें से आधे आभार और सकारात्मक प्रतिक्रिया के शब्द हैं।

एक आफ्टरवर्ड के बजाय

स्क्रैच से कैलेंडर विकसित करने की प्रक्रिया केवल डेढ़ साल तक चलती है, और कैलेंडर एक साल पहले की तुलना में थोड़ा कम जारी किया गया था। यह परियोजना युवा है, और हम, इसके डेवलपर्स, इसके बुनियादी ढांचे में लगातार सुधार कर रहे हैं। मैं आपको भविष्य के लिए हमारी योजनाओं के बारे में थोड़ा बताऊंगा।

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

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

व्लादिमीर रुडनीख,
Mail.Ru कैलेंडर के तकनीकी निदेशक