कॉपी-पेस्ट से घटकों तक: विभिन्न अनुप्रयोगों में कोड का पुन: उपयोग करना

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

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

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

लेकिन पहले, आइए उन समस्याओं पर ध्यान दें, जिनके समाधान से सामान्य घटकों का निर्माण हुआ। उनमें से कई थे:

• अनुप्रयोगों के बीच कॉपी-पेस्ट;
  
• प्रक्रियाएं जो पहियों में चिपक जाती हैं;
  
• परियोजनाओं की विभिन्न वास्तुकला।
  

यह लेख AppsConf 2019 के साथ मेरी रिपोर्ट का एक पाठ संस्करण है, जिसे यहां देखा जा सकता है ।

समस्या: कॉपी पेस्ट

कुछ समय पहले, जब पेड़ मुरझाये हुए थे, घास की हरियाली थी, और मैं एक साल छोटा था, हम अक्सर निम्न स्थिति रखते थे।

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

समस्या यह है कि हमारे सभी एप्लिकेशन विभिन्न रिपॉजिटरी में हैं।



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

इस स्थिति में, आंद्रेई या तो अपना निर्णय (जो कि 80% मामलों में होता है) लिखेगा या लायोशा के समाधान को कॉपी-पेस्ट करेगा और इसमें सब कुछ बदल देगा ताकि यह उसके आवेदन, कार्य या मनोदशा पर फिट बैठे।



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

यह स्थिति कई समस्याएं लाती है।

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

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

तीसरा, एप्लिकेशन आर्किटेक्चर बहुत अलग है: एमवीपी से एमवीआई तक, ईश्वर गतिविधि से एकल गतिविधि तक।

ठीक है, "कार्यक्रम का मुख्य आकर्षण": आवेदन विभिन्न रिपॉजिटरी में हैं, प्रत्येक की अपनी प्रक्रियाएं हैं।

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

निर्णय: हम प्रक्रियाएं स्थापित करते हैं

उपरोक्त समस्याओं में से, दो प्रक्रियाओं से संबंधित हैं:

1. दो रिपोजिटरी जो एक अभेद्य दीवार के साथ परियोजनाएं साझा करती हैं।
   
2. स्थापित संचार और उत्पाद अनुप्रयोग टीमों की विभिन्न आवश्यकताओं के बिना अलग-अलग टीम।
   

आइए पहले से शुरू करें: हम एक ही मॉड्यूल संस्करण के साथ दो रिपॉजिटरी के साथ काम कर रहे हैं। सैद्धांतिक रूप से, हम git-subtree या इसी तरह के समाधान का उपयोग कर सकते हैं और आम प्रोजेक्ट मॉड्यूल को अलग-अलग रिपॉजिटरी में डाल सकते हैं।



संशोधन के दौरान समस्या होती है। ओपन-सोर्स प्रोजेक्ट्स के विपरीत, जिनके पास स्थिर एपीआई है और बाहरी स्रोतों के माध्यम से वितरित किए जाते हैं, अक्सर आंतरिक घटकों में परिवर्तन होते हैं जो सब कुछ तोड़ देते हैं। सबट्री का उपयोग करते समय, इस तरह के प्रत्येक प्रवास में दर्द होता है।

IOS टीम के मेरे सहयोगियों के पास भी ऐसा ही अनुभव है, और यह बहुत सफल नहीं हुआ, क्योंकि एंटोन शुकिन ने पिछले साल मोबियस सम्मेलन में बात की थी।

अध्ययन करने और उनके अनुभव को समझने के बाद, हमने एक एकल भंडार पर स्विच किया। सभी Android एप्लिकेशन अब एक ही स्थान पर हैं, जिससे हमें कुछ लाभ मिलते हैं:

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

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

दूसरी समस्या - टीमों के बीच बातचीत - कई भागों से मिलकर बनी:

• स्थापित संचार के बिना अलग टीमों;
  
• सामान्य मॉड्यूल के लिए जिम्मेदारी का अप्रत्यक्ष वितरण;
  
