ciągła integracja oprogramowania naukowego

Nie jestem inżynierem oprogramowania. Jestem doktorantem z dziedziny geologii.

Prawie dwa lata temu zacząłem programować oprogramowanie naukowe. Nigdy nie korzystałem z ciągłej integracji (CI), głównie dlatego, że na początku nie wiedziałem, że istnieje i byłem jedyną osobą pracującą nad tym oprogramowaniem.

Ponieważ baza oprogramowania działa, inni ludzie zaczynają się nim interesować i chcą wnieść swój wkład w oprogramowanie. Plan jest taki, że inne osoby na innych uniwersytetach wdrażają dodatki do podstawowego oprogramowania. (Boję się, że mogą wprowadzić błędy). Ponadto oprogramowanie stało się dość złożone i coraz trudniejsze do przetestowania, a także planuję kontynuować pracę nad nim.

Z tych dwóch powodów coraz częściej zastanawiam się nad użyciem CI. Ponieważ nigdy nie miałem wykształcenia inżyniera oprogramowania i nikt wokół mnie nie słyszał o CI (jesteśmy naukowcami, nie ma programistów), ciężko jest mi zacząć projekt.

Mam kilka pytań, na które chciałbym uzyskać porady:

Przede wszystkim krótkie wyjaśnienie działania oprogramowania:

• Oprogramowanie jest kontrolowane przez jeden plik .xml zawierający wszystkie wymagane ustawienia. Oprogramowanie uruchamia się po prostu przekazując ścieżkę do pliku .xml jako argument wejściowy, a on uruchamia się i tworzy kilka plików z wynikami. Jedno uruchomienie może potrwać ~ 30 sekund.

• To oprogramowanie naukowe. Prawie wszystkie funkcje mają wiele parametrów wejściowych, których typami są w większości klasy dość złożone. Mam wiele plików .txt z dużymi katalogami, które są używane do tworzenia instancji tych klas.

Teraz przejdźmy do moich pytań:

1. testy jednostkowe, testy integracyjne, testy kompleksowe? : Moje oprogramowanie ma teraz około 30 000 linii kodu z setkami funkcji i ~ 80 klasami. To dziwne, że zaczynam pisać testy jednostkowe dla setek już zaimplementowanych funkcji. Pomyślałem więc o stworzeniu kilku przypadków testowych. Przygotuj 10–20 różnych plików .xml i uruchom oprogramowanie. Sądzę, że nazywa się to testami end-to-end? Często czytam, że nie powinieneś tego robić, ale może na początek jest dobrze, jeśli masz już działające oprogramowanie? Czy jest to po prostu głupi pomysł, aby spróbować dodać CI do już działającego oprogramowania.

2. Jak piszesz testy jednostkowe, jeśli parametry funkcji są trudne do utworzenia? Załóżmy, że mam funkcję double fun(vector<Class_A> a, vector<Class_B>)i zwykle musiałbym najpierw przeczytać w wielu plikach tekstowych, aby utworzyć obiekty typu Class_Ai Class_B. Pomyślałem o stworzeniu niektórych fikcyjnych funkcji, takich jak Class_A create_dummy_object()bez wczytywania plików tekstowych. Pomyślałem także o wdrożeniu pewnego rodzaju serializacji . (Nie planuję testować tworzenia obiektów klasy, ponieważ zależą one tylko od wielu plików tekstowych)

3. Jak pisać testy, jeśli wyniki są bardzo zmienne? Moje oprogramowanie wykorzystuje duże symulacje Monte Carlo i działa iteracyjnie. Zwykle masz ~ 1000 iteracji i przy każdej iteracji tworzysz ~ 500-20 000 instancji obiektów na podstawie symulacji Monte Carlo. Jeśli tylko jeden wynik jednej iteracji jest nieco inny, całe nadchodzące iteracje są zupełnie inne. Jak sobie radzisz z tą sytuacją? Myślę, że to duża zaleta w porównaniu z testami typu end-to-end, ponieważ wynik końcowy jest bardzo zmienny?

Wszelkie inne porady z CI są bardzo mile widziane.

