👩🏾‍🤝‍👩🏼 🤰🏿 💺 सिटीमोबिल एप्लिकेशन को फिर से शुरू करने का इतिहास 🔉 👧🏻 🏍️

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

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

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

अगर आपको वास्तव में रिफैक्टरिंग की आवश्यकता है, तो पहली बात यह समझना चाहिए? इस पर विचार किया जाना चाहिए:

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

किसी समस्या के अस्तित्व को महसूस करने के बाद, व्यक्ति को निम्नलिखित प्रश्नों के उत्तर खोजने चाहिए:

क्या, वास्तव में, गलत है?
इसके कारण क्या हुआ?
इसे फिर से होने से रोकने के लिए क्या किया जाना चाहिए?
कैसे करें स्थिति को ठीक?

एक निश्चित आर्किटेक्चर बिछाने के बिना एक अच्छा लंबे समय तक चलने वाली परियोजना का निर्माण करना लगभग असंभव है। हमारी परियोजना में, हमने "स्तरित" वास्तुकला शुरू करने का फैसला किया, जो पहले से ही अच्छी तरह से साबित हो चुका है।

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

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

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

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

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

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

<!-- android:name=".SplashActivity" - old launcher activity --> <!-- android:targetActivity=".cleanarchitecture.presentation.SplashActivity" - new launcher activity --> <activity-alias android:name=".SplashActivity" android:targetActivity=".cleanarchitecture.presentation.SplashActivity"> <intent-filter> <action android:name="android.intent.action.MAIN"/> <category android:name="android.intent.category.LAUNCHER"/> </intent-filter> </activity-alias>

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

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

आवेदन के अगले भाग को फिर से लिखने के बाद, हमने आवेदन के पुराने भाग में कोड के खंडों की खोज की और उन्हें @Deprecated एनोटेशन और इन के एनालॉग्स के साथ चिह्नित किया: https://github.com/VitalyNikonorov-UsefulAnnotation । उनमें हमने संकेत दिया कि कार्यक्रम के इस भाग को पुनर्लेखन करते समय क्या किया जाना चाहिए, क्या कार्यशीलता और कहां इसे लागू किया गया है।

 /** * This class deprecated, you have to use * com.project.company.cleanarchitecture.utils.ResourceUtils * for new refactored classes */ @Deprecated public class ResourceHelper {...}

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

रिफैक्टिंग के बाद, एप्लिकेशन की कार्यक्षमता में परिवर्तन बहुत आसान हो गया। इसलिए, हाल ही में हम फिर से प्राधिकरण स्क्रीन के प्रसंस्करण में लगे हुए थे।

प्रारंभ में, वे इस प्रकार दिखे:

पहले प्रसंस्करण और रीफैक्टरिंग के बाद, वे इस तरह दिखने लगे:

अब वे इस तरह दिखते हैं:

नतीजतन, पहले पुनरावृत्ति ने दूसरे के रूप में दो बार से अधिक समय लिया। चूंकि यूआई को संसाधित करने के अलावा, मुझे उसी स्थान पर स्थित व्यावसायिक तर्क कोड को समझना था, हालांकि यह आवश्यक नहीं था, लेकिन दोष को समाप्त कर दिया गया था, जिसने दूसरी पुनरावृत्ति में कार्य पर खर्च किए गए समय को कम कर दिया।

फिलहाल हमारे पास क्या है?

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

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

विरासत कोड रीफैक्टरिंग से संबंधित कई और दिलचस्प बिंदु हैं। अगर पाठकों की दिलचस्पी होगी, तो मैं अगली बार उनके बारे में और लिखूंगा। मुझे भी खुशी होगी अगर आप भी अपना अनुभव साझा करें।

सिटीमोबिल एप्लिकेशन को फिर से शुरू करने का इतिहास

More articles: