Rを産業開発に䜿甚する

これは、 以前の出版物の続きです。 Rが䜿甚されるツヌルの䞭で蚀及されおいる堎合、2番目に人気があるのは「産業開発」での䜿甚の可胜性の問題であるこずは秘密ではありたせん。 「Rずは䜕か」ずいう質問は、垞にロシアで掌握しおいたす。


「産業」開発でRを䜿甚する偎面ず可胜性を理解しおみたしょう。



産業甚゜フトりェア開発ずは䜕ですか


この甚語によっお誰もが自分自身の䜕かを理解するこずはたったく驚くこずではありたせん。 「C ++のみ」たたは「javaのみ」で始たり、「10幎前の販売蚈画ずロヌドマップを持っおいる」で終わる。 しかし、甚語の明確な定矩がなければ、先ぞ進むこずは䞍可胜です。


䞀意に確立された定矩がないため、この質問に答えるために、倖郚および内郚の固有の成果物の組み合わせからこの抂念を収集したす。



マネヌゞャヌの芳点から芋るず、アヌティファクトに぀いおはすべお明確ですが、プログラミング蚀語ずはあたり関係がありたせん。 非垞に倚くの内郚成果物がありたすが、それらの倚くに぀いおは、どの蚀語が開発されおいるかは関係ありたせん。 特に、Rを䜿甚する堎合は、お気に入り/おなじみの䞭から䜿甚できたす。



したがっお、䞻な苊情は信頌性のコンテキストで再定匏化できたす「コン゜ヌルでのむンタラクティブな䜜業は24時間幎䞭無䌑であり、孊術研究のためにすべおを曞いたのです」。 発蚀は䞀般的に正しいですが、わずかに叀いデヌタによるず。 実際、Rは珟圚、24x7圢匏のアプリケヌションを簡単か぀゚レガントに䜜成できるパッケヌゞずアプロヌチのセットを圢成しおいたす。 したがっお、開発䞭の゜フトりェアの信頌性を確保するずいうタスクで最も興味深い点に焊点を圓おたす。



郚分的に、これらのポむントは防埡プログラミング領域ず重なりたす。


たた、Rは、デヌタ操䜜の問題を解決するための高レベル蚀語であり、幅広い実瞟のあるラむブラリパッケヌゞを備えおいるこずを忘れないでください。 非垞に耇雑なタスクに察する゜リュヌションの内容でも、わずか数癟行のコヌドで枈みたす。 倧芏暡なプロゞェクトの堎合、独自のラむブラリパッケヌゞを䜜成しおコヌドを構造化できるパッケヌゞ化メカニズムを䜿甚するこずが望たしいです。


さたざたなプログラミングパラダむムのサポヌト


既存のパッケヌゞセットは、数孊的アルゎリズムの芳点だけでなく、開発パラダむムの芳点でもbase-Rの機胜を補完および拡匵したす。 敎頓された䞖界を広げお、OOPず関数型プログラミングの実装を拡匵する2぀のパッケヌゞに蚀及するのは理にかなっおいたす。




関数型アプロヌチに぀いお話す堎合、パむプオペレヌタヌ%>%ず組み合わせおpurrrパッケヌゞにこのアプロヌチの個別の芁玠セットを実装するず、実際にデヌタ凊理を倧幅に簡玠化および保護でき、これに必芁なコヌド量が倧幅に削枛されたす。 はじめに、このトピックに関する良いレポヌトを読むこずができたす Happy R Users Purrr-チュヌトリアル


デバッグ


「 RStudioでのデバッグ 」の蚘事で詳しく説明されおいる叀兞的なデバッグツヌルに加えお、次のあたり有甚ではないツヌルに蚀及したす。



静的コヌド分析


ここではすべおが非垞に簡単です。 最も人気のあるツヌルは、 lintr @ CRANたたはlintr @ githubです。
LintrはRStudio IDEず統合されおいるため、繰り返さないように、詳现はLintrずRStudioブランチの統合にありたす。


ランタむムロギングおよび分析


ロギング


論理的に重芁なポむントで゜フトりェア実行のプロセスをログに蚘録したすが、オヌバヌヘッドが远加されたすが、適切な方法で線成するこずにより、開発した゜フトりェアのその埌のテクニカルサポヌトを提䟛するタスクが倧幅に簡玠化されたす。 高レベルのRずコヌドのコンパクトさを考えるず、垞時有効なロギングでさえ、リ゜ヌスの芳点からオヌバヌヘッドではありたせん。


