Kdy bych místo vývojového diagramu použil pseudokód?

Fl owcharts a pseudokód mají často stejnou úroveň expresivity, ale liší se v linearizaci. Pseudokód je lineární (tj. Posloupnost řádků s pokyny), vývojový diagram nikoli. Vývojové diagramy proto představují vyšší úroveň abstrakce, která se používá před psaním pseudokódu nebo pro dokumentaci.

Vývojové diagramy mají podle mého názoru oproti pseudokódu dvě silné výhody: Za prvé jsou grafické. Mnoho netechnických lidí má silný strach ze strukturovaného textu, ale nikoli z grafických popisů, takže vývojové diagramy jim budou sedět mnohem lépe. Zadruhé, vývojové diagramy mnohem lépe vyjadřují meta-úvahy, jako je zobrazení hlavní linie provedení na rozdíl od větví.

Vaše dotazy podrobně:

1. Pro opravdu komplikované problém, měli byste nejprve použít vývojové diagramy, pak pseudokód. Oba jsou volitelné, pokud se cítíte dostatečně zabezpečené.
2. Ano, pseudokód má tu výhodu, že je sloučitelný se skutečným kódem. Steve McConnell například důrazně doporučuje nejprve psát metody v pseudokódu a poté ponechat pseudokód v kódu jako komentáře.
3. Vždy jsem cítil, že potřeba nakreslit vývojový diagram během návrhu ukazuje nedostatečné rozdělení vašeho problému. Netriviální vývojové diagramy označují spletitou logiku, které je třeba se za velkou cenu vyhnout.

Komentáře

• Vývojové diagramy jsou také skvělými způsoby aby se ujistil, že každý rozhodovací bod definuje akce pro méně časté i nejběžnější cesty. Díky tomu budete mít jistotu, že budete vědět, co dělat, když je schválení zamítnuto nebo je objednávka zrušena! V okrajových případech je často více chyb, protože lidé je zapomněli udělat nebo to udělali ve spěchu během kontroly kvality, když je testování najde.

Na Pseudokódu

Abych byl upřímný, pseudokód moc nepoužívám. Obvykle je rychlejší jen napsat kód, takže když jsem hotový s můj kód, je to skutečný kód. Existují případy, kdy může být pseudokód užitečný, ale obvykle pracujete na něčem velmi složitém a snažíte se rozebrat strukturu metody nebo něčeho jiného. V těchto případech používám komentáře v mém IDE k rozvržení struktury dokud nebudu mít vše v pořádku. Poté přejdu dovnitř a do komentářů napíšu skutečný kód. To mi pomůže udělat pár věcí:

• Vidím oblasti, které mám a dosud nebyly implementovány číst komentáře a vidět v nich zjevné mezery.
• Když vyplním skutečný kód, mám komentáře vysvětlující v angličtině, co dělám. (Pravděpodobně to budou potřebovat, pokud je to tak složité že musím nejdříve napsat pseudo kód).

Na vývojových diagramech

