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

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

बाकी सभी के लिए, कहानी मोबाइल स्पीचकट टीम के जीवन से वास्तविक कहानियों से भरी होगी, इसलिए यह मजेदार होना चाहिए।

सामग्री

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

भाषण मिनट

मैं यह नहीं पूछूंगा कि क्या आपने स्पीचकिट के बारे में सुना है, क्योंकि यैंडेक्स के अंदर भी, हर कोई नहीं जानता कि यह क्या है।

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

आपने शायद आवाज सहायक ऐलिस के बारे में सुना - वह सिर्फ स्पीचकिट के आधार पर काम करती है। स्पीचकिट में स्वयं मान्यता या संश्लेषण शामिल नहीं है, यह सर्वर पर होता है। लेकिन यह हमारे पुस्तकालय के माध्यम से है कि सब कुछ आवेदन में एकीकृत किया जा सकता है।

निम्नलिखित आमतौर पर सवाल आता है - अगर सर्वर पर सब कुछ होता है, तो पुस्तकालय क्या करता है? इसकी आवश्यकता क्यों है?

पुस्तकालय बहुत कुछ करता है:

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

SpeechKit का उपयोग आंतरिक टीमों में किया जाता है। अब इसे 16 यैंडेक्स टीमों द्वारा एकीकृत किया गया है। और हम कई बाहरी टीमों के बारे में भी जानते हैं जिन्होंने ऐसा किया।

डिज़ाइन

आइए एक सुविधाजनक एप्लिकेशन द्वारा हमारे बारे में सोचें। आमतौर पर, यह एक विचारशील और समझने योग्य यूएक्स है, हमारी समस्याओं का समाधान, स्थिर संचालन, आदि।

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

मूल सिद्धांत

ये कुछ पहलू हैं जो मैंने अपने अनुभव से स्पीचकिट के साथ सीखे हैं।

• सबसे पहले, याद रखें कि आपके उपयोगकर्ता डेवलपर्स हैं ।
  

एक तरफ, यह अच्छा है, क्योंकि आप आम उपयोगकर्ताओं को नहीं समझाते हैं: "आप देखते हैं, बैकएंड हमारे साथ है, और इसलिए कुछ भी काम नहीं करता है, और हम ठीक हैं!" आप इसे डेवलपर्स को समझा सकते हैं - आप डेवलपर्स को बहुत कुछ समझा सकते हैं!

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

इसके अलावा, तथ्य यह है कि उपयोगकर्ता डेवलपर्स हैं इसका मतलब है कि आपके पास हमेशा कैसे विकास और कैसे सब कुछ बेहतर बनाने के लिए युक्तियों और चाल का पहाड़ होगा।

दूसरा महत्वपूर्ण बिंदु पहले के साथ पूरी तरह से संगत है।

• आपके पुस्तकालय में जो कुछ भी अनुमति नहीं है, उसे निषिद्ध किया जाना चाहिए,
  ताकि अवांछित खामियां न हों।
  

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

• अपने पुस्तकालय के एपीआई की व्याख्या में अस्पष्टता की अनुमति न दें।
  

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

केस स्पीचकिट एपीआई

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

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

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

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

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

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

नीचे एक उदाहरण है कि कैसे मुख्य वर्ग जो मान्यता से संबंधित है, रिफैक्टिंग करने से पहले जैसा दिखता था।

// SpeechKit v2 @interface YSKRecognizer: NSObject @property (nonatomic, strong, readonly, getter=getModel) NSString* model; @property (nonatomic, assign, getter=isVADEnabled) BOOL VADEnabled; - (instancetype)initWithLanguage:(NSString *)language model:(NSString *)m; - (void)start; - (void)cancel; - (void)cancelSync; @end @interface YSKInitializer: NSObject - (instancetype)init; - (void)dealloc; - (void)start; + (BOOL)isInitializationCompleted; @end extern NSString *const YSKInactiveTimeout; extern NSString *const YSKVADEnabled; @interface YSKSpeechKit: NSObject + (instancetype)sharedInstance; – (void)setParameter:(NSString *)name withValue:(NSString *)value; @end 

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

फिर, बनाते समय, दो पंक्तियाँ (भाषा और मॉडल) इसके पास जाती हैं। ये लाइनें क्या हैं? यदि आप "हैलो, वर्ल्ड" भाषा में पास करते हैं, तो आउटपुट अनुवाद होगा, या क्या? बहुत स्पष्ट नहीं है।

