Kiedy miałbym używać pseudokodu zamiast schematu blokowego?

Jestem studentem pracującym z różnymi technikami programowania i natknąłem się na pseudokod i schemat blokowy. Wiem, że oba są używane do przemyślenia problemu przed rozpoczęciem programowania, ale mam z tym kilka pytań.

1. Kiedy miałbym używać pseudokodu do planowania, a kiedy miałbym używać schematów blokowych? A może lepiej zrobić obie rzeczy przed rozpoczęciem programowania. Szczególnie w przypadku małej gry zręcznościowej w JAVA, ponieważ jest to mój następny projekt.
2. Zauważyłem, że pseudokod jest bardzo podobny do rzeczywistego kodu, a nie schematów blokowych. Czy poprawiłoby to pseudokodowanie, ponieważ zasadniczo kopiujesz / wklejasz pseudokod do swojego programu (oczywiście musisz go zmienić, aby pasował do języka. Rozumiem tę część).
3. Czy praktyczne jest używanie obu tych programów podczas programowania? W szczególności ta sama gra, o której wspomniano wcześniej. Dzięki.

Schematy blokowe i pseudokod często mają ten sam poziom ekspresji, ale różnią się linearyzacją. Pseudokod jest liniowy (tj. Ciąg linii z instrukcjami), a schemat blokowy nie. Dlatego schematy blokowe są wyższym poziomem abstrakcji, używanym przed zapisaniem pseudokodu lub dokumentacji.

Schematy blokowe mają, moim zdaniem, dwie silne zalety w stosunku do pseudokodu: po pierwsze, są graficzne. Wiele osób nietechnicznych obawia się silnie ustrukturyzowanego tekstu, ale nie opisów graficznych, więc schematy blokowe będą z nimi o wiele przyjemniejsze. Po drugie, schematy blokowe są znacznie lepsze w wyrażaniu meta-rozważań, takich jak pokazywanie głównej linii wykonania w przeciwieństwie do gałęzi.

Twoje szczegółowe pytania:

1. W przypadku naprawdę skomplikowanego problemu należy najpierw użyć schematów blokowych, a następnie pseudokodu. Oba są opcjonalne, gdy czujesz się wystarczająco bezpiecznie.
2. Tak, pseudokod ma tę zaletę, że można go łączyć z prawdziwym kodem. Na przykład Steve McConnell zdecydowanie zaleca pisanie metod w pseudokodzie, a następnie pozostawienie pseudokodu w kodzie jako komentarza.
3. Zawsze czułem, że potrzeba narysowania schematu blokowego podczas projektowania pokazuje niewystarczający podział twojego problemu. Nietrywialne schematy blokowe wskazują na skomplikowaną logikę, której należy unikać przy wielkich kosztach.

Na pseudo kodzie

Szczerze mówiąc, nie używam zbyt często pseudokodu. Zazwyczaj pisanie kodu jest szybsze, więc kiedy skończę z moim kodem, jest to rzeczywisty kod. W niektórych przypadkach pseudo-kod może być pomocny, ale generalnie pracujesz nad czymś bardzo złożonym i próbujesz rozbić strukturę metody lub czegoś takiego. W takich przypadkach używam komentarzy w moim IDE, aby rozplanować strukturę, dopóki nie wszystko będzie w porządku. Następnie wchodzę i piszę właściwy kod w komentarzach. Pomaga mi to zrobić kilka rzeczy:

• Widzę obszary, które mam i których nie wdrożyłem, czytając komentarze i widząc w nich oczywiste luki.
• Kiedy wypełniam prawdziwy kod, mam komentarze wyjaśniające po angielsku, co robię. (Prawdopodobnie będą go potrzebować, jeśli będzie to tak skomplikowane, że najpierw muszę napisać pseudo kod).

Na schematach blokowych

