Diejenigen, die mit R arbeiten, sind sich bewusst, dass die Sprache ursprünglich als Werkzeug für interaktives Arbeiten entwickelt wurde. Natürlich erweisen sich die Methoden, die für eine konsolenbasierte schrittweise Anwendung durch eine Person geeignet sind, die sich tief mit dem Thema befasst, als ungeeignet für die Erstellung einer Anwendung für den Endbenutzer. Die Möglichkeit, sofort nach einem Fehler eine detaillierte Diagnose zu erhalten, alle Variablen und Traces zu durchsuchen, Codeelemente manuell auszuführen (möglicherweise die Variablen teilweise zu ändern) - all dies ist nicht verfügbar, wenn die R-Anwendung in einer Unternehmensumgebung offline ist. (Wir sagen R, wir meinen im Grunde Shiny Webanwendungen).

Allerdings ist nicht alles so schlecht. Die R-Umgebung (Pakete und Ansätze) hat sich so weit entwickelt, dass eine Reihe sehr einfacher Tricks das Problem der Gewährleistung der Stabilität und Zuverlässigkeit von Benutzeranwendungen elegant lösen können. Einige davon werden nachstehend beschrieben.

Es ist eine Fortsetzung früherer Veröffentlichungen .

Was ist die Schwierigkeit der Aufgabe?

Der Hauptaufgabenbereich, für den R häufig verwendet wird, ist die vielfältige Datenverarbeitung. Und selbst ein vollständig debuggter Algorithmus, der durch Tests allseitig angelegt und vollständig dokumentiert ist, kann leicht zusammenbrechen und Unsinn ausstoßen, wenn gekrümmte Daten in seine Eingabe eingefügt werden.

Daten können sowohl von anderen Informationssystemen als auch von Benutzern eingegeben werden. Und wenn es im ersten Fall möglich ist, die Einhaltung der API zu fordern und die Stabilität des Informationsflusses sehr streng einzuschränken, gibt es im zweiten Fall kein Entkommen vor Überraschungen. Eine Person kann einen Fehler machen und die falsche Datei verschieben, sie falsch schreiben. 99% der Benutzer verwenden Excel in ihrer Arbeit und ziehen es vor, das System mit vielen Seiten mit gerissener Formatierung abzuschalten. In diesem Fall wird die Aufgabe noch komplizierter. Sogar ein visuell gültiges Dokument kann aus Sicht der Maschine völlig unsinnig aussehen. Die Daten sind verstreut (die sehr berühmte Geschichte "Excel's Designer dachte, 1900 sei ein Schaltjahr, aber es war nicht" ). Numerische Werte werden als Text und Satz gespeichert. Unsichtbare Zellen und versteckte Formeln ... und vieles mehr. Grundsätzlich ist es unmöglich, alle möglichen Rechen vorherzusehen - es gibt nicht genug Vorstellungskraft. Was ist es wert, nur Datensätze in verschiedenen Verknüpfungen mit gekrümmten Quellen zu verdoppeln?

Als zusätzliche Überlegung werden wir Folgendes berücksichtigen:

1. Das hervorragende Dokument „Eine Einführung in die Datenbereinigung mit R“ beschreibt den Prozess der vorläufigen Datenaufbereitung. Für weitere Schritte werden zwei Validierungsphasen herausgearbeitet: technische und logische.

   
   
   • Die technische Validierung dient zur Überprüfung der Richtigkeit der Datenquelle. Struktur, Typen, quantitative Indikatoren.
   • Die logische Validierung kann mehrstufig sein und im Verlauf von Berechnungen durchgeführt werden. Sie besteht darin, die Konformität bestimmter Datenelemente oder ihrer Kombinationen mit verschiedenen logischen Anforderungen zu überprüfen.
   
   