इसके अतिरिक्त, चूंकि यह NSObject का उत्तराधिकारी है, इसलिए हम इस पर init, new इत्यादि कह सकते हैं। क्या होगा? क्या यह काम करेगा, या यह कुछ मापदंडों का इंतजार करेगा?

बेशक, मैं इन सवालों के जवाब जानता हूं, मुझे यह कोड पता है। लेकिन जो लोग पहली बार इसे देख रहे हैं, उन्हें यह बिल्कुल भी समझ नहीं आ रहा है कि यह सब क्यों है। यहां तक ​​कि सेटर और गेट्टर के तरीकों में भी वह नहीं दिखता है जो आईओएस में दिखता है। प्रारंभ, रद्द करें, रद्द करेंSSync विधियाँ (और जो अभी-अभी रद्द हुई है - क्या यह aSync है?) - यदि उन्हें एक साथ बुलाया जाए तो क्या होगा? इस कोड में बहुत सारे प्रश्न।

इसके बाद वह वस्तु आती है जिसके बारे में मैंने (YSKInitializer) बात की थी, जिसे हर काम के लिए शुरू किया जाना चाहिए - यह आमतौर पर किसी प्रकार का जादू है। यह देखा जा सकता है कि यह कोड डेवलपर्स द्वारा लिखा गया था जो iOS के लिए नहीं लिखते हैं, लेकिन C ++ में लगे हुए हैं।

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

थान v3 v2 से बेहतर है

जब हमने रिफैक्ट किया और संस्करण 3 पर स्विच किया तो हमें क्या मिला?

• पूरी तरह से देशी एपीआई।
  

अब हमारा iOS API iOS-API की तरह लग रहा था, Android API Android की तरह लग रहा था।

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

उदाहरण के लिए, एंड्रॉइड के लिए कक्षाएं बिल्डरों का उपयोग करके बनाई गई हैं, क्योंकि यह एंड्रॉइड डेवलपर्स के लिए एक बहुत ही समझने योग्य पैटर्न है। आईओएस में, यह इतना लोकप्रिय नहीं है, इसलिए एक अलग दृष्टिकोण का उपयोग किया जाता है: हम एक विशेष वर्ग की सेटिंग्स के साथ ऑब्जेक्ट बनाते हैं।

मुझे याद है कि हमने इस विषय पर लंबे समय तक बहस की थी। यह हमारे लिए महत्वपूर्ण था कि डेवलपर हमारे कोड को iOS या Android पर ले, और मैच 99% होगा। लेकिन ऐसा है नहीं। बेहतर, कोड उस प्लेटफॉर्म के समान होगा जिसके लिए इसे विकसित किया जा रहा है।

• सरल और सहज प्रारंभिक ।
  

इस ऑब्जेक्ट की आवश्यकता है - यहां इसकी सेटिंग्स हैं, उन्हें बनाएं, उन्हें स्थानांतरित करें - लाभ! यही है, कोई छिपी हुई वैश्विक सेटिंग्स नहीं हैं जिन्हें कहीं स्थानांतरित करने की आवश्यकता है।

• वैश्विक घटकों की कमी।
  

हमने वैश्विक घटकों को फेंक दिया, जो भ्रमित हो गए, डर गए और इस लाइब्रेरी के डेवलपर्स के बीच भी बहुत सारे सवाल पैदा हुए, न केवल उपयोगकर्ताओं को।

अब नए संस्करण में एक ही वर्ग इस तरह दिखता है (यह अभी भी उद्देश्य-सी है - आप तब स्विफ्ट पर स्विच नहीं कर सकते)।

 // SpeechKit v3 NS_ASSUME_NONNULL_BEGIN __attribute__((objc_subclassing_restricted)) @interface YSKOnlineRecognizer: NSObject<YSKRecognizing> @property (nonatomic, copy, readonly) YSKOnlineRecognizerSettings *settings; - (instancetype)initWithSettings:(YSKOnlineRecognizerSettings *)s audioSource:(id<YSKAudioSource>)as NS_DESIGNATED_INITIALIZER; + (instancetype)new __attribute__((unavailable("Use designated initializer."))); - (instancetype)init __attribute__((unavailable("Use designated initializer."))); @end NS_ASSUME_NONNULL_END @protocol YSKRecognizing <NSObject> - (void)prepare; - (void)startRecording; - (void)cancel; @end @interface YSKOnlineRecognizerSettings: NSObject<NSCopying> @property (nonatomic, copy, readonly) YSKLanguage *language; @property (nonatomic, copy, readonly) YSKOnlineModel *model; @property (nonatomic, assign) BOOL enableVAD; - (instancetype)initWithLanguage:(YSKLanguage *)l model:(YSKOnlineModel *)m NS_DESIGNATED_INITIALIZER; @end @interface YSKLanguage: YSKSetting + (instancetype)russian; + (instancetype)english; @end 

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

