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.
- napisać tyle kodu, żeby rozszerzenie się odpaliło (czyli HelloWorld)
- napisać kod, który wykrywa, czy strona to Facebook
- ściągnąć zdjęcie pieseła z netu
- podmienić jedno wybrane zdjęcie na stronie na zdjęcie pieseła (żeby wiedzieć, jak napisać kod, który podmienia zdjęcia)
- napisać kod, który przelatuje przez wszystkie obrazki (i dla każdego z nich wyświetla coś w konsoli, żebyśmy widzieli, że przeleciał)
- 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ś:
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:
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...
vin