Testowanie oprogramowania naukowego jest trudne, zarówno ze względu na złożoną tematykę, jak i typowe naukowe procesy rozwojowe (czyli hakowanie go, aż zadziała, co zwykle nie skutkuje testowalnym projektem). To trochę ironiczne, biorąc pod uwagę, że nauka powinna być powtarzalna. Jakimi zmianami w porównaniu do „normalnego” oprogramowania nie jest to, czy testy są przydatne (tak!), Ale jakie rodzaje testów są odpowiednie.

Obsługa losowości: wszystkie uruchomienia oprogramowania MUSZĄ być odtwarzalne. Jeśli używasz technik Monte Carlo, musisz umożliwić podanie konkretnego źródła dla generatora liczb losowych.

• Łatwo o tym zapomnieć np. Przy użyciu rand()funkcji C, która zależy od stanu globalnego.
• Idealnie generator liczb losowych jest przekazywany jako jawny obiekt przez twoje funkcje. randomStandardowy nagłówek biblioteki C ++ 11 ułatwia to.
• Zamiast współdzielić losowy stan pomiędzy modułami oprogramowania, uznałem, że warto utworzyć drugi RNG, który jest rozstawiony przez losową liczbę z pierwszego RNG. Następnie, jeśli liczba żądań do RNG przez inny moduł zmienia się, sekwencja wygenerowana przez pierwszy RNG pozostaje taka sama.

Testy integracyjne są całkowicie w porządku. Są dobrzy w sprawdzaniu, czy różne części oprogramowania działają poprawnie, i do uruchamiania konkretnych scenariuszy.

• Jako minimalny poziom jakości „nie ulega awarii” może już być dobrym wynikiem testu.
• Aby uzyskać silniejsze wyniki, będziesz musiał również sprawdzić wyniki względem niektórych wartości wyjściowych. Jednak kontrole te będą musiały być nieco tolerancyjne, np. Uwzględniać błędy zaokrąglania. Pomocne może być również porównanie statystyk podsumowujących zamiast pełnych wierszy danych.
• Jeśli sprawdzanie w stosunku do linii bazowej byłoby zbyt delikatne, sprawdź, czy dane wyjściowe są prawidłowe i czy spełniają pewne ogólne właściwości. Mogą być ogólne („wybrane lokalizacje muszą być oddalone co najmniej 2 km od siebie”) lub specyficzne dla scenariusza, np. „Wybrana lokalizacja musi znajdować się w tym obszarze”.

Podczas uruchamiania testów integracyjnych dobrym pomysłem jest napisanie testera jako osobnego programu lub skryptu. Ten tester uruchamia niezbędną konfigurację, uruchamia testowany plik wykonywalny, sprawdza wszelkie wyniki, a następnie czyści.

Sprawdzanie stylu testów jednostkowych może być dość trudne do wprowadzenia do oprogramowania naukowego, ponieważ oprogramowanie nie zostało do tego zaprojektowane. W szczególności testy jednostkowe stają się trudne, gdy testowany system ma wiele zewnętrznych zależności / interakcji. Jeśli oprogramowanie nie jest wyłącznie obiektowe, na ogół nie można wyśmiewać / usuwać tych zależności. Uważam, że najlepiej jest w dużej mierze unikać testów jednostkowych dla takiego oprogramowania, z wyjątkiem funkcji czysto matematycznych i funkcji użytkowych.

Nawet kilka testów jest lepszych niż brak testów. W połączeniu z zaznaczeniem „musi się skompilować” jest to dobry początek ciągłej integracji. Zawsze możesz wrócić i dodać więcej testów później. Następnie możesz nadać priorytet obszarom kodu, które są bardziej podatne na uszkodzenie, np. Ponieważ mają większą aktywność programistyczną. Aby zobaczyć, które części kodu nie są objęte testami jednostkowymi, możesz użyć narzędzi do pokrycia kodu.

Testowanie ręczne: Zwłaszcza w przypadku złożonych domen problemowych nie będziesz w stanie przetestować wszystkiego automatycznie. Np. Obecnie pracuję nad problemem wyszukiwania stochastycznego. Jeśli sprawdzę, czy moje oprogramowanie zawsze daje ten sam wynik, nie mogę go poprawić bez przerwania testów. Zamiast tego ułatwiłem przeprowadzanie testów ręcznych : uruchamiam oprogramowanie ze stałym ziarnem i otrzymuję wizualizacjęwyniku (w zależności od twoich preferencji, R, Python / Pyplot i Matlab ułatwiają uzyskanie wysokiej jakości wizualizacji twoich zestawów danych). Mogę użyć tej wizualizacji, aby sprawdzić, czy coś nie poszło bardzo źle. Podobnie, śledzenie postępów twojego oprogramowania poprzez rejestrowanie danych wyjściowych może być wykonalną techniką ręcznego testowania, przynajmniej jeśli mogę wybrać rodzaj zdarzeń, które mają być rejestrowane.

