Mikor használnék álkódot a folyamatábra helyett?

Fl az owchartok és az álkódok expresszivitása gyakran azonos, de a linearizációban különböznek egymástól. Az álkód lineáris (vagyis utasításokkal ellátott sorok sora), a folyamatábra nem. Ezért a folyamatábra magasabb absztrakciós szint, amelyet az álkód megírása előtt vagy dokumentációként használnak.

A folyamatábra véleményem szerint két erős előnnyel rendelkezik az álkóddal szemben: Először is grafikusak. Sok nem technikai embertől nagyon tartanak a strukturált szövegtől, de a grafikus leírásoktól nem, ezért a folyamatábra sokkal jobban illik hozzájuk. Másodszor, a folyamatábra sokkal jobban fejezi ki a meta-szempontokat, például megmutatja a végrehajtás fő vonalát az ágakkal szemben.

A kérdéseivel részletesen:

1. Egy igazán bonyolult megoldáshoz probléma, először a folyamatábrákat használja, majd az álkódot. Mindkettő opcionális, ha elég biztonságosnak érzi magát.
2. Igen, az álkód előnye, hogy összeolvasztható a valós kóddal. Steve McConnell például nyomatékosan javasolja, hogy először pszeudokódba írjanak módszereket, majd kommentárként hagyják a pszeudokódot a kódban.
3. Mindig úgy éreztem, hogy a folyamat során folyamatábra rajzolásának szükségessége a probléma elégtelen felosztását mutatja. A nem triviális folyamatábrák tekervényes logikát jeleznek, amelyet nagy költségekkel el kell kerülni.

Megjegyzések

• A folyamatábrák is nagyszerű módszerek s győződjön meg arról, hogy minden döntési pont meghatározza a kevésbé gyakori út (ok) és a leggyakoribb útjait. Ez segít abban, hogy tudja, mit kell tennie, ha a jóváhagyást elutasítják vagy a megrendelést törlik! Az éles esetekben gyakran több hiba fordul elő, mert az emberek elfelejtik ezeket megtenni, vagy a QA során rohanással végzik, amikor a tesztek megtalálják őket.

Az álkódról

Hogy őszinte legyek, nem sokat használok pszeudokódot. Általában gyorsabb csak a kódot írni, így amikor az én kódom, ez a tényleges kód. Vannak olyan esetek, amikor az álkód hasznos lehet, de Ön általában valami nagyon összetett dolgon dolgozik, és csak egy módszer vagy valami felépítését próbálja lebontani. Ezekben az esetekben az IDE-mben található megjegyzéseket használom a szerkezet felépítésére amíg rendbe nem hozom a dolgokat. Ezután bemegyek, és beírom a tényleges kódot a megjegyzésekbe. Ez segít nekem néhány dolgot megtenni:

• Látom azokat a területeket, amelyek vannak és amelyeket még nem hajtottam végre elolvasva a megjegyzéseket, és nyilvánvaló hiányosságokat látok bennük.
• Amikor kitöltöm a valós kódot, vannak megjegyzéseim, amelyek angolul elmagyarázzák, hogy mit csinálok. (Valószínűleg szükségük lesz rá, ha annyira bonyolult. hogy először ál kódot kell írnom).

Folyamatáblákon

