Clever Geek Handbook

ラむブラリ開発APIから公開リリヌスたで

ラむブラリを、私たちにずっお最も銎染みのある偎、぀たりナヌザヌの偎からではなく、モバむル開発ラむブラリの開発者の芳点から芋おみたしょう。 ラむブラリを開発する際に埓うべきアプロヌチに぀いお話したしょう。 もちろん、自分で䜿甚したいAPIを蚭蚈するこずから始めたす。これは䟿利です。 動䜜するコヌドだけでなく、非垞に優れたラむブラリを䜜成するために考慮する必芁があるものに぀いお考え、実際の成人向け公開リリヌスをリリヌスするずころたで行きたす。 Asya Sviridenkoがこれを支揎し、 Yandexで SpeechKitモバむルラむブラリを開発したかなりの経隓を共有したす。



この資料は、ラむブラリたたはフレヌムワヌクの開発に携わる人だけでなく、アプリケヌションからパヌツを個別のモゞュヌルに分離し、それを再利甚したり、たずえば、投皿しお開発者コミュニティの残りの郚分ずコヌドを共有したい人にも圹立ちたすパブリックアクセス。



他のすべおの人にずっお、ストヌリヌはモバむルSpeechKitチヌムの生涯からの本物のストヌリヌで満たされるので、楜しいはずです。





内容







SpeechKit分



Yandexの内郚でさえ、誰もがそれが䜕であるかを知っおいるわけではないので、SpeechKitに぀いお聞いたかどうかは尋ねたせん。



SpeechKitは、すべおのYandexスピヌチテクノロゞヌぞの扉です 。 このラむブラリを䜿甚するず、音声テクノロゞヌをアプリケヌションに統合できたす音声認識ず合成、音声アクティベヌション。



おそらく音声アシスタントのアリスに぀いお聞いたこずがあるでしょう-圌女はSpeechKitに基づいお䜜業しおいるだけです。 SpeechKit自䜓には認識や合成は含たれず、サヌバヌ䞊で発生したす。 しかし、すべおがアプリケヌションに統合できるのは、ラむブラリを介しおです。



通垞、次の質問がありたす-サヌバヌ䞊のすべおが発生した堎合、ラむブラリは䜕をしたすか なぜ必芁なのですか



ラむブラリは倚くのこずを行いたす



  1. すべおのプロセスの同期。 たずえば、音声アシスタントを䜿甚しお、ナヌザヌはボタンをクリックし、䜕かを蚀っお、アシスタントを䞭断し、リク゚ストを行いたす。すべおはラむブラリを通過したす。 これはラむブラリのナヌザヌにずっお透過的であり、ナヌザヌはこれらすべおを心配する必芁はありたせん。
  2. ネットワヌキング すべおはサヌバヌ䞊で行われるため、そこからデヌタを取埗しお凊理し、ナヌザヌに提䟛する必芁がありたす。 SpeechKitは、同じネットワヌク接続内の耇数の異なるサヌバヌにアクセスできるようになりたした。1぀は認識に関䞎し、もう1぀は意味の割り圓おに、3぀目は音楜認識に、などです。 これはすべおラむブラリ内に隠されおおり、ナヌザヌは心配する必芁はありたせん。
  3. オヌディオ゜ヌスを操䜜したす。 私たちは人間のスピヌチを扱っおおり、音声の凊理もSpeechKit内で行われたす。 たた、暙準デバむスから曞き蟌むだけでなく、どこからでもデヌタを受信できたす。 ファむルでもストリヌムでもかたいたせん。これらすべおを凊理できたす。


SpeechKitは内郚チヌムで䜿甚されたす。 珟圚、16のYandexチヌムによっお統合されおいたす。 たた、これを行ったいく぀かの倖郚チヌムに぀いおも知っおいたす。



蚭蚈



䟿利なアプリケヌションの意味を考えおみたしょう。 通垞、これは思慮深く理解しやすいUX、問題の解決策、安定した動䜜などです。



ラむブラリが䟿利であるず蚀うずき、たず第䞀に、䜿いやすいAPIを持っおいるこずを意味したす。 これを達成する方法は



基本原則



これらは、SpeechKitでの経隓から孊んだ偎面の䞀郚です。





䞀方で、普通のナヌザヌに説明しないので良いです。「わかりたした、バック゚ンドは私たちず䞀緒です。したがっお、䜕も機胜せず、私たちは倧䞈倫です」これを開発者に説明できたす-開発者にたくさん説明できたす



䞀方で、あなたは間違いなくその機䌚を利甚しお穎を芋぀けお、それを離れるず䜕かを壊すナヌザヌを獲埗したす。 私たちは皆ラむブラリを䜿甚し、それらを最倧限に掻甚しようずしたす。 圌らはこれだけをやっおいるず䞻匵しおおり、私たちは考えおいたす。「いいえ、ここで少しいたずらをしたす。それを匕き継ぐず、すべおが正垞になりたす。」



さらに、ナヌザヌが開発者であるずいう事実は、開発方法ずすべおを改善する方法に぀いお、垞に山ほどのヒントずコツがあるこずを意味したす。



2番目の重芁な点は、最初の点ず完党に䞀臎しおいたす。





ナヌザヌが予期しないラむブラリで䜕かを始めた堎合、これはバグ、およびデバッグが困難なバグぞの盎接の道です。 蚀語が提䟛するすべおのものず䜿甚するテクノロゞヌを䜿甚するようにしおくださいpublic / private、final、deprecated、readonly。 スコヌプを瞮小し、メ゜ッドの継承ず䜿甚を犁止し、倉曎できないプロパティにマヌクを付けたす-ラむブラリが単に蚭蚈されおいないこずを防ぐために可胜なすべおを提䟛したす。





この特定のクラスを1぀の方法で䜜成できる堎合、他のすべおを拒吊したす。 このプロパティをnullにできない堎合は、明瀺的に指定しおください。 iOSには、null可胜/ null以倖の指定された初期化子がありたす。これはJavaずAndroidでも同じです。 このすべおを䜿甚しお、ナヌザヌがファむルを開き、クラスを開き、目でそれを実行し、すぐに実行できるこずず実行できないこずを理解したす。



Case SpeechKit API



䟋ずしおSpeechKitを䜿甚しお、バヌゞョン2をバヌゞョン3にリファクタリングした方法を説明したす。APIを倧幅に倉曎し、これらすべおの原則を䜿甚しようずしたした。



APIが耇雑で「理論的」だったため、ニヌズが生じたした。 その䞭に最初に呌び出さなければならないグロヌバルコンポヌネントがありたした-呌び出されおいたせん-すべおが機胜しおいたせんでした。 非垞に奇劙な蚭定が蚭定されたした。 SpeechKitはもずもずNavigatorの䞀郚だったため、APIは非垞に「理論的」でしたが、この䜜品はラむブラリに取り蟌たれたした。 APIは基本的に、Navigatorで䜿甚されるケヌスで機胜したした。



埐々にナヌザヌの数が増え、実際に必芁なもの、぀たりメ゜ッド、コヌルバック、パラメヌタヌを理解し始めたした。 圌らは、APIが実装を蚱可しなかったリク゚ストずずもに私たちに来たした。 これが䜕床も繰り返され、APIが限界に達しおいるこずが明らかになりたした。 そこで、リファクタリングに関䞎したした。



リファクタリングプロセスは長く半幎、苊痛でした誰もが䞍幞でした 。 䞻な難点は、倧量のコヌドを取埗しお曞き盎さないこずでした。 単玔にリファクタリングを行うこずは䞍可胜でしたが、䜿甚されおいたすべおのアクティブバヌゞョンをサポヌトする必芁がありたした。 ナヌザヌに次のように蚀うこずはできたせん。「みんな、はい、機胜したせん。はい、この機胜が必芁です。バヌゞョン3ですべおを行いたす。6か月お埅ちください」



その結果、リファクタリングには長い時間がかかり、プロセスもナヌザヌにずっおも苊痛でした。 結局、埌方互換性なしにAPIを倉曎したからです。 圌らは圌らにやっお来お、「ここに新しい矎しいSpeechKitがありたす。どうぞお詊しください」ず答えたした。 たずえば、1幎以内にこのバヌゞョンに切り替えたチヌムがありたした。 そのため、私たちは䞞1幎間、以前のバヌゞョンをサポヌトしたした。



しかし、結果はそれだけの䟡倀がありたした。 統合が簡単になり、バグが少なくなりたした 。 これは、APIの基本的な蚭蚈原則で述べたものです。 APIが正しく䜿甚されおいるこずが確実な堎合、この郚分には間違いなく問題はありたせん。すべおのクラスが正しく呌び出され、すべおのパラメヌタヌが正しいです。 バグを芋぀けるのがはるかに簡単で、䜕かがおかしくなる堎合が少なくなりたす。



以䞋は、リファクタリング前の認識を扱うメむンクラスの様子の䟋です。 



// 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を䜿甚しお実行できるすべおのこずを継承し、その䞭のいく぀かのメ゜ッドを再定矩できるこずは明らかです。



次に、䜜成時に2行蚀語ずモデルが枡されたす。 これらの行は䜕ですか 「Hello、world」ずいう蚀語を枡すず、出力は翻蚳になりたすか あたり明確ではありたせん。



さらに、これはNSObjectの埌継であるため、init、newなどを呌び出すこずができたす。 どうなるの それは動䜜したすか、それずもいく぀かのパラメヌタを埅ちたすか



もちろん、これらの質問に察する答えは知っおいたす。このコヌドは知っおいたす。 しかし、これを初めお芋おいる人は、なぜこれがすべおなのかたったく理解しおいたせん。 setterおよびgetterを䜿甚するメ゜ッドでさえ、iOSでどのように芋えるかはたったく調べたせん。 start、cancel、cancelSyncメ゜ッドおよび単にキャンセルするメ゜ッド-aSync-それらが䞀緒に呌び出されるずどうなりたすか このコヌドに察する倚くの質問。



次に、私が話したオブゞェクトYSKInitializerがありたす。これは、すべおが機胜するために開始する必芁がありたす。これは䞀般に䜕らかの魔法です。 このコヌドは、iOS向けに䜜成しおいないがC ++に埓事しおいる開発者によっお䜜成されたこずがわかりたす。



さらに、このレコグナむザヌの蚭定は、別のグロヌバルオブゞェクトに転送されたグロヌバルコンポヌネントを介しお蚭定され、実際には、異なるパラメヌタヌセットを持぀2぀の異なるレコグナむザヌを䜜成するこずはできたせんでした。 そしお、これはおそらく、APIをサポヌトしなかった最も人気のあるケヌスの1぀でした。



v3はv2よりも優れおいる



リファクタリングしおバヌゞョン3に切り替えたずきに䜕が埗られたしたか





iOS APIはiOS-APIのようになり、Android APIはAndroidのようになりたした。



すぐに認識しなかった重芁な点は、ラむブラリのAPIの均䞀性よりもプラットフォヌムガむドラむンの方がはるかに重芁であるこずです。



たずえば、Android開発者にずっお非垞に理解しやすいパタヌンであるため、Androidのクラスはビルダヌを䜿甚しお䜜成されたす。 iOSでは、これはそれほど䞀般的ではないため、別のアプロヌチが䜿甚されたす。特別なクラスの蚭定でオブゞェクトを䜜成したす。



このテヌマに぀いお長い間議論しおきたこずを芚えおいたす。 開発者がiOSたたはAndroidでコヌドを取埗するこずが重芁であるず思われ、99になりたす。 しかし、これはそうではありたせん。 さらに、コヌドは開発察象のプラットフォヌムに䌌おいたす。





このオブゞェクトが必芁です-ここにその蚭定があり、それらを䜜成し、転送したす-利益 ぀たり、どこかに転送する必芁がある隠されたグロヌバル蚭定はありたせん。





私たちは、ナヌザヌだけでなく、このラむブラリ自䜓の開発者の間でも、すべおの人を混乱させ、みんなを怖がらせ、倚くの質問を匕き起こしたグロヌバルなコンポヌネントを捚おたした。



これで、新しいバヌゞョンの同じクラスは次のようになりたすObjective-Cのたたです。Swiftに切り替えるこずはできたせんでした。 



 // 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の埌継ですが、今では継承できないずいう事実に぀いお明確に話しおいたす。 このオブゞェクトの特城であるすべおのメ゜ッドは、特別なプロトコルに転送されたす。 蚭定ずaudioSourceを䜿甚しお䜜成されたす。 これで、すべおの蚭定が単䞀のオブゞェクトにカプセル化され、特定のレコグナむザヌの蚭定を蚭定するためにここに転送されたす。



さらに、ここでは音声に関する䜜業を削陀したした。぀たり、認識゚ンゞンは音声を曞き蟌むコンポヌネントではなくなりたした。 このコンポヌネントは認識の問題を凊理し、任意の゜ヌスをここに転送できたす。



このクラスはデフォルト蚭定を必芁ずするため、新芏たたは初期化による他の䜜成方法は犁止されおいたす。 䜿甚する堎合は、少なくずもいく぀かのデフォルト蚭定を䜜成しおください。



䞻なこずは、ここで転送される蚭定は䞍倉であるずいうこずです。぀たり、プロセスで蚭定を倉曎するこずはできたせん。 モデルたたは蚀語を眮き換えるために、䜕かが認識されたずきに詊す必芁はありたせん。 したがっお、既に転送された蚭定でオブゞェクトを倉曎する機䌚をナヌザヌに提䟛したせん。



NS_ASSUME_NONNULL_BEGIN / NS_ASSUME_NONNULL_ENDマクロは、これらの蚭定をnullにするこずはできないこずを匷調するために䜿甚したす。audioSourceをnullにするこずはできたせん。



先ほど蚀ったように、startメ゜ッドずcancelメ゜ッドcancelSyncはなくなりたしたは別のプロトコルに移動したした。 ラむブラリには、レコグナむザヌではなく他のものを䜿甚できる堎所がありたす。 たずえば、このプロトコルを実装し、コンポヌネントを転送できるAppleのネむティブを䜿甚したす。



ここでの蚭定はNSCopyingなので、コピヌするこずができ、プロセスで倉曎するこずはできたせん。 initでは、必須パラメヌタヌは蚀語、モデル、およびNS_DESIGNATED_INITIALIZERです。 これは非掚奚のメ゜ッドず同䞀のコヌドではありたせんが、アむデアは明確です。 これらは、蚭定が䜜成される必須パラメヌタヌです。 それらはれロでなければなりたせん。



残りのセットは、玄20のレコグナむザヌの蚭定がここに蚭定されおいたす。 蚀語やモデルの蚭定でさえ、私たちが䜜業できない抜象的な䜕かを䌝えるこずを蚱可しない別個のクラスです。 ぀たり、私たちははっきりず蚀いたす。 コンパむラヌはこれを蚱可したせん。」



そこで、APIで䜕ができるかに぀いお話したした。 開発には独自のニュアンスもありたす。



開発



たず第䞀に、ラむブラリはあなたが曞いたものをするべきです-その機胜をうたく実行するために。 ただし、コヌドを非垞に優れたラむブラリにするこずができたす。 SpeechKitの開発䞭に収集したいく぀かのコメントを提䟛したす。



コヌドはあなただけのものではありたせん



ラむブラリが原因でサヌビスが機胜しおいないずナヌザヌに蚀わせたくないので、 デバッグ情報を収集するこずは絶察に必芁です。



IOSには、収集する必芁がある情報を瀺すデバッグ情報レベルがありたす。 デフォルトでは、すべおの呌び出し、すべおの倀など、怜出可胜なすべおのものを完党に収集したす。 これはすばらしいこずですが、非垞に倧量のデヌタです。 -gline-tables-onlyを蚭定するず、関数呌び出しに関する情報を収集できたす。 これで問題を芋぀けお修正するには十分です。



これはXcode蚭定ビルド蚭定に含たれおおり、デバッグ情報レベルず呌ばれたす。 たずえば、この蚭定を有効にするこずで、SpeechKitバむナリファむルのサむズを600 MBから90 MBに削枛したした。 これはあたり必芁な情報ではなく、ただ捚おたした。



2番目の重芁なこずは、 プラむベヌトキャラクタヌを隠すこずです。 ラむブラリにiTunesをアップロヌドするたびに、䜕かを远加するのではなく、䜕か間違っおいるこずを䜿甚しおいるずいう新しい譊告が衚瀺されるリスクがありたす。 したがっお、Appleがプラむベヌトず芋なすラむブラリを䜿甚する堎合は、必ず非衚瀺にしおください。 これはあなたにずっお䜕の意味もありたせん。あなたは圌らず䞀緒に仕事をするこずもできたすが、ナヌザヌがあなたのラむブラリを䜿っおアプリケヌションをiTunesにアップロヌドしようずするずすぐに゚ラヌを受け取りたす。 誰もがあなたにそれを修正するように頌むわけではなく、ほずんどはあなたの解決策を䜿うこずを単に拒吊するでしょう。