To dziwne, że zaczynam pisać testy jednostkowe dla setek już zaimplementowanych funkcji.

Będziesz chciał (zwykle) pisać testy , zmieniając wymienione funkcje. Nie musisz siedzieć i pisać setek testów jednostkowych dla istniejących funkcji, co byłoby (w dużej mierze) stratą czasu. Oprogramowanie działa (prawdopodobnie) w porządku. Celem tych testów jest upewnienie się, że przyszłe zmiany nie psują starego zachowania. Jeśli nigdy więcej nie zmienisz określonej funkcji, prawdopodobnie nigdy nie warto poświęcić czasu na jej przetestowanie (ponieważ obecnie działa, zawsze działała i prawdopodobnie nadal będzie działać). Polecam lekturę Skuteczne działanie ze starszym kodemautor: Michael Feathers na tym froncie. Ma kilka świetnych ogólnych strategii testowania rzeczy, które już istnieją, w tym techniki łamania zależności, testy charakteryzacji (wyniki funkcji kopiuj / wklej do zestawu testów, aby zapewnić zachowanie zachowania regresji) i wiele więcej.

Jak piszesz testy jednostkowe, jeśli parametry funkcji są trudne do utworzenia?

Idealnie nie. Zamiast tego ułatwisz tworzenie parametrów (a zatem ułatwisz testowanie swojego projektu). Trzeba przyznać, że zmiany w projekcie wymagają czasu, a refaktoryzacja może być trudna w przypadku starszych projektów, takich jak Twój. TDD (Test Driven Development) może w tym pomóc. Jeśli parametry są bardzo trudne do utworzenia, będziesz mieć dużo problemów z pisaniem testów w stylu testu.

W krótkim okresie używaj kpiny, ale uważaj na drwiny z piekła i problemy, które towarzyszą im w dłuższej perspektywie. Jednak gdy dorastałem jako inżynier oprogramowania, zdałem sobie sprawę, że drwiny są prawie zawsze mini-zapachem, które próbują ominąć jakiś większy problem i nie rozwiązują podstawowego problemu. Lubię to nazywać „owinięciem torfu”, ponieważ jeśli położysz kawałek cyny na kawałku psiej kupy na dywanie, nadal będzie śmierdział. Musisz właściwie wstać, zgarnąć kupę i wrzucić ją do śmieci, a następnie wyjąć śmieci. To oczywiście więcej pracy i ryzykujesz dostaniem się kału do rąk, ale na dłuższą metę lepiej dla ciebie i twojego zdrowia. Jeśli nadal pakujesz te kupy, nie będziesz chciał dłużej mieszkać w domu. Drwiny mają podobny charakter.

Na przykład, jeśli masz Class_Aplik, który jest trudny do utworzenia, ponieważ musisz czytać w 700 plikach, możesz po prostu wyśmiewać go. Następną rzeczą, którą wiesz, jest fakt, że twoja próbka przestaje być aktualna, a prawdziwy Class_A robi coś zupełnie innego niż próbka, a twoje testy wciąż mija, nawet jeśli powinny zawieść. Lepszym rozwiązaniem jest rozbicie Class_Ana łatwiejsze w użyciu / przetestowanie komponentów, a zamiast tego przetestowanie tych komponentów. Może napisz jeden test integracji, który faktycznie trafi na dysk i upewnij się, że Class_Adziała jako całość. A może po prostu masz konstruktor Class_A, który możesz utworzyć za pomocą prostego ciągu (reprezentującego twoje dane) zamiast odczytywać z dysku.

Jak pisać testy, jeśli wyniki są bardzo zmienne?

Kilka wskazówek:

1) Użyj odwrotności (lub, bardziej ogólnie, testowania na podstawie właściwości). O co chodzi [1,2,3,4,5]? Brak pomysłu. Co jest ifft(fft([1,2,3,4,5]))? Powinien być [1,2,3,4,5](lub blisko niego, mogą pojawić się błędy zmiennoprzecinkowe).

