it-swarm-eu.dev

Měl by někdo použít pseudokód před vlastním kódováním?

Pseudokód nám pomáhá porozumět úkolům jazykově agnostickým způsobem. Je nejlepší praxí nebo navrhovaným přístupem vytvoření pseudokódu jako součásti životního cyklu vývoje? Například:

  • Identifikujte a rozdělte úlohy kódování
  • Napište pseudokód
  • Získejte schválení [pomocí PL nebo TL]
  • Začněte kódování založené na pseudokódu

Je to navrhovaný přístup? Je to praktikováno v průmyslu?

23
Vimal Raj

Psaní pseudokódu před kódováním je určitě lepší než pouhé kódování bez plánování, ale zdaleka to není nejlepší praxe. Testem řízený vývoj je vylepšení.

Ještě lepší je analyzovat problémovou doménu a navrhnout řešení pomocí technik, jako jsou uživatelské příběhy, případy použití, karty CRC, schéma, jak se osvědčují metodiky jako Cleanroom, RUP, Lean, Kanban, Agile atd.

Důkladné pochopení povahy problému a součástí, které používáte k implementaci řešení, je zásadou osvědčených postupů.

17
Huperniketes

Komentáře používám jako druh pseudokódu na vysoké úrovni, v tom, že píšu komentáře, než píšu kód. Zjistil jsem, že myšlení skrz celý problém, i na vysoké úrovni, značně zlepšuje můj kód.

19
Hal Helms

Ne, nejdřív pseudokód

To je příliš mnoho režie. Pracujete na psaní logiky, aniž by to mělo nějakou výhodu. Místo toho bych navrhl některou z následujících možností:

  1. Prototyp v jazyce, s nímž se chystáte dodávat (AKA Napište jeden zahozený )
  2. Schémata architektury s úryvky kódu pro testování předpokladů/návrhů klíčů
  3. Testem řízený vývoj, ve kterém nejprve napíšete strukturu rozhraní/kódu, poté testy a následně implementaci kódu.

Na rozdíl od pseudokódu vás všechny tři posunou přímo k vašemu řešení. Osobně mám tendenci používat techniky 1 nebo 2 v závislosti na velikosti týmu. Pro menší týmy (např. 5 a méně lidí) funguje prototypování velmi dobře. U větších týmů, které mají paralelně více skupin vývojářů, jsem zjistil, že dokumentace vytvořená brzy technikou 2 funguje dobře, protože vám dává něco k diskuzi a pomůže vám lépe definovat hranice komponent. Jsem si jistý, že TDD bude také fungovat velmi dobře, ale ještě musím pracovat na týmu, který se k tomuto procesu zavázal.

8
Jay Beavers

Podle mého názoru má pseudokód pouze dva platné účely:

(1) Pro studenty programování, kteří se potřebují naučit konceptu modularity a algoritmů, ale dosud neovládají plynule programovací jazyk.

(2) Sdělit, jak něco bude fungovat, s netechnickou osobou nebo jen pro účelnost na schůzce typu bílou tabuli.

7
JohnFx

Je pseudokód doporučeným přístupem? Pro začínající programátory říkám ano. Pomáhá novému programátorovi naučit se překládat problém do kódu bez obav z přesné syntaxe jazyka. Toto utváří myšlenkový proces a může pomoci zakořenit užitečné návyky (a také předpokládám špatné návyky). To je důvod, proč se ve školách tolik používá.

Je to praktikováno v průmyslu? Podle mé zkušenosti ne. Nikdo nemá čas prozkoumat projekt mezi dokumentací (požadavky, specifikace, scénáře, případy použití nebo cokoli jiného, ​​co používají) a skutečným kódem. Obecně se předpokládá, že dostatečná myšlenka již byla do problému před zeleným světlem kódována. V tomto okamžiku je kódování projektu důležitější než přidání další vrstvy přípravy návrhu.

5
Corin

Pseudokód může být užitečný, pokud nejste obeznámeni s jazykem nebo potřebujete změnit mentální kontext. Ve vzácných případech, kdy píšu pseudokód, je to na papíře. Někdy stačí obejmout ruce z klávesnice a čmárat na papíře může pomoci obejít mentální blok.