• उत्पाद टीमों की विभिन्न आवश्यकताओं।
  

इसे हल करने के लिए, हमने टीमों का गठन किया जो प्रत्येक एप्लिकेशन में कुछ कार्यक्षमता के कार्यान्वयन में लगे हुए हैं: उदाहरण के लिए, चैट या पंजीकरण। विकास के अलावा, वे इन घटकों को अनुप्रयोग में एकीकृत करने के लिए भी जिम्मेदार हैं।

उत्पाद टीमों के पास पहले से ही उनके हाथ में मौजूदा घटक हैं, उन्हें सुधारने और किसी विशेष परियोजना की जरूरतों को अनुकूलित करने के लिए।

इस प्रकार, अब एक पुन: प्रयोज्य घटक का निर्माण पूरी कंपनी के लिए प्रक्रिया का हिस्सा है, विचार के चरण से उत्पादन की शुरुआत तक।

समाधान: वास्तुकला को सुव्यवस्थित करना

पुन: उपयोग की दिशा में हमारा अगला कदम वास्तुकला को सुव्यवस्थित करना था। हमने ऐसा क्यों किया?

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

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

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



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

आइए एक साधारण स्क्रीन के उदाहरण को देखें कि यह वास्तविकता में कैसा दिखता है।



हम मूल RxJava इंटरफेस का उपयोग उन तत्वों को इंगित करने के लिए करते हैं जिनके साथ तत्व काम करता है। इनपुट इंटरफ़ेस उपभोक्ता <टी>, आउटपुट - ऑब्जर्वेबल सोर्स <टी> द्वारा दर्शाया गया है।

// input = Consumer<ViewModel> // output = ObservableSource<Event> class View( val events: PublishRelay<Event> ): ObservableSource<Event> by events, Consumer<ViewModel> { val button: Button val textView: TextView init { button.setOnClickListener { events.accept(Event.ButtonClick) } } override fun accept(model: ViewModel) { textView.text = model.text } } 

इन इंटरफेस का उपयोग करके, हम View को Consumer <ViewModel> और ObservableSource <Event> के रूप में व्यक्त कर सकते हैं। ध्यान दें कि ViewModel में केवल स्क्रीन की स्थिति होती है और इसका MVVM के साथ बहुत कम संबंध होता है। मॉडल प्राप्त करने के बाद, हम इससे डेटा दिखा सकते हैं, और जब हम बटन पर क्लिक करते हैं, तो हम ईवेंट भेजते हैं, जो बाहर प्रसारित होता है।

 // input = Consumer<Wish> // output = ObservableSource<State> class Feature: ReducerFeature<Wish, State>( initialState = State(counter = 0), reducer = ReducerImpl() ) { class ReducerImpl: Reducer<Wish, State> { override fun invoke(state: State, wish: Wish) = when (wish) { is Increment -> state.copy(counter = state.counter + 1) } } } 

सुविधा पहले से ही हमारे लिए ऑब्जर्वेबल सोर्स और उपभोक्ता को लागू करती है; हमें वहां प्रारंभिक अवस्था (0 के बराबर काउंटर) को स्थानांतरित करने की आवश्यकता है और इंगित करें कि इस स्थिति को कैसे बदलना है।

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

दो तत्वों को बनाने के बाद, उन्हें जोड़ना हमारे लिए शेष है।

 val eventToWish: (Event) -> Wish = { when (it) { is ButtonClick -> Increment } } val stateToModel: (State) -> ViewModel = { ViewModel(text = state.counter.toString()) } Binder().apply { bind(view to feature using eventToWish) bind(feature to view using stateToModel) } 

पहले, हम इंगित करते हैं कि हम एक प्रकार के तत्व को दूसरे में कैसे बदलते हैं। तो, ButtonClick Increment बन जाता है, और राज्य का काउंटर फ़ील्ड टेक्स्ट में चला जाता है।

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

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

अंग

अंत में, हम घटकों पर चलते हैं। वे क्या पसंद हैं?