2. Eine der Grundregeln bei der Entwicklung von Benutzeroberflächen ist die Erstellung der vollständigsten Diagnose bei Benutzerfehlern. Das heißt, wenn der Benutzer die Datei hochgeladen hat, muss sie so weit wie möglich auf ihre Richtigkeit überprüft und eine vollständige Zusammenfassung aller Fehler erstellt werden (es ist auch ratsam, zu erklären, was falsch ist), und nicht mit dem ersten Problem mit einer Meldung wie „Falsche Eingabe value @ line 528493, pos 17 ”und erfordern das Herunterladen einer neuen Datei mit diesem Fehler. Mit diesem Ansatz können Sie die Anzahl der Iterationen erheblich reduzieren, um die richtige Quelle zu bilden und die Qualität des Endergebnisses zu verbessern.

Technologien und Methoden zur Validierung

Lass uns vom Ende gehen. Es gibt eine Reihe von Paketen zur logischen Validierung. In unserer Praxis haben wir uns auf folgende Ansätze festgelegt.

1. Schon ein klassischer dplyr . In einfachen Fällen ist es zweckmäßig, einfach ein Rohr mit einer Reihe von Überprüfungen und Analysen des Endergebnisses zu zeichnen.
2. Das validate zum Überprüfen technisch korrekter Objekte auf Übereinstimmung mit den angegebenen Regeln.

Bei der technischen Validierung haben wir uns auf folgende Ansätze konzentriert:

1. checkmate Paket mit einer Vielzahl schneller Funktionen für die Durchführung einer Vielzahl technischer Prüfungen.
2. Explizite Arbeit mit den Ausnahmen „Advanced R. Debugging, Bedingungsbehandlung und defensive Programmierung“ , „Advanced R. Beyond Exception Handling: Bedingungen und Neustarts“, um sowohl die vollständige Validierung in einem Schritt durchzuführen als auch die Stabilität der Anwendung sicherzustellen.
3. Verwenden Sie Schnurrverpackungen für Ausnahmen. Sehr nützlich, wenn es in einem Rohr verwendet wird.

In Code, der in Funktionen unterteilt ist, besteht ein wichtiges Element der defensiven Programmierung darin, die Eingabe- und Ausgabeparameter von Funktionen zu überprüfen. Bei Sprachen mit dynamischer Typisierung muss die Typprüfung unabhängig durchgeführt werden. Für qtest ist das Schachmatt-Paket ideal, insbesondere die qassert qtest \ qassert . Um data.frame zu überprüfen data.frame bei der folgenden Konstruktion angehalten (Überprüfen von Namen und Typen). Der Trick beim Zusammenführen von Name und Typ reduziert die Anzahl der Zeilen in der Prüfung.

 ff <- function(dataframe1, dataframe2){ #        calledFun <- deparse(as.list(sys.call())[[1]]) tic("Calculating XYZ") #       (class,   typeof,  Date ) list(dataframe1=c("name :: character", "val :: numeric", "ship_date :: Date"), dataframe2=c("out :: character", "label :: character")) %>% purrr::iwalk(~{ flog.info(glue::glue("Function {calledFun}: checking '{.y}' parameter with expected structure '{collapse(.x, sep=', ')}'")) rlang::eval_bare(rlang::sym(.y)) %>% assertDataFrame(min.rows=1, min.cols=length(.x)) %>% {assertSetEqual(.x, stri_join(names(.), map_chr(., class), sep=" :: "), .var.name=.y)} # {assertSubset(.x, stri_join(names(.), map_chr(., typeof), sep=" :: "))} }) … } 

Im Rahmen der Typprüfung können Sie entsprechend den erwarteten Daten eine Methode nach Ihrem Geschmack auswählen. class wurde ausgewählt, weil das Datum als Date und nicht als Zahl angegeben wird (interne Darstellung). Das Problem der Bestimmung von Datentypen wird im Dialog "Eine umfassende Übersicht über die Arten von Dingen in R." Modus "und" Klasse "und" Typ "ist nicht ausreichend erörtert. "

assertSetEqual oder assertSubset werden aus Gründen klarer übereinstimmender Spalten oder des ausreichenden Minimums ausgewählt.

Für praktische Aufgaben deckt ein so kleines Set die meisten Anforderungen vollständig ab.

Vorheriger Beitrag - R als Rettungsboje für einen Systemadministrator .