Piszę swoje podejście do rozwiązywania problemów na papierze? [Zamknięte]

Jestem studentem pierwszego roku informatyki i właśnie zaczęliśmy robić rzeczywiste projekty w Pythonie. Przekonałem się, że jestem bardzo wydajny, kiedy używam długopisu i papieru, które mój profesor zaproponował na zajęciach. Ale kiedy nie mogę zapisać swojego problemu i wypracować algorytmów na papierze, jestem naprawdę powolny. Podczas laboratoriów zawsze wydaje mi się, że muszę zabrać zadanie z powrotem do mojego akademika. Kiedy tam docieram i zapisuję, rozwiązuję problem, który zajął mi całą klasę w około 5 minut.

Może dlatego, że stresuję się widząc ludzi rozwiązujących przede mną laboratoria. A może to metoda długopisu i papieru.

Przeglądałem fora i ktoś napisał, że jeśli musisz pisać swoje programy na papierze, nie powinieneś być programistą. Naprawdę się martwię, ponieważ jestem o wiele lepszy, kiedy widzę, co robi program i śledzę go przed wpisaniem właściwego kodu. czy robię coś źle?

Edycja: Przepraszam, że jestem niejasny, ale kiedy powiedziałem, że pisanie na papierze mam na myśli moje podejście do rozwiązywania problemów (np. Pisanie przykładów, tworzenie tabel z wartościami itp.), A nie mój rzeczywisty kod. Po prostu używam papieru, aby wydobyć moje pomysły.

Nie ma nic złego w opracowaniu najpierw algorytmów na papierze. Nie tyle w codziennym kodowaniu, ale w przypadku bardziej skomplikowanych algorytmów profesjonalni programiści cały czas opracowują je na papierze lub tablicy, szczególnie jeśli format graficzny jest bardziej przejrzysty. Dla studenta każdy program jest złożony.

Jeśli jednak chcesz poprawić projektowanie algorytmów na komputerze, możesz przećwiczyć kilka technik. Nie zaczynaj od napisania kodu, napisz te same rzeczy, które zapisałeś na papierze jako komentarze, a następnie rozwiń go w prawdziwy kod lub bardziej szczegółowe komentarze jeden po drugim.

Na przykład, jeśli usuwam element ze środkowej listy, mogę zacząć od czegoś takiego:

// find the element
// point the previous element to the next element
//    How do I get a pointer to the previous element?
//        doubly-linked list?
//        another find?
//        keep track during the first find?
// delete the element

Następnie mógłbym zastąpić // find the elementfunkcją z większą liczbą pseudokodów i kontynuować, aż będę mieć kompletne rozwiązanie. Nie myśl, że kod musi być napisany w sposób liniowy.

Idź po to! Jeśli nazywamy to, co robisz, myśleniem i projektowaniem swojego rozwiązania, to ma sens, że Twój proces będzie znacznie szybszy niż zwykłe niszczenie kodu.

Ludzie lubią myśleć (a hałaśliwi lubią nam mówić), że ich sposób działania jest lepszy. Ale umiejętności i umiejętności każdego są inne. Więc rób to, co Ci odpowiada. Gdy zdobędziesz praktykę, prawdopodobnie przejdziesz do wykonywania większej ilości prac projektowych w głowie i będziesz używać papieru w przypadku większych problemów.

Jedną rzeczą, na którą należy zwrócić uwagę, jest to, jaką formę przyjmą egzaminy. Czy będą na papierze, czy będą oparte na komputerze? Jeśli są oparte na papierze, twoja droga da ci przewagę. Jeśli są oparte na komputerach, to też jest w porządku: zrób dowolny projekt na papierze, a następnie napisz kod. Cokolwiek działa najlepiej!

Nie zapisuję rzeczywistego kodu na papierze, ale dla wszystkiego, co nie jest trywialne, prawie zawsze zaczynam od tablicy lub notebooka. Zazwyczaj szkicuję:

• Algorytmy / przebieg procesu / kontroli
• Struktury danych
• Relacje
• Komponenty (jak rozwiązać ten problem)

Zwykle jest to kombinacja szkiców, pseudokodu i angielskiego.

Uważam, że dzięki temu łatwiej jest wizualizować, kiedy zaczynam kodować. Zauważyłem także wady, zanim zacznę pisać w kodzie, ponieważ widzę wszystko przede mną (zamiast ciągłego przewijania i przeskakiwania okna). Mało tego, kiedy to zostanie napisane, mogę pozwolić, aby rzeczy powstawały w moich myślach, gdy pracuję nad innymi zadaniami. Mogę również pracować w sposób nieliniowy, zgłaszając pomysł na papier, gdy mnie uderza, a następnie wracam do niego, gdy osiągnę punkt, w którym go potrzebuję.

Popełnianie czegoś na papierze jest ogromną pomocą w zachowaniu pamięci. Hasłem marki notebooków Field Notes jest:

Nie zapisuję tego, aby zapamiętać później, zapisuję to, aby zapamiętać teraz.

Po bardziej skoncentrowanym podejściu do zapisywania rzeczy na papierze, nawet jeśli chwilę później piszę w aplikacji ToDo na telefonie, stwierdzam, że ta myśl jest o wiele lepsza niż tylko zapisywanie w formie elektronicznej. IOW, planując kodowanie na papierze / tablicy, pomysły pozostają w mojej głowie.

Służy również jako przydatne odniesienie, gdy trzeba udokumentować to, co napisałem.

Nie wydaje mi się, żeby najpierw było pisanie kodu (pseudo lub w inny sposób) na papierze - to tak naprawdę nie różni się od pisania go na tablicy, co robi wiele osób, dyskutując o tym, jak rozwiązać problem.

