Răspunsul la această întrebare simplă, inofensivă este: Depinde.
Depinde de pachetul în cauză, desigur. Poate mai puțin evident, dar la fel de important, depinde de cine pune întrebarea.
Suntem siguri că dacă v -am întreba despre „calitatea pachetului”, am veni cu toții cu ceea ce face un pachet bun:
- Documentare
- Testele unitare
- Credibilitatea autorului
- Pachetul are o pagină web?
- Vulnerabilități de securitate
- Rata de închidere a erorilor
- Există mai mulți întreținători?
- Pachetul are dependențe inversă?
Am putea (și am) să venim cu alte douăzeci dintre aceste atribute. Cu o încredere de 95%, suntem siguri că majoritatea oamenilor ar fi de acord că tot ceea ce ne -am gândit este important. Dar, cu o încredere 100%, suntem siguri că nu am fi de acord cu cât de substanțiale sunt aceste caracteristici. Cu siguranță, testarea unității este mai importantă decât popularitatea pachetului? Dar cât de importantă este calitatea documentației în raport cu numărul de întreținători?
Totul depinde de ce întrebăm. Este vorba despre apetitul dvs. de risc.
Ce este pofta de risc?
Apetitul riscului se referă la riscurile pe care le aveți și nu sunt dispuși să le asumați. Acesta variază de la „pachetele noastre trebuie să fie vag sensibile, să nu compromită sistemul nostru și să aibă un loc în care să pot înregistra erori” pentru „dacă pachetele noastre nu sunt testate în detaliu și se dovedesc a fi potrivite pentru scopuri, nu le pot folosi în producție”. Primul este destul de ușor de raportat, în timp ce cel de -al doilea este ceva mai complicat.
Căutătorii de risc!
Cine dintre noi nu ar dori un pachet R de cea mai bună calitate? Cine sunt solicitanții de risc? Cei mai mulți dintre noi, la un moment sau altul. Dacă experimentați cu construirea de aplicații strălucitoare, atât timp cât pachetul este „sigur”, orice pachet vechi este în regulă – doriți doar să experimentați. De asemenea, dacă sunteți academic și doriți să comparați metoda dvs. cu una deja publicată, atât timp cât pachetul este „corect”, este suficient de bun.
În timpul cursurilor noastre de formare, ni se pune adesea această întrebare despre calitate. Cât de rău poate fi utilizabil un pachet? Un experiment de gândire pe care ne place să îl facem este „să presupunem că aveți un pachet R, cu o singură versiune. Nu este niciodată actualizat, nimeni nu a auzit de la întreținător în zece ani. Dar oferă cod pentru un algoritm pe care doriți să îl utilizați. Ce ați face?” Răspunsul evident pentru cei care au un pofta de risc ridicat este „ceva mai bun decât nimic” și „procedează cu prudență”.
Risc averse
Există o mulțime de exemple despre locul în care ne aflăm (și ar trebui să fie) aversa riscului atunci când vine vorba de pachete R. De exemplu:
- În industria farmaceutică, avem nevoie de reasigurare că statisticile utilizate în raportare sunt corecte. Este vital ca aceste pachete să fie foarte reglementate!
- Precizia și stabilitatea sunt cruciale pentru rapoartele oficiale ale guvernului privind starea economiei. Un bug minor ar putea avea consecințe semnificative.
- De asemenea, băncile lucrează într -un mediu reglementat, care rulează modele complexe, așa că trebuie să fie atenți la exactitatea datelor lor.
Un alt aspect crucial este faptul că nu numai că trebuie să ia în considerare ce pachete folosesc, ci și să demonstreze această gândire într -un mod audibil. Acest lucru nu este diferit de procesul ISO 9001. În contextul industriei farmaceutice, Sfântul Graal folosește pachete R în trimiterile FDA pentru noile terapii.
Hub -ul de validare R deschide calea
Industria farmaceutică este prima care abordează aceste cerințe într -un mod semnificativ. Hub-ul de validare R a prezentat o carte albă care abordează utilizarea R și pachetele sale pentru analiza statistică în trimiteri de reglementare farmaceutică, propunând o abordare bazată pe riscuri pentru validarea pachetelor R în infrastructura validată. Lucrarea sugerează că pachetele R de bază prezintă un risc minim, în timp ce pachetele contribuite necesită evaluarea riscurilor în funcție de scopul lor, practicile de întreținere, utilizarea comunității și protocoalele de testare.
Cadrul propus clasifică pachetele ca fiind „destinate utilizării” (încărcate direct de utilizatori) sau „importuri” (dependențe de susținere), concentrând eforturile de validare în principal pe primele. Evaluarea riscurilor ar trebui să evalueze dacă pachetele sunt de natură statistică sau non-statistică, să examineze practicile de dezvoltare, să ia în considerare valorile de adopție a comunității și să revizuiască acoperirea testării. Organizațiile pot utiliza această evaluare pentru a determina includerea pachetelor în sistemele validate și pentru a identifica cerințele suplimentare de testare, pachetele cu risc ridicat care au nevoie de o validare mai riguroasă.
Abordarea necesară pentru cei care nu lucrează în industrii reglementate probabil nu va fi la fel de serioasă ca aceasta, dar acest lucru oferă o idee despre care ar trebui să fie standardul de aur pentru validarea pachetului R, din care ne putem inspira pentru aplicații mai puțin stricte. De asemenea, au creat câteva instrumente utile, cum ar fi {RiskMetric}, care ne permite să tragem metadate despre pachete și să creăm scoruri de calitate pentru aceste date.
Cum activăm evaluarea riscurilor pentru toată lumea din spectrul de risc?
Aceasta este întrebarea cu care ne -am prins în ultimele luni. Cum adunăm toate informațiile necesare pentru a lua decizii în cunoștință de cauză cu privire la includerea pachetelor din mediile de producție, folosind un cadru flexibil care răspunde nevoilor tuturor celor cu privire la spectrul apetitului de risc? Mai ales având în vedere …
Există atât de multe pachete pe Cran!
Aceasta este atât o binecuvântare, cât și un blestem, așa cum vă poate spune oricine a lucrat vreodată într -un mediu reglementat. Răspunsul evident este de a automatiza, automatiza, automatiza! Aceasta este exact ceea ce am făcut în crearea cadrului de validare a pachetelor Litmus.
Procesul nostru se bazează pe automatizare, acolo unde este posibil:
- Am scris cod bazat pe {RiskMetric} care trage metadate de pachete de la CRAN, depozite GIT și Manager de pachete Posit pentru a oferi o imagine de ansamblu cuprinzătoare a calităților pachetului
- Am creat un cadru pentru analizarea și punctajul pachetelor pe baza acestor date
- Am creat fluxuri de lucru de raportare și tablou de bord care ne permit să generăm prezentări generale de pachete și la nivel de colectare a scorurilor pentru fiecare pachet
- Am implementat acceptarea automată/respingerea unui pachet bazat pe criterii specificate de client
- Procesul nostru permite, de asemenea, raportarea automată a oricăror măsuri manuale suplimentare făcute pentru salvarea unui pachet din coș, de exemplu, scrierea testelor de remediere suplimentare sau documentație
Fii atent la blogurile viitoare pe acest subiect, în timp ce ne aruncăm puțin mai adânc în principiile de bază care conduc abordarea noastră pentru validarea pachetelor.
Pachetul dvs. trece testul litmus?
Sunteți gata să aflați cum vă putem ajuta să vă validați colecția de pachete R? Verificați litmusverse și luați legătura.
Pentru actualizări și revizii la acest articol, consultați postarea originală
