Dzisiejszy wpis omawia grę Sliding Puzzle. Gra ta ma proste reguły. Polega ona na tym, aby wykorzystać lukę do przesuwania puzzli, tak aby uzyskać liczby w rosnącej kolejności.

Dla przykładu, gra może mieć na początku następujący stan:

W tym przypadku możemy wykonać 3 możliwe ruchy:

• przesunąć 6 w dół,
• przesunąć 3 w górę,
• przesunąć 2 w prawo.

Gdy wybierzemy 3, wtedy plansza będzie wyglądać następująco:

Teraz możemy wykonać ruch 3 w dół albo 8 w prawo.

Implementacja

Lista list bardzo dobrze nadaje się do reprezentowania planszy:

    board = [
        [1, 0, 2],
        [3, 4, 5],
        [6, 7, 8]
    ]

Zero oznacza puste pole, od którego wychodzimy podczas rozgrywki.

Do sprawdzenia, czy dwie pozycje są sąsiednie, możemy wykorzystać  funkcję connected, która zwraca wartość logiczną:

def connected(a, b):
    row_diff = abs(a[0] - b[0])
    col_diff = abs(a[1] - b[1])
    return row_diff + col_diff == 1

Funkcja ta liczy dystans między pozycjami i jeśli uzyskana wartość wynosi 1, wtedy dwie pozycje są sąsiednie.

Operowanie samymi współrzędnymi pozycji nie jest wygodne. W tej sytuacji znacznie łatwiej jest odwołać się do określonej liczby, np.  3, zamiast do jej pozycji, która obecnie wynosi [1, 2]. Takie odwołanie staje się możliwe dzięki funkcji get_pos:

def get_pos(board, x):
    for row_index, row in enumerate(board):
        for col_index, value in enumerate(row):
            if value == x:
                return row_index, col_index
    return None

Powyższa funkcja przyjmuje planszę i szukaną wartość, a jako wynik zwraca jej pozycję. Teraz możemy napisać kod, który oceni, czy obie wartości zajmują sąsiednie miejsca na planszy:

print(connected(
  get_pos(board, 1),
  get_pos(board, 0)
))

Po zweryfikowaniu czy pozycje są sąsiadujące, czas najwyższy, by zapisać funkcję, która dokona zamiany wartości na wskazanych polach.

def swap(board, a, b):
    v1 = board[a[0]][a[1]]
    v2 = board[b[0]][b[1]]
    board[a[0]][a[1]] = v2
    board[b[0]][b[1]] = v1

Funkcja swap przyjmuje planszę i dwie dowolne pozycje, w obrębie których ma dojść do zamiany wartości.

Pozostaje jeszcze obsługa użytkownika. Chociaż gra jest prosta, to na etapie wprowadzania wartości, można popełnić różne błędy, które warto obsłużyć w tworzonym programie.

def ask_user(board):
    zero_pos = get_pos(board, 0)
    while True:
        try:
            nr = int(input('> '))
        except ValueError:
            print('number is required')
            continue

        user_pos = get_pos(board, nr)
        if user_pos is None:
            print('required number between 1 and 8')
            continue

        if not connected(zero_pos, user_pos):
            print('wrong number, try again')
            continue

        return user_pos

Funkcja ask_user jest odporna na podanie znaków różnych od cyfr. Sprawdza dostępność pozycji na planszy i na sam koniec weryfikuje, czy wybrane pola są sąsiednie względem siebie.

Do sprawdzenia, czy gra dobiegła końca, możemy wykorzystać dwie następujące funkcje:

def iter_board(board):
    for row in board:
        for value in row:
            yield value


def is_ordered(board):
    values = list(iter_board(board))
    return sorted(values) == values

Podczas gdy funkcja is_ordered odpowiada na pytanie, czy pola są ułożone rosnąco, funkcja iter_board tworzy generator, który umożliwia przejście po dwuwymiarowej strukturze. To pozwala na wykorzystanie funkcji sorted.

Na sam koniec pozostała nam jeszcze funkcja run game, która wykorzystuje wcześniej omówione funkcje.

def run_game():
    board = [
        [1, 0, 2],
        [3, 4, 5],
        [6, 7, 8]
    ]
    while True:
        for row in board:
            print(row)

        user_pos = ask_user(board)
        zero_pos = get_pos(board, 0)
        swap(board, user_pos, zero_pos)

        if is_ordered(board):
            break

    for row in board:
        print(row)

run_game()

Szczegółowy opis każdej z funkcji znajdziesz również na moim kanale youtube. Linki do odcinków znajdują się poniżej:

1. https://www.youtube.com/watch?v=CI2qCsF5EI4
2. https://www.youtube.com/watch?v=bkVBoX0NSYY
3. https://www.youtube.com/watch?v=ZJrVPcPdlww&t=3s
4. https://www.youtube.com/watch?v=ne-b6IW1bwI
5. https://www.youtube.com/watch?v=dhd1O237QMo
6. https://www.youtube.com/watch?v=RdSAOpNqpu8

