अपने करियर के दौरान, मैंने विभिन्न विरासत परियोजनाओं के साथ काम किया, जिनमें से प्रत्येक को विभिन्न खामियों का सामना करना पड़ा।

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

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

मैं आपको कई प्रकार के वास्तुशिल्प समाधानों के बारे में बताऊंगा, जिनका मैंने सामना किया है, जो ऐसी प्रणालियों का समर्थन करने वाली टीमों के लिए एक वास्तविक बोझ बन सकता है।

आपकी पूरी कंपनी आपके डेटाबेस को साझा करती है

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

पहली बात जो दिमाग में आती है वह है डेटा मॉडल की कपलिंग। कल्पना कीजिए कि दो एप्लिकेशन, ए और बी, कारों पर डेटा प्रोसेस करते हैं। परिशिष्ट A का उपयोग मरम्मत कार्य के लिए जिम्मेदार टीम द्वारा किया जाता है, और इसलिए उन्हें बहुत सारी तकनीकी जानकारी संग्रहीत करने की आवश्यकता होती है: यांत्रिकी, ब्रेकडाउन, कार में हस्तक्षेप के इतिहास के बारे में ... तकनीकी टीम के लिए परिशिष्ट B का उपयोग कार्यों को निर्धारित करने के लिए किया जाता है, ताकि इसे कार के बारे में केवल बुनियादी जानकारी की आवश्यकता हो, इसके लिए पर्याप्त है। इसकी पहचान। इस मामले में, दोनों कार्यक्रमों के लिए समान डेटा संरचना का उपयोग करने का कोई मतलब नहीं है: वे विभिन्न डेटा का उपयोग करते हैं, इसलिए प्रत्येक को अपनी स्वयं की डेटा संरचना का उपयोग करना चाहिए। यह आसान बनाया गया है क्योंकि कार की पहचान करना आसान है, इसलिए सामान्य संदर्भ की आवश्यकता नहीं है।

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

सब कुछ तब और भी घृणित हो जाता है जब अनुप्रयोग न केवल एक स्रोत से डेटा पढ़ते हैं, बल्कि उन्हें बदलते हैं! इस मामले में डेटा स्वामी कौन है? किस पर भरोसा करें? डेटा अखंडता की गारंटी कैसे दी जा सकती है? एक ही डेटा को एक ही एप्लिकेशन के अलग-अलग हिस्सों द्वारा बदल दिए जाने पर भी यह मुश्किल होता है, लेकिन जब कई अलग-अलग एप्लिकेशन इसे करते हैं, तो समस्या और अधिक बढ़ जाती है ...

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

आपका सिस्टम कंपनी में उपयोग किए जाने वाले सॉफ़्टवेयर से जुड़ा हुआ है

हर कंपनी अपने व्यवसाय की सभी जरूरतों को पूरा करने वाले सॉफ़्टवेयर का विकास नहीं कर सकती है। वास्तव में, कई मामलों में यह साइकिल का एक आविष्कार होगा, क्योंकि कई कंपनियों की ज़रूरतें समान हैं, और बाजार में ऐसे सॉफ़्टवेयर खोजना आसान है जिनके पास पहले से ही आवश्यक कार्यक्षमता है।

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

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

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

कई अनुप्रयोगों के बीच मजबूत जाल

2000 के दशक की शुरुआत को याद करें: आपके सूचना प्रणाली में अनुप्रयोगों के बीच दूरस्थ कॉल को संभालने के लिए एंटरप्राइज़ जावा बीन्स (EJB) का उपयोग करना कितना सुखद था। उस समय, यह एक अच्छे विचार की तरह लग रहा होगा। नकल से बचने के लिए अपना कोड अन्य टीमों के साथ साझा करना भी अच्छा लगता है। हां, सभी टीमों को यह सुनिश्चित करने के लिए एक ही समय में अपने आवेदन पत्र को रोल आउट करने के लिए मजबूर किया गया था कि बाइनरी निर्भरताएं नहीं टूटीं, लेकिन यह मजेदार शाम थी - 2 घंटे के लिए आवेदन के इंतजार में सहकर्मियों के साथ पिज्जा खाने, सही?

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

एक बार जब आपको पता चलता है कि ये शुरुआती निर्णय कितने उलझे हुए हैं, तो आपके आवेदन को बाकी दुनिया से अलग करने के लिए आवश्यक प्रयास बहुत बड़ा है। आप देखते हैं, शाब्दिक अर्थों में, आपकी परियोजना को विभिन्न घटकों में स्लाइस करने में वर्षों लगेंगे ताकि अन्य अनुप्रयोग अब आपके विषय क्षेत्र, आपके ग्राहक या कैशिंग तंत्र के मूल का उपयोग न कर सकें; बाहरी कॉल के लिए सभी कॉल को हटाने के लिए जो अन्य परियोजनाओं के साथ मजबूत जुड़ाव का नेतृत्व करती है; REST API के साथ सभी EJB कॉल को बदलने के लिए ... हालांकि, इन सभी प्रयासों के लिए, परियोजना से जुड़े प्रत्येक कर्मचारी को पुरस्कृत से अधिक होगा: विकास और परीक्षण को सरल बनाया जाएगा, वितरण प्रक्रिया में तेजी आएगी, क्योंकि अब आपके काम को किसी और के साथ सिंक्रनाइज़ करने की कोई आवश्यकता नहीं है ; अपने स्वयं के कोड में अवधारणाएं बेहतर रूप से अलग हो जाएंगी; निर्भरता प्रबंधन को सरल बनाया जाएगा, जब आप अपने क्लासपाथ में अन्य अनुप्रयोगों की निर्भरता का एक गुच्छा आयात करेंगे तो ट्रांजेक्टिव निर्भरता के साथ समस्याएं गायब हो जाएंगी ... इन सभी महंगे बदलावों से टीम के जीवन को बचाया जा सकेगा, और यदि परियोजना के समय पर उन्हें बनाया गया तो उन्हें लागू करना बहुत आसान हो सकता है!

आप किसी और के प्रोजेक्ट के आधार पर अपना प्रोजेक्ट बनाते हैं

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

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

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

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

हम इस परियोजना को खत्म करने में कामयाब रहे, लेकिन इसकी गुणवत्ता एक वास्तविक दर्द थी। कम से कम 40% कोड और डेटाबेस की सामग्री अप्रयुक्त गिट्टी थी, और इस मृत कोड को हटाना प्राथमिकता नहीं थी। मुझे उम्मीद है कि टीम को अंततः अपना कोड अलग करने का अवसर मिला - मुझे नहीं पता, ऐसा होने से पहले मैंने टीम छोड़ दी!

आपके सभी व्यावसायिक तर्क एक नियम प्रबंधन प्रणाली के अंदर संग्रहीत हैं

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

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

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

यदि यह पहले से ही एक समस्या की तरह लगता है, तो यहां कुछ और है: किसी भी नियम में इसके उद्देश्य के बारे में बिल्कुल कोई सुराग नहीं था। नियमों को नियम १, नियम २ इत्यादि के नाम दिए गए, कुल मिलाकर १०० से अधिक! और मूल रूप से, प्रत्येक नियम में बिना किसी डोमेन शर्तों के कठिन कोडित मूल्यों की जांच और असाइनमेंट शामिल था। यहां तक ​​कि परियोजना के नाम ने पूरे ईटीएल के उद्देश्य को स्पष्ट नहीं किया।

निष्कर्ष

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

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

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