एक विरासत परियोजना में एसपीआर के एक सफल अनुप्रयोग की कहानी

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

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

कुछ मैं अपनी भाषा में वर्णन करूंगा।

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

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

नेत्रहीन, इस तरह की वास्तुकला को कार्यक्षमता के कई ऊर्ध्वाधर के रूप में दर्शाया जा सकता है



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

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

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

फैसला अचानक और अप्रत्याशित रूप से आया।

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

तर्कों का एक हिस्सा संस्थाओं में लागू किया गया था, जो विभिन्न एल्गोरिदम में समान संस्थाओं के उपयोग को रोकता था।

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

मैंने अपने आवेदन के "ब्रह्मांड" को सख्ती से विभाजित करने का निर्णय लिया

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

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

उदाहरण के लिए
CloudClient - एक क्लाउड सेवा का एक क्लाइंट जिसके लिए दस्तावेज़ भेजे और संसाधित किए जाते हैं
- डाउनलोड करें
- भेजें
- जाओ
- डाउनलोड करें
- सहमत हैं
...

FileSystemClient - फाइल सिस्टम क्लाइंट
ERPClient - क्लाइंट अकाउंटिंग सिस्टम

ग्राहकों ने सभी मॉड्यूल में पहले से उपयोग किए गए सभी तरीकों को एल्गोरिदम में लागू किया, जिससे एक ही हिस्सों से नए लागू किए गए एल्गोरिदम को जल्दी और आसानी से लागू करना संभव हो गया।

और संबंधित क्लाइंट में समान कार्यक्षमता विधियों का आवंटन कोड के अधिक विशेषज्ञता और पुन: उपयोग के लिए प्रेरित करता है।

आर्किटेक्चर अब चित्र के रूप में एक आरेख था



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

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

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

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

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