W tym wpisie chciałbym przedstawić konstrukcje do zarządzania stanem jakie oferuje język Python.

Funkcja

Na początek warto poruszyć szczególny przypadek, jakim jest funkcja. Z założenia funkcja nie ma stanu więc nie powinna być rozpatrywana pod kątem jego zarządzania. Należy jednak podkreślić, że istnieje wiele odstępstw od tej reguły, o ile funkcja opiera swoje działanie:

• na korzystaniu z globalnych lub
• posiada mutowalny domyślny argument lub
• powoduje efekty uboczne, np. zapisanie danych do pliku.

W takich przypadkach możemy powiedzieć, że funkcja rzeczywiście zarządza stanem.

Domknięcie

Domknięcie to funkcja, która pamięta zmienne z zakresu funkcji nadrzędnej. Na pierwszy rzut oka wydaje się ona trudniejszym pojęciem do przyswojenia, ale w rzeczywistości tak nie jest.

W gruncie rzeczy chodzi tylko o hermetyzację stanu, czyli o utworzenie stanu w funkcji nadrzędnej, aby tylko funkcja wewnętrzna mogła nim zarządzać. To ograniczenie powoduje, że zmiana stanu jest możliwa jedynie w obrębie stworzonej funkcji.

W poniższym przykładzie dochodzi do zwrócenia nowej funkcji zarówno dla c1 jak i c2. Każda z tych funkcji pamięta swój własny licznik.

def make_counter():
    i = 0
    def counter():
        nonlocal i
        result = i
        i += 1
        return result
    return counter

c1 = make_counter()
print(c1())  # 0
print(c1())  # 1
print(c1())  # 2

c2 = make_counter()
print(c2()) # 0

Jeśli przykład z licznikami wydaje Ci się zbyt uproszczony, to zachęcam Cię do analizy praktycznego przypadku z biblioteki Selenium.

Generator

Kolejną konstrukcją dostępną w Pythonie, która świetnie sprawdza się w zarządzaniu stanem jest generator. Jest to rozwiązanie o charakterze pośrednim między domknięciem, a klasą. Temat generatora został omówiony w osobnym wpisie.

Przykład z użyciem generatora przedstawia analogiczny przypadek z odliczaniem:

def make_counter():
    i = 0
    while True:
        yield i
        i += 1

c1 = make_counter()
print(next(c1))  # 0
print(next(c1))  # 1
print(next(c1))  # 2

c2 = make_counter()
print(next(c2))  # 0

Największa różnica jaka jest pomiędzy użyciem generatora, a domknięcia to ilość zapisanego kodu. W przypadku generatora jest go zdecydowanie mniej, co więcej ta konstrukcja jest łatwiejsza niż funkcje wyższego rzędu. Warto wspomnieć również, że użycie generatora częściej będzie dotyczyć operacji związanych z iteracją.

Klasa

Następną konstrukcją, której nie mogło tu zabraknąć jest klasa. Poniższy przykład kodu również przedstawia odliczanie.

class Counter:
    
    def __init__(self):
        self._i = 0
        
    def next(self):
        result = self._i 
        self._i += 1
        return result

c1 = Counter()
print(c1.next())  # 0
print(c1.next())  # 1
print(c1.next())  # 2

c2 = Counter()
print(c2.next())  # 0

Klasy, w przeciwieństwie do domknięcia czy generatora, charakteryzuje możliwość manipulowania stanem z poziomu wielu różnych metod. To sprawia, że klasy są dużo bardziej elastyczne w zakresie zarządzania stanem.

Specjalnym przypadkiem klasy, który zasługuje na uwagę jest funktor, czyli klasa, która implementuje magiczną metodę call. Obiekty tej klasy można wywoływać podobnie jak zwykłe funkcje.

class Counter:

    def __init__(self):
        self._i = 0

    def __call__(self, *args, **kwargs):
        result = self._i
        self._i += 1
        return result

c1 = Counter()
print(c1())  # 0
print(c1())  # 1
print(c1())  # 2

c2 = Counter()
print(c2())  # 0

Podsumowanie
Jedną ze szczególnych zalet Pythona, którą bardzo cenię, to możliwość korzystania z wielu różnych konstrukcji. Oczywiście większość, jak nie wszystkie przypadki związane ze stanem, można rozwiązać z użyciem klas. To co jednak przemawia za alternatywami to fakt, że są prostsze i krótsze, a co za tym idzie łatwiejsze w zrozumieniu.  

Funkcyjne programowanie (dalej FP) to paradygmat, który pomimo coraz większej popularności i coraz lepszego wsparcia w językach programowania, wciąż wydaje się nieoczywisty w codziennym programowaniu.

