Jaką metodologię oprogramowania powinienem stosować podczas badań?

9

Zwykle analizuję dane z eksperymentów i chociaż mam ogólny schemat kroków, które muszę wykonać, być może będę musiał dostosować go do specyfiki eksperymentów lub stojących za nimi pytań. Zazwyczaj jestem jedynym, który koduje.

Patrzyłem na wikipedię, ale nie jestem pewien, której metodologii mogę użyć, częściowo dlatego, że nigdy jej nie zastosowałem, a częściowo dlatego, że czasami po prostu przeglądam dane, aby zobaczyć, jak to wygląda, a innym razem chcę tylko odpowiedzi. (A ponieważ nie oczekuje się ode mnie zbytniego testowania ani posiadania pewnej jakości mojego kodu)

Zostałem poproszony o zadanie tego pytania po godzinie lub dwóch odkryciu, że funkcja r tablezależy od kolejności wektorów, a nie od nazwy elementów, z którymi je porównamy. Potem pomyślałem, że powinienem przetestować zachowanie i funkcje, których użyłem z niektórymi próbnymi danymi. Ale użyłem tabeli po innej analizie, która spowodowała brak informacji, dlatego nie mogłam zastosować metodyki opartej na testach (jeśli dobrze to zrozumiałem). Jednak czuję, że z pewną poprawą w podejściu do projektu mogę być bardziej wydajny, oprócz wcześniejszego wykrywania błędów, ale także tego, jak i czego szukać, w razie wątpliwości, więc nie skupiaj się tylko ten przykładowy błąd.

Która metodologia oprogramowania najlepiej pasuje do badań?

Zasadniczo pytam, jak zapewnić jakość i terminowy postęp, a także zachować specyfikę badań.

Przykład mojej pracy:

Biolog ma na myśli pytanie i wie, że przeprowadzenie eksperymentu doprowadzi do uzyskania interesujących danych (tj. Poziomów ekspresji genów w dwóch warunkach), a następnie ustali eksperyment i przypomni próbki od 10 osób / myszy / szczurów. Teraz muszę przeanalizować te dane dla tych 10 próbek przy użyciu istniejących bibliotek i testów (lub wdrażając nowe testy), ale biorąc pod uwagę pytanie, które biolog miał na myśli (tj. Które geny są bardziej wyrażane w jednym stanie niż w innym). Struktura jest taka sama jak w poprzednich eksperymentach (które obejmowały 6 warunków i inne zwierzę), ale test statystyczny, normalizacje, struktura danych mogą ulec zmianie. Zwykle więc kopiuję poprzednią wersję i dostosowuję ją do bieżących potrzeb.

llrs
źródło
7
co teraz masz, jest w porządku. Żadna metodologia nie powstrzyma cię przed popełnianiem błędów! upewnij się tylko, że korzystasz z systemu kontroli wersji i utrzymuj porządek w swoich kodach.
gbjbaanb
Żadna metodologia nie powstrzyma błędów. Ale niektórzy szybciej wychwycą błędy! Projektowanie na podstawie umowy lub projektowanie na podstawie umowy.
Frank Hileman,
Czy mógłbyś opracować swoje ostatnie zdanie? W ogóle tego nie zrozumiałem.
llrs
być może en.wikipedia.org/wiki/Test-driven_development z jakimś zautomatyzowanym szkieletem testów - małe testy są przydatne do wychwytywania błędów, a większe testy mogą (z grubsza) mapować (z grubsza) na twoje hipotezy
david.libremone
1
@Llopis idealnie piszesz najpierw test, to się nie udaje, potem piszesz kod, test przechodzi, a następnie zatwierdzasz kod - jeśli odkryjesz błąd później, napiszesz test, który by go złapał, to się nie powiedzie , popraw kod, test kończy się pomyślnie, a następnie zatwierdzasz kod - nie możesz wszystko przewidzieć, ale możesz się upewnić, że to samo się nie powtórzy
david.libremone

Odpowiedzi:

6

