7 kroków do usprawnienia pracy w R

Problem

Codzienna praca analityka z pewnością wygląda różnie. Są miejsca, w których spędza się długi czas nad jednym projektem, gdzie dużą wagę przykłada się do każdego detalu jak również są miejsca, w których wykonuje się kilka zadań dziennie wspomagając bieżące funkcjonowanie biznesu. Obojętnie, w której z tych skrajnych sytuacji zawsze trzeba mieć wszystko dobrze poukładane. Warto wyrobić sobie rutynę organizowania systemu plików, dokumentacji, sposobu nazewnictwa plików, funkcji, zmiennych tak aby zawsze nie było problemu w poruszaniu się po naszym warsztacie analitycznym. Skrypty pisane przez nas powinny być dokumentem rejestrującym kolejno wszystkie czynności popełnione w trakcie realizacji projektu. To wymaga pewnych umiejętności i nauki wielu 'niepotrzebnych' technik aby zaprogramować każdy etap generowania raportu od plików wejściowych do plików z wynikami i wizualizacjami. Takie podejście nosi miano reproducible research (jaki jest polski odpowiednik? Odtwarzalne analizy?). Reproducible research jest niezwykle cenione w środowisku analitycznym, gdzie proces badawczy musi być rzetelny i wiarygodny dla osób, które na ich podstawie będą podejmować decyzje.


Dla mnie reproducible research jest częścią szerszego pojęcia jakim jest higiena pracy. Nie chodzi mi bynajmniej o warunki bytowe w biurze (korporacje nam to zapewniają), problemem jest, że pracujemy w przestrzeni wirtualnej, a tam pojęcie porządku jest abstrakcją. Stan skrzynki mailowej, folderów z projektami i organizacja zadań wpływa na nasz komfort pracy. Wyrobienie sobie standardów pozwala na spokojniejszą, łatwiejszą, bardziej przewidywalną pracę. Prawdopodobnie nikt w firmie nie rozumie danych tak jak my, stąd też sami dla siebie powinniśmy wymyślić system pracy. 

Zanim jednak przekonamy innych do jakości naszej pracy, musimy zacząć od podstaw porządkując własny analityczny warsztat. Zastanówmy się więc nad wszystkimi elementami pracy, co jest dobrym rozwiązaniem problemów naszych i organizacji. Wdrażajmy zmiany zaczynając od siebie, później przekonujmy innych.

Rozwiązanie

1. Uporządkowanie systemu plików.

Dla zainteresowanych, którzy miewają podobny problem proponuję w pierwszej kolejności otworzyć kilka starych folderów, zobaczyć jak zorganizować zamknięty już projekt tak aby był maksymalnie czytelny.

Najlepiej zademonstrować to na sprawdzonych przykładach. Warto skorzystać z dobrodziejstw wypracowanych nie tylko przez kolegów po fachu. Weźmy za przykład taką typową statyczną stronę internetową, która zbudowana jest z pliku .html, odwołującego się do osobno zlokalizowanych styli, skryptów js, obrazków itd. Folder lokalizacji strony w uproszczeniu wygląda następująco:

[Folder_główny]

styles/

images/

scripts/

- index.html

W takim układzie łatwo podmieniać obrazki, dodawać kolejne funkcjonalności czy zmiana stylów poszczególnych elementów bez przewracania wszystkiego do góry nogami. Z podobnym układem spotkała się nie jedna osoba zanim zaczęła pracę analityka. Możemy działać w podobny sposób budując projekt z wymienialnych części, podmieniając dane, modyfikując funkcje generujące wizualizacje itd.

Za dobry przykład prezentuję znanego większości z Was Hadleya Wickhama. Wickham to człowiek, którego pracy owoce rewolucjonizują analityczny workflow, wiele jego wynalazków pojawi się w dalszej części wpisu. Jego github to prawdziwa kopalnia dobrych przykładów:

• Pobieranie czyszczenie i eksport danych z IMDB - mały, wartościowy przykład, w którym kodowanie rozbite jest na kilka plików ponumerowanych zgodnie z kolejnością wykonywania. Skrypty krótkie, ze znikomą liczbą komentarzy. Wszystko bardzo czytelne zawierające plik readme opisującym zawartość i funkcjonalność.
• Folder projektu analizującego występowanie imion w USA - podobnie jak w poprzednim przykładzie, tym razem ponumerowane skrypty R i oczyszczone pliki z danymi w folderze projektu. Pliki nie mieszają się z 'brudnymi', a sama analiza jest łatwo odtwarzalna przez osoby trzecie.
• Analiza kryzysu mieszkaniowego - Pliki z danymi i skrypty czyszczące w osobnym folderze data/, a eksploracja w folderze exploration/. Większość folderów i podfolderów udokumentowanych plikiem readme. Osoby trzecie mogą szybko połapać się w dużym projekcie. Dodany skrypt pomocniczy helper.R z własnymi funkcjami używanymi w projekcie.

Przykłady pokazują pewien wspólny mianownik, który warto realizować w swoich projektach:

• 1_wczytywanie_danych.R  - plik szczególnie potrzebny gdy podpinamy się pod hurtownie danych, w takim pliku możemy napisać kwerendy sql, zapytania wysyłane do API, skrypt webScrapingowy itd.
• 2_czyszczenie_danych.R - skrypt doprowadzający nasze dane do stanu bezpośredniej używalności. Tworzymy zestaw obiektów, które będziemy bezpośrednio wrzucać do takich funkcji jak glm, pls, mlogit, hclust czy inne. Za 
• 3_funkcje.R - samodzielnie napisane funkcje wywoływane z source(), których będziemy używać wewnątrz bieżącego projektu (funkcje lokalne). Nie wymagają rozległej dokumentacji. 
• 4_analizy.R - wywoływanie analiz na wcześniej przygotowanych danych i funkcjach. Plik powinien być dobrze udokumentowany, najlepiej napisany z wykorzystaniem jednego z narzędzi generowania raportów w RStudio.

2.  Odseparowanie zgromadzonych danych (np. pliki z GUS) od plików importowanych bezpośrednio do analiz (oczyszczone i połączone pliki). 

W przypadku gdy otrzymuję więcej niż jeden plik do analizy, wtedy bezwzględnie przestrzegam zasady, że dane przechowywane są w folderze  input_data/. W zależności od charakteru projektu warto czasem stosować prefiks będący datą otrzymania pliku np. 20150424_stała_nazwa_cyklicznego_pliku.csv.

Dla porządku przydaje się czasem folder output_data/ gdzie przetrzymujemy zbiory danych gotowe do wysłania. W myśl tej zasady mamy dobrze odseparowane pliki skryptów od plików wejściowych i wyjściowych.

3.  Kolekcjonowanie przydatnych funkcji.

Jeżeli uznamy którąś z napisanych funkcji lokalnych za przydatne w przyszłości kopiujemy ją do miejsca z funkcjami globalnymi. Lokalizacją dla takich plików powinien być folder znajdujący się ponad wszystkimi projektami, gdzie gromadzić będziemy wszystkie funkcje-tricki, funkcje do wizualizacji i prezentacji danych itd. W przypadku rozrostu pliku z funkcjami warto rozbić go na kilka innych z funkcjami powiązanymi jakąś kategorią tematyczną. Funkcje globalne powinny być dobrze udokumentowane, prawdopodobnie będziemy do nich wracać wielokrotnie w przyszłości, być może będziemy się dzielić nimi z osobami trzecimi. 

Z racji dużej liczby funkcji globalnych i częstą potrzebą dotarcia do dokumentacji idealnym wyjściem jest stworzenie pakietu. Oczywiście nie musimy go jeszcze nigdzie publikować, możemy go trzymać na swoim dysku albo co wygodniejsze i bezpieczniejsze - skopiować w repozytorium (gihub). Dzięki skopiowaniu do repozytorium, możemy współdzielić funkcjonalność pakietu ze współpracownikami bez potrzeby przesyłania plików. Tworzenie pakietu R wraz z dokumentacją zademonstruję w niedalekiej przyszłości.

4. Kolekcjonowanie przydatnych danych.

Często przy okazji wykonywania jakiegoś zadania w pracy opracowujemy metody ściągające dane z zewnętrznych z innych źródeł lub operujące na danych znajdujących się w firmie (xls z księgowości, bazy danych itd.). Podobnie jak z funkcjami, które uznajemy za globalne identycznie postępować powinniśmy z danymi. Globalne dane do folderów ogólnych, łatwo dostępne dla każdego wykonywanego projektu.

5.  Kodowanie zgodne z przyjętymi standardami.

Usystematyzowany styl kodowania jest krytyczny, a konsekwencja stylistyczna pozwala na łatwiejsze odczytanie kodu w przyszłości. Dobrym przykładem jest style guide opublikowany na stronie Advanced R Hadleya Wickhama napisany z małymi modyfikacjami w stosunku do google R style guide. Bynajmniej nie chodzi tutaj o kopiowanie innych standardów ale o konsekwencję i pisanie za każdym razem jakby nasze dzieło było przeznaczone dla innych czytelników. Powyższe przykłady google i Wickhama są obowiązkowe :)

Do automatycznego sformatowania kodu proponuję formatR, w sytuacji gdy przyjdzie nam kiedyś analizować czyiś kod. Lepiej jednak od początku do końca być konsekwentnym w pisaniu, a nawet przeforsować standard w swoim dziale.

6. Używaj RStudio

Obecnie najbardziej funkcjonalne IDE dla R. Zalety tej aplikacji przedstawię już w następnym wpisie, ze wszystkimi znanymi mi trickami, które ułatwiają mi codzienną pracę.

7. Koniec robótek ręcznych i koniec powtarzalnej pracy.

Automatyzacja wszystkich procesów od początku do końca. Nie modyfikować plików 'z ręki', nie zmieniać w ten sposób nazw kolumn, nie usuwać artefaktów, do tego jest plik 2_czyszczenie_danych.R. Chociaż zdarza się czasem, że otrzymamy pliki zdemolowane, jakby w ich bebechach panowało wieczne tornado - wtedy odpuszczamy kodowanie. 

Generowanie raportów powtarzalnych oddelegowujemy osobom zamawiającym, tworząc dla nich aplikacje takie jak shiny, tworząc na lokalnych dyskach pseudo-aplikacje z dostępem do zewnętrznego źródła danych, budując serwery bazujące na obliczeniach w R (rApache, rServe). 

W myśl zasady "to my jesteśmy kucharzami na tej imprezie".