Na tę kwestię warto spojrzeć szerzej, ponieważ stosowanie dowolnego paradygmatu wiąże się z przyjęciem pewnych odgórnych zasad, które z jednej strony torują myślenie o problemach, a z drugiej strony ograniczają pole manewru. Innymi słowy, oddajemy część kontroli/władzy w zamian za większą przewidywalność.

W przypadku FP dąży się do uzyskania kodu, który nie zarządza stanem ani również nie powoduje efektów ubocznych w postaci dodatkowych działań takich jak np. zapisanie pliku czy wysłanie wiadomości. To co zaskakuje w tym podejściu, to fakt, że z punktu widzenia użytkownika, taki kod tak naprawdę nie robi nic użytecznego. W takim razie, jaki jest powód dla którego programiści wybierają to podejście?

Motywacją do stosowania FP są korzyści wynikające z oddzielenia obliczeń od pozostałych akcji jakie mają miejsce w aplikacji.

Jeśli funkcja tylko oblicza wynik, bez wywoływania dodatkowych efektów, wtedy jest łatwiejsza w czytaniu oraz testowaniu. Dzieje się tak, ponieważ funkcja zawsze obliczy ten sam wynik dla tych samych danych wejściowych .

Spójrzmy na poniższy kod, który rysuje siatkę na ekranie.

Możemy wtedy:

• bezpośrednio wywołać funkcje odpowiedzialne za rysowanie,
• albo zgodnie z FP utworzyć funkcję, która będzie wolna od efektów.

Przedstawiony kod oblicza w pierwszej kolejności linie:

def grid_lines(pos, width, height, rows, cols):
    x, y = pos
    cell_width = width // cols
    cell_height = height // rows

    for row_y in range(rows + 1):
        line_start_pos = (x, y + cell_height * row_y)
        line_end_pos = (x + width, y + cell_height * row_y)
        yield line_start_pos, line_end_pos

    for col_x in range(cols + 1):
        line_start_pos = (x + cell_width * col_x, y)
        line_end_pos = (x + cell_width * col_x, y + height)
        yield line_start_pos, line_end_pos

by następnie użyć tę funkcję w następujący sposób:

for start_pos, end_pos in grid_lines(
    pos=(x, y),
    width=self.CELL_SIZE * self.CELL_COLS,
    height=self.CELL_SIZE * self.CELL_ROWS,
    rows=self.CELL_ROWS,
    cols=self.CELL_COLS
):
    pygame.draw.line(self._screen, color, start_pos, end_pos)

Docelowe użycie funkcji wygląda teraz trywialnie, ponieważ  grid_lines odpowiada za przeprowadzenie obliczeń.

Niestety stosowanie FP nie zawsze ma sens.

Gdyby funkcja grid_lines w języku Python, przy każdym wywołaniu zamiast generatora, zwracała listę krotek, wówczas takie podejście byłoby niepraktyczne z punktu widzenia wydajności.

We wpisie Kiedy przydaje się generator, został poruszony temat związany z wyodrębnianiem działań z pętli, który chciałbym tutaj rozszerzyć o kolejny przykład.

Spórzmy na poniższy fragment kodu:

for i in range(len(numbers) - 1):
    print(numbers[i], numbers[i+1])

Pętla skupia się na wyświetleniu elementów z przykładowej listy [1, 2, 3, 4, 5] w sposób następujący:

1 2
2 3
3 4
4 5

Tutaj można przygotować generator, który wyodrębni część związaną z indeksami.

def pairwise(xs):
    for i in range(len(xs) - 1):
        yield xs[i], xs[i+1]

Zapis tego generatora będzie tak wyglądać:

for a, b in pairwise(numbers):
    print(a, b)

Ta pętla jest nie tylko krótsza, ale również, co warte podkreślenia, ukrywa pracę z indeksami. Dzięki temu zabiegowi kod tej pętli staje się czytelniejszy, ponieważ nieistotne szczegóły zostają zepchnięte na dalszy plan.

Podsumowując, gdyby pairwise był funkcją, wtedy jej zastosowanie nie byłoby zasadne, ponieważ z każdym jej użyciem, tuż przed wykonaniem pętli, funkcja musiałaby wykonać się w całości.

Nauka trudniejszych rzeczy niesie ze sobą zawsze nowe szanse i wyzwania. Będąc na jej samym początku, niezwykle łatwo wyobrazić sobie jak wiele może zmienić nowa umiejętność. Z taką motywacją niemal wszystko wydaje się możliwe. Można wtedy poczuć, że jest się gotowym na maraton.

Jednak z czasem nadchodzi fala narastających problemów i frustracji. Nie da się ukryć, że rzeczy trudne wymagają nie tylko pełnego zaangażowania, ale również pochłaniają ogromną ilość czasu i uwagi. Nie chodzi jedynie o to, by iść do przodu, ale także, a może przede wszystkim o to, by napotkana trudność czy niepowodzenie nie zgasiły naszej motywacji.