2) Użyj „znanych” twierdzeń. Jeśli napiszesz funkcję wyznacznika, może być trudno powiedzieć, czym jest wyznacznik macierzy 100 x 100. Ale wiesz, że wyznacznikiem macierzy tożsamości jest 1, nawet jeśli jest 100 x 100. Wiesz również, że funkcja powinna zwracać 0 na nieodwracalnej macierzy (jak 100 x 100 pełna wszystkich zer).

3) Używaj szorstkich stwierdzeń zamiast dokładnych stwierdzeń. Jakiś czas temu napisałem jakiś kod, który rejestrował dwa obrazy, generując punkty wiążące, które tworzą mapowanie między obrazami i wypaczając między nimi, aby je dopasować. Może zarejestrować się na poziomie subpikseli. Jak możesz to przetestować? Rzeczy jak:

EXPECT_TRUE(reg(img1, img2).size() < min(img1.size(), img2.size()))

ponieważ możesz zarejestrować się tylko na nakładających się częściach, zarejestrowany obraz musi być mniejszy lub równy twojemu najmniejszemu obrazowi), a także:

scale = 255
EXPECT_PIXEL_EQ_WITH_TOLERANCE(reg(img, img), img, .05*scale)

ponieważ zarejestrowany sam obraz powinien być ZAMKNIĘTY dla siebie, ale możesz napotkać nieco więcej niż błędy zmiennoprzecinkowe z powodu używanego algorytmu, więc po prostu sprawdź, czy każdy piksel ma +/- 5% prawidłowego zakresu (0–255 to wspólny zakres, skala szarości). Powinien być co najmniej tego samego rozmiaru. Możesz nawet po prostu przetestować dym (tzn. Zadzwoń i upewnij się, że się nie zawiesi). Ogólnie rzecz biorąc, ta technika jest lepsza w przypadku większych testów, w których wyniku końcowego nie można (łatwo) obliczyć a priori przed uruchomieniem testu.

4) Użyj LUB ZAPISZ losowy numer początkowy dla swojego RNG.

Działa nie muszą być powtarzalne. Fałszywe jest jednak, że jedynym sposobem na uzyskanie powtarzalnego przebiegu jest dostarczenie określonego ziarna do generatora liczb losowych. Czasami testowanie losowości jest cenne . Widziałem błędy w kodzie naukowym, które pojawiają się w zdegenerowanych przypadkach, które zostały wygenerowane losowo . Zamiast zawsze wywoływać funkcję z tym samym ziarnem, wygeneruj losowe ziarno, a następnie użyj tego ziarna i zapisz jego wartość. W ten sposób każde uruchomienie ma inne losowe ziarno, ale jeśli wystąpi awaria, możesz ponownie uruchomić wynik, używając ziarna, które zalogowałeś się w celu debugowania. Właściwie użyłem tego w praktyce i to zmiażdżyło błąd, więc pomyślałem, że wspomnę o tym.Wada: Musisz zalogować swoje testy. Zaleta: poprawność i nukanie błędów.

HTH.

1. Rodzaje testu

   • To dziwne, że zaczynam pisać testy jednostkowe dla setek już zaimplementowanych funkcji

     Pomyśl o tym na odwrót: jeśli łatka dotykająca kilku funkcji psuje jeden z twoich kompleksowych testów, jak zamierzasz dowiedzieć się, który z nich jest problemem?

     O wiele łatwiej jest pisać testy jednostkowe dla poszczególnych funkcji niż dla całego programu. O wiele łatwiej jest mieć pewność, że masz dobry zasięg poszczególnych funkcji. Znacznie łatwiej jest zrefaktoryzować funkcję, gdy masz pewność, że testy jednostkowe wychwycą wszystkie złamane przez siebie przypadki narożne.

     Pisanie testów jednostkowych dla już istniejących funkcji jest całkowicie normalne dla każdego, kto pracował nad starszą bazą kodu. Są to dobry sposób, aby przede wszystkim potwierdzić zrozumienie funkcji, a po napisaniu są dobrym sposobem na znalezienie nieoczekiwanych zmian w zachowaniu.

   • Warto też przeprowadzić kompleksowe testy. Jeśli łatwiej je napisać, zrób to najpierw i dodaj testy jednostkowe ad-hoc, aby objąć funkcje, które najbardziej niepokoją cię w przypadku uszkodzenia innych. Nie musisz robić tego wszystkiego naraz.

   • Tak, dodanie CI do istniejącego oprogramowania jest rozsądne i normalne.

