Dlaczego i kiedy utworzyć pakiet R?

Rozumiem, że to pytanie jest dość szerokie, ale zastanawiam się, jakie powinny być decydujące punkty przy podejmowaniu decyzji o utworzeniu (lub nie) nowego pakietu dla R. Aby być bardziej szczegółowym, dodam, że pytanie nie dotyczy powodów użyj R w sobie, więcej o decyzji o kompilacji różnych skryptów i zintegrowaniu ich w nowym pakiecie.

Wśród kwestii, które mogą prowadzić do tych decyzji, pomyślałem (w dość niewyczerpujący sposób) o:

• brak innych pakietów w tym samym subpolu;
• potrzeba wymiany z innymi badaczami i umożliwienia powtarzalności eksperymentów;

A wśród kwestii, które mogą prowadzić do sprzecznej decyzji:

• część zastosowanych metod jest już obecna w niektórych innych pakietach;
• liczba nowych funkcji jest niewystarczająca, aby uzasadnić utworzenie nowego niezależnego pakietu.

Mogłem zapomnieć o wielu punktach, które mogłyby znaleźć się na obu listach, a także te kryteria wydają się częściowo subiektywne. Co zatem powiesz, co powinno uzasadnić i w którym momencie zacząć gromadzić różne funkcje i dane w nowym udokumentowanym i szeroko dostępnym pakiecie?

Nie programuję w języku R, ale programuję inaczej i nie widzę tutaj żadnego problemu związanego z językiem R.

Wyobrażam sobie, że większość ludzi najpierw coś pisze, ponieważ naprawdę chcą tego dla siebie. I odwrotnie, każdemu poczuciu, że należy publikować oprogramowanie, ponieważ należy to zrobić, należy zdecydowanie się oprzeć. Mądrzy ludzie mogą być kiepskimi programistami i często nimi są.

Upublicznienie wydaje się sprawą pewności, że masz coś tak dobrego lub lepszego niż to, co już jest publiczne i wypełnia lukę. Świadomość, że inni ludzie chcą robić to samo, jest z pewnością impulsem.

W razie wątpliwości nie publikuj. W wielu społecznościach występuje problem kontroli jakości przeciętnego lub błędnego oprogramowania wydanego przez bezkrytycznych lub niedoświadczonych programistów, chociaż kwestia tego, jak poważny jest problem, pozostaje otwarta na dyskusję. Optymiści uważają, że ciekawostki można po prostu zignorować, a użytkownicy będą wystarczająco szybko ujawniać błędy i ograniczenia; pesymiści uważają, że toniemy w rzeczach złej jakości i ciężko jest odróżnić zwycięzców od przegranych. (Z drugiej strony doświadczenie zdobyte podczas publikacji jest częścią tego, co pozwala programistom się doskonalić.)

Może być na ten temat książka, ale przychodzi mi na myśl kilka wskazówek:

1. Dokumentacja dobrej jakości wyróżnia dobre oprogramowanie, a także dobry kod, czasem nawet bardziej oczywisty. Nigdy nie lekceważ, ile pracy będzie wymagało dostarczenie dokumentacji, na którą kod zasługuje. Programiści R często wydają się wymagać, aby użytkownicy R wiedzieli tyle samo, co robią na temat wdrażanej techniki i minimalnie dokumentują ...

2. W miarę możliwości przetestuj swój kod, aby móc odtwarzać opublikowane rozwiązania z prawdziwymi danymi z innych źródeł. (Jeśli kodujesz coś zupełnie nowego, może to być trudniejsze, ale nie niemożliwe. Często możesz się zastanawiać, czy to ich błąd, czy twój.)

3. Programiści często nie doceniają zdolności użytkowników do rzucania nieodpowiednich danych w programie. Pomyśl więc o tym, co może pójść nie tak, np. Z brakującymi wartościami, zerami, jeśli program przyjmuje wartość dodatnią itp., Itp. (Łagodne podejście polega na tym, że zadaniem użytkowników jest znalezienie problemów i poprawienie kodu za pomocą ich opinii , ale program, który łatwo się psuje, nie poprawi Twojej reputacji).

To ważne i praktyczne pytanie. Zacznijmy od rozróżnienia między pisaniem pakietu a publikowaniem go w CRAN.

Powody, dla których nie pisać paczki:

• Efektywność kosztowa.
• Brak doświadczenia.

Powody, dla których warto napisać pakiet R:

• Udostępnianie ludziom i platformom.
• Wymusza uporządkowanie kodu i proces pracy.
• Łatwość użycia (nawet dla siebie), gdy funkcje zaczynają się kumulować.

Powody, dla których należy przesłać pakiet (CRAN, Bioconductor, ...):

• Wkład w społeczność.
• Łatwość dystrybucji.

Pamiętaj, że istnieje opcja # 3; możesz poprosić opiekuna odpowiedniego pakietu o podanie kodu lub danych.

Moje osobiste wyzwalacze do pakowania to:

• Zauważyłem, że ponownie używam kodu, który napisałem kiedyś do innego projektu analizy danych.
• Myślę, że będę potrzebować metody, którą właśnie napisałem.

• Kolega prosi mnie o kod. Znaczna część kodu, który piszę, jest przynajmniej tyle na prośbę kolegów (którzy używają R, ale sami nie programują tak dużo) jak dla mnie.

• Używam formalnych wymagań dotyczących pakietu (dokumentacji), aby „zmusić” mnie do wyczyszczenia i udokumentowania mojego kodu.

Zgadzam się z @JohnRos, że istnieje duża różnica między pisaniem pakietu a jego publikowaniem.