Gdy napotykamy opór, prędzej czy później pojawia się pytanie, które jest tematem przewodnim dzisiejszego wpisu: Ile jeszcze?

Wielokrotnie spotykałem się z tym pytaniem prowadząc zajęcia z programowania.

Co warto podkreślić, sam czas trwania nauki wydaje się nie być najważniejszą kwestią, lecz przyjęta postawa, która opiera się na jak najszybszym osiągnięciu celu, a nie na samej drodze.

Stawiając pytanie ile jeszcze? chciałoby się spojrzeć na to wszystko z góry tak, aby widzieć przed sobą naukę rozbitą na poszczególne etapy. Chyba każdy chciałby znaleźć złotą metodę na osiągnięcie zamierzonego celu w rozsądnych ramach czasowych.

Niestety, w praktyce nie jest to już takie łatwe. Ilekroć próbowałem uczyć się nowych rzeczy patrząc na naukę z góry, tylekroć ta nauka kończyła się fiaskiem.

Z biegiem lat, pytanie: ile jeszcze? nabrało dla mnie innego znaczenia. Postrzegam je jako sygnał ostrzegawczy przed przyjęciem niewłaściwej postawy do nauki.

W tym wpisie chciałbym również przedstawić alternatywne podejście, które ułatwia naukę i pozwala na nią spojrzeć z innej perspektywy.  To podejście to:

     odnajdź radość i zabawę w programowaniu

Czy to żart? Ależ nie! Będąc w sytuacji gdy nauka nie idzie zgodnie z planem, co jest większego do stracenia?

Zabawa na pierwszy rzut oka, wydaje się zarazem taka dziecinna i niepoważna. Z wiekiem, nam dorosłym coraz trudniej przychodzi zaakceptowanie jej sprawczości, dlatego nie myśląc zbyt wiele, odrzucamy to podejście. Warto jednak się przełamać, dać sobie szansę, ponieważ zmiana myślenia może przynieść wymierne korzyści. Co z resztą widać w przypadku dzieci, które szybko i sprawnie przyswajają nowe rzeczy.

Nauka nie powinna stwarzać presji, nie trzeba wszystkiego wiedzieć ani być w tym płynnym czy perfekcyjnym, szczególnie na samym początku naszej drogi. Zdecydowanie lepiej jest działać wolniej, eksplorować i wydobywać z nauki to co zaciekawi i zachwyci.

Podczas nauki warto zastanowić się, czy jest jakiś wycinek przerobionego materiału, który wydaje się ciekawy, a zarazem przystępny. Jeśli tak to dobrym pomysłem będzie poświęcenie dodatkowych godzin i energii na dodatkową eksplorację: to może to być drobny program, eksperyment albo nietypowe użycie.

Moim zdaniem, podążanie za ciekawością i wyobraźnią jest kluczem do efektywnej nauki, której nieodłącznym elementem powinna być dobra zabawa.

Architektura warstwowa (eng. Layered Architecture) to popularny wzorzec przy tworzeniu oprogramowania, który opiera się na rozdzieleniu interfejsu użytkownika, logiki i persystencji danych na osobne warstwy.

Możliwość podzielenia projektu na warstwy sprawia, że przetestowanie każdej z osobna jest nie tylko prostsze, ale również szybsze i co ważne dokładniejsze niż w przypadku testowania aplikacji jako całość.

Jeśli testy w projekcie nie opierają się na rozbiciu, wtedy nie wykorzystujemy pełnego potencjału jaki niesie to podejście. To tak jak korzystać z urządzeń elektrycznych, bez podłączania ich do prądu.

Jednak nie da się ukryć, że podział na warstwy pociąga za sobą również pewne koszty.

Pierwszym z nich jest fakt, że biznesowe szczegóły są rozłożone na wszystkie warstwy. W praktyce oznacza to, że chcąc zrozumieć dowolną funkcjonalność w projekcie, konieczne jest przejście przez każdą z warstw z osobna.

Drugim kosztem są możliwe negatywne konsekwencje wprowadzania zmian w projekcie. W omawianym podejściu, górne warstwy są zależne od dolnych, a więc jeśli dokonamy zmiany w dolnej warstwie, to ta zmiana może spowodować kaskadowe wprowadzenie modyfikacji we wszystkich górnych warstwach skończywszy na warstwie prezentacji.

Bez wątpienia logowanie zdarzeń to istotna praktyka. Logi są nieocenioną pomocą, w sytuacji, gdy próbujemy zidentyfikować potencjalne problemy jakie wystąpiły w czasie działania aplikacji.

Niestety, w praktyce logi logom nie są równe. Czasem mamy ich w nadmiarze, a czasem zbyt mało, aby znaleźć przyczynę błędu. Niekiedy logi są zbyt precyzyjne, a niekiedy zbyt szczątkowe w informacje. To wciąż otwarty temat.