2. Jak pisać testy jednostkowe

   Jeśli twoje obiekty są naprawdę drogie i / lub złożone, napisz pozory. Możesz po prostu połączyć testy przy użyciu próbnych testów osobno z testami przy użyciu rzeczywistych obiektów, zamiast przy użyciu polimorfizmu.

   W każdym razie powinieneś mieć jakiś łatwy sposób na tworzenie instancji - funkcja do tworzenia instancji fikcyjnych jest powszechna - ale sensowne jest także przeprowadzenie testów dla prawdziwego procesu tworzenia.

3. Zmienne wyniki

   Musisz mieć kilka niezmienników dla wyniku. Przetestuj je, a nie pojedynczą wartość liczbową.

   Możesz podać próbny generator liczb pseudolosowych, jeśli twój kod Monte Carlo akceptuje go jako parametr, co uczyniłoby wyniki przewidywalnymi przynajmniej dla dobrze znanego algorytmu, ale jest kruchy, chyba że dosłownie zwraca tę samą liczbę za każdym razem.

1. Nigdy nie jest głupim pomysłem dodanie CI. Z doświadczenia wiem, że taka jest droga, gdy masz projekt open source, w którym ludzie mogą wnieść swój wkład. CI pozwala powstrzymać ludzi przed dodawaniem lub zmianą kodu, jeśli kod psuje Twój program, więc jest prawie nieoceniony w posiadaniu działającej bazy kodu.

   Rozważając testy, z pewnością możesz zapewnić kilka testów end-to-end (myślę, że jest to podkategoria testów integracyjnych), aby upewnić się, że przepływ kodu działa tak, jak powinien. Powinieneś podać przynajmniej kilka podstawowych testów jednostkowych, aby upewnić się, że funkcje generują prawidłowe wartości, ponieważ w ramach testów integracyjnych można zrekompensować inne błędy popełnione podczas testu.

2. Tworzenie obiektów testowych jest naprawdę trudne i pracochłonne. Masz rację, chcąc tworzyć atrapy. Te obiekty powinny mieć pewne wartości domyślne, ale wielkość liter, dla których z pewnością wiesz, jaki powinien być wynik.

3. Problem z książkami na ten temat polega na tym, że krajobraz CI (i innych części devops) ewoluuje tak szybko, że wszystko w książce prawdopodobnie stanie się nieaktualne kilka miesięcy później. Nie znam żadnych książek, które mogłyby ci pomóc, ale Google powinien jak zawsze być twoim wybawcą.

4. Powinieneś sam uruchomić testy wiele razy i przeprowadzić analizę statystyczną. W ten sposób możesz zaimplementować niektóre przypadki testowe, w których bierzesz medianę / średnią z wielu przebiegów i porównujesz ją z analizą, aby wiedzieć, które wartości są poprawne.

Kilka porad:

• Użyj integracji narzędzi CI na swojej platformie GIT, aby powstrzymać uszkodzony kod przed wejściem do bazy kodu.
• przestań scalać kod, zanim inni programiści dokonają przeglądu. To sprawia, że ​​błędy są łatwiej znane i ponownie uniemożliwia wejściu uszkodzonego kodu do twojej bazy kodów.

W odpowiedzi przed Amonem wspomniano już o kilku bardzo ważnych kwestiach. Pozwól, że dodam jeszcze:

1. Różnice między tworzeniem oprogramowania naukowego a oprogramowaniem komercyjnym

W przypadku oprogramowania naukowego zwykle koncentruje się na problemie naukowym. Problemy polegają bardziej na radzeniu sobie z teoretycznym tłem, znalezieniu najlepszej metody numerycznej itp. Oprogramowanie to tylko jedna, mniej więcej, niewielka część pracy.

Oprogramowanie jest w większości przypadków pisane przez jedną lub kilka osób. Często jest napisany dla konkretnego projektu. Po zakończeniu projektu i opublikowaniu wszystkiego w wielu przypadkach oprogramowanie nie jest już potrzebne.