• Zazwyczaj pakuję wcześnie, ale potem robię to tylko „półpubliczne”. Oznacza to, że może być dostępny na serwerze wewnętrznym (lub na r-forge), aby moi koledzy mieli dostęp do pakietu. Ale publikuję w CRAN dopiero po tym, jak pakiet był używany przez miesiące lub nawet kilka lat przez bliskich współpracowników. To nie wywołuje wszystkich błędów zgodnie z punktem 3 Nicka Coxa, ale spora ich liczba.
  Wersje pakietu (wstawiam datę po myślniku w numerze wersji) ułatwiają naprawianie rzeczy („aby to zrobić i tamto, upewnij się, że instalujesz przynajmniej wersję z zeszłego tygodnia”)

• Zgodnie z moją umową o pracę mój pracodawca ma ostatnie słowo na temat tego, czy i jak pakiet może zostać opublikowany na zewnątrz.

Rzeczą, gdzie ja nie jeszcze dobrą strategię na opakowaniu jest dane.

Komentarze do twojej listy powodów:

• brak innych pakietów w tym samym subpolu;

Nie znalezienie pakietu, który robi to, czego potrzebuję, powoduje napisanie kodu, ale nie ma to związku z decyzją, czy go spakować, czy nie.

• potrzeba wymiany z innymi badaczami i umożliwienia powtarzalności eksperymentów;

Zdecydowanie. Być może już potrzebuję współdzielić kilka komputerów, z których korzystam.

A wśród kwestii, które mogą prowadzić do sprzecznej decyzji:

• część zastosowanych metod jest już obecna w niektórych innych pakietach;

możesz zaimportować te metody do swojego pakietu / kodu: jest to argument przeciwko pisaniu takiego kodu, ale tylko pośrednio dotyczy pakowania.

• liczba nowych funkcji jest niewystarczająca, aby uzasadnić utworzenie nowego niezależnego pakietu.

Dla mnie nie ma minimalnej liczby funkcji do uruchomienia pakietu. Z mojego doświadczenia wynika, że ​​pakiety rosną „automatycznie”. Wręcz przeciwnie, po tym, jak kilka razy rozgałęziłem nowy pakiet z innego (ponieważ np. Niektóre funkcje pomocnicze okazały się być tematycznie różne i przydatne również w innych sytuacjach), teraz jestem raczej natychmiastowe tworzenie nowych pakietów.

Ponadto, jeśli nie napisałeś dokumentacji i testów, może to być zbyt duża ilość pracy, gdy zgromadzi się „wystarczająca” liczba funkcji do utworzenia pakietu.
(Jeśli napiszesz je natychmiast, dodatkowy wysiłek włożenia go do pakietu jest znikomy, gdy poznasz przepływ pracy).

Powiedziałbym, że stwórz pakiet za każdym razem, gdy wykonujesz wystarczająco duży zestaw podobnych zadań w R, aby skorzystać z pakietu, w którym możesz umieścić rzeczy w przestrzeni nazw (aby uniknąć konfliktów z funkcjami o podobnych nazwach), w których możesz pisać dokumentacja. Mam nawet pakiet na github do pakowania pakietu funkcji, które nie są powiązane, ale używam tak często, że myślałem, że zasługują na dokumentację, pliki man itp.

Innym przypadkiem użycia może być przesłanie artykułu, jeśli masz wiele funkcji, możesz łatwo stworzyć pakiet, w tym dokumentację dla tych funkcji, przykłady dla każdej funkcji i samouczek, jak z niej korzystać. I nie musisz umieszczać go w CRAN, jak powiedziano w powyższych odpowiedziach. Może to być niesamowite ze względu na powtarzalność.

Ważne są trzy narzędzia:

• devtools pkg , aby ułatwić tworzenie pakietów (zobacz także wiki na stronach github devtools
• roxygen2 pkg , aby ułatwić pisanie dokumentacji dla paczki
• GitHub, możesz użyć install_github(lub podobnie install_bitbucket itp.), Aby zainstalować bezpośrednio z GitHub, co jest miłe do udostępniania innym.

Zgadzam się ze wszystkim, co czytałem do tej pory. Wszystkie te powody są dobrą praktyką programowania i nie dotyczą w szczególności R. Jednak najczęściej piszę pakiety R i to z innego powodu. Dodam więc:

Powód dla którego należy napisać pakiet R:

• ponieważ piszesz w C.

Za każdym razem, gdy używasz języków obcych, takich jak C, C ++ lub FORTRAN (głównie do obliczeń o wysokiej wydajności), napisanie pakietu jest w dużej mierze warte kłopotu. Jeśli masz więcej niż jedną lub dwie funkcje, szybko dostajesz pliki w dowolnym miejscu i zależności między kodem R i C, które są trudne do utrzymania i przeniesienia.

Jeden powód nie wymieniony w innych doskonałych odpowiedziach: Masz duży lub złożony projekt analizy danych. Najpierw pakowanie danych jako pakiet, a następnie rozszerzanie o przydatne funkcje do przekształcania, kreślenia lub obliczania konkretnych analiz. W ten sposób otrzymujesz udokumentowaną wersję danych wraz ze wszystkimi funkcjami użytymi do obliczenia raportowanej analizy. Następnie raport (y) z projektu można napisać przy użyciu knitr lub innych pakietów do powtarzalnych badań!

Może to znacznie zaoszczędzić czas, jeśli trzeba przeprowadzić ponowną analizę, a nawet może zostać opublikowane (lub częściowo opublikowane), jeśli analiza zostanie opublikowana.