तीन निश्चित संकेत हैं कि यह आपके ढांचे को काटने का समय है

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

"क्या रूपरेखा, आप किस बारे में बात कर रहे हैं?"

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

WWDC ने हमें जोड़ा

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

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

साइकिल का विकास

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

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

ट्रिगर विस्तार

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



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

इस प्रक्रिया में, अलग-अलग रूपरेखाओं में कोड का हिस्सा निकालने के लिए एक आर्किटेक्चरल सबकास्ट उत्पन्न हुआ। कुल चार थे:

• नेटवर्क (मध्य) परत - यहां नेटवर्क, मॉडल कक्षाएं, एपीआई सेवाओं के साथ सभी काम हैं। यह परत पूरी तरह से स्वचालित रूप से उत्पन्न होती है।
  
• प्राधिकरण
  
• उपयोगिताएँ - उपयोगिताएँ और सहायक
  
• भंडारण - सुरक्षित भंडारण
  

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

• हमने एक पर्याप्त कोड आधार विकसित किया है
• व्यवसाय हमारी (यानी, इसकी) वास्तु आवश्यकताओं को समझने लगा।
• एक उपयुक्त कार्य उत्पन्न हुआ है

नए क्षितिज

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

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

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

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

थोड़ा सा भविष्य

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

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

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

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