✍🏿 👾 🤴🏾 लानत पुराने सीआरएम 😂 👩🏻‍🏭 🏓

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

इस बीच, इस विषय में दिलचस्पी होने के कारण, मुझे एक ऐसा ही मामला मिला - और 2010 की शुरुआत में विरासत को छोड़ने के अपने अनुभव के बारे में फिनम से दिमित्री कोसोव से पूछने का फैसला किया।

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

प्रेरणा को खोने और खोजने के लिए कैसे नहीं, अगर आप समझते हैं कि उत्पादन पर अपना कोड लॉन्च करने से पहले यह एक पूरे साल है,

कोई दस्तावेज क्यों नहीं है अगर वह झूठ नहीं बोल रहा है, यह झूठ है

और वास्तविक परियोजना और टीम के उदाहरण का उपयोग करके सुविधाओं के उत्पादन को रोकने के बिना दो साल की रीफैक्टरिंग की प्रक्रिया कैसे आयोजित की जाती है।

पढ़ने या सुनने में मजा आता है ।

2011 के बीच कौन से ढांचे चुने गए? और 2016 में एक नया कैसे चुनना है

दीमा, फिनम: मैंने विशेष रूप से रिलीज की तैयारी में देखा: हमारे पास डैडी में लगभग 4,600 फाइलें हैं, जहां वास्तव में हमारा कोड विक्रेता नहीं है, कोई जेएस नहीं है। इस डैडी का वजन 16 मीटर है। और पहली कमेटी हमने दिसंबर 2011 में बनाई थी, - इसका लेखक अभी भी काम कर रहा है, यह हमारी टीम लीडर है।

प्रारंभ में, स्टैक को सही ढंग से चुना गया था। और 2012 में भी, यह काफी आधुनिक था - पहला ज़ेंड काफी प्रासंगिक था। मैंने तब एक और काम किया, लेकिन मुझे याद है कि बसंत के वसंत में कहीं 12 वीं में, हमने एक नए प्रोजेक्ट के लिए स्टैक चुना। हमने देखा:

Zend - दूसरा वाला अभी बाहर आया था, लेकिन बहुत छोटा था, उसके लिए कोई समुदाय नहीं था,

पहले Yii - लेकिन हमने ActiveRecord अवधारणा की तरह नहीं किया,

फाल्कन,

और विदेशी से कुछ और।

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

अंततः, पहले Zend ने इसका समर्थन करना बंद कर दिया। उदाहरण के लिए, 7.0 पर उन्होंने अभी भी एक सुरक्षा अद्यतन पैच जारी किया, और हमने 7.2 और 7.3 स्वयं पैच किया।

हमने स्थानांतरण प्रक्रिया की शुरुआत के साथ थोड़ा खींच लिया।

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

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

ठीक। हमने एक ढांचा चुना है। आगे क्या होगा?

शेरोज़ा, स्काईेंग: दो तरीके हैं - आप एक ही बार में सब कुछ फिर से लिख सकते हैं। आप धीरे-धीरे खींचने और छोड़ने की कोशिश कर सकते हैं। कहाँ से शुरू किया? डिमा, फिनम

: हमने होलीवर के साथ शुरू किया, जिस रास्ते से जाना है। किसी को भी इस तरह की मात्रा को फिर से लिखने का अनुभव नहीं था। उदाहरण के लिए, अपनी पिछली नौकरी से मुझे एक छोटी सी स्वायत्त सेवा को फिर से लिखने का अनुभव था - वहां हमने एक महीने के लिए विकास को रोक दिया, सब कुछ फिर से लिखा और आगे बढ़ गए। यहाँ हम एक साल के लिए पर्याप्त नहीं होंगे। शायद हम एक साल में 80 प्रतिशत बनाने में कामयाब रहे होंगे, लेकिन, आप जानते हैं ...

एक सिद्धांत है: काम का पहला 80% समय 80% लेता है। शेष 20% कार्य में 80% समय लगेगा।

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

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

फिर हमें एक और अनुभव याद आया जो हमारी टीम के पास पहले से था।

यह डेटा तक पहुंचने के लिए एक परत को फिर से लिखने का अनुभव है। क्योंकि एक बार, पहले Zend के साथ, Mongo को मुख्य डेटाबेस के रूप में चुना गया था। लेकिन अभ्यास से पता चला है कि चुनाव बहुत सही नहीं है।

Seryozha, Skyeng: हाँ, आपके पास सभी संबंधपरक कनेक्शन हैं, लेकिन आपने दस्तावेज़-उन्मुख डेटाबेस चुना है।

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

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

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

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

मैं कीड़े पकड़ा, वापस लुढ़का, बाहर लुढ़का

शेरोज़ा, स्काईेंग: फिर भी, रिफैक्टरिंग एक महत्वपूर्ण बात है, आपने खुद को कैसे बीमा किया?

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

स्वाभाविक रूप से, हमने अपने हाथों से बहुत कुछ जांचा: विशेष रूप से कुछ महत्वपूर्ण और महत्वपूर्ण चीजें, जैसे एक ही क्लाइंट और कॉल।

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

Seryozha, Skyeng: सभी तरह से चले गए , लेकिन अब यह शायद आधे से अधिक तरीके से है, तो आप क्या सलाह देंगे?

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

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

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

ps

पढ़ने और सुनने के लिए धन्यवाद। अधिक PHP पॉडकास्ट यहाँ पाया जा सकता है ।

और अगर आप उनके आसपास और अधिक दिलचस्प रिपोर्ट और वार्तालाप चाहते हैं, तो 30 मई को तीसरी आभासी PHP-बैठक में "आओ" ।

लानत पुराने सीआरएम