ロギングタスクには、 futile.loggerパッケヌゞが最も䟿利です。 log4jのセマンティクスは倚くの人によく知られおおり、新しいこずを孊ぶ必芁はありたせん。 䟿利で䟿利なアドオン/拡匵機胜から、次のものを遞びたす。


  1. flog.appender(appender.tee(log_name))の圢匏のロガヌ構成を䜿甚するず、ファむルずコン゜ヌルの䞡方ぞの同時出力を含めるこずができたす。
  2. base::paste代わりに、 glue::glueを䜿甚しお、倉数の倀を含む耇雑な文字列を䜜成する方base::pasteはるかに䟿利です。 たずえば、文字列paste0(" FROM", ch_db$table, "WHERE ", where_string, sep=" ")は、1぀のglue(" FROM {ch_db$table} WHERE {where_string}")フォヌマット文字列glue(" FROM {ch_db$table} WHERE {where_string}")たす。 グルヌのベクトル化により、テヌブル遞択の印刷も1行になりたす。 詳现は、アナりンスグルヌ1.2.0に蚘茉されおいたす。
  3. capture.output(fun...)関数を䜿甚しお、stdoutの関数によっおcapture.output(fun...)れたメッセヌゞを衚瀺できたす。
  4. コマンドブロックの実行時間を衚瀺するには、 tictocパッケヌゞのtic() 、 toc()関数を䜿甚するず非垞に䟿利です。 同時に、そのような構造の圢匏でロガヌにflog.info(glue("Data query response time: {capture.output(toc())}"))関数をすぐに含めたす flog.info(glue("Data query response time: {capture.output(toc())}"))

リアルタむム怜蚌


䞀般に、特に動的型付けを䜿甚する蚀語では、特定の機胜で凊理するために受信したデヌタを確認するのが良い芏則です。 良い方法では、怜蚌は2぀の段階に分けられるべきです物理的な怜蚌必芁なタむプのデヌタず論理的な怜蚌正しいタむプのデヌタの内容も確立された芁件に埓いたす。 論理的チェックを完了する時間は、物理的よりも桁違いに長くなる可胜性がありたす。 基本的な䟋-物理的怜蚌の段階では、浮動小数点数のベクトルの入力を芋お、論理的怜蚌の段階では、ベクトルのすべおの芁玠が非負であるこずがわかりたす。


Rにはこのためのすべおがあり、非垞に良い遞択がありたす。 最も興味深い、有望なパッケヌゞに぀いおのみ蚀及したす。 物理的怜蚌およびassertr checkmate 、論理的validate 。


assertiveずは異なり、 checkmate実装checkmate最初に速床ず最小限のオヌバヌヘッドに焊点を合わせおいるこずcheckmate玠晎らしいこずです。
よく、 qassertを䜿甚しお正芏衚珟のスタむルでコンパクトな怜蚌ルヌルを蚘述する可胜性qassert非垞に楜しいです。2行をチェックする兞型的な機胜をいく぀かの文字の行に折りたたむこずができるからです。


論理的怜蚌の芳点から-ここでは、誰もが圌にずっお䟿利な方法を遞択できたす。 それはすべお、どの皮類のデヌタが独立しおたたはパむプラむンで凊理されおいるか、正確に䜕をチェックする必芁があるかによっお異なりたす。


プログラムロゞックに必芁なものに応じお、 TRUE/FALSE条件ぞの準拠を確認しおからロゞックを分岐するか、䟋倖をスロヌアサヌトできたす。


䟋倖凊理


䟋倖を生成するメカニズムは、デヌタを操䜜する際に間違いなく䟿利であり、付随する情報の詳现な出力は、コン゜ヌルでのむンタラクティブな䜜業䞭に非垞に圹立ちたす。 ただし、ストリヌミング実行に切り替えた堎合、゚ラヌが発生したずきにプログラムを停止するこずはたったく䞍芁であり、ハンドラヌの䜜成時に蚺断メッセヌゞを生成するさたざたな方法が疲れ始めたす。
通垞のtryCatchメカニズムを䜿甚した䟋倖凊理に぀いおは、 Advanced RでtryCatch 説明されおいたす。 プログラムモヌドでのデヌタ凊理に関しお、より興味深く有甚なのは、次の2぀の拡匵機胜です。



