साफ अपघटन

इस आलेख में, मैं क्लीन आर्किटेक्चर का उपयोग करते समय उप-विभाजन कार्यों में एक दृष्टिकोण पर विचार करना चाहता हूं।

अपघटन समस्या का सामना नलग्लाइट मोबाइल डेवलपमेंट टीम द्वारा किया गया था और नीचे हमने इसे कैसे हल किया और आखिर में क्या हुआ।

प्रागितिहास

यह 2018 की गिरावट थी, हम एक टेलिकॉम ऑपरेटर के लिए अगला एप्लिकेशन विकसित कर रहे थे। लेकिन यह समय अलग था। ग्राहक के विपणन अभियान के लिए शर्तें काफी चुस्त और बंधी हुई थीं। Android टीम 3 से 6-7 डेवलपर्स से बढ़ी है। स्प्रिंट में कई कार्य किए गए थे और सवाल यह था कि उन्हें प्रभावी ढंग से कैसे विघटित किया जाए।

जब हम प्रभावी ढंग से बोलते हैं तो हमारा क्या मतलब होता है:

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

हमने समस्या का समाधान कैसे किया?

हम सभी उप-प्रकारों को निम्न प्रकारों में विभाजित करते हैं:

• डेटा
• डोमेन
• खाली
• यूआई
• मद
• रिवाज
• एकीकरण

डेटा और डोमेन क्लीन आर्किटेक्चर में परतों के अनुरूप है।
खाली, UI, आइटम और कस्टम प्रस्तुति परत को देखें।
एकीकरण डोमेन और प्रस्तुति परतों दोनों पर लागू होता है।


_{चित्रा 1. स्वच्छ वास्तुकला परतों के सापेक्ष कार्यों का स्थान}

आइए प्रत्येक प्रकार को व्यक्तिगत रूप से देखें।

डेटा

डीटीओ, एपीआई, डेटाबेस, डेटासोर्स, आदि के साथ काम करने का विवरण

डोमेन

रिपॉजिटरी इंटरफ़ेस, बिज़नेस मॉडल, इंटरेक्टर्स का विवरण।

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

यूआई

यदि कोई हो, तो बेसिक स्क्रीन लेआउट और अतिरिक्त स्टेट्स बनाना।

मद

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

खाली

Ui या आइटम जैसे कार्यों के लिए आवश्यक आधार कक्षाएं: PresentationModel, Framgent, Layout, DI मॉड्यूल, AdapterDelagate factory। बाइंडिंग इंटरफेस और कार्यान्वयन। स्क्रीन पर एक एंट्री पॉइंट बनाएं।

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

रिवाज

एक गैर-मानक यूआई घटक का कार्यान्वयन।

यूआई के कार्य से एक नए घटक के विकास को अलग करने के लिए एक अतिरिक्त प्रकार की आवश्यकता होती है।

एकीकरण

डोमेन और प्रस्तुति परतों का एकीकरण।

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

कार्य आदेश

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

डेटा टास्क के बाद डोमेन टास्क को अंजाम दिया जाता है।

खाली कार्य के बाद ui और आइटम कार्य।

एकीकरण कार्य पूरा होना अंतिम है क्योंकि इसके लिए पिछले सभी कार्यों को पूरा करने की आवश्यकता होती है।


_{चित्रा 2. समयरेखा कार्य निष्पादन}

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


_{चित्रा 3. ताले के साथ कार्य करने की समयरेखा}

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

प्रक्रिया स्वचालन और सांख्यिकी संग्रह

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

स्वचालन के लिए, हम एक समाधान खोजने में भी कामयाब रहे। चूंकि कार्य विशिष्ट हैं, इसलिए जीरा में उनका वर्णन अलग होना चाहिए। हमने सारांश और विवरण के लिए टेम्पलेट्स विकसित किए। सबसे पहले यह सिर्फ एक json फाइल थी, इस फाइल का Python parser, और Jira REST API कार्यों को जनरेट करने के लिए जुड़ा था।

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

हो सकता है कि MVP ओवरहेड था, लेकिन जब Tkinter पर पहले संस्करण ने MacOS संस्करण 10.14.6 को क्रैश कर दिया और सभी टीमें एप्लिकेशन का उपयोग नहीं कर सकीं, तो हमने आसानी से आधे दिन में PyQt के लिए दृश्य को फिर से लिखा और यह काम कर गया। एक बार फिर, हम आश्वस्त थे कि इस तरह के सरल कार्यों के लिए वास्तुशिल्प दृष्टिकोण का उपयोग, इसके फायदे हैं। JiraSubTaskCreator का एक स्क्रीनशॉट चित्र 4 में दिखाया गया है।


_{चित्रा 4. मुख्य JiraSubTaskCreator स्क्रीन}

निष्कर्ष

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