Ale jako formalizovaná součást procesu vývoje? V žádném případě. Je to ojediněle užitečný nástroj pro jednotlivce. Existují lepší způsoby, jak „vědět, co píšete, než píšete“, například:

  1. definování smlouvy (pre/post/invariantní podmínky) metody před zahájením
  2. TDD
  3. 1 a 2 společně (písemné testy k provedení smlouvy)

Navrhl bych také, aby získání jakéhokoli schválení před zahájením psaní kódu pravděpodobně způsobovalo mnohem více potíží, než stojí za to. Přezkum návrhů (před implementací) může být užitečný, ale musí být na vyšší úrovni než jednotlivé algoritmy.

3
Ben Hughes

Rozhodně bych doporučil pseudokód. Pomáhá vám objasnit, co budete dělat, a identifikovat položky, na které jste zapomněli, nebo potenciální problémy. Je to mnohem snazší/rychlejší opravit váš kód, když je stále ve fázi plánování, a pak čekat, dokud jste již nekódovali jeho velkou část.

3
Rachel

Jedinýkrát, co jsem použil pseudokód za posledních 10 let, jsou rozhovory, když pracujeme na tabuli a na konkrétním jazyce nezáleží.

Je to jistě užitečné, když můžete mluvit skrz proces/algoritmus volně, aniž byste se zabrali se syntaxí. Např. psaní třídy C++, která má vlastnosti C #, pouze pro ilustraci bodu.

Má své „místo“, ale mělo by být použito pouze tam, kde je to potřeba (je to práce, kterou vyhodíte), a rozhodně by neměl být součástí formálního procesu, pokud nemáte normy typu ISO, které na tom trvají.

2
JBRWilkinson

Pro mě a lidi, se kterými jsem v posledních několika letech pracoval, se pseudokód změnil v ne zcela dokonalý skutečný kód. pokud nebudete pracovat s mnoha jazyky současně, zdá se, že většina lidí začíná přemýšlet podle obecného vzorce svého hlavního jazyka. Chvilku jsem pracoval v obchodech .net, takže klikyháky většiny lidí v kanceláři vypadají jako vb nebo c #, přičemž některé interpunkce chybí.

Cvičení je stále cenné při debatování o možnostech atd., Ale jazyková agnostická bitová tendence se unáší, protože trávíte více času několika jazyky.

2
Bill

Stále více je pseudokód psán graficky pomocí nástrojů, jako je UML. Například vyzkoušejte yUML .

online nástroj pro vytváření a publikování jednoduchých diagramů UML. Je pro vás opravdu snadné:

  • Vložit diagramy UML do blogů, e-mailů a wiki.
  • Post U diagramy UML ve fórech a blog komentáře.
  • Používejte přímo ve svém webovém nástroji pro sledování chyb.
  • Zkopírujte a vložte diagramy UML do dokumentů MS Word a PowerPoint prezentací ...

... yUML vám ušetří čas. Je určen pro ty, kteří rádi vytvářejí malé UML diagramy a náčrtky.

Bez aplikace yUML by vytvoření diagramu UML mohlo vyžadovat načtení nástroje UML, vytvoření diagramu, pojmenování, fiddling s rozvržením, export do bitmapy a následné nahrání online někam. yUML nedělá nic z toho ...

2
mouviciel

Budu nesouhlasit s předchozími odpověďmi a řeknu ne, ale s výhradou: můžete se zbavit psuedocode, pouze pokud jste horečně oddaní refactoring kódu, abyste se vypořádali s problémy, které se objevují. Psuedocode je ve své podstatě způsob, jak definovat váš kód před definováním kódu; je to zbytečná abstrakce za mnoha okolností, a protože váš kód nebude nikdy dokonalý poprvé (a pravděpodobně nebude následovat návrh psuedocode k dokončení), zdá se mi cizí.

2
EricBoersma

Pokud píšete COBOL nebo C, může být užitečný pseudokód, protože psaní skutečného kódu bude trvat mnohem déle a pokud si z pseudokódu můžete ověřit svůj algoritmus/požadavky, můžete ušetřit čas.

Ve více moderních jazycích, pseudokód nedává tolik smyslu. Co by fungovalo lépe, je psaní metody útržků a vyplňování logiky nejvyšší úrovně a tolik podrobností, kolik je třeba k ověření algoritmu a požadavků, to vše ve skutečném kódu. Poté můžete tento kód ukázat vedoucímu týmu ke schválení a svůj skutečný kód nechat již spustit.

2
Larry Coleman

Skvělá práce. Začali jste dobrou diskusi. Jako já jsem psal pseudokódy, když jsem se učil programovat, abych pochopil různé smyčky a algoritmy. Bylo to před více než jednou a půl desetiletími. Tehdy ani programovací jazyky nebyly moc silné ... a programování řízené událostmi bylo budoucí. Nyní se 4GL a 5GL uvažujeme spíše v samotném jazyce než v prosté angličtině. Když myslíme na problém, myslíme na objekty a operace. A dokud to není složité algo, psaní pseudokódů (nebo P-S-E-U-DO-kódů, jen si dělám srandu) nedává žádný smysl. Lepší je znázornit řešení grafickým způsobem.

1
devcoder

Existuje několik okolností, kdy se pseudokód ve své práci obvykle vymaní, což je na akademické půdě, kde se programování zvykne používat jako nástroj nebo „a nyní to řešíme“ vyplňování uprostřed projektu:

  1. Když bude kód více kontraproduktivní pro skutečné pochopení toho, co se stane, bude pseudokód. SAS zabere polovinu tabule, která provádí některé docela základní programovací úkoly. Viz také C, o kterých diskutovali některé další plakáty).
  2. S velkým množstvím analýzy dat a kódování statistik, tam je tendence být hodně pohrávání s kódem, jak jsou generovány výsledky. Použití pseudokódu je o něco jednodušší pro „zde leží proces dozadu a dopředu, pokud diagnostický diagram nevypadá správně, zkuste X“.
  3. Studenti se učí spoustu různých programovacích jazyků. Například mezi lidmi, které znám, může být statistický problém analyzován v SAS, R nebo Stata. Něco, co vyžaduje něco bližšího k tradičnímu programování, může být provedeno v jazycích R, Matlab, C, C++, Java, Python ... opravdu záleží na tom, co daný student implementuje a za jakým účelem. Ale je stále užitečné pro Java lidi a Python lidi a Matlab lidi) mít společnou představu o tom, co dělají ostatní a jak - přístup, spíše než samotný kód funguje.
0
Fomite

To není otázka typu ano/ne. Spíše by se měli ptát kdy používat pseudokód. Před návrhem řešení je důležité tento problém pochopit a před implementací je důležité mít jasný pohled na řešení. Pseudokód lze použít v kterémkoli z těchto kroků:

  1. Při definování problému je běžné zapisovat případy použití, někdy pomocí sekvencí akcí.
  2. Při navrhování řešení. Diagramy tříd jsou pěkné, ale popisují pouze „statickou“ část, tj. Data. Pokud jde o dynamickou část, jakmile se budete muset vypořádat se smyčkou a netriviálními údaji, považuji pseudokód za nejlepší dostupnou metodu. Grafické alternativy zahrnují stavové stroje (dobré pro komplexní řídicí tok s malými daty) a datové tokové diagramy (dobré pro jednoduché toky s komplexními daty).
  3. Při implementaci řešení (nebo těsně předtím). Některé programovací jazyky jsou obtížně čitelné (myslím, shromáždění). V tomto případě může být užitečné alternativní zobrazení. Pokud nejste obeznámeni s jazyky, vyplatí se to také.

Používá se také pseudokód, který je ve skutečnosti správným kódem v jazyce vysoké úrovně, obvykle se nazývá prototypování.

Kromě porozumění je pseudokód také vhodný pro komunikaci.

Pokud vás zajímá, zda byste měli pravidelně používat pseudokód, osobně jsem proti všem přísným pravidlům. To se může snadno proměnit v nudnou ztrátu času, pokud se používá pro triviální problémy, kterým všichni v týmu rozumí. Použití pseudokódu pro specifikace, které udržujete po celou dobu trvání projektu, může být také nákladné a nabídnout malou hodnotu.

0
Joh

Závisí na použitém jazyce a na jeho znalosti.

Mnoho moderních jazyků jako Python nebo Java jsou již tak blízko pseudokódu, že psaní nějakého ad hoc pseudokódu jako první je zbytečné, IMHO). pomocí přístupu tracer bullet .

Je to jiná dohoda, pokud děláte nějaké nízkoúrovňové věci, blízko kovovým věcem nebo nejste dosud spokojeni s jazykem, který používáte. Pak může být pseudokód rozhodně užitečný.

0
Joonas Pulakka