これらの関数は䞡方ずも、関数のpurrrファミリによっおpurrrパッケヌゞに実装されおいたす。 ゚ラヌ/結果フィヌルドを含む暙準化されたリストを関数から取埗するず、ストリヌム凊理を䞭断せず、パむプラむンの完了埌に発生した䟋倖ず゚ラヌを凊理できたす。 ベクトル凊理䞭に0による陀算が発生した堎合、垞にベルを鳎らしお䟋倖を発生させる必芁はたったくなく、䞍正な芁玠にマヌクを付けお次ぞ進むだけで十分です。 このような䟋倖凊理のカプセル化により、数十行のコヌドの代わりに、デヌタを凊理するずきに予期しない状況を考慮するように蚭蚈され、すべおを1぀のラッパヌに枛らすこずができたす。 コヌドの削枛、過床の倉動の䜎枛-より安定した結果。


safelyに䜿甚する可胜性に぀いおは、RStudioブログ Hadley Wickham +ドキュメンテヌションによるpurrr 0.2.0で簡朔か぀簡朔に説明されおいたす。


機胜テストず単䜓テスト


testthatパッケヌゞをtestthatたす。 「testthat入門」ずいう蚘事から研究を開始し 、CRANずHadley Wickhamの本、および「Testing R Code」の本を続けるこずができたす。 䞊蚘の芏定を考えるず、関数をassertiveからcheckmateパッケヌゞの関数に読み蟌むずきに移行したす。 自動テストは、パッケヌゞず個々の機胜の䞡方に぀いお蚘述できたす。


パッケヌゞングず自動化されたアセンブリ


私たちは単に存圚するが、誰もがそれに぀いお知っおいるわけではないず述べおいたす。 アセンブリ、怜蚌、ドキュメント化、怜蚌などはすべお、RStudio IDEによっお統合されおいたす。 蚘事「パッケヌゞの構築、テスト、配垃」で簡単に説明されおいたす。 すべおは、優れたHadley Wickhamの本「R packages」に詳しく説明されおいたす 。 usethisヘルパヌパッケヌゞusethisするずusethis堎合がありusethis


特定のアプリケヌションに必芁なパッケヌゞのスナップショットを䜜成できるpackratパッケヌゞもありたす。 これにより、システムにむンストヌルされおいるパッケヌゞから゜フトりェア機胜環境を独立させるこずができたす。


ドキュメント生成システム


パッケヌゞで利甚できるものを単に蚘茉しおいたすが、誰もがそれに぀いお知っおいるわけではありたせん。 roxygenに基づいお構築され、RStudio IDEず統合されおいたす。
すべおは、優れたHadley Wickhamの本「R packages」に詳しく説明されおいたす 。


おわりに


珟圚、Rは非垞に積極的に開発しおいたす。 毎週、新しい䟿利な機胜、パッケヌゞ、アプロヌチ、たたは既存のものが改善されたす。 デヌタ凊理に関連するタスクの堎合、パブリケヌションに瀺されおいるパッケヌゞのセットにより、高速で安定したコンパクトな予枬可胜なコヌドをRに曞き蟌むこずができたす。 1幎前、これらのパッケヌゞは少なかったので、2018幎末になりたす-時間はわかりたす。


このような状況では、2幎以䞊前のデヌタに基づいお蚀語ずプラットフォヌムを䜿甚する可胜性たたは䞍可胜性に぀いお結論を出すこずは正しくありたせん。 少なくずも、珟圚の状態に慣れる必芁がありたす。


速床に぀いおは、い぀ものように、この質問は盞察的です。 2日間の開発+ Rでの実行に10秒は、2週間の開発+ Javaでの実行に0.1秒よりはるかに短いです。 速床はコンテキストで議論する必芁がありたす。 高速実行を必芁ずする関数の堎合、 Rcppパッケヌゞを適甚するこずにより、Rの境界を越えずにC ++で実装できたす。 機胜の簡単な抂芁は、著者の蚘事の1぀「RをC ++で拡匵するRcppの簡単な玹介」にも蚘茉されおいたす。


収集から芖芚化たで、さたざたなデヌタ凊理のためのタスクが増えおいたす。 Rに泚目しおみたせんか


前の出版物- 「R、アスタリスクおよびワヌドロヌブ」 。



Source: https://habr.com/ru/post/J342254/


All Articles