Oprogramowanie komercyjne jest zwykle opracowywane przez duże zespoły przez dłuższy czas. Wymaga to dużego planowania w zakresie architektury, projektowania, testów jednostkowych, testów integracyjnych itp. Planowanie to wymaga znacznej ilości czasu i doświadczenia. W środowisku naukowym zwykle nie ma na to czasu.

Jeśli chcesz przekonwertować swój projekt na oprogramowanie podobne do oprogramowania komercyjnego, sprawdź następujące elementy:

• Czy masz czas i zasoby?
• Jaka jest długoterminowa perspektywa oprogramowania? Co stanie się z oprogramowaniem po zakończeniu pracy i opuszczeniu uniwersytetu?

2. Testy kompleksowe

Jeśli oprogramowanie staje się coraz bardziej złożone i pracuje nad nim kilka osób, testy są obowiązkowe. Ale jak Amon już wspomniano, dodając testów jednostkowych do oprogramowania naukowego jest dość trudne. Musisz więc zastosować inne podejście.

Ponieważ twoje oprogramowanie pobiera dane wejściowe z pliku, podobnie jak większość programów naukowych, idealnie nadaje się do tworzenia kilku przykładowych plików wejściowych i wyjściowych. Powinieneś uruchamiać te testy automatycznie w każdym wydaniu i porównywać wyniki z próbkami. Może to być bardzo dobry zamiennik testów jednostkowych. W ten sposób otrzymujesz również testy integracyjne.

Oczywiście, aby uzyskać powtarzalne wyniki, powinieneś użyć tego samego ziarna dla generatora liczb losowych, jak już napisał amon .

Przykłady powinny obejmować typowe wyniki twojego oprogramowania. Powinno to również obejmować przypadki brzegowe przestrzeni parametrów i algorytmy numeryczne.

Powinieneś spróbować znaleźć przykłady, które nie wymagają zbyt wiele czasu do uruchomienia, ale nadal obejmują typowe przypadki testowe.

3. Ciągła integracja

Ponieważ uruchomienie przykładów testowych może zająć trochę czasu, myślę, że ciągła integracja nie jest możliwa. Prawdopodobnie będziesz musiał omówić dodatkowe części ze swoimi kolegami. Na przykład muszą pasować do zastosowanych metod numerycznych.

Myślę więc, że lepiej jest przeprowadzić integrację w dobrze zdefiniowany sposób po omówieniu podstaw teoretycznych i metod numerycznych, dokładnych testów itp.

Nie sądzę, aby dobrym rozwiązaniem był ciągły proces integracji.

Nawiasem mówiąc, czy używasz systemu kontroli wersji?

4. Testowanie algorytmów numerycznych

Jeśli porównujesz wyniki liczbowe, np. Podczas sprawdzania wyników testu, nie powinieneś sprawdzać liczb zmiennoprzecinkowych pod kątem równości. Zawsze mogą występować błędy zaokrąglania. Zamiast tego sprawdź, czy różnica jest mniejsza niż określony próg.

Dobrym pomysłem jest również sprawdzenie algorytmów w stosunku do różnych algorytmów lub sformułowanie problemu naukowego w inny sposób i porównanie wyników. Jeśli uzyskasz te same wyniki przy użyciu dwóch lub więcej niezależnych sposobów, jest to dobry wskaźnik, że twoja teoria i implementacja są poprawne.

Możesz wykonać te testy w kodzie testowym i użyć najszybszego algorytmu dla kodu produkcyjnego.

Radzę starannie wybrać sposób, w jaki wydasz swoje wysiłki. W mojej dziedzinie (bioinformatyka) najnowocześniejsze algorytmy zmieniają się tak szybko, że wydawanie energii na sprawdzenie błędów może być lepiej wydane na sam algorytm.

To, co jest cenione, to:

• czy jest to obecnie najlepsza metoda pod względem algorytmu?
• jak łatwo jest przenieść na różne platformy obliczeniowe (różne środowiska HPC, wersje systemu operacyjnego itp.)
• solidność - czy działa na MOIM zestawie danych?

Instynkt budowy kuloodpornej bazy kodowej jest szlachetny, ale warto pamiętać, że nie jest to produkt komercyjny. Uczyń go tak przenośnym, jak to możliwe, odpornym na błędy (dla twojego typu użytkownika), wygodnym dla innych użytkowników, a następnie skup się na samym algorytmie