एप्लिकेशन में स्क्रीन पर विचार करें और इसे तार्किक भागों में विभाजित करें।



इसे प्रतिष्ठित किया जा सकता है:

• शीर्ष पर लोगो और बटन के साथ टूलबार;
  
• एक प्रोफ़ाइल और लोगो के साथ एक कार्ड;
  
• इंस्टाग्राम सेक्शन।
  

इन भागों में से प्रत्येक बहुत ही घटक है जिसे पूरी तरह से अलग संदर्भ में पुन: उपयोग किया जा सकता है। तो, इंस्टाग्राम अनुभाग एक अन्य एप्लिकेशन में प्रोफ़ाइल संपादन का हिस्सा बन सकता है।



सामान्य मामले में, एक घटक कई व्यू, लॉजिक तत्व और नेस्टेड घटक हैं, जो सामान्य कार्यक्षमता द्वारा एकजुट होते हैं। और तुरंत सवाल उठता है: उन्हें एक समर्थित संरचना में कैसे इकट्ठा किया जाए?

पहली समस्या जो हमें मिली, वह यह है कि MVICore तत्वों को बनाने और बाँधने में मदद करता है, लेकिन एक सामान्य संरचना प्रदान नहीं करता है। एक सामान्य मॉड्यूल से तत्वों का पुन: उपयोग करते समय, यह स्पष्ट नहीं है कि इन टुकड़ों को एक साथ कहां रखा जाए: आम हिस्से के अंदर या आवेदन पक्ष पर?

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

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

 object SomeScopedComponent : ScopedComponent<SomeComponent>() { override fun create(): SomeComponent { return DaggerSomeComponent.builder() .build() } override fun SomeComponent.subscribe(): Array<Disposable> = arrayOf( Binder().apply { bind(feature().news to otherFeature()) bind(feature() to view()) } ) } 

एक साथ दो स्थानों पर समस्याएं शुरू हुईं:

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

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