文字の競合を避ける 所有するすべおのもの、クラス、カテゎリにプレフィックスを远加したす。 ラむブラリにカテゎリUIColor + HEXがある堎合、ナヌザヌが正確に同じカテゎリを䜿甚しおいるこずを確認しおください。ラむブラリを統合するず、キャラクタヌの競合が発生したす。 繰り返しになりたすが、誰もがあなたに蚀っおそう蚀いたいずは限りたせん。



別の質問は、自分がラむブラリでサヌドパヌティラむブラリを䜿甚する堎合です。 芚えおおく䟡倀のあるニュアンスがいく぀かありたす。 たず、ラむブラリよりも叀いバヌゞョンにあるものを䜿甚する堎合は、必ず匱いリンクを䜿甚しおくださいXcode-> Build Phases-> Link Binary With Libraries-> Status is on。 これにより、突然このラむブラリが萜ちない堎合、萜ちないようにするこずができたす。



Appleのドキュメントには、この仕組みの詳现が蚘茉されおいたす。 しかし、匱いリンクは、ラむブラリが䜿甚されない堎合、ラむブラリがロヌドされないこずを意味したせん。 ぀たり、アプリケヌションの開始時間がナヌザヌにずっお重芁であり、サヌドパヌティのラむブラリを䜿甚しお開始に時間がかかるラむブラリの䞀郚が䞍芁な堎合、りィヌクリンクは圹に立ちたせん。 これにより、ラむブラリは䜿甚されおいるかどうかに関係なくロヌドされたす。



ランタむムにロヌドする堎合、これは起動時のリンクの問題を取り陀くのに圹立ちたす。その埌、dlopenず動的ロヌドを䜿甚する必芁がありたす。 これには倚くの手間がかかりたす。たず、これが理にかなっおいるかどうかを理解する必芁がありたす。 Facebookには、動的にリンクする方法の䟋ずしお、かなり興味深いコヌドがありたす。



最埌に、 内郚でグロヌバル゚ンティティを䜿甚しないようにしおください 。 各プラットフォヌムにはいく぀かのグロヌバルコンポヌネントがありたす。 ラむブラリにドラッグしないこずをお勧めしたす。 これはグロヌバルオブゞェクトであり、ラむブラリナヌザヌはそれを䜿甚しお奜きなように構成できるため、これは明らかなようです。 ラむブラリで䜿甚する堎合、䜕らかの方法でその状態を保存し、再構成しおから状態を埩元する必芁がありたす。 倚くのニュアンスがあり、間違いを犯す堎所がありたす。 これを芚えお、避けおください。



たずえば、SpeechKitでは、3番目のバヌゞョンの前に、ラむブラリ内でオヌディオを操䜜し、オヌディオセッションを明瀺的に蚭定およびアクティブ化したした。 iOSでのオヌディオセッションは、すべおのアプリケヌションが持っおいるものです。持っおいないず蚀っおはいけたせん。 開始時に䜜成され、アプリケヌションずシステムメディアデヌモンの盞互䜜甚を担圓し、アプリケヌションがオヌディオで䜕をしたいかを䌝えたす。 これは、単語の真の意味でのシングルトンオブゞェクトです。 私たちは萜ち着いおそれを必芁に応じお蚭定したしたが、これはナヌザヌに音量の倉曎などの小さな問題があるずいう事実に぀ながりたした。 蚭定の蚭定を担圓するオヌディオセッションのもう1぀の方法は、非垞に長い方法です。 箄200ミリ秒かかりたす。これは、アクティブ化たたは非アクティブ化の顕著な䜎䞋です。



3番目のバヌゞョンでは、ラむブラリからオヌディオセッションを匕き出したした。 その埌、SpeechKitが統合されたすべおのサヌビスのほずんどすべおのナヌザヌは、非垞に䞍幞だず蚀いたした。 これで、SpeechKit甚に特別に蚭定する必芁のある皮類のオヌディオセッションがあるこずを理解するはずです。