Potrzebna może być może nie jest metodologia oprogramowania, ale zmiana polityczna w środowisku akademickim, która rozwiązuje problem braku uznania roli, jaką odgrywa oprogramowanie w nauce.

Software Sustainability Institute (UK) jest organizacją najbliżej czego szukasz: jak argumentować za bardziej sumiennego stosowania programów komputerowych w badaniach naukowych.

Zapewnia także wskazówki dla osób zainteresowanych metodologiami tworzenia oprogramowania.

Muszę jednak zaznaczyć, że metodologie zwykle zarządzają zespołami programistów, z iteracjami i stopniowym udoskonalaniem celów projektu, i działają ze stabilnymi bazami kodu, które działają przez długi czas. Są przeznaczone dla projektów o rzędach wielkości bardziej złożonych niż to, co robisz.


Co do tego, dlaczego ta bardzo oczywista poprawna rzecz (bardziej sumienne wykorzystanie programowania komputerowego w badaniach naukowych) nie została osiągnięta i zawsze podtrzymana, oto niewygodna prawda: w akademickich środowiskach administracyjnych można zaobserwować, że naukowcy zmniejszają znaczenie komputera programowanie. Czasami można ich spotkać razem, aby odmówić uznania wkładu osób zaangażowanych w oprogramowanie, nawet jeśli charakter tego wkładu pasuje do dyscypliny naukowej.


W twoim miejscu pracy brakuje rzeczy, które możesz zrobić.

Rzeczy, których brakowało:

  • Brak wytycznych
  • Brak nadzoru lub osoby do zadawania pytań
  • Brak mentorów lub programistów posiadających wiedzę na temat używanych narzędzi (np. R)
  • Brak ponownego wykorzystania oprogramowania, archiwizacji, kontroli wersji lub dokumentacji wcześniej opracowanego oprogramowania, w celu zapewnienia powtarzalności i uczenia się

Krótko mówiąc, ogólna kultura jest taka, że ​​zaangażowani ludzie nie są tak naprawdę zainteresowani ... zgadliście ... bardziej sumiennym wykorzystaniem programowania komputerowego w badaniach naukowych.


Rzeczy, które możesz zrobić:

  • Poświęć więcej czasu na naukę swoich narzędzi.
    • Poświęć więcej czasu na czytanie dokumentacji i próbek kodu dla języków programowania
    • Musisz nauczyć się kochać narzędzia, których używasz.
  • Spróbuj coś zapisać, z korzyścią dla kolejnego programisty, który przez kilka następnych lat zostanie zniewolony dla tej samej grupy ludzi.
    • Wiki będzie doskonała.
  • Spróbuj skonfigurować kontrolę wersji źródłowej
    • Być w stanie odzyskać często używane fragmenty kodu
    • Być w stanie zapisać migawkę kodu użytego w danym eksperymencie

Wytyczne dla twórców oprogramowania do kariery można znaleźć w:

Są to uważane za podstawowe wymagania do prowadzenia działalności związanej z programowaniem oprogramowania. Jednak gdy walczysz samotnie z wojną apatii, musisz ustalić priorytety. Ulepszanie narzędzi, zapisywanie i utrzymywanie informacji, utrzymywanie wersji kodu źródłowego to absolutne minimum dla jedynego środowiska.

rwong
źródło
Dzięki za interesujący udział w Software Sustainability Institute! Napiszę własne wytyczne dotyczące zarządzania kodem i danymi, mam przełożonego, ale on nie wydaje się mieć „wiedzy na temat narzędzi”, używam git, ale postaram się postępować zgodnie z twoją radą na temat dokumentacji
llrs
ha tak, wiki ... za wypróbowanie kilku polecam tutaj dokuwiki.org/dokuwiki# . Prosty w konfiguracji i zachowuje dokumenty jako pliki tekstowe, a nie w bazie danych. Odkryłem, że to najlepsza równowaga między łatwością konfiguracji, łatwością użycia i trwałością danych.
Newtopian
Problemy w nauce wspomaganej komputerowo, które opisuje @rwong, są obecne w większości instytutów, w których pracowałem (fizyka i astronomia)
steffen
2

