[ProfesorBigos]

Tak sobie pomyślałem, że przy sobocie napiszę o "alternatywnym" sposobie programowania w pythonie, który akurat mi bardzo pomógł, więc może znajdą się tutaj osoby, którym też umożliwi bardziej produktywne kodowanie. Pomysł nie jest mój, to raczej zlepek porad znalezionych w internecie, w tym kilku prezentacjach z różnych konferencji pythonowych do obejrzenia na yt. Raczej nie przyda się zawodowym inżynierom oprogramowania, którzy mają z góry określone co i jak mają zrobić. To bardziej dla tych, którzy sami zarządzają swoim projektem i mają problemy z ogarnięciem wielu elementów jednocześnie

Główną zasadą jest to, żeby nie patrzeć na swój program, jako na coś, co mamy stworzyć raz i tak ma już pozostać. To raczej żywy ekosystem, który ewoluuje z chaotycznej zupy niepasujących do siebie elementów, aż utworzy skomplikowany, wysokopoziomowy system. Python jest poniekąd tak zaprojektowany, żeby umożliwiał nie tylko sprawne pisanie kodu, ale również, a nawet przede wszystkim, jego modyfikowanie.

Zacznij od napisania jednego testu. Wyobraź sobie, co twój program ma robić. Czy to ma być biblioteka z której ktoś będzie importował jakieś klasy. A może skrypt, który ma coś pobrać z internetu. Cokolwiek to ma być, w swoim pierwszym teście napisz, jak tego będziesz używał. Zignoruj wszystkie dodatkowe parametry, argumenty. Test ma być krótki i prosty.

Gdy już masz to napisane, napisz swój pierwszy kod, który ten test przechodzi. I tutaj trzymaj się zasady "w dupie mam jakość". Pisz brzydko, pisz szybko, nie przejmuj się kompletnie niczym. Jak nie chce ci się pisać funkcji, po prostu zrób kopiuj wklej. Jak nie chce ci się pisać klasy, umieść parametry w słowniku. Twoim jedynym celem jest przejście twojego testu.

Twój test przeszedł. Pora na refaktoryzację. Ale nie taką poważną. Po prostu przeskanuj kod używając pylint, mypy, flake8 czy innych narzędzi. Postaraj się naprawić wszystkie wskazane problemy. Ale jeśli coś wymaga zbyt dużo zachodu, olej. Na koniec sformatuj wszystko przy pomocy black albo yapf i gotowe.

Dopisz drugi test. Dodaj w nim użycie nowej funkcji w twoim programie, albo poprzedniej z dodatkowym parametrem. I znowu, mniej w dupie jakość. Pisz, żeby zadziałało. Potem znowu refaktoryzuj.

Serio, nie przejmuj się tym, że Twój kod wygląda, jakby ci coś narzygało do edytora. Niech nazwy zmiennych będą długie na pół linijki. Niech ci się powtarza ten sam kod po kilka razy. Niech działa kompletnie nieoptymalnie. Byle działał.

Dlaczego tak? Ponieważ powtarzając w kółko te same kroki - test, kod, poprawki, w pewnym momencie zaczniesz dostrzegać naturalnie wyłaniające się elementy wyższego rzędu. Po którymś razie, zamiast znowu kopiować jakiś blok kodu, wytniesz go i zrobisz funkcję albo klasę. Bo wyda ci się to oszczędnością czasu. Potem znowu i znowu. Twój kod zacznie samoistnie wykształcać strukturę. A ty będziesz miał poczucie, że on jest coraz lepszy, że nie tylko działa, ale się rozwija.

Zaczną ci się przydawać elementy pythona stworzone właśnie w celu doklejania dodatkowych rzeczy do już istniejącego kodu - dekoratory, functools, dziedziczenie z wielu klas itp.

Teraz zaczniesz wyłapywać coś jeszcze. Błędy i źle obsługiwane skrajne przypadki. I to będzie twój następny rodzaj testów. Nie myśl z góry o tym, co może pójść źle w twoim kodzie. Napisz żeby działało. A jak wyskoczy błąd, to go przeanalizuj, napraw i wsadź do testu. Zaprzyjaźnij się z paczką do testów hypothesis.

Chodzi o to, żeby twój plik z testami czytany od góry do dołu opisywał jakby historię tworzenia twojego programu. Tutaj dodałem funkcję, dodałem parametr ten, tu znalazłem błąd, tu znowu dodałem parametr itd.

Spróbuj wyobrazić sobie siebie w dwóch rolach. Ty piszący testy zadajesz zadanie domowe, a Ty piszący kod programu próbujesz to zadanie odwalić jak najmniejszym nakładem sił.

Zamiast planować, zastanawiać się, zmieniać zdanie, rób byle działało. Bo gdy twój program zadziała, twój mózg dostanie pozytywne wzmocnienie. Będziesz chciał pisać dalej. Będziesz czuł satysfakcję. A to z czasem zacznie przekładać się na jakość. Elementy, które masz dodać lub zmienić zaczną być dla ciebie oczywiste. Nie będziesz musiał ich szukać. Zaczniesz widzieć kierunek, w którym chcesz podążać.

Mam nadzieję, że komuś to pomoże.

#python #programowanie #programista15k

[O.....I]

@ProfesorBigos: a słyszałeś kiedyś o złożoności obliczeniowej? Przy spaghetti kodzie jest duża szansa że osiągniesz
Ο(x^n) albo O(n!) ( ͡° ͜ʖ ͡°)
Poza tym z doświadczenia wiem że pisanie bez przemyślenia problemu, kończy się jednorazowym użyciem danego kodu i porzuceniem projektu, bo refaktoryzacja oznacza przepisanie go od nowa.
Wiesz to jest jak w każdym projekcie, jak nie poświęcisz czasu na planowanie, to potem 2x tyle czasu poświęcisz