これによる結論は次のずおりです。すべお同じように、グロヌバル゚ンティティを䜿甚しないようにしたすが、ナヌザヌが垞に決定に満足するずは限らないずいう事実に備えおください。



ナヌザヌにずっお䟿利なものにしたす



他にどのようにナヌザヌを支揎できたすか





最も簡単な方法は、ファむルを添付するこずです。ファむルがあるず、メガデバッグモヌドが起動したす。 ナヌザヌに゚ラヌのあるナヌザヌがいお、正確に䜕が起こったのかを理解する必芁がある状況でデバッグを行うこずは本圓に圹立ちたす。





ラむブラリでのバヌゞョンサポヌトに぀いお話すずき、それは通垞のアプリケヌションでのバヌゞョンサポヌトず同じではないこずに泚意しおください。 通垞のアプリケヌションでは、たずえば、ナヌザヌの2のみがiOS 8を䜿甚し、iOS 8のサポヌトを停止できるこずを意味する統蚈を調べたす。これはラむブラリヌには圓おはたりたせん。ここでは、OSバヌゞョンを攟棄するず、ナヌザヌずすべおのナヌザヌが完党に攟棄されたす。 これは原則ずしおナヌザヌの半分かもしれたせん。



したがっお、ラむブラリを䜿甚するアプリケヌションがどのバヌゞョンを䜿甚しおいるかを監芖する必芁があり、これに基づいお、䜕かをサポヌトするかどうかをすでに結論付けおいたす。 私たちはiOS 7を長い間攟棄したせんでした。iOS8を攟棄し、iOS 9を攟棄する準備ができおいる人が既にいたようです。そしお私たちは圌ず密接に協力し、そのような状況に圌を残すこずはできたせんでした。



繰り返しになりたすが、ナヌザヌは「サポヌトしおいないバヌゞョンでこの機胜をオフにしたしょう」ずは蚀いたせん。いいえ、単にラむブラリを削陀し、䞀連のバヌゞョン党䜓をサポヌトするラむブラリを芋぀けたす。





これはラむブラリ開発者にずっお非垞に「それほどではない」です。 リリヌスの準備ができおいるすべおのものをリリヌスしたい。 機胜を䜜成し、バグを修正したした。次に、パケット党䜓を入れおリリヌスにロヌルアりトしたす。 リリヌスもプロセスです。 これはナヌザヌにずっおはそうではありたせん。 補品のテストずリリヌスの準備を行っおいるずき、远加のテストが必芁な新機胜を備えたアセンブリを受け取りたくありたせん。



いく぀かのリリヌスをロヌルバックし、それらをパヌツに分割し、すでにバラバラに展開しおいるケヌスが本圓にありたした。 その埌、倉曎を実装したチヌムは、䞀床にすべおではなく、小さな倉曎があるバヌゞョンを正確に䜿甚できたす。



これは実際には開発にはあたり䟿利ではありたせんが、バヌゞョンの最小の増分により、ナヌザヌは少し幞せになりたす。



倚くのテストはありたせん



これは、通垞のアプリケヌションずラむブラリの䞡方に圓おはたりたす。 しかし、ラむブラリの堎合も機胜がありたす。



もちろん、 自動テストが必芁ですが、それらに加えお、ラむブラリ甚のテストアプリケヌションがあるこずは玠晎らしいこずです。 自分で曞いたものを統合し、どのような問題や萜ずし穎が生じるかを理解するのに圹立ちたす。 ナヌザヌが䜕であるかを自分で感じるこずができたす。



ラむブラリが䜕らかの方法でネットワヌクず盞互䜜甚し、暗号化を含む堎合、少なくずもデヌタずセキュリティに関連するものがあり、 怜蚌のためにセキュリティガヌドに枡しおください。 あなたは絶察に脆匱性が芋぀かったラむブラリになりたくありたせん-それは人生の汚名です。 ほずんどすべおの倧䌁業には、補品の安党性のチェックを扱う郚門党䜓がありたす。 持っおいない堎合は、倖郚監査がありたす。 倖郚に䜙裕がない堎合は、ネットワヌクでテストを芋぀けお実行し、ラむブラリがナヌザヌデヌタの挏掩を蚱可しおいないこずを確認しおください。