इस समस्या को हल करने के बाद, हमने तत्वों को जोड़ने की जिम्मेदारी साझा की। लेकिन हमने अभी भी स्क्रीन पर घटकों को साझा किया है, जो स्पष्ट रूप से हमारे लिए हाथ में नहीं था, जिसके परिणामस्वरूप एक ही स्थान पर बड़ी संख्या में निर्भरताएं थीं।

 @Scope internal class ComponentImpl @Inject constructor( private val params: ScreenParams, news: NewsRelay, @OnDisposeAction onDisposeAction: () -> Unit, globalFeature: GlobalFeature, conversationControlFeature: ConversationControlFeature, messageSyncFeature: MessageSyncFeature, conversationInfoFeature: ConversationInfoFeature, conversationPromoFeature: ConversationPromoFeature, messagesFeature: MessagesFeature, messageActionFeature: MessageActionFeature, initialScreenFeature: InitialScreenFeature, initialScreenExplanationFeature: InitialScreenExplanationFeature?, errorFeature: ErrorFeature, conversationInputFeature: ConversationInputFeature, sendRegularFeature: SendRegularFeature, sendContactForCreditsFeature: SendContactForCreditsFeature, screenEventTrackingFeature: ScreenEventTrackingFeature, messageReadFeature: MessageReadFeature?, messageTimeFeature: MessageTimeFeature?, photoGalleryFeature: PhotoGalleryFeature?, onlineStatusFeature: OnlineStatusFeature?, favouritesFeature: FavouritesFeature?, isTypingFeature: IsTypingFeature?, giftStoreFeature: GiftStoreFeature?, messageSelectionFeature: MessageSelectionFeature?, reportingFeature: ReportingFeature?, takePhotoFeature: TakePhotoFeature?, giphyFeature: GiphyFeature, goodOpenersFeature: GoodOpenersFeature?, matchExpirationFeature: MatchExpirationFeature, private val pushIntegration: PushIntegration ) : AbstractMviComponent<UiEvent, States>( 

इस स्थिति में सही समाधान घटक को तोड़ना है। जैसा कि हमने ऊपर देखा, प्रत्येक स्क्रीन में कई तार्किक तत्व होते हैं जिन्हें हम स्वतंत्र भागों में विभाजित कर सकते हैं।

थोड़ा प्रतिबिंब के बाद, हम एक पेड़ की संरचना में आए और, मौजूदा घटकों से भोलेपन से इसका निर्माण किया, हमें यह योजना मिली:



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



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

इस प्रकार, पिछले पुनरावृत्तियों की तुलना में, हमें यह मिलता है:

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

बेशक, यह सभी से दूर है। GitHub पर भंडार में अधिक विस्तृत और अद्यतित विवरण शामिल है।

और यहाँ हमारे पास एक आदर्श दुनिया है। इसमें ऐसे घटक हैं जिनसे हम एक पूरी तरह से पुन: प्रयोज्य पेड़ का निर्माण कर सकते हैं।

लेकिन हम एक अपूर्ण दुनिया में रहते हैं।

वास्तविकता में आपका स्वागत है!

अपूर्ण दुनिया में, चीजों का एक गुच्छा होता है, जिन्हें हमें अपने साथ रखना होता है। हम निम्नलिखित के बारे में चिंतित हैं:

• विभिन्न कार्यक्षमताओं: सभी एकीकरण के बावजूद, हम अभी भी अलग-अलग आवश्यकताओं के साथ व्यक्तिगत उत्पादों के साथ काम कर रहे हैं;
  
• समर्थन: ए / बी परीक्षणों के तहत नई कार्यक्षमता के बिना कैसे?
  
• विरासत (वह सब कुछ जो हमारी नई वास्तुकला से पहले लिखा गया था)।
  

समाधानों की जटिलता तेजी से बढ़ जाती है, क्योंकि प्रत्येक अनुप्रयोग अपने स्वयं के कुछ को सामान्य घटकों में जोड़ता है।

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

विविध आवश्यकताएं

प्रत्येक एप्लिकेशन की अपनी विशिष्ट पंजीकरण विविधताएं होती हैं, दोनों तर्क पक्ष और UI पक्ष की ओर से। इसलिए, हम एक न्यूनतम में घटक में कार्यक्षमता को सामान्य करना शुरू करते हैं: डेटा डाउनलोड करके और संपूर्ण प्रवाह को रूट करके।



ऐसा कंटेनर सर्वर से डेटा को एप्लिकेशन में स्थानांतरित करता है, जिसे तर्क के साथ समाप्त स्क्रीन में बदल दिया जाता है। केवल आवश्यकता यह है कि इस तरह के कंटेनर को पारित स्क्रीन पूरे प्रवाह के तर्क के साथ बातचीत करने के लिए निर्भरता को पूरा करना चाहिए।

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

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



इसलिए हम यूआई को विभाजित करके तर्क का पुन: उपयोग करते हैं। नतीजतन, समर्थन बहुत अधिक सुविधाजनक हो जाता है।

समर्थन

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



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

एकीकरण

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

एकल गतिविधि अनुप्रयोगों के लिए, बहुत कुछ नहीं बदलता है। लगभग सभी चौखटे अपने मूल तत्वों की पेशकश करते हैं जिसमें आरआईबी घटक खुद को लपेटने की अनुमति देते हैं।

अंत में

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

हमारा अनुभव बताता है कि:

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

मेरे सहयोगी Zsolt Kocsi ने पहले MVICore और इसके पीछे के विचारों के बारे में लिखा था। मैं उनके लेखों को पढ़ने की अत्यधिक सलाह देता हूं, जिनका हमने अपने ब्लॉग ( 1 , 2 , 3 ) पर अनुवाद किया है।

आरआईबी के बारे में, आप उबर का मूल लेख पढ़ सकते हैं। और व्यावहारिक ज्ञान के लिए, मैं हमसे (अंग्रेजी में) कुछ सबक लेने की सलाह देता हूं।