Nie przejmuj się tak bardzo metodologią, ale spróbuj bardziej skoncentrować się na tym, czego potrzebujesz, aby śledzić swoje wymagania dotyczące samego oprogramowania.

Po krótkim pobycie w pozycji stosunkowo podobnej do twojej mogę wyciągnąć z mojego osobistego doświadczenia.

Algorytmiczna dokładność

Prawdopodobnie najważniejszy aspekt, powinieneś być w stanie udowodnić, że twoje oprogramowanie robi to, co zostało zaprojektowane. Tutaj automatyczne testowanie jest twoim najlepszym sprzymierzeńcem. Zdaję sobie sprawę, że bez odpowiedniego zestawu danych może to być trudne, ale w rzeczywistości powinieneś tworzyć nawyk tworzenia własnych zestawów danych. Ich cel jest jednak nieco inny, nie próbujesz wydobywać trendów z danych, ale upewniasz się, że oprogramowanie daje przewidywalne i poprawne wyniki ze znanego zestawu danych. Na przykład do rozpoznawania wzorów nie potrzebujesz genetycznego makijażu z wieloma gigami, wystarczy kilka linii tekstu, aby algorytm wykrył wzór.

Kiedyś tworzyłem swoje dane do reprezentowania przypadków narożnych, przypadków niemożliwych. Miałem tendencję do skupiania się bardziej na skrajnościach niż na oczekiwanej normie. Wiele razy pamiętam testowanie na coś niemożliwego tylko do zobaczenia, jak ta sytuacja pojawia się w rzeczywistym zbiorze danych. Gdybym tego nie testował, nie wprowadziłbym wykrywania błędów i rejestrowania niezbędnych do zidentyfikowania potencjalnych uszkodzeń lub błędów w zestawie danych. TDD dobrze pasuje do tej części, chociaż tworzenie dobrego zestawu testowego jest ważniejsze, niezależnie od tego, czy robisz to przed czy po rzeczywistym kodzie.

Wersjonowanie

Zbyt często tę część pomija się. Dobry schemat wersjonowania dla twojego kodu i wyprodukowanych pakietów / plików wykonywalnych pomoże niezmiernie utrzymać porządek w postępach. Aby móc dokładnie odzyskać kod, który został użyty do utworzenia wcześniej uzyskanych wyników, może pomóc w śledzeniu błędów lub rozbieżności. Rozgałęzianie może również pomóc podczas eksperymentowania z różnymi podejściami lub algorytmami.

Upewnij się, że otagujesz kod użyty w rzeczywistych obliczeniach. Sprawdź wersję semantyczną, jeśli potrzebujesz pomocy w nazywaniu wersji.

Zautomatyzowana kompilacja

Następstwo do powyższego punktu. Upewnij się, że w jak największym stopniu zautomatyzujesz proces budowania i pakowania oprogramowania. Nie musisz iść na całość, wystarczy, że stworzenie ostatecznego systemu ze źródeł i zależności będzie banalne. Celem jest zaoszczędzenie czasu, ale także zapewnienie powtarzalnego sposobu na odtworzenie oprogramowania ze źródła, w tym zależności i innych czynników zewnętrznych. Groovy, Maven, ant, Scons, cmake, to tylko niewielka próbka narzędzi do automatyzacji budowy i systemów skryptowych, które mogą pomóc.

Jeśli chcesz pójść o krok dalej, zainstaluj Jenkins, teamcity lub inny system ciągłej integracji. Dodano bonus, jeśli musisz utrzymywać wiele serwerów lub pracowników do przetwarzania rozproszonego. Większość z tych systemów będzie miała środki pomocne w utrzymaniu. Ponadto będziesz mógł w pełni zautomatyzować przebiegi testowe, więc nie musisz czekać na wyniki przed kontynuowaniem, wystarczy zatwierdzić i odebrać wiadomość później. Miałem system, który potrzebował godzin, aby przejść przez zestawy testowe. Uruchomienie tej automatyzacji było najlepszą inwestycją mojego czasu. Zwłaszcza jeśli masz już skrypty do zbudowania wszystkiego.

