Așa cum se întâmplă adesea, este destul de ușor să vorbim despre pachetele R „bune”. Putem chiar să ne întoarcem mâinile și să vorbim despre pachete care urmează „standarde software” sau „cele mai bune practici”. Dar ce înseamnă asta?
Cei mai mulți dintre noi ar fi de acord că pachetele precum {Rcpp} sau {dplyr} sunt solide. La celălalt capăt al spectrului, am putea sublinia pachetele învechite, slab testate sau nedeprimate drept „riscante”. Dar realitatea este că majoritatea pachetelor R se încadrează undeva între ele.
Cu toate acestea, realitatea este considerabil mai nuanțată: marea majoritate a pachetelor R există undeva de -a lungul continuumului dintre aceste două extreme. Aceștia pot prezenta excelență în anumite aspecte, în timp ce se încadrează în altele sau ar putea reprezenta soluții perfect adecvate pentru cazuri de utilizare specifice, în timp ce sunt improprii pentru aplicațiile critice pentru misiune. Obiectivul principal al acestui post este de a ajuta organizațiile și practicienii individuali în dezvoltarea unei înțelegeri mai clare și mai sistematice a pachetelor de care depind. Este important să recunoaștem în avans că orice sistem de notare va avea limitări-unele pachete cu adevărat de înaltă calitate ar putea primi scoruri neașteptat de mici din cauza circumstanțelor specifice, în timp ce unele pachete cu probleme de bază semnificative ar putea înscrie bine la valorile la nivel de suprafață. Cu toate acestea, acest lucru nu diminuează valoarea considerabilă a stabilirii unui cadru consistent și structurat pentru evaluarea pachetelor.
În dezvoltarea Litmus, soluția noastră pentru evaluarea și validarea pachetelor R, a trebuit să ne luptăm cu aceste concepte în detaliu. Am venit cu un cadru care credem că abordează provocările prezentate de validarea pachetelor. În seria următoare de postări pe blogul Litmus, vom examina în detaliu alegerile pe care le -am făcut pentru a echilibra nevoia atât a robustetei, cât și a flexibilității în evaluarea calității pachetelor R.
Înainte de a examina specificul modului în care evaluăm și punctează pachetele, este crucial să înțelegem principiile fundamentale care stau la baza metodologiei noastre. În această postare, vom săpa în principiile de bază ale abordării noastre.
Ghidul 1: Scorurile nu sunt statice
La prima vedere, acest principiu ar putea părea contraintuitiv, dar reflectă o realitate fundamentală: standardele pe care le aplicăm la pachetele R de astăzi nu pot fi în mod rezonabil identice cu cele pe care le -am fi folosit în 2015 și nici nu ar trebui să rămână neschimbate așteptând cu nerăbdare 2030.
Mai mult, abordarea noastră de notare este legată în mod explicit de versiuni specifice de pachete. Atunci când un întreținător eliberează o nouă versiune a unui pachet, care poate aborda vulnerabilitățile de securitate, îmbunătățind documentația, adăugând noi caracteristici sau îmbunătățirea acoperirii testelor, versiunea anterioară devine adesea o alegere mai puțin optimă, în ciuda faptului că a fost perfect adecvată atunci când a fost actuală.
Soluţie: Implementăm un audit anual cuprinzător al mecanismelor noastre de notare. Acest proces de revizuire anuală servește mai multe funcții: actualizarea datelor de bază utilizate pentru a genera scoruri, dacă este relevant (cum ar fi ajustarea pragurilor de descărcare pentru a reflecta creșterea ecosistemului), introducerea de noi criterii de notare pe măsură ce evoluează cele mai bune practici și care se retrag metrici care ar putea deveni mai puțin relevante sau discriminatorii.
Ghidul 2: Scorurile nu ar trebui să se schimbe des
În timp ce recunoaștem că scorurile sunt tranzitorii, acestea nu ar trebui să se schimbe des sau dramatic. De exemplu, este logic să audați anual mecanismul nostru de notare pentru descărcări și să ajustați criteriile. Acest lucru ar schimba scorurile pe pachete, dar numai într -un mod mic.
Soluţie: Menținem audituri anuale disciplinate ale mecanismelor noastre de notare, cu modificările implementate în mod deliberat și cu o documentare clară a rațiunii. Între aceste recenzii anuale, criteriile de notare rămân stabile, cu excepția cazului în care sunt identificate probleme critice.
Ghidul 3: Decupaje depind de cazurile de utilizare
Într -o lume ideală, ar trebui să „analizăm manual toate pachetele, petrecând timp evaluând fiecare pachet individual. Dintr -o perspectivă practică, concentrându -ne atenția asupra pachetelor de frontieră, a celor care sunt destul de bune sau doar Destul de bun pentru a face tăierea, are sens. Cu toate acestea, ceea ce constituie „Borderline” variază dramatic în funcție de cererea prevăzută. Un pachet considerat pentru utilizare într -o depunere de reglementare la FDA se confruntă cu cerințe de calitate cu totul diferite în comparație cu unul utilizat într -un proiect de statistică MSC sau o analiză de date exploratorii. Primul context necesită o validare extinsă, documentație cuprinzătoare și stabilitatea demonstrată, în timp ce acesta din urmă ar putea accepta în mod rezonabil un risc suplimentar în schimbul funcționalității sau comodității de ultimă oră.
Soluţie: În loc să impunem praguri de pachete „riscante” universale, pledăm pentru întreruperi dependente de situație care reflectă cerințele specifice și toleranța la risc a diferitelor cazuri de utilizare. Oferim îndrumări pentru stabilirea pragurilor adecvate pentru scenarii comune, recunoscând în același timp că organizațiile ar putea avea nevoie să le personalizeze pe baza contextelor lor de reglementare, comerciale sau academice specifice.
Consultați postarea noastră despre apetitul la risc pentru mai multe despre acest lucru.
Ghidul 4: Pachetele „bune” pot avea probleme serioase
Este crucial să recunoaștem că chiar și cele mai bine apreciate pachete se pot confrunta cu probleme care se află în întregime în afara controlului direct al întreținătorilor lor. De exemplu, un pachet ar putea depinde de o bibliotecă de sistem care, ulterior, dezvăluie o vulnerabilitate de securitate, sau una dintre dependențele sale ar putea deveni neliniștită. În mod alternativ, modificări ale ecosistemului R mai larg – cum ar fi modificările la baza R sau actualizări ale dependențelor critice – pot crea probleme de compatibilitate care încă nu au fost abordate. Aceste scenarii evidențiază motivul pentru care un singur scor numeric, deși valoros pentru triajul inițial, nu poate surprinde complexitatea completă a evaluării riscului de pachete. Unele probleme reprezintă „showstoppers” autentice care necesită atenție imediată, indiferent de scorul general al unui pachet.
Soluţie: În timp ce menținem angajamentul nostru de a clarifica scoruri numerice interpretabile pentru evaluarea inițială, le completăm cu steaguri specifice pentru probleme „showstopper” care necesită o revizuire umană imediată. Acestea pot include vulnerabilități de securitate cunoscute, dependențe de pachete riscante sau probleme de compatibilitate cu versiunile R actuale.
Ghid 5: Evitați marginile stâncilor
Indiferent de persuasiunea dvs. statistică, cu toții putem fi de acord că o decupaj super greu de „P = 0.05” este o prostie. Ideea că „P = 0.05000001” nu este „semnificativă”, dar „P = 0.4999999” poate schimba lumea, nu are sens cu adevărat. Aceeași idee ar trebui să se aplice la scoruri. Acolo unde este posibil, mecanismul de notare ar trebui să fie neted și continuu.
Soluţie: Utilizăm funcții de notare continuă și lină, acolo unde este posibil. De exemplu, în loc să acordăm puncte complete pentru pachete cu> 80% acoperire de testare și zero puncte pentru cei cu <80%, folosim curbe de notare treptată care recompensă îmbunătățiri la toate nivelurile, în timp ce recunoaștem încă distincții semnificative în calitate.
Ghid 6: Nu toate scorurile sunt create în mod egal
Un scor bazat pe faptul că există sau nu un întreținător ar trebui să conteze mai mult pentru un scor general decât un scor bazat pe dacă există sau nu o adresă URL a site -ului. Prima este mai importantă decât cea din urmă în majoritatea cazurilor și, prin urmare, ar trebui să contribuie mai mult la un scor general, dacă acest scor general trebuie considerat util.
Soluţie: Crearea unei strategii de notare care cântărește în mod sensibil valori individuale în categorii, care sunt, de asemenea, ponderate pentru a reflecta importanța lor relativă. Vom discuta mai detaliat această strategie într -o postare ulterioară pe blog, dar iată ideea generală.
Ne gândim la calitatea pachetelor ca având patru atribute:
- Documentație (greutate 15%): evaluați calitatea și completitudinea documentației pachetului. Acest lucru este clar subiectiv, ca un pachet cu documentație completă, ar putea avea documentație „proastă” sau depășită. Cu toate acestea, pachetele care nu au exemple în paginile de ajutor, vinietele sau fișierele de știri au scoruri mai mici.
- Cod (greutate 50%): Aceasta evaluează calitatea și structura codului pachetului. Componentele cheie ale acestui scor includ dependențele de pachete (întotdeauna un subiect controversat), numărul de obiecte exportate, vulnerabilități și acoperirea testelor.
- Întreținere (greutate 20%): revizuiește aspectele standard de întreținere ale pachetului, inclusiv actualizări de frecvență, gestionarea erorilor și numărul de contribuabili.
- Popularitate (greutate 15%): Examinați popularitatea pachetului. Aceasta include descărcări de pachete în ultimul an și dependențe inversă. Ideea este că aceștia sunt indicatori puternici că comunitatea a plasat deja încredere în acel pachet.
Desigur, aceste numere pot fi ajustate.
Considerații de implementare și dezvoltare viitoare
Acest cadru de notare reprezintă un efort continuu pentru a aduce o mai mare sistematizare și transparență la evaluarea calității pachetului R. Pe măsură ce ecosistemul R continuă să evolueze, anticipăm că atât metodologia noastră, cât și înțelegerea noastră despre ceea ce constituie calitatea pachetelor vor necesita rafinament continuu. Salutăm feedback -ul comunității atât despre cadrul teoretic prezentat aici, cât și despre implementarea sa practică. Domeniile particulare în care contribuția comunității ar fi valoroasă includ ponderile adecvate pentru diferite atribute de calitate, identificarea unor valori suplimentare care ar putea spori precizia evaluării și dezvoltarea de îndrumări specifice contextului pentru diferite scenarii de utilizare. Angajamentul nostru față de revizuirea anuală a metodologiei asigură că acest cadru se va adapta pentru a reflecta schimbările în cele mai bune practici, disponibilitatea uneltelor și standardele comunitare, menținând în același timp stabilitatea și predictibilitatea pe care utilizatorii o necesită pentru luarea deciziilor practice.
Luați legătura
Dacă sunteți interesat să aflați mai multe despre validarea R și cum poate fi utilizat pentru a dezlănțui puterea open source în organizația dvs., contactați -ne.
Pentru actualizări și revizii la acest articol, consultați postarea originală