[ImCandy]

@ProfesorBigos: Szkoda, ze dupencja ze zdjecia zostala programerem, a nie porno gwiazdka ( ͡° ʖ̯ ͡°)

[e.....a]

@ProfesorBigos: ten twój alternatywny sposób, to standard w firmach używających TDD

[r.....k]

@ProfesorBigos: ma ktoś link do tej bluzki? XD

[ProfesorBigos]

@thexDguy: @erajwa: No w sumie TDD, tylko nie samo pisanie testów przed implementacją jest tutaj głównym pomysłem. Chodzi o to, że python pozwala na pracowanie z kodem bardzo niskiej jakości, oraz że jego poprawa może być efektem ubocznym implementowania nowych funkcji. W Javie już z takim podejściem będzie gorzej, bo jak coś na początku spieprzysz, to później będziesz musiał to najczęściej pisać od nowa. A już taki golang w ogóle

[isInteger]

@ProfesorBigos: bluza kozak, zamówiłbym sobie taką

[Boska_Klaudia]

Zaryzykuję stwierdzenie, że w zdecydowanej większości programów złożoność obliczeniowa nie ma najmniejszego znaczenia

@ProfesorBigos: nie chciałbym z tobą pracować

[MysGG]

@ProfesorBigos kij z tym jak kodzisz w pytonie, super bluza

[damw]

@ProfesorBigos: no czyli opisałeś TDD

Chodzi o to, że python pozwala na pracowanie z kodem bardzo niskiej jakości, oraz że jego poprawa może być efektem ubocznym implementowania nowych funkcji. W Javie już z takim podejściem będzie gorzej, bo jak coś na początku spieprzysz, to później będziesz musiał to najczęściej pisać od nowa.

A czemu w takiej Javie niby będziesz musiał napisać od nowa? I czemu tylko w pythonie poprawa gównianego kodu

[ProfesorBigos]

@damw: Chociażby dynamiczne typowanie. Python ma w nosie czym są obiekty, dopóki się odpowiednio zachowują. Więc możesz je łatwo podmieniać. W Javie jest z tym trudniej.

[damw]

Chociażby dynamiczne typowanie. Python ma w nosie czym są obiekty, dopóki się odpowiednio zachowują. Więc możesz je łatwo podmieniać. W Javie jest z tym trudniej.

@ProfesorBigos: czekaj moment bo się zgubiłem. Najpierw piszesz o tym, że python pozwala na pracę z gównianej jakości kodem, potem podajesz przykład duck typingu. W sensie uważasz, że duck typing jest gównianym mechanizmem, czy jednak jest spoko?
Jak tak bardzo potrzebujesz z tego mechanizmu korzystać, to

[kopiret]

@ProfesorBigos: aww

[cartsy]

@rozowyPrzegrywek:
@isInteger:
@MysGG:
Link

[isInteger]

@cartsy: no właśnie w tym sens że że to nie jest ten sam wzór, a pewnie jakościowo też gorsza.

[asterix61]

@ProfesorBigos: Wrzuciłem sobie do zakładek, bo po ilości plusów i komentarzy spodziewałem się powiewu, a Ty mi tutaj wymyśliłeś TDD. Aż mi się przypomniało, gdy w firmie miałem gościa, który wymyślił TDD na godzinnym spotkaniu.

[ProfesorBigos]

@asterix61: Wszystko, w czym na początku piszemy test, to TDD, a wszystko, do czego dodajemy jajka, to omlet #logika15k

[asterix61]

@ProfesorBigos: Tu nie chodzi o pisanie testów na początku. Tu chodzi o proces red-green-refactor, który opisałeś, który jest głównym elementem TDD. Jedynie dodałeś do tego trochę własnych obserwacji i uwag ( ta z hypothesis jest dość ciekawa). Ale najłatwiej się obrazić i generalizować.

Poza tym to właśnie "zawodowym inżynierom" przydaje się ta metodyka, ponieważ aby pisać kod, zaczynając od testów, trzeba wiedzieć z góry, czego oczekuje się od implementacji, logiki i

[ProfesorBigos]

@asterix61: W tym co napisałem chodziło właśnie o to, żeby nie robić refaktoryzacji, żeby nie przejmować się jakością kodu. Na początku skupić się tylko na dowożeniu kolejnych funkcji, bo dopiero po spędzeniu jakiegoś czasu przy pracy z kodem, wyklaruje nam się w głowie wizja tego, jak go rozsądnie zorganizować. TDD działa dobrze w przypadku komercyjnych projektów, gdzie musisz zagwarantować klientowi jakieś stabilne, niezmienne API. W przypadku mniejszych, prywatnych projektów nie trzeba

[asterix61]

@ProfesorBigos:

W TDD etapu refactor to nie jest mus. Nie trzeba po każdej implementacji go robić a wyłącznie wtedy, gdy uważamy, że warto. Refactor to nie zawsze zmiana połowy implementacji, to czasem zmiana nazwy zmiennej.

Dowożenie kolejnych funkcji bez myślenia o tym co robimy to tworzenie umyślnie długu technicznego. Robienie czegoś dla siebie nie oznacza, że powinniśmy olać wszystkie dobre wzorce pracy z kodem. Zwłaszcza że częściej czyta się kod, niż