Aktywne Wpisy
shark93 +427
marcin-kolecki +11
#tinder jak sobie psychicznie poradzić z tym że dziewczyna po dwóch latach związku, zerwaniu z jej inicjatywy. Następnego dnia już skakała po innym? A teraz po dwóch miesiącach wróciła i jojczy?
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
Ze skrajności w skrajność.
To jest narzędzie jak każde inne. Agile też ma wiele zasad, ale nikt nie pracuje według nich wszystkich, ponieważ to jest narzędzie i ma ono pracować dla nas, a nie my dla narzędzia.
"Testy mają reprezentować rzeczywiste zachowania użytkowników" - Pytanie co masz na myśli poprzez rzeczywiste zachowania użytkowników, bo chyba chodziło Ci o BDD i opisywanie testów poprzez given-when-then, a wtedy to nie jest żaden
@ProfesorBigos: I pozwolę sobie wrócić do Twojego tekstu. TDD to Test Driven Development lub też czasem nazywany Test First Development. Implementacja jest napędzana poprzez testy, więc są one pisane na początku przed faktycznym kodem. Spieranie się o to, że tak nie jest to walka ze słownikiem, a nie ze mną.