इसके अलावा, हमने यहां से ऑडियो के साथ काम को हटा दिया है, अर्थात, टोही अब वह घटक नहीं है जो ऑडियो लिखता है। यह घटक मान्यता मुद्दों से संबंधित है, और किसी भी स्रोत को यहां स्थानांतरित किया जा सकता है।

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

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

मैक्रोज़ NS_ASSUME_NONNULL_BEGIN / NS_ASSUME_NONNULL_END इस बात पर जोर देने के लिए कि ये सेटिंग्स शून्य नहीं हो सकती हैं: ऑडियो स्रोत शून्य नहीं हो सकता है - काम करने के लिए यह सभी कुछ विशिष्ट मूल्य होना चाहिए।

जैसा कि मैंने कहा, प्रारंभ और रद्द करने के तरीके (कैंसलसिंक शेष) एक अलग प्रोटोकॉल में चले गए। पुस्तकालय में ऐसे स्थान हैं जहां आप हमारे टोही का उपयोग नहीं कर सकते हैं, लेकिन किसी भी अन्य। उदाहरण के लिए, हम Apple के मूल का उपयोग करते हैं, जो इस प्रोटोकॉल को लागू करता है और जिसमें यह हमारे घटकों को स्थानांतरित कर सकता है।

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

सेट के बाकी के बारे में 20 पहचानकर्ता की सेटिंग्स यहाँ सेट कर रहे हैं। यहां तक ​​कि किसी भाषा या मॉडल की सेटिंग्स भी अलग-अलग वर्ग हैं जो हमें कुछ सार बताने की अनुमति नहीं देते हैं, जिसके साथ हम काम करने में सक्षम नहीं हैं। यही है, हम स्पष्ट रूप से कहते हैं: “कृपया हमें कुछ ऐसा न दें जो हमें पता नहीं है कि हमें कैसे काम करना है। संकलक आपको ऐसा नहीं करने देगा। ”

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

डिज़ाइन

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

कोड सिर्फ अपने लिए नहीं है

डिबग जानकारी एकत्र करना पूरी तरह से आवश्यक है, क्योंकि आप नहीं चाहते कि उपयोगकर्ता यह कहें कि आपकी लाइब्रेरी के कारण उनकी सेवा काम नहीं कर रही है।

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

यह Xcode सेटिंग्स (Build Settings) में शामिल है, और इसे डीबग सूचना स्तर कहा जाता है। उदाहरण के लिए, इस सेटिंग को चालू करके, हमने स्पीचकिट बाइनरी फाइल का आकार 600 एमबी से घटाकर 90 एमबी कर दिया। यह बहुत आवश्यक जानकारी नहीं है और हमने इसे दूर फेंक दिया।

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

चरित्र संघर्षों से बचें : अपनी कक्षाओं में, अपनी कक्षाओं में, अपनी हर चीज़ में उपसर्ग जोड़ें। यदि लाइब्रेरी में एक श्रेणी UIColor + HEX है, तो सुनिश्चित करें कि आपके उपयोगकर्ताओं के पास समान श्रेणी है, और जब वे आपकी लाइब्रेरी को एकीकृत करते हैं, तो उन्हें चरित्र संघर्ष प्राप्त होंगे। और फिर, हर कोई आपको बताना और ऐसा नहीं चाहेगा।

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

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

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

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

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

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

इससे निष्कर्ष यह है: सभी समान हैं, वैश्विक संस्थाओं का उपयोग न करने की कोशिश करें, लेकिन इस तथ्य के लिए तैयार रहें कि आपके उपयोगकर्ता हमेशा आपके निर्णयों से खुश नहीं होंगे।

हम इसे उपयोगकर्ताओं के लिए सुविधाजनक बनाते हैं

आप अपने उपयोगकर्ताओं की सहायता कैसे कर सकते हैं?

• लॉग जोड़ें: विभिन्न स्तर, गतिशील समावेश ।
  

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