W tej notce chciałbym poruszyć kwestię kiedy warto logować.

Czy na przykład poniższa funkcja, która odpowiada na pytanie, czy elementy są posortowane, powinna cokolwiek logować?

def ordered(xs):
    for i in len(range(xs) - 1):
        if xs[i] > xs[i+1]:
            return False
    return True

Moim zdaniem nie, ponieważ ta funkcja jest oderwana od kontekstu użycia i trudno oczekiwać, by logowanie z jej wnętrza wnosiło większą wartość.

A teraz trochę trudniejszy przypadek. Mamy tu przykład klasy, która odzwierciedla pewne biznesowe wymagania. Czy w tej sytuacji warto włączyć logowanie?

class Battery:

    def __init__(self, value, limit):
    	if limit < 0:
            raise ValueError('Required positive limit')
        
        self._value = 0
        self._limit = limit
        
        self.charge(value)

    def charge(self, delta):
        if delta < 0:
            raise ValueError('Required non-negative value')
        self._value = min(self._value + delta, self._limit)

    @property
    def percents(self):
        return self._value / self._limit * 100

Mimo biznesowej logiki nie zastosowałbym tutaj żadnego logowania, ponieważ ta klasa jest oderwana od jej docelowego przypadku użycia. Warto zwrócić uwagę, że trudniejsze sytuacje, które mogą wpłynąć negatywnie na jej stan, są chronione poprzez wyjątki.

Kiedy warto logować?

Najlepszym miejscem do logowania są procedury biznesowe, czyli funkcje na najwyższym poziomie, które odpowiadają za realizację biznesowych zadań. To właśnie tam dysponujemy kontekstem na podstawie którego warto logować zdarzenia jakie mają miejsce w aplikacji.

Od czasu do czasu lubię napisać konsolową grę, która stanowi dla mnie punkt wyjścia do postawienia różnych pytań związanych z samym kodem, podziałami czy też technikami. W przeciwieństwie do większych projektów, praca nad drobnymi programami umożliwia uzyskanie szybszego feedbacku.

Podczas jednej z takich sesji, postawiłem sobie za cel oddzielenie zasadniczego kodu gry (czyli jej logiki) od rzeczy abstrakcyjnych, które nie były bezpośrednio powiązane ze szczegółami gry.

Zgodnie z tym założeniem, wydzieliłem następujące funkcje i klasy o charakterze abstrakcyjnym:

def matrix_find_value(matrix, x):
    for row in matrix:
        for value in row:
            if value == x:
                return True
    return False


def select(coll, indices):
    return [coll[i] for i in indices]


class ParserError(Exception):
    pass


def ask(parser, prompt='> '):
    while True:
        try:
            return parser(input(prompt))
        except ParserError as e:
            print(str(e) + ", try again")


class OneOfNumberParser:

    def __init__(self, numbers):
        self._numbers = numbers

    def __call__(self, s):
        try:
            value = int(s)
        except ValueError:
            raise ValueError('Required number')

        if value not in self._numbers:
            raise ValueError('Not available number')

        return value

Największą korzyścią tego kodu jest to, że w przypadku potencjalnych zmian wymagań gry, utworzone funkcje/klasy pozostaną nienaruszone.

Spójrzmy na przykład na funkcję select. Bez względu na charakter  wprowadzonych zmian w grze, funkcja ta cały czas będzie odpowiadać za pobranie wielu wartości z listy po indeksach.

Jedynie w przypadku większych zmian część kodu może okazać się zbędna.

W ostateczności, w przypadku większych zmian w logice gry, część kodu może okazać się co najwyżej niepotrzebna. Istnieje możliwość, że funkcja ask będzie do usunięcia, gdy docelowa gra zacznie działać w trybie graficznym.

Z drugiej strony można zadać sobie pytanie: czy ask i OneOfNumberParser są lepsze od następującej funkcji?

def update(board, symbol):
    while True:
        try:
            value = int(input('> '))
        except ValueError:
            print('Required number')
            continue

        if value < 1 or 9 < value:
            print('Required is number from 1 to 9')
            continue

        index = value - 1

        if board[index] != '_':
            print('The position is taken')
            continue
        
        break
  
    board[index] = symbol
        

Ta funkcja chociaż zawiera szczegóły gry (więc niestety jest podatna na zmiany), to mimo to jest łatwiejsza w zrozumieniu.

Warto zastanowić się nad zasadnością tworzenia abstrakcji.

Z jednej strony abstrakcje pozwalają kontrolować złożoność, pozwalają ukryć wszelkie nieistotne szczegóły, ale z drugiej strony użycie abstrakcji takich jak ask czy OneOfNumberParser czynią kod nieco trudniejszy w zrozumieniu.

Gdy nie mamy pewności to lepiej poczekać z odpowiedzią, by dać sobie trochę więcej czasu i dokonać przemyślanego wyboru.