Kód se obvykle mění natolik, že vývojové diagramy nejsou užitečné, kromě větší, celosystémové architektury návrh nebo dokumentace. V takových případech „jen napíšu tabulku diagramu, abych získal podstatu věcí nebo ukázal někomu jinému v týmu. Pokud opravdu nepotřebujete vývojový diagram, který vám pomůže pochopit, pak je opravdu nepotřebujete k tomu, aby„ dělali “software že jo. V dnešní době existuje spousta pluginů pro IDE , které vygenerují vývojové diagramy ze samotného kódu, stejně jako diagramy tříd a další (a naopak `)). Jediným reálným časem, který potřebujete udělat opravdu přesný vývojový diagram, je, pokud si nedokážete zachovat celou architekturu a to, jak věci fungují ve vaší hlavě najednou, a potřebujete si promluvit pomocí něčeho vizuálního, abyste chytili smyčky.

Obecně nepracuji vývojové diagramy, když pracuji na osobních projektech (protože projekty nejsou příliš velké) a většina vstupů, výstupů a procesů je jasná.

ale jakmile začnete pracovat na složitých velkých projektech s různými vstupními zdroji, ploché soubory, databáze, manuální rozhraní atd. jsou užitečné.

Doporučil bych píšete pseudokód a digramy UML, protože tyto nástroje vám pomohou přijít s lepšími třídami, metodami atd. Někdy při psaní pseudokódu najdete různé a efektivnější způsoby řešení programu.

Pseudokód slouží k rychlému představení nápadu těm, kteří rozumí alespoň základům kódu. Vývojové diagramy vytvářejí pěkné obrázky pro všechny ostatní pochopit totéž.

Vývojové diagramy se často používají pro účely dokumentace, protože tuto dokumentaci používá mnoho různých lidí a vývojové diagramy se snáze následovat než pseudokód pro neprogramátory. V projektu, na kterém sami pracujete, je dodržování pseudokódu v pořádku, protože je mnohem užitečnější a mnohem snadněji se vytváří, protože potřebujete pouze textový editor.

Vývojové diagramy představují vysokou úroveň abstrakce a umožňují vám plánovat, jak by věci měly pokračovat, například

pokud x dies y wins

Nemusí se spoléhat na to, jak program navrhujete z hlediska tříd a metod, na druhé straně pseudokód poskytnout nižší úroveň abstrakce (i když to opravdu záleží)

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

takže pseudokód lze nyní přeložit do skutečného programu na základě jazyka, který používáte.

U hry bych doporučil nejprve použít vývojový diagram, poté design třídy a metody, napište pseudokód a nakonec jej převeďte do programu.

Zvažte povahu kódu, který píšete. Pokud je:

1. Vysoce iterativní / rekurzivní
2. Větve komplikovaným způsobem
3. Implementováno v několika systémech, které chcete reprezentovat

V prvních dvou případech je pseudokód postupně těžší čitelný než velký obrazový diagram. Na druhou stranu kód, který je většinou lineární, vytváří neuvěřitelně nudné diagramy, díky nimž je proces těžší pochopit, protože ho vyhodí do povětří.

Ve třetím případě vývojové diagramy lépe reprezentují procesy, které překračujte hranice systému a představujte celý proces.

1. Měli byste použít vše, s čím se budete cítit dobře. To znamená, že mám dojem, že vývojové diagramy se dnes příliš nepoužívají k načrtnutí řízení programu; za prvé jsou obvykle nestrukturované ve srovnání s pseudokódem. Je běžnější používat diagramy závislostí tříd, jako je UML, k popisu vaší architektury na mnohem vyšší úrovni. Pokud má vaše aplikace stavový automat, je zásadní nakreslení (stavového) diagramu stavového stroje.
2. Myslím, že zde máte pravdu. Jedním ze způsobů, jak pracovat, je napsat svůj pseudokód jako komentář do zdrojového souboru, a nejprve do něj vložit skutečné implementační řádky.
3. Opět použijte vše, s čím se cítíte dobře. Pokud si nejste jisti, vyzkoušejte je oba; očekávám, že se vaše praxe rychle sblíží v tom, co je pro vás nejužitečnější. Osobně mi vývojové diagramy nepřijdou užitečné, pokud se nepokouším rozmotat zvlášť komplikovaný příkaz k provedení. li>

Proč psát pseudokód, když umíš psát Javu? Našel jsem Javu, dobré IDE a Javadoc je nejjednodušší způsob, jak uchopit programovací problém – alespoň objektově orientovaný . (A arkádová hra by měla být OO.) Jazyk byl k tomu navržen od základů. Je to jednoduché a přímé. (Možná je to pro mnoho účelů příliš jednoduché, ale to nejlepší, co jsem pro to viděl.) Hypertext v Javadocu a prostřednictvím IDE v samotném kódu vytváří srozumitelnější „schéma“, než na které byste mohli čerpat i velký list papíru. Java kód je stejně jednoduchý jako jakýkoli pseudokód a mnohem přísnější. A jakmile ho „napíšete“ a „pseudo“ zakódujete, program se skutečně spustí!

Komentáře

• java a další mohou být dlouho naladěné. “ public static void main .. “ nebo “ system.out.println “ nebo dlouhé identifikátory s notací camelback, tam dlouho navíjeny.n pak výjimky nechte 2b chytit .. A volání do libovolné knihovny může být dlouhé, vzpomínám si, že před 10 lety jsem otevíral soubor. něco jako nový BufferedReader (nový InputStreamReader (System.in)); nyní zjevně jednodušší mkyong.com / java / … Ale opravdu každá knihovna, kterou voláte, může být dlouhá, ne jako pseudokód, který může být tak stručný, jak si dokážete představit
• také v Javě nebo jiném jazyce narazíte na chyby při kompilaci. nic z toho s pseudokódem. můžete se soustředit na design bez rozptýlení. Komentáře k pseudokódu mohou být mnohem stručnější, protože pseudokód je pro mysl jasnější, protože ‚ je z mysli. ‚ Nejste omezeni tím, že budete myslet pouze v jednom jazyce, a můžete vidět, že tento jiný jazyk budete používat i ‚. Psaní ‚ je rychlejší a méně bolestivé (není třeba kompilace – dokonce i velmi plynulé chyby v kompilaci) a tak méně času na psaní usnadňuje redesign.
• @barlop: Funguje to pro mě, ale nemusí to fungovat pro každého. Nechávám například spoustu kódu (“ BufferedReader „), dokud to nepotřebuji nebo nebudu potřebovat vědět, jestli může to fungovat. I když ji mám, ‚ s se ve třídách, na které se ‚ nemusím dívat, při zvažování celkového hodnocení, nemusel dobře dívat design. Chyby kompilátoru lze snadno opravit a mohou zabránit velkým chybám v návrhu, například použití nesprávné třídy v místě, kde můžete ‚ dokonce získat instanci správná třída. Přiznávám, “ jsem navrhl “ software takovým způsobem, který mohl pouze být napsán v Javě, ale OP používá jazyk Java.
• takže řekněte, že chcete otevřít soubor, vidíte, jak funguje pseudokód openfile (“ c: \ blah \ file „) je na to kratší než java? nebo že tisk “ dfdfd “ je na to kratší než java? ‚ Nikdy jsem nedělal (zatím) stránky pseudokódu a více tříd. částečně ‚ cos ‚ jsem nenapsal velké programy ve věku b) částečně ‚ cos Nemyslím si ‚, že bych to udělal, myslím, že napíšu nějaký pseudokód a nechám ho implementovat. ‚ d Jakýkoli jiný pseudokód, pokud existuje, by byl vyšší úrovně. Mohl bych mít seznam všech tříd a metod včetně konstruktérů. Takže vím, jaké třídy jsou a co a že k tomu mohu získat instanci.
• takže bych nebyl ‚ v situaci, kdy používám špatnou třídu ale každopádně, pokud je to ‚ s mým programem, ‚ jsem si do poznámek zapsal, která třída je co .. třídy jsou hezké vysoká úroveň. Mám ‚ poznámku, že pokud si to ‚ nepamatuji. A pseudokód je o tom, co jeden znamená, takže pokud jste chtěli vytvořit instanci třídy bla a napsali jste bleh, pak ‚ je to jen překlep, ale ‚ nebrání vašemu designu. (pokud ‚ píšete pro sebe ‚ protože víte, co tím myslíte, a použili jste to jako bla)).

Vývojový diagram můžete použít, pokud jste opravdu zmateni výroky if a snažíte se porozumět že. Nebo pokud se snažíte porozumět smyčce, podívejte se na účinek čítačů. Pokud se učíte, může to hodně pomoci.

Může to působit trochu omezujícím dojmem, protože musíte do políček vkládat krátká prohlášení. A pokud je váš program velmi lineární a vaše smyčky a ifs jsou triviální, nevidím pro to žádný užitek.

Pseudokód je užitečný pro návrh programu. Bez rozptylování, které vyžaduje správnou syntaxi, a bez zdlouhavosti, kterou mohou některé jazyky zahrnovat. Skutečnost, že je jeho psaní rychlejší, také usnadňuje redesign kód. A můžete být tak struční, jak si vaše mysl přeje, je příjemné to psát, vyžaduje méně duševního úsilí, aby to fungovalo (jako žádné nebo mnohem méně ladění), a větší schopnost soustředit se na celkový obraz a design.

Takže užitečné pro sebe.

Mohou být také zvyklí komunikovat s ostatními.