A kód általában annyira megváltozik, hogy a folyamatábra nem segít, kivéve a nagyobb, rendszerszintű architektúrát tervezés vagy dokumentáció. Ezekben az esetekben csak egy táblázatot fogok kitáblázni, hogy megismerhessem a dolgok lényegét, vagy megmutathassam másoknak a csapatban. Hacsak nem igazán kell folyamatábra a megértéshez, akkor nem igazán kellenek nekik a szoftverek “megcsinálásához”. jobb. Manapság rengeteg bővítmény van az IDE-k számára , amelyek magából a kódból generálnak folyamatábrákat, valamint osztálydiagramokat és másokat (és fordítva `). Az egyetlen valós idejű, amikor komolyan pontosan folyamatábrát kell készítenie, az az, ha nem tudja megtartani az egész architektúrát és a dolgok működését a fejében egyszerre, és valami vizuális eszközzel kell beszélnie a kincsek elkapása érdekében.

Általában nem írok folyamatábrákat, miközben személyes projekteken dolgozom (mivel a projektek nem túl nagyok), és a legtöbb bemenet, kimenet és folyamat egyértelmű.

de amint elkezdesz dolgozni összetett nagy projekteken, különböző bemeneti forrásokkal, a lapos fájlok, adatbázisok, kézi interfészek stb. hasznosak a folyamatábra.

Javasolnám ál kódot és UML digramokat írsz, mivel ezek az eszközök segítenek jobb osztályok, módszerek stb. kidolgozásában. Néha az ál kód írása során különböző és hatékonyabb módszereket találsz egy program megoldására.

Az álkód arra szolgál, hogy gyorsan megjelenítsen egy ötletet azok előtt, akik értenek legalább a kód alapjaihoz. A folyamatábra mindenki számára szép képeket rajzol megérteni ugyanazt.

A folyamatábrákat gyakran használják dokumentációs célokra, mert sok ember használja ezt a dokumentációt, és a folyamatábra könnyebb követni, mint álkódot nem programozók számára. Egy olyan projektben, amelyen magadnak dolgozol, az álkód betartása rendben van, mivel sokkal hasznosabb és sokkal könnyebb létrehozni, mivel csak egy szövegszerkesztőre van szükséged.

A folyamatábra magas szintű absztrakció, amely lehetővé teszi, hogy megtervezze a dolgok folytatását, például

ha x meghal és y nyer

Nem kell attól függeniük, hogy hogyan tervezik a programot osztályok és módszerek szempontjából, másrészt álkód alacsonyabb szintű absztrakciót biztosít (bár ez valóban függ)

if (isdead (s) y.win ()

így az álkód most már lefordítható a tényleges programba az Ön által használt nyelv alapján.

Egy játék esetében először egy folyamatábra használatát javasolnám, majd a tervezést. az osztályokat és metódusokat, írj álkódot, és végül alakítsd át programgá

d vegye figyelembe az Ön által írt kód jellegét. Ha igen:

1. erősen iteratív / rekurzív
2. ágak bonyolult módon
3. több rendszerben megvalósítva, amelyeket képviselni szeretne

Az első két esetben az álkód fokozatosan nehezebben olvasható, mint egy nagy képdiagram. Másrészt a többnyire lineáris kód hihetetlenül unalmas diagramokat készít, amelyek valójában megnehezítik a folyamat megértését, mert mennyire robbantja fel.

A harmadik esetben a folyamatábra jobban ábrázolja azokat a folyamatokat, amelyek lépje át a rendszer határait és képviselje az egész folyamatot.

1. Bármit használjon, amiben jól érzi magát. Ennek ellenére az a benyomásom, hogy manapság a folyamatábrákat nem nagyon használják a programszabályozás vázlatára; egyrészt jellemzően strukturálatlanok, az álkódhoz képest. Gyakrabban olyan osztályfüggőségi diagramokat használnak, mint az UML, amelyek sokkal magasabb szinten írják le az architektúrát. Továbbá, ha az alkalmazásának van egy állapotgépe, akkor elengedhetetlen egy (folyamatábra-szerű) állapotgép-diagram megrajzolása.
2. Szerintem itt igaza van. A munka egyik módja, ha kiírja az álkódot megjegyzésként a forrásfájlba, és beilleszti közéjük a tényleges megvalósítási sorokat.
3. Ismét használjon bármit, amiben jól érzi magát. Ha nem biztos benne, próbálja ki mindkettőt; várom, hogy gyakorlata gyorsan összeforrjon a számodra leghasznosabb dolgokkal. Én személy szerint nem találom hasznosnak a folyamatábraokat, hacsak nem próbálok kibogozni egy különösen bonyolult végrehajtási sorrendet.

Miért kell álkódot írni, ha Java-t írhat? Találtam Java-t, jó IDE-t és A javadoc a programozási probléma megértésének legegyszerűbb módja – legalább egy objektumorientált probléma. (És egy arcade játéknak kellene OO-nak lennie.) A nyelvet erre az alapoktól kezdve tervezték. Egyszerű és egyértelmű. (Lehet, hogy sok célra túl egyszerű, de a legjobb dolog, amit erre láttam.) A Javadoc hipertextje és egy IDE révén maga a kód is érthetőbb “diagramot” hoz létre, mint amire még rá is lehetne húzni egy nagy papírlap. A Java kód ugyanolyan egyszerű, mint bármelyik álkód, és sokkal szigorúbb. És ha “ábrázoltuk” és “ál” kódoltuk, akkor a program valóban futni fog!

Megjegyzések

• a java és mások hosszasan felhúzhatók. ” public static void main .. ” vagy ” system.out.println ” vagy hosszú azonosítóval, camelback jelöléssel. van 2b elkapva..És bármelyik könyvtár hívása hosszas lehet. Emlékszem, hogy 10 évvel ezelőtt megnyitottam egy fájlt. valami új BufferedReader (új InputStreamReader (System.in)); láthatóan könnyebb most mkyong.com / java / … De valójában bármelyik könyvtár, amelyet hívsz, hosszú ideig fel lehet tekerni, nem olyan, mint az álkód, amely annyira tömör lehet, amennyit csak el tudsz képzelni
• Java-ban vagy bármely más nyelven is, a fordítás során hibákat talál el. egyik sem pszeudokóddal. figyelemelterelés nélkül koncentrálhat a tervezésre. Az álkóddal kapcsolatos megjegyzések sokkal rövidebbek lehetnek, mivel az álkód világosabb az elme számára, mivel ‘ az elmétől. ‘ nincs korlátozva, ha csak egy nyelven gondolkodik, és láthatja, hogy ah i ‘ ezt a másik nyelvet használja. ‘ gyorsabb és kevésbé fájdalmas írni (nincs szükség fordításokra – még a nagyon folyékonyan is fordulnak összeállítási hibák), és így kevesebb idő írásra megkönnyíti az újratervezést.
• @barlop: Nekem működik, de lehet, hogy nem mindenkinek. Nagyon sok kódot (például ” BufferedReader “) otthagyok az osztályaimból, amíg szükségem nincs rá, vagy tudnom kell, hogy működőképessé teheti. Még akkor is, ha megvan, ‘ s szépen eltűnt az útból azokban az osztályokban, amelyeket nem ‘ kell megvizsgálnom tervezés. A fordítói hibák könnyen kijavíthatók, és megakadályozhatják a nagyobb tervezési hibákat, például a rossz osztály használatát egy olyan ponton, ahol ‘ még is kaphat a megfelelő osztály. Bevallom, én már ” úgy terveztem meg a ” szoftvert, amely csak írd Java-ban, de az OP a Java-t használja.
• szóval mondd, hogy fájlt szeretnél nyitni, látod-e, hogy az openfile ( c: \ blah \ file “) rövidebb, mint a java? vagy hogy a ” dfdfd ” nyomtatás rövidebb, mint a java, hogy ezt megtehesse? Én ‘ még soha nem készítettem (még) oldalakat álkódról és több osztályról. részben ‘ cos nincsen ‘ t nagy programokat írtam korokban b) részben ‘ cos Nem ‘ nem hiszem, hogy megtenném, azt hiszem,

Használhat egy folyamatábrát, ha nagyon összezavarodik, ha az állítások és megpróbálja megérteni hogy. Vagy ha meg akar érteni egy hurkot, nézze meg a számlálók hatását. Ha megtanulja, ez sokat segíthet.

Kicsit korlátozónak érezheti magát, mivel rövid utasításokat kell mezőbe tenni. És ha a programja nagyon lineáris, a ciklusai és az if-i pedig triviálisak, akkor nem látok hasznot. >

Az álkód hasznos egy program megtervezéséhez. anélkül, hogy elvonná a figyelmet a helyes szintaxis megszerzéséről, és anélkül, hogy egyes nyelvek sokáig benne lennének. Az a tény, hogy gyorsabban ír, megkönnyíti az újratervezést is. kód. És lehetsz olyan tömör, amennyire az elméd vágyik, kellemes írni, kevesebb szellemi erőfeszítést igényel a működéshez (mivel nincs vagy sokkal kevesebb a hibakeresés), és nagyobb képességet kell összpontosítania az összképre és a tervezésre.

Tehát hasznos önmagad számára.

Használhatják másokkal való kommunikációra is.