• सभी उपयोगकर्ता OS संस्करणों का समर्थन करें।
  

याद रखें कि जब आप किसी लाइब्रेरी में संस्करण समर्थन के बारे में बात करते हैं, तो यह नियमित अनुप्रयोग में संस्करण समर्थन के समान नहीं है। एक नियमित अनुप्रयोग में, हम उन आंकड़ों को देखते हैं, उदाहरण के लिए, हमारे केवल 2% उपयोगकर्ता iOS 8 का उपयोग करते हैं, और इसका मतलब है कि आप iOS 8 का समर्थन करना बंद कर सकते हैं। पुस्तकालय में, ऐसा नहीं है, यहाँ OS संस्करण को अस्वीकार करने का अर्थ है अपने उपयोगकर्ता और सभी उपयोगकर्ताओं को पूरी तरह से छोड़ देना। यह सिद्धांत रूप में आपके आधे उपयोगकर्ता हो सकते हैं।

इसलिए, आपको यह निगरानी करने की आवश्यकता है कि कौन से संस्करण उन अनुप्रयोगों द्वारा उपयोग किए जाते हैं जो आपके पुस्तकालय का उपयोग करते हैं, और इसके आधार पर, आपको पहले से ही निष्कर्ष निकालना चाहिए कि आप कुछ का समर्थन करते हैं या नहीं। हमने बहुत लंबे समय के लिए iOS 7 का परित्याग नहीं किया है। मुझे ऐसा लगता है कि पहले से ही लोग थे जिन्होंने iOS 8 को छोड़ दिया था और iOS 9 को छोड़ने के लिए तैयार थे। हमने अभी भी iOS 7 का समर्थन किया था क्योंकि हमारे पास एक ब्राउज़र था जो आखिरी तक सभी उपयोगकर्ताओं को रखता था। और हम उसके साथ मिलकर काम करते थे और ऐसी स्थिति में उसे छोड़ नहीं सकते थे।

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

• नए संस्करणों में न्यूनतम वेतन वृद्धि जोड़ें।

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

हमारे पास वास्तव में ऐसे मामले थे जब हमने कुछ रिलीज़ वापस किए, उन्हें भागों में विभाजित किया और उन्हें पहले से ही टुकड़ों में विभाजित किया। फिर जिन टीमों के लिए हमने बदलाव लागू किए वे ठीक उसी संस्करण को ले सकते हैं जिसमें छोटे-मोटे बदलाव हों, और एक बार में ही नहीं।

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

बहुत अधिक परीक्षण कभी नहीं होते हैं

यह एक नियमित अनुप्रयोग और पुस्तकालय दोनों के लिए सही है। लेकिन पुस्तकालय के मामले में, फिर से विशेषताएं हैं।

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

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

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

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

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

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

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

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

लांच

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

मैं Yandex के अंदर उपयोगकर्ताओं के लिए स्थानीय रिलीज़ के साथ शुरू करूँगा। यहां योजना एक नियमित अनुप्रयोग के विकास में समान है: नियमित, मासिक या साप्ताहिक रिलीज।

प्रक्रिया में सामान्य चरण होते हैं, लेकिन एक पुस्तकालय विकसित करते समय, इनमें से प्रत्येक बिंदु की अपनी विशेषताएं होती हैं।

आयोजन

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

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

SpeechKit , , , . , , - . , — . , n . , . , , - .

, , : , , . Agile- .

, , , — . , . !

Scrum . , , , . . « », .

Scrum , , , — — , . . — , - . , ? , : «, , , ». , , - , , Scrum . ! , .

. , , . , . , , , , . , . .

, — , - . , , , , . , . : « 4, 3 — ». , . - , , , , .

— . Continuous Integration , , , .

, . .

1. .

— . - - , , , . .

. , — , , , , . , , - .

2. .

, , , — , , , , , !

. , . , , -, .

— . SpeechKit . , , — , - . — , - .

, . , 4 2, , . , -, , .

— . , , , .

. .

, -, . . , , , help , .

. : -, GitHub, , . — , — . , , .

, , - , , ..

, , :

• . , . - , , .
  
• . , . , OpenSource , , , , .
• . , . , , . . SpeechKit .
  

परिणाम

• , API.
  
• , , .
  
• .
  
• , - :) - , .
  

Yandex.SpeachKit GitHub iOS , Android , Mobile SDK.

AppsConf — — 22 23 2019 , , .

. , , .