テストで非垞に重芁な最埌のこずは、時間、消費電力、特定のラむブラリに兞型的なすべおなど、 可胜なすべおの枬定倀を最初から远加しようずするこずです 。 最終的にはこれを行う必芁がありたすので、最初から枬定に぀いお考えおみおください。



これは、倉曎に察する保護やラむブラリの高速化の必芁性から保護するものではありたせんが、䜕が間違っおいたかを把握するのに圹立ちたす。 グラフがある堎合、これは、どの機胜が時間遅延を远加したか、たたは消費電力が増加したかをリアルタむムで監芖するのに圹立ちたす。



これはラむブラリの機胜ではないため、これを行う時間はほずんどありたせん。これはあなたが開発するためのものではありたせん。 しかし、これは、良奜な状態ず品質でそれを維持するのに圹立ちたす。



ここでは、Yandexでモバむルデバむスの゚ネルギヌ消費量を枬定する方法を読むこずができたす。 時間枬定に぀いおは面癜い話でした。 ラむブラリ開発者ずしお、すべおのチヌムがすべおのSpeechKitスクリプトを䜿甚するわけではないため、特定の堎合の動䜜を枬定するこずは困難です。 時間たでは、テストアプリケヌションを䜿甚したした。 音声合成甚のレコグナむザヌたたはコンポヌネントなどの特殊な䜿甚䟋が蚘述され、ログが蚘録されおすべおのステップが保存され、その結果、クヌルなグラフィックが䜜成されたした。



すべおは問題ありたせんが、オヌディオを操䜜し、すべおをチェックするために、特定のケヌスではオヌディオトラックが実際に再生されたす。 さらに、倚くの枬定を行う必芁があるため、圌らはテストを倜に残したした。スピヌカヌを配眮し、䜕らかのデバむスを近くに配眮し、オヌディオファむルを開始したした。 朝、すべおがオフになり、翌倜、それが繰り返され、その埌再び繰り返されたした。 オフィスを歩き回ったのは魔法の生き物ではありたせんでした-クリヌナヌだけが怖かったです。 時々、非垞に奇劙なテキストが時々読たれおいたした。



その結果、ロヌカルテストベンチを䜜成するこずになりたした。これをキャビネットず呌びたす。 これは自然なキャビネットで、防音のみが斜されおいたす。 倚くのデバむスが含たれおおり、ファヌム党䜓にデバむスがありたす。各デバむスは、誰も傷぀けないため、就業日に䜕床も起動できたす。



打ち䞊げ



最埌に、最埌の重芁な郚分に来たす-これが発売です。 コヌドが䜜成され、優れたAPIがナヌザヌにずっお䟿利になるように蚭蚈されおいたす。 これをすべおリリヌスにリリヌスする方法。



Yandex内のナヌザヌ向けのロヌカルリリヌスから始めたす。 ここでのスキヌムは、通垞のアプリケヌションの開発ず同じです通垞、月次、たたは週次リリヌス。



このプロセスは通垞の段階で構成されおいたすが、ラむブラリを開発する堎合、これらの各ポむントには独自の特性がありたす。



蚈画䞭



ラむブラリにはいく぀かの補品チヌムがあるため、私にずっおこれは最も苊痛な郚分です。 通垞のアプリケヌションには、チヌムが優先順䜍を付けおタスクを蚭定し、䞀床に1぀のタスクを開始するプロダクトマネヌゞャヌが1人いたす。



耇数の補品チヌムがある堎合、各チヌムはリアルタむムで凊理する必芁があるリク゚ストを受け取りたす。 私はアドバむスをしたすすぐに来る倚数のタスクに察凊する方法を知っおいる人がいるなら、あなたのチヌムで圌を拟っおみおください。 すべおの倖郚マネヌゞャヌず開発者の間に誰かが必芁だからです-タスクの優先順䜍付けのための機胜を匕き受ける人。



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



開発



, , : , , . Agile- .



, , , — . , . !



Scrum . , , , . . « », .



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



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







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



— . Continuous Integration , , , .







, . .



1. .



— . - - , , , . .



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



2. .



, , , — , , , , , !



. , . , , -, .



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



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



— . , , , .



. .



, -, . . , , , help , .



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



, , - , , ..







, , :





たずめ





Yandex.SpeachKit GitHub iOS , Android , Mobile SDK.



AppsConf — — 22 23 2019 , , .



. , , .



More articles:


All Articles