Izolacja środowiska

Badacze spędzają nadmiernie dużo czasu izolując pojedynczy lub niewielki zestaw interesujących zmiennych od złożonych systemów za pomocą ich protokołów. Należy to również rozszerzyć na praktyki tworzenia oprogramowania. Możesz także sprawdzić konteneryzację za pomocą Docker lub Vagrant. Zapewni to lepszą kontrolę nad środowiskiem, w którym działa oprogramowanie.

Nie musisz mieć dużego zespołu, zanim to się opłaci, przez większość czasu byłem sam, ale skorzystałem z jego wprowadzenia. Oszczędność czasu i spokoju, pod warunkiem, że znacznie przewyższy to koszty, które mnie to kosztowało.

Newtopian
źródło
Zwykle zostawiałem kod w takiej postaci, w jakiej się go skończyłem, więc najnowsza wersja jest używana do obliczeń, więc może być konieczne ulepszenie tego. Także jeśli chodzi o dokładność algorytmiczną, czy nie powinienem zakładać, że używane biblioteki działają poprawnie?
llrs
możesz, chociaż wcześniej testowałem zależności zewnętrzne, ale to było rzadkie ... to twój kod, który powinieneś testować, czy poprawnie używałeś bibliotek? Czy zawodzi z widocznym skutkiem (Twój kod)? itp.
Newtopian
0
  1. Czy umiesz używać R? Po to jest.

  2. Zachować swój kod proste . Postaw na czytelność i nie przejmuj się wydajnością, chyba że jest to problem. Istnieją metodologie mające na celu powstrzymanie zespołów programistów przed wzajemnym zgłaszaniem błędów, nawet jeśli zespół jest jedną osobą.

  3. To powiedziawszy, dyscyplina kodowania jest bardzo ważna. Widziałem kod od wysoko wyszkolonych zaawansowanych naukowców i matematyków, i to jest okropne . Całkowicie ignorują formatowanie. Tworzą kod razem, jakby był pakowany próżniowo. Ich nazwy zmiennych są całkowicie tajemnicze. Nie piszą komentarzy, piszą niezrozumiałe komentarze lub komentarze mówią jedną rzecz, podczas gdy kod mówi inną. Nie rób tych rzeczy. Zawsze myśl z wyprzedzeniem o przyszłych zmianach, które ty lub inni musielibyście wprowadzić.

Mike Dunlavey
źródło
1
Używam R, mam nadzieję, że mój kod jest wystarczająco prosty, aby wykryć błędy, które mogłem napisać i każdy błąd, który mogłem zrobić. Postępuję zgodnie ze stylem formatowania kodu Google R i chciałbym sądzić, że komentarze są przydatne do wyjaśnienia, dlaczego podejmuję takie decyzje w kodzie.
llrs
@Llopis: Powiedziałbym, że jesteś na dobrej drodze.
Mike Dunlavey
@Llopis w zespołowym opracowywaniu oprogramowania, członkowie zespołu proszą o sprawdzenie kodu w oparciu o założenie, że więcej oczu może wykryć więcej błędów. Niestety, w twojej sytuacji nie ma nikogo, kto mógłby dokonać przeglądu twojej, a kultura tajemnicy w badaniach uniemożliwiłaby innym osobom (poza uprawnieniami w miejscu pracy) sprawdzenie twojego kodu.
rwong
1
@ rwong w rzeczywistości wolno mi teraz udostępniać mój kod badawczy, więc każdy może go przejrzeć na github
llrs
@Llopis: Jeszcze jeden powód, aby uczynić go czytelnym. Jedną rzeczą, którą próbuję zrobić, jest bardzo mały samouczek (w komentarzach) na ten temat, ponieważ są szanse, że wiedza czytelnika będzie inna niż moja.
Mike Dunlavey