Planowanie programów, czyli generalnie jak nie utrudniać sobie życie

0

Nie jestem programistą, ale w swojej pracy zdarza mi się dosyć często programować jakieś skrypty albo małe rozszerzenia do niektórych programów. Czasem idzie mi to dosyć opornie głównie z tego względu, że wg mnie zabieram się do tego od d... strony. Tzn. jak mam wymyślić jakiś "algorytm", który robi coś mądrego to zwykle zaczynam od samego początku tj. od pętli lub if/switch (zwykle tak właśnie zaczynają się moje "algorytmy"), a potem linijka po linijce dopisuje po kolei następne instrukcje, co jakiś czas debugując i sprawdzając, czy działa tak jak należy. Zwykle nie działa więc myślę co jest nie tak i powoli naprawiam kod. Czasem udaje mi się tą metodą za pierwszym razem napisać bardziej skomplikowane bloki kodu, ale najczęściej męczę się w ten sposób z kilku-kilkunastu linijkowym zestawem instrukcji.

Nie wierzę, że nie ma lepszych metod na pisanie programów. Nie chodzi zbytnio o clean code, ale generalnie o planowanie programów i to co się robi zanim się siądzie do klawiatury celem przelania swojej myśli na ekran. Kiedyś bawiłem się w pseudokody, ale kiepsko mi to szło bo w pewnym momencie zauważyłem, że równie dobrze mógłbym zastąpić każdą linijkę pseudokodu instrukcją i wyszłoby czasowo tak samo.

W jaki sposób wy zabieracie się do programowania? Od razu programujecie, czy przedtem jest jakiś proces rozpisywania, może nawet rysowania albo inne pożyteczne czynności. Będę wdzięczny za podzielenie się wiedzą albo poleceniem materiałów do nauki. Celem jest redukcja czasu poświęcanego na programowanie (a raczej na kopanie się z kodem i z samym sobą).

Język chyba w tym przypadku nie ma znaczenia, ale jakby co to najczęściej mam do czynienia z Pythonem i C#.

1

Myśl o kodzie, po prostu. Wyobrażaj go sobie. Zarówno ogólnie, jak i szczegółowo. Umiej odpalić go sobie w głowie, czy wyobrazić co kod robi. Spróbuj wykryć potencjalne bugi czy problemy w myślach (nie zawsze się będzie działo, plus czasem to, co sobie radośnie wymyślisz, po wpisaniu w komputer nie wypali - ale jednak mimo wszystko myślenie pomaga). Rysowanie też pomaga, rozbudza wyobraźnię. No i oczywiście praktyka, pisanie tych programów tak, żeby mieć jakieś intuicyjne wyczucie i model mentalny "jak się uruchamiają programy" (więc również znajomość języka programowania, w którym piszesz. Bo jak słabo znasz język, to będziesz miał więcej błędów, z których nawet nie będziesz sobie zdawać sprawy. A więc również warto przeczytać trochę z dokumentacji języka czy jakieś podręczniki przerobić).

Tzn. jak mam wymyślić jakiś "algorytm", który robi coś mądrego to zwykle zaczynam od samego początku tj. od pętli lub if/switch (zwykle tak właśnie zaczynają się moje "algorytmy"), a potem linijka po linijce dopisuje po kolei następne instrukcje, co jakiś czas debugując i sprawdzając, czy działa tak jak należy

Dobra. Robisz małymi krokami. I to nie jest złe. Ale nie tylko pisanie kodu warto podzielić na etapy, jak również etapy rozwiązania. Czyli np. masz do napisania... nie wiem, co możesz mieć. Np. rozszerzenie do przeglądarki, które zamienia wszystkie obrazki na Facebooku w zdjęcia Pieseła. To nie powinieneś robić tego tak, żeby od razu całą apkę napisać, tylko raczej podzielić na etapy, np.

  1. napisać tyle kodu, żeby rozszerzenie się odpaliło (czyli HelloWorld)
  2. napisać kod, który wykrywa, czy strona to Facebook
  3. ściągnąć zdjęcie pieseła z netu
  4. podmienić jedno wybrane zdjęcie na stronie na zdjęcie pieseła (żeby wiedzieć, jak napisać kod, który podmienia zdjęcia)
  5. napisać kod, który przelatuje przez wszystkie obrazki (i dla każdego z nich wyświetla coś w konsoli, żebyśmy widzieli, że przeleciał)
  6. ponieważ wiemy już, jak przelecieć przez obrazki i jak zamienić obrazek na zdjęcie pieseła, to możemy połączyć punkty 4 i 5 i napisać kod, który podmienia obrazki na zdjęcie pieseła.

No i generalnie posuwać się naprzód małymi ostrożnymi krokami (ale jednocześnie też wybiegać myślą w przód).

a potem linijka po linijce dopisuje po kolei następne instrukcje, co jakiś czas debugując i sprawdzając, czy działa tak jak należy.

Dlaczego "co jakiś czas"? Zmieniasz coś, nawet małą rzecz, to uruchamiasz i sprawdzasz czy działa tak, jak należy na tym etapie, na którym jesteś. Czasem warto odpalić program, nawet jak się robi coś, co powinno zadziałać, np. załóżmy, że chciałbym wrócić do Pythona, bo dawno nie programowałem, więc ściągam tego Pythona, żeby mieć najnowszego i piszę takie coś:

print "foo"

i to powinno działać, bo zawsze działało. A tu figa, bo w Pythonie 3 taka konstrukcja jest błędna, bo nawiasy. Ale dobra, to dodaję nawiasy:

print(foo")

i też nie zadziała, a powinno. Ale ups. Pisząc nawias niechcący skasowałem jeden cudzysłów.

Itp. itd.

więc dlatego warto jak najczęściej odpalać, nawet wtedy, kiedy się nam wydaje, że wszystko działa (błędy nie muszą być składniowe, mogą być bardziej ukryte, podałem tylko tak dla przykładu). Natomiast jak będziesz odpalać program "co jakiś czas", to będziesz miał więcej błędów zwykle i nie będziesz wiedział, gdzie one są.

zastąpić każdą linijkę pseudokodu instrukcją i wyszłoby czasowo tak samo.

Python to już jest pseudokod praktycznie...

1 użytkowników online, w tym zalogowanych: 0, gości: 1