Kod zwykle zmienia się tak bardzo, że schematy blokowe nie są pomocne, z wyjątkiem większego, bardziej ogólnosystemowego projektu architektury lub dokumentacji. W takich przypadkach po prostu spiszę diagram, aby uzyskać sedno rzeczy lub pokazać komuś innemu z zespołu. Chyba że naprawdę potrzebujesz schematu blokowego, który pomoże ci zrozumieć, to tak naprawdę nie potrzebujesz ich do „robienia” oprogramowania prawidłowo. Obecnie istnieje wiele wtyczek dla IDE, które będą generować schematy blokowe z samego kodu, a także diagramy klas i inne (i odwrotnie `). Jedynym czasem, w którym musisz zrobić bardzo dokładny schemat blokowy, jest to, że nie możesz zachować całej architektury i tego, jak rzeczy działają od razu w twojej głowie, i musisz porozmawiać przez coś wizualnego, aby złapać załamania.

Zasadniczo nie piszę schematów blokowych podczas pracy nad projektami osobistymi (ponieważ projekty nie są zbyt duże), a większość danych wejściowych, wyjściowych i procesów jest jasna.

ale gdy zaczniesz pracować nad złożonymi dużymi projektami z różnymi źródłami danych, przydatne są płaskie pliki, bazy danych, ręczne interfejsy itp. schematy blokowe.

Polecam pisanie pseudo-kodu i digramów UML, ponieważ narzędzia te pomogą ci wymyślić lepsze klasy, metody itp. Czasami pisząc pseudo-kod, znajdziesz inne i bardziej wydajne sposoby rozwiązania programu.

Pseudo kod służy do szybkiego przedstawienia pomysłu tym, którzy rozumieją przynajmniej podstawy kodu. Schematy blokowe fr rysują ładne zdjęcia, aby wszyscy inni mogli zrozumieć to samo.

Schematy blokowe są często używane do celów dokumentacji, ponieważ wiele różnych osób korzysta z tej dokumentacji, a schematy blokowe są łatwiejsze do naśladowania niż pseudo-kod dla programistów. W projekcie, nad którym pracujesz, trzymanie się pseudo-kodu jest w porządku, ponieważ jest o wiele bardziej przydatne i znacznie łatwiejsze do utworzenia, ponieważ wystarczy edytor tekstowy.

Schematy blokowe to wysoki poziom abstrakcji, na przykład pozwalający zaplanować, jak należy postępować

jeśli x umiera, wygrywa

Nie muszą zależeć od tego, jak projektujesz program pod względem klas i metod, z drugiej strony pseudo-kod zapewnia niższy poziom abstrakcji (choć tak naprawdę zależy)

if (isdead (s)) y.win ()

w ten sposób pseudo kod można teraz przetłumaczyć na rzeczywisty program w oparciu o używany język.

W przypadku gry polecam najpierw użyć schematu blokowego, a następnie zaprojektować klasy i metody, napisać pseudo kod i na koniec przekonwertować go na program

Rozważę naturę kodu, który piszesz. Jeśli to jest:

1. Wysoce iteracyjne / rekurencyjne
2. Oddziały w skomplikowany sposób
3. Zaimplementowane w kilku systemach, które chcesz reprezentować

W pierwszych dwóch przypadkach pseudokod staje się coraz trudniejszy do odczytania niż schemat dużego obrazu. Z drugiej strony kod, który jest głównie liniowy, sprawia, że ​​niezwykle nudne diagramy sprawiają, że proces jest trudniejszy do zrozumienia ze względu na to, jak bardzo go wysadza.

W trzecim przypadku schematy blokowe lepiej reprezentują procesy przekraczające granice systemu i reprezentujące cały proces.

1. Powinieneś używać tego, na co masz ochotę. Mimo to mam wrażenie, że schematy blokowe nie są obecnie używane do szkicowania kontroli programów; po pierwsze, są one zazwyczaj nieustrukturyzowane, w porównaniu do pseudokodu. Bardziej powszechne jest używanie diagramów zależności klas, takich jak UML, do opisywania architektury na znacznie wyższym poziomie. Ponadto, jeśli aplikacja ma maszynę stanu, konieczne jest narysowanie (podobnego do schematu) diagramu maszyny stanu.
2. Myślę, że masz rację tutaj. Jednym ze sposobów pracy jest napisanie pseudokodu jako komentarza w pliku źródłowym na początek i wstawienie między nimi wierszy rzeczywistej implementacji.
3. Ponownie używaj tego, na co masz ochotę. Jeśli nie jesteś pewien, wypróbuj je oba; Oczekuję, że twoja praktyka szybko zbliży się do wszystkiego, co jest dla ciebie najbardziej przydatne. Osobiście nie uważam, że schematy blokowe są przydatne, chyba że próbuję rozwikłać szczególnie skomplikowane polecenie wykonania.

Po co pisać pseudo kod, skoro można pisać w Javie? Odkryłem, że Java, dobre IDE i Javadoc to najłatwiejszy sposób na zrozumienie problemu programistycznego - przynajmniej na obiekt . (A gra zręcznościowa powinna być OO.) Język został zaprojektowany do tego od podstaw. To proste i jednoznaczne. (Być może zbyt proste dla wielu celów, ale najlepsza rzecz, jaką widziałem w tym przypadku.) Hipertekst w Javadoc i, poprzez IDE, w samym kodzie tworzy bardziej zrozumiały „diagram”, niż można by na nim nawet oprzeć duży arkusz papieru. Kod Java jest tak prosty jak każdy pseudo-kod i jest o wiele bardziej rygorystyczny. A kiedy już go „zakodujesz” i „pseudo”, program faktycznie uruchomi się!

Możesz użyć schematu blokowego, jeśli naprawdę wprawia Cię w zakłopotanie stwierdzenie if i próbujesz to zrozumieć. Lub jeśli próbujesz zrozumieć pętlę, zobacz efekt liczników. Jeśli się uczysz, może to bardzo pomóc.

Może wydawać się nieco restrykcyjne, ponieważ musisz wstawiać krótkie stwierdzenia do skrzynek. A jeśli twój program jest bardzo liniowy, a twoje pętle i ifs są trywialne, to nie widzę dla niego żadnego pożytku.

Pseudokod jest użyteczny przy projektowaniu programu. Bez rozpraszania się koniecznością poprawnej składni i bez długiego czasu, który może wiązać się z niektórymi językami. Szybsze pisanie ułatwia także przeprojektowanie kodu. I możesz być tak zwięzły, jak tego pragnie twój umysł, przyjemnie jest pisać, wymaga mniej wysiłku umysłowego, aby go uruchomić (jako brak lub dużo mniej debugowania), i więcej umiejętności skupienia się na dużym obrazie i projekcie.

Przydatny dla ciebie.

Mogą być również używane do komunikowania się z innymi.