Czy najpierw piszesz na papierze pierwsze szkice esejów dla klas spoza CS, zanim je napiszesz? W rzeczywistości robiłem to wiele lat temu, kiedy jeszcze byłem studentem, ale po pierwszym roku studiów zmusiłem się do napisania wszystkich szkiców na ekranie, ponieważ dzięki temu pisanie kolejnych szkiców było o wiele łatwiejsze i ten sam pomysł ma zastosowanie do pisania kodu.

Sugeruję wypróbowanie algorytmów, nawet jeśli jest to tylko edytor tekstowy, taki jak Word. Im częściej to robisz, tym wygodniej będzie ci nie polegać na papierze i długopisie. A jeśli brakuje Ci umiejętności pisania na klawiaturze, co jest źródłem frustracji, wybierz kurs pisania na klawiaturze! Byłoby to najlepsze, co możesz zrobić dla swojej przyszłej kariery.

Rozwiązanie problemu i napisanie kodu implementującego rozwiązanie to dwa różne działania.

Jeśli nie znasz języka, poświęcisz dużo czasu na sam kod - a nie na znalezienie dobrego rozwiązania. Jeśli papier, tablica lub zaczynasz od sufitu ci w tym pomagają, to na pewno to zrób.

(Osobiście schodzę z komputera i chodzę w kółko, próbując zbudować rozwiązanie w mojej głowie)

Będziesz wywiadem asa! Sprawiają, że piszesz kod na papierze lub na tablicy. Jestem dokładnie odwrotnie. Próba pisania nawiasów klamrowych lub wycinania i wklejania za pomocą pióra jest TAK żmudna!

Mój tata zużył dużo papieru podczas programowania COBOL. Myślę, że to tylko twój styl myślenia.

Kiedyś mieliśmy dwa semestralne zajęcia o nazwie Podstawy programowania. Zarówno testy w połowie semestru, jak i egzaminy na koniec zostały wykonane na papierze. Jeśli popełniłeś błędy kompilacji, straciłeś poważną liczbę punktów. Jeśli popełniłeś ogromne błędy kompilacji, nie powiodło się. Jednak wydaje mi się, że rozwinęło to w nas zdolność do spojrzenia na dowolny kod i znalezienia błędnych linii w stosunkowo krótszym czasie.

Nie ma nic złego w tym, co robisz, nauczyłem się programować również za pomocą papieru i pióra.

Jak sugerują inni, zrób to, co Ci odpowiada. Pamiętam, że pierwszy napisany przeze mnie program Java był głównie na papierze, a potem spędziłem dwie godziny na pisaniu i piętnaście minut płacząc, gdy zobaczyłem ponad 200 błędów kompilatora. Było ich więcej, ale kompilator wyświetlałby tylko pierwsze 200! Chodzi mi o to, że pisząc kod na papierze, byłem w stanie przemyśleć podstawowy algorytm i funkcjonalność tego, co program powinien zrobić. Kompilator wskazał powody, dla których mój program nie działał. 90% problemów wykraczało poza granice wyjątków dotyczących tablic.

Gdy zdobędziesz więcej doświadczenia i pewności siebie, zużyjesz mniej pióra i papieru. Będziesz już wiedział, jak korzystać z podstawowych pojęć, takich jak pętle i tak dalej. Będziesz mieć przykłady w innych programach, których możesz użyć ponownie. Użyjesz kompilatora i IDE, aby znaleźć oczywiste błędy podczas pisania programu. W tej chwili nie masz tego doświadczenia.

Czytając twoje pytanie, zastanawiam się, czy niektóre z twoich problemów mogą wynikać z koncentracji. Jeśli używanie długopisu i papieru w cichym otoczeniu pomaga skupić się, to świetnie.

Nadal jesteś na studiach i wciąż się uczysz. Ostatecznie wszystko, co robisz, to to, co działa dla Ciebie. Jeśli używając papieru i pióra porządkujesz swoje myśli i myślisz jasno i spokojnie, to programujesz.

Mój kod jest znacznie lepiej zorganizowany, gdy zapisuję notatki i zbliżam się do notatnika, sprawdzam książki, sprawdzam internet i myślę o tym. Jestem również bardziej wizualną osobą, więc rysowanie obrazów za pomocą struktur danych jest bardzo pomocne. Nie zapisuję każdej linii, ale zapisuję to, co uważam za „ważne” fragmenty lub kluczową funkcjonalność. W przypadku większych projektów uruchamiam Visio. Nie jestem pewien, dlaczego ktoś opowiada się za skokiem na klawiaturę, chyba że jest o wiele bardziej wydajny lub opłacany z godziny na godzinę.

Rób, co Ci odpowiada. Nie pisałbym kodu na papierze. Piszę pseudokod i rysuję schematy blokowe na papierze, ale pisanie pełnego kodu wydaje się stratą czasu.

Ten sam problem mam również w początkowej fazie nauki umiejętności technicznych.

Ale taka praktyka nie powinna dawać 100% sukcesu, ponieważ jeśli piszemy kod na papierze, nie ma szansy na naprawienie błędów, istnieje szansa na rozwiązanie błędów i wyjątków podczas wykonywania papierkowej roboty.

Dzięki temu praca papierkowa nie zapewnia żadnej nawigacji w celu rozwiązania problemów, a prędkość pisania może być dodatkowa ze względu na praktykę systemową.

Robię też papierkową robotę, ale kiedy przed wdrożeniem mojej funkcjonalności po prostu dokonam przybliżonej oceny, zacznę moją implementację w systemie.

Spróbuj poświęcić więcej czasu na ćwiczenie systemu. To da 100% pewności i wyniku.