[asterix61]

Heloł! Jakiś czas temu jeden z mirków prosił o code review, postanowiłem mu pomóc, tworząc artykuł omawiający bolączki jego kodu. Sam zainteresowany artykuł już przejrzał i pewne poprawki zostały naniesione więc brawo dla niego!

https://akademiapython.pl/code-review-indeed-scraper/

Smacznego! #python

[L.....k]

@asterix61:

Testy powinny być w głównym katalogu

Jestem fanem rozdystrybuowania testów jednostkowych po danych modułach. Dodatkowo jeżeli używasz pytesta to testy znacznie przyśpieszą, gdyż nie wszystkie testy potrzebują wszystkie fixture'y z conftesta

Plus taka struktura sprawia że ludzie znacznie chętniej i łatwiej piszą testy dla swoich funkcjonalności (bo wiadomo gdzie i jak je dodać) - ale to potraktuj jako bro science.

Zamiast standardowego "input" można użyć paczki "PyInputPlus" który jest dużo

[KevinMalone]

@asterix61: Przyjemny artykuł, plusik ( ͡~ ͜ʖ ͡°)

[DodatnieUjemny]

@asterix61:

self._url = url

To jest błąd, bo nigdzie tej zmiennej nie używasz.

Sam fakt używania self'ów jest zły- może to powodować side-effecty i ciężkie do wyłapania bugi. Przekazanie argumentu o funkcji >>>>> zmienne globalne/klasowe.

W tym przypadku nasza funkcja zwraca obiekt requests.models.Response, a gdy wystąpi błąd, zwróci ona requests.exceptions.RequestException. Te klasy nie mają tego samego interfejsu, co spowoduje, że nasz kod może generować masę błędów.

Sorry, ale to jest bullshit.

[asterix61]

@Lunatik:
Z mojego doświadczenia, ludzie chętniej piszą testy gdy się łatwo testuje, a do tej pory w projektach testy w innym miejscu widziałem tylko w przypadku django, ale dobrze znać inną perspektywe.

Można, to prawda. Ja staram się wyciskać z czystego pythona ile się da, więc dla prostego input nie chciałbym instalować zależności.

Skupiłem się na mikrośrodowiskach to prawda. Postaram się rozszerzyć ten artykuł i skupić się na architekturze kolejnym razem.