Myślę, że poniższy cytat z tej strony świetnie nawiązuje do tematu abstrakcji:

Don't build technology unless you feel the pain of not having it. It applies to the big, architectural decisions as well as the smaller everyday programming decisions.

– Nathan Marz

Cytat z książki Reguły programowania. Jak pisać lepszy kod również trafnie opisuje to zagadnienie:

Skuteczne programowanie polega na opóźnianiu tego, co nieuniknione.

– Chris Zimmerman

W tym wpisie chciałbym przedstawić moje podejście dotyczące prowadzenia zajęć z programowania w języku Python.

Pierwszą rzeczą, którą kieruję się nauczając programowania to nie narzucanie żadnego stylu, ponieważ mam świadomość, że może to skomplikować naukę. Trudniej jest wtedy ocenić czy nauka programowania zmierza w dobrym kierunku, szczególnie, gdy poruszane problemy stają się coraz bardziej wymagające.

Drugą kwestią, która ma dla mnie znaczenie, to ograniczenie materiału do tego co niezbędne. Z jednej strony by nie przytłaczać, a z drugiej, żeby celowo ograniczyć różnorodność używanych konstrukcji. Im mniej dostępnych opcji, tym łatwiej się skupić na rozwiązaniu ćwiczenia, a tym samym osiągnąć lepszy rezultat z nauki.

Poniższy cytat idealnie opisuje to podejście:

Brak stylu jest stylem, brak ograniczeń jest ograniczeniem.
– Bruce Lee

Algorytm dotyczący spłaszczenia listy jest dla mnie szczególny, ponieważ podczas mojej pierwszej rozmowy kwalifikacyjnej otrzymałem zadanie związane właśnie z tym tematem.

Wtedy rozwiązanie tego algorytmu nie przyszło mi łatwo, ale z biegiem czasu udało mi się wypracować bardziej wyszukane rozwiązania.

Celem zadania było przekształcenie listy:

[10, [20, [25], 30], 50]

tak, by nie było w niej zagnieżdżeń:

[10, 20, 25, 30, 50]

Próba pierwsza:

results = []

def flatten(xs):
    for x in xs:
        if isinstance(x, list):
            flatten(x)
        else:
            results.append(x)
            

To była moja pierwsza próba, w której skorzystałem z globalnej results. Wadą tego podejścia jest fakt, że wynik ponownego wywołania funkcji flatten zapisywany jest w tej samej kolekcji, a zatem spłaszczając dwie odrębne listy uzyskamy jeden wspólny rezultat.

Próba druga:

def flatten(xs, results):
    for x in xs:
        if isinstance(x, list):
            flatten(x, results)
        else:
            results.append(x)

To rozwiązanie niweluje użycie globalnej zmiennej. W tym przypadku funkcja wymaga przekazania listy, która w ramach jej wywołania zostanie zmodyfikowana. W tej liście będą zachowane wyniki. To na co warto zwrócić uwagę to fakt, że funkcja ta nie zwraca wyniku, ponieważ z zasady funkcja, która modyfikuje argument, nie powinna zwracać go z użyciem instrukcji return.

Poniższy kod rozszerza to użycie:

def flatten(xs):
    results = []
    _flatten(xs, results)
    return results
    

def _flatten(xs, results):
    for x in xs:
        if isinstance(x, list):
            _flatten(x, results)
        else:
            results.append(x)

Funkcja flatten rozpoczyna wykonanie zadania poprzez stworzenie wynikowej pustej listy, by potem przekazać ją do _flatten i na sam koniec zwrócić wynik.

Próba trzecia

Poniższe rozwiązanie opiera się na instrukcji return, która zwraca pośrednie wyniki. Przykład ten idealnie obrazuje jak złożony problem zostaje podzielony na mniejsze części. Warto zauważyć, że każdorazowe użycie flatten zwraca spłaszczoną listę, która wymaga ujęcia w końcowym wyniku.

def flatten(xs):
    results = []
    for x in xs:
        if isinstance(x, list):
            results.extend(flatten(x))
        else:
            results.append(x)
    return results

Omawiany temat poruszyłem także w filmiku:

Próba czwarta

Wszystkie przedstawione wcześniej podejścia korzystają z rekurencji, która wg mnie jest najczytelniejszym sposobem rozwiązania tego problemu. Niestety poleganie na rekurencji nie zawsze jest dobrym pomysłem, ponieważ opiera się ona na stosie wywołań, który w dużym stopniu ma ograniczoną pamięć.

Poniższe rozwiązanie wykorzystuje jawny stos (w oparciu o listę).

Należy tutaj pamiętać, aby po przetworzeniu wartości zwrócić wynik w odwrotnej kolejności.

def flatten(xs):
    results = []
    stack = [xs]
    while stack:
        x = stack.pop()
        if isinstance(x, list):
            stack.extend(x)
        else:
            results.append(x)
    return results[::-1]

Zachęcam także do zapoznania się z poniższym filmikiem, który omawia ten temat.

Gdybym miał wskazać jedną rzecz, która w największym stopniu ułatwiła mi naukę programowania, to byłoby to systematyczne zadawanie pytań związanych z projektami nad którymi pracowałem, jak również z narzędziami z których regularnie korzystałem.

Stawiając sobie różne pytania nie wymagałem od siebie natychmiastowej i najlepszej odpowiedzi, wręcz przeciwnie, siła tego podejścia tkwiła w regularnym wracaniu do tych pytań i patrzeniu na problemy z różnych perspektyw. Dzięki tej metodzie, moje odpowiedzi z biegiem czasu dojrzewały i nabierały większej głębi.

Muszę przyznać, że również i dziś nie stronię od zadawania sobie pytań, bo przecież szukanie właściwej odpowiedzi na nurtujące zagadnienia, to najlepszy sposób na poszerzanie wiedzy.

Jedną z zasad jaką kieruję się w czasie pisania kodu jest dbanie o to, by zgłaszać błędy możliwie blisko źródła ich wystąpienia. Temat wydaje się trywialny, ale od zwykłej funkcji oczekuję, że zrobi jedną z dwóch poniższych rzeczy:

1) zrealizuje zadanie z sukcesem
2) albo zgłosi błąd.

Funkcje, które nie zgłaszają błędów są kłopotliwe, ponieważ znalezienie przyczyny wyciszonego błędu jest kosztowne.

Dobieranie trafnych nazw w kodzie to często wymagające zadanie. Myślę, że niemal każdy programista zgodzi się z tym stwierdzeniem.

Ten temat został poruszony w publikacjach takich jak: Czysty kod. Podręcznik dobrego programisty czy Kod doskonały. Jak tworzyć oprogramowanie pozbawione błędów i na blogu Digital Digressions by Stuart Sierra.

W poniższej notce chciałbym rozszerzyć kwestię dobierania nazw o własne spostrzeżenia.

#1 - A może wyrażenie zamiast nazwy?

Pracując z wysokopoziomowym językiem, takim jak Python, zwykle oceniam czy wybrana część kodu może zostać ujęta w formie wyrażenia.
Drobne wyrażenia często bowiem mówią więcej niż sama nazwa i przede wszystkim nie wymagają dodatkowego skoku do treści funkcji, aby zrozumieć jej działanie.

Więcej na temat wyrażeń można znaleźć w tym wpisie.

#2 - Oceń zakres użycia

Dobra nazwa, podobnie jak abstrakcja, współgra z resztą kodu dopóki ukrywa nieistotne szczegóły. W takiej sytuacji łatwiej jest się skupić na tym co istotne. Tutaj pomocna wskazówka: im mniejszy zakres użycia wybranej zmiennej, tym łatwiej o dobór ogólnej nazwy.

Temat abstrakcji został omówiony tutaj.

Przykład 1:

def xmin(a, b):
    return a if a < b else b

Funkcja xmin porównuje dwie dowolne wartości. Mogą to być np. ceny, ale z perspektywy definicji funkcji nie ma to większego znaczenia, dlatego w tym przypadku nazwy a i b są zupełnie wystarczające.

Przykład 2:

def cheapest_product(products):
    return min(products, key=lambda p: p.price)

Funkcja cheapest_products przyjmuje różne produkty, mogą to być np. książki, filmy, ubrania i stąd nazwa products mimo że ogólna, jest wystarczająca. W definicji lambda użyto także nazwę p, ponieważ jej zakres użycia jest wąski.

Przykład 3:

Poniższa funkcja sprawdza czy komponenty na stronie są posortowane rosnąco względem osi Y.

def ordered(xs):
    for i in len(range(xs) - 1):
        if xs[i] > xs[i+1]:
            return False
    return True
    
    
print(ordered([w.y for w in widgets]))

W kodzie została wyodrębniona funkcja ordered, która odpowiada na pytanie, czy wybrana sekwencja jest posortowana rosnąco. Warto zauważyć, że ta funkcja jest oderwana od przypadku użycia, nie pojawia się tutaj nazwa widgetu, lecz tylko xs, która oznacza sekwencję wartości.

Podsumowanie

Wszystkie trzy przykłady pozwalają na stosowanie krótkich i ogólnych nazw, ponieważ funkcje są oderwane od ich kontekstu.

Generatory przydają się do pracy z dużymi zbiorami danych, które nie mieszczą się w pamięci komputera. Natomiast sam muszę przyznać, że w mojej pracy zawodowej nie przetwarzałem tak dużych zbiorów danych bezpośrednio w Pythonie, aby mieć okazję wykorzystać generator.

Z czasem zrozumiałem, że stosowanie generatora tak naprawdę nie wymaga przetwarzania danych na dużą skalę. O tym właśnie w dzisiejszym wpisie.

Na samym początku warto porównać zapis funkcji i generatora:

def select_odd_numbers(xs):
    results = []
    for x in xs:
        if x % 2 == 1:
            results.append(x)
    return results

def select_odd_numbers(xs):
    for x in xs:
        if x % 2 == 1:
            yield x

Pierwszą znaczącą różnicą w tym przykładzie jest fakt, że wywołanie funkcji pociąga za sobą wykonanie całego kodu. Nie można przerwać wykonania funkcji od zewnątrz, ponieważ jest ona niepodzielna.

Dodatkowo warto zwrócić uwagę, że powyższa funkcja na czas wykonania, musi buforować wynik swojej pracy w pomocniczej liście.

Przypadek generatora jest odmienny, ponieważ jego praca jest podzielona na etapy. Przejście przez nie wymaga korzystania z funkcji next. To sprawia, że generator nie musi ani buforować wyników ani realizować w całości swojej pracy.

Znając zasadniczą różnicę między funkcją, a generatorem możemy łatwiej przeanalizować poniższy przykład:

for x in select_odd_numbers(numbers):
    if x == 13:
        break

W przypadku, gdy select_odd_numbers jest generatorem, break powoduje nie tylko przerwanie pętli, ale również kończy pracę generatora. Liczba 13 jest ostatnią liczbą jaką wyprodukuje generator.

Użycie  select_odd_numbers jako funkcji w tej sytuacji nie jest zasadne, ponieważ przed wykonaniem pętli, kod funkcji musi ukończyć się wcześniej, co w wielu przypadkach może okazać się niewydajne.

Generatory z racji leniwego wykonania, mogą wyodrębnić część działań z pętli, bez uszczerbku na jej wydajności.

Pierwszy raz o pojęciu czysty kod dowiedziałem się przeglądając w księgarni książkę Czysty kod. Podręcznik dobrego programisty. Książka ta zrobiła na mnie wtedy pozytywne wrażenie, ponieważ była ona inna od wszystkich jakie dotychczas znałem.
To co wyróżniało tą pozycję, to poruszone w niej zagadnienia związane z jakością oprogramowania, a także cenne wskazówki dotyczące samego kodu.

Najbardziej zapadającą w pamięć wskazówką z książki był poniższy cytat:

Funkcje powinny wykonywać jedną operację. Powinny robić to dobrze. Powinny robić tylko to.
– Czysty Kod, Robert C. Martin

Początkowo nie zwracałem uwagi na narastającą złożoność, ponieważ w większości przypadków, kod który wydzieliłem mogłem łatwiej i dokładniej przetestować. Była to zasłużona nagroda za włożony trud.

Z perspektywy czasu widzę, że kładłem zbyt duży nacisk na rozbijanie kodu, podążając "ślepo" za założeniami jakie stały za czystym kodem.

Niestety, to co może wymknąć się spod kontroli pisząc czysty kod, to paradoksalnie utrata czytelności kodu. Porozbijany kod jest niemożliwy w czytaniu linia po linii jak opowiadanie. W pogoni za szczegółami trzeba skakać po plikach i łączyć wiele faktów, aby zrozumieć to za co odpowiada aktualny wybrany fragment kodu.

Ktoś może powiedzieć: Po to dzielę kod na funkcje/klasy, aby nie myśleć o szczegółach.

Problem w tym, że w przypadku biznesowego kodu, biznesowe szczegóły są istotne i próba ich ukrywania zwykle zawodzi, wywołując efekt odwrotny do zamierzonego. Innymi słowy, tworzenie abstrakcji z biznesowych szczegółów może okazać się nie do końca trafionym pomysłem.

Czyli jak widać założenia czystego kodu, nie zawsze się sprawdzają, ponieważ rozbijanie kodu może wpłynąć negatywnie na jego czytelność.

Warto dopuszczać do powtórzeń, a w rezultacie zwlekać z DRY. Dzięki temu możemy zredukować liczbę możliwych skoków w czytaniu, do tych niezbędnych w zrozumieniu rozpatrywanego kodu.

Zarówno podejście z czystym kodem, jak i podejście z tolerowaniem powtórzeń ma na celu ułatwienie pracy z oprogramowaniem. To pierwsze ułatwia modyfikowanie, ponieważ zmianę wprowadza się tylko w jednym miejscu, a powstały efekt ma szeroki zasiąg. Drugie podejście umożliwia skupienie całej uwagi na czytaniu i analizie kodu dostępnym w jednym miejscu.

W praktyce korzystam z obu podejść. Pisząc kod preferuję wydzielać te części kodu, które mają marginalną rolę i nie są związane bezpośrednio z biznesem.
Natomiast część biznesową piszę bez nacisku na wyodrębnianie. Wychodzę z założenia, że biznesowa logika do pewnego stopnia może i ma prawo się powtarzać.