दिल की सर्जरी: हम एक डीएलपी सिस्टम के मुख्य घटक को कैसे फिर से लिखते हैं

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

कट के तहत, हमने योजना के 17 साल के इतिहास (!) से क्लोजर तक उत्पाद के मुख्य घटक को कैसे फिर से लिखा, और यह सब तुरंत (अच्छी तरह से, लगभग :) काम किया।

"वॉच" में 17 साल

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

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

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


छानने की सेवा

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

यह समझते हुए कि प्रणाली को अद्यतन करने के लिए आवश्यकता उत्पन्न हुई है, कुछ समय पहले प्रकट हुई है। लेकिन एक विशाल और प्राचीन प्रणाली सेवा को छूने की भावना में स्पष्ट रूप से कमी थी।

अपरिहार्य देरी करने की कोशिश नहीं कर रहा

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

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

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

हमें संसाधन की खपत को कम करने के लिए भी लड़ना था, मौजूदा प्रसंस्करण दर को बनाए रखना (और आदर्श रूप से बढ़ाना)।

भराई के बारे में थोड़ा सा

उत्पाद विकास पथ के दौरान, सौर डोजर टीम एक कार्यात्मक दृष्टिकोण की ओर बढ़ी। यह परिपक्व उद्योग के लिए प्रोग्रामिंग भाषाओं के बजाय गैर-मानक विकल्प की ओर जाता है। सिस्टम के जीवन के विभिन्न चरणों में, ये पारंपरिक सी (++) और जावा के अलावा, स्कीम, ओकेएमएल, स्काला, क्लोजर थे।

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

लौंग!

यहाँ, निश्चित रूप से, मुझे कुछ शब्दों के बारे में कहना चाहिए कि हमने क्लोजर को मुख्य कार्यान्वयन भाषा के रूप में क्यों चुना।

सबसे पहले, मैं स्कीम पर विकसित होने वाली टीम के अनूठे अनुभव को खोना नहीं चाहता था। क्लोजर भाषाओं के लिस्प परिवार का एक आधुनिक सदस्य भी है, और एक लिस्प से दूसरे में स्विच करना आमतौर पर काफी सरल है।

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

तीसरा, क्लोजर एक संक्षिप्त और अभिव्यंजक भाषा है। इससे किसी और के कोड को पढ़ना आसान हो जाता है और टीम के साथी को कोड पास करना आसान हो जाता है।

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

आगे देखते हुए, मैं कह सकता हूं: मुझे लगता है कि हमने चुनाव नहीं गंवाया।

कार्यक्षमता को थोड़ा-थोड़ा करके लाना

जब हम एक पूर्ण-विशेषताओं के प्रतिस्थापन के बारे में बात करते हैं, तो पहला सवाल यह है कि मौजूदा कार्यक्षमता के बारे में जानकारी का संग्रह है।

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

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


संदेश फ़िल्टरिंग प्रक्रिया

प्रलेखन पर्याप्त नहीं है

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

मैं सभी डेवलपर्स से संपर्क करना चाहता हूं। अपने कोड का ख्याल रखें! यह आपकी सबसे महत्वपूर्ण संपत्ति है। प्रलेखन पर भरोसा मत करो। केवल स्रोत कोड पर भरोसा करें।

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

एक प्रक्रिया बनाएँ

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

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

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

ऐसी स्थितियों में, चरण-दर-चरण कार्यात्मक परीक्षण की एक प्रणाली बनाई गई थी। हमने एक निश्चित राज्य में सेवा को बढ़ाया, जिसे सक्रिय परीक्षण द्वारा प्रबलित किया गया, और फिर एक नए कार्यान्वयन को आगे बढ़ाया।

विकास शुरू करें

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

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

अनपैकिंग तंत्र आंतरिक पुस्तकालयों, बाहरी कार्यक्रमों या तीसरे पक्ष की सेवाओं के उपयोग के बीच अंतर नहीं करता है, अनपैकिंग पाइपलाइनों के आयोजन के लिए एकल इंटरफ़ेस प्रदान करता है।

क्लोजर के प्रति एक और प्रशंसा: हमें एक कामकाजी प्रोटोटाइप मिला, जिसमें हमने कम से कम समय में भविष्य की कार्यक्षमता की रूपरेखा को रेखांकित किया।

राजनीति के लिए डी.एस.एल.

दूसरा चरण फ़िल्टरिंग नीतियों का उपयोग करके संदेश सत्यापन को जोड़ना था।

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

MFLang "स्क्रिप्ट ऑन द फ्लाई" क्लोजर कोड में व्याख्या की गई है, संदेश पर चेक के परिणामों को कैश करता है, काम का एक विस्तृत लॉग रखता है (और, स्पष्ट रूप से, एक अलग लेख के हकदार हैं)।

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

हम विश्वास के साथ कह सकते हैं कि MFLang डिबगिंग कार्यक्षमता के लिए एक बिल्कुल अमूल्य उपकरण है।

पूरी ताकत से

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

बेशक, मुख्य प्रश्न यह था कि कार्यान्वित कार्यक्षमता किस प्रकार अपेक्षित थी और यह पूरी तरह से कैसे लागू होती है।

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

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

लेकिन यदि आप प्रतिरोध को दूर करने का प्रबंधन करते हैं, तो एक ठोस आधार बनाया जाता है जो आपको सिस्टम के स्वास्थ्य का एक विचार बनाने की अनुमति देता है।

हम प्रतिस्थापित करते हैं

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

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

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

और केवल जब कार्यान्वयन टीम से सवाल आने लगे, तो समझ में आया - जिस सेवा पर हम इतने लंबे समय से काम कर रहे थे, वह पहले से ही साइटों पर थी और ... काम कर रही थी!

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

अंत में

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

मैं कुछ व्यक्तिगत इंप्रेशन जोड़ सकता हूं।

एक लंबे इतिहास के साथ एक केंद्रीय घटक को बदलना विकास के लिए ताजी हवा की एक सांस है। पहली बार एक लंबे समय के लिए, विश्वास है कि उत्पाद नियंत्रण हमारे हाथों में लौट रहा है।

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

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

यह केवल नए घटक को लंबे समय तक और सफलतापूर्वक अपने पूर्ववर्ती के रूप में काम करने की इच्छा रखता है।