Ako programuješ?

Nechceš se zeptat trochu konkrétněji? Tohle je hrozně obsáhlá problematika.

proste ako sa v praxi píše kód napr. v Jave, ako si rozobrať problém a ako postupovať pri písaní a tak

To jsi to moc nekonkretizoval.

tak inak je nejaké zadanie čo má ten program robiť a teraz to dostane programátor, čo začne robiť? zoberie papier a pero? začne rovno ťukať do pc? napíše si algoritmus? rozdelí si to? premyslí si to? atď

Nejsem programátor, ale každý podle toho, jak mu to vyhovuje. Někdo je tak geniální, že může začít hned mlátit do klávesnice, někdo si to čmárá třeba na zdeď, někdo musí začít tím, že si udělá kafe, ...

mne ide o to aby sa vyjadrilo zopár programátorov aby som videl ako to asi robia a potom skúšal podľa toho čo vyhovuje mne :) ja viem mal by som vedieť sám čo mi je najlepšie ale neuškodilo by vidieť nejaké príklady a nejako si ich skombinovať a inšpirovať sa

Nejlepší je najít si vlastní postup. Jako na všechno. Já třeba třeba myju auto tak, že nejdřív vemu wapku, opláchnu ho, potom ručně myju houbou se šamponem, potom opláchnu a nakonec vysuším jelenicí. Soused si jezdí nechat poškrábat auto do myčky a kamarád myje auto vlhkým hadrem a nakonec ho opláchne kýblem. Všichni tři myjeme auta. Takže asi tak.

Programátor ještě úplně nejsem, ale z dosavadních zkušeností na školních projektech můžu popsat aspoň něco (věřím, že nás na FITu vedou správným směrem). V první řadě je potřeba provést dekompozici problému, tj. rozdělit problém na podproblémy a zhruba si ujasnit, jak se budou řešit. Dalším krokem je algoritmizace - promyslet si, jaký algoritmus se použije na konkrétní podproblém. Pokud pracuje na projektu víc lidí, tak se musí domluvit, co kdo bude dělat - rozdělit projekt na několik modulů, ujasnit si rozhraní, knihovny apod. Zdá se to možná jednoduché, ale třeba práce v pěti lidech vyžaduje určitou koordinaci - git repozitář, časté schůzky apod. Potom se může začít tvořit. Je to různé, ale mě třeba vyhovuje začít od úplného základu (k tomu dojdu dekompozicí). Jak je hotová první funkční část, tak ji vyzkoušet a pokračovat na další úroveň. A taky je potřeba pořádně otestovat výsledný program - napsat si vlastní testy, nebo použít nějaké jiné. Program musí správně reagovat na nejrůznější vstupy, situace apod. Neměl by spadnout, ani se zacyklit, když mu dá uživatel nesmyslné vstupy.

Do PC rozhodně nic nezačne psát, leda by sám dělal nějaký malý projektík. Obvykle se ale dělají větší programy a v týmech. Je tedy vhodné (spíš nutné) si ten program rozdělit na menší části, ty na ještě menší atd. Až je každá část tak velká, aby ji zvládnul udělat jeden člověk během několika málo dní. Při tomhle se taky uvažuje o tom, co je nutné udělat hned, co později, co počká až na verzi 2.0 atd. Stanovují se taky požadavky na uložení dat, na výkon jednotlivých částí, různé konvence...
Tohle je téma o kterém se píší celé knihy.

Zkus si přečíst tohle:
http://pc.poradna.net/a/view/307882-uvodni-analyza -projektu

Od myslienky mozgom, a potom rukami.
Ked sa takto pytas tak bud nemas paru ani co to je printf, alebo to proste nedas nikdy.

(P.S. a nazyvat analytika vyrazom "programator" je uz skoro urazka :D)

Urážka analytika nebo programátora?

Na škole jsem jeden program rovnou začal psát. V assembleru
U některých projektů jsem začínal vývojovým diagramem (když šlo například o minimalizaci doby trvání, o určení, co může "běžet" zároveň). A pak už jen psát, jeden řádek kódu za druhým.

Dnes už neprogramuju, Fortran i Cobol mi jsou k ničemu

Programovat treba. Ja mam naprogramovane: dnes o 20:00 s kamaratmi na pive.

To jsme na tom stejně. Ty jednoduché úlohy v asembleru šli psát rovnou (zvlášť, když měl člověk k dispozici funkční debuger). Teď jsem se ale k mikročipům vrátil (v Céčku) a tam už jsem projekt rovnou z hlavy nedal (a ani v asembleru by to nešlo). Byl příliš komplikovaný a pokaždé, když jsem si ho na papíře rozebíral mě něco nového napadlo.

Geekové dokáží programovat i tak, že v editoru založí nový program.exe a přímo to tam klovou v hexa. Ti nejlepší z nejlepších pak umí rovnou implementovat i UPX packer.

To jsou masla, ti lepsi pisou rovnou program.iso..

Programátor je človek, ktorý píše program, a píše ho tak, ako mu ho zadajú. Nemal by vymýšľať žiadne extra myšlienky, pretože od toho sú tu analytici a architekti. Takže programátor v podstate len prepisuje špecifikáciu do programu a väčšinou je to tak, že môže rovno začať písať.

Všetko sa samozrejme projekt od projektu líši. Niekde dostane programátor od analytika div nie že pseudokód toho, čo má spraviť. Inde zas dostane len všeobecný popis, ktorý by lepšie napísali deti z materskej škôlky. Spôsob práce programátora je tiež iný v prípade, že vytvára nový program od základov, alebo len rozširuje prípadne opravuje existujúcu funkcionalitu.

No a ak ťa zaujíma, ako je to v praxi, tak obchodník predá zákazníkovi modré z neba. Projekťák podľa toho nastaví plán, hoci tuší, že sa nevojde do rozpočtu a/alebo do deadlajnu. Analytici vydolujú zo zákazníka (ktorý nikdy nevie, čo chce) špecifikáciu, presnejšie jej prvú verziu. Architekt to celé navrhne po technickej stránke a potom dáva celé dni a noci dokopy ten domček z karát, ktorý postavia programátori. Programátor len píše kód.

A pak se to celé rozsype, protože zákazník si vymyslí funkčnost, o které se na začátku dušoval, že nikdy nebude chtít. A pokud se s ní nepočítalo v návrhu od začátku (samozřejmě to znamená vyšší náklady na prvotní vývoj), musíš celkou část napsat znovu a jinak.
Tohle vše by měl zvládnout analytik, domyslet i to, co by zákazník mohl potřebovat v budoucnu.

A jak to obvykle dopadne? Takto:

Tohle jsem viděl už v několika verzích, ale tahle je asi nejlepší

Získám zadání. Promyslím si, proč je takové, jaké je a co asi skutečně potřebuje zadavatel. (Málokdy zadavatel řekne, co skutečně potřebuje, většinou to neumí zformulovat a často píše o něčem zcela jiném.) Zkonzultuju to s ním (často se ukáže že tam jsou další dosud nezmíněné věci a že je vše zcela jinak). Opakuju, dokud mi vše není jasné.

Navrhnu si hrubé rozdělení systému a vazby mezi jednotlivými částmi (jak logické, tak protokoly). Rozdělím celý problém na víc relativně samostatných částí. Vezmu jednu část a celý proces opakuju. Tak dlouho, až se dostanu k něčemu dostatečně malému a jasnému, aby to šlo rozumně realizovat.

Shromáždím potřebné nástroje, technologie, data a jiné podklady. Založím dokumentaci, průběžně ji udržuju (jinak se z toho člověk zblázní a něco opomene/udělá na dvou místech jinak/...) V kódu loguju všechny zajímavé obraty, dosažená místa, úspěchy, neúspěchy ... (ladím s maximálním logováním, až to bude fungovat, tak nastavím, aby se logovaly jen důležité milníky). Všechny hodnoty, kde to jen trochu jde používám z konfigurace (s rozumnými defaulty) - magické hodnoty v programu jsou peklo. Pokud se stejná hodnota použije na více místech, nastavím ji v jednom bodě, dál se na ni odkazuju - při kopírování vznikají chyby, když opravuješ něco s více kopiemi/výskyty, zcela zákonitě to aspoň na jednom místě zapomeneš/uděláš trochu jinak.

Průběžně testuju, zda vytvářená věc dělá co dělat má. (Unit testy, logické testy v kódu, testovací data, pro která znám výsledky ...)

Každou větší změnu (a taky pokaždé když odcházím od klávesnice) komituju do verzovacího systému (doporučuju git).

Pokud vyvýjená část není zcela dole v hierarchii (dosud neudělaných), tak všechny odkazy na okolní funkce zapisuju do zvláštního souboru, abych je později vytvořil ve správném tvaru.

Používám přiměřeně dlouhá a konzistentní jména, píšu hodně komentářů, píšu do dokumentace co a proč je jak dělané. (Teď je to třeba jasné, až se k tomu vrátím po několika desítkách let, nemusím si to už tak zřetelně pamatovat.) (Osvědčila se mi na to wikipedie) Proměnné deklaruju/inicializuju pokud možno na začátku bloku, kterého se týkají, včetně komentáře, proč tato proměnná, proč tato hodnota.
Používám foldování, výrazně zvyšuje přehlednost kódu - vidím co se děje okolo a rozbalím jen to, na čem aktuálně pracuju.

Snažím se zabránit duplicitám, vedu si záznamy, co ještě chybí, co nefunguje zcela správně, co chce vylepšit (ideálně pro každý projekt mít bugzillu, nebo něco podobného). Když to vyřeším, označím to jako vyřešené a v příslušném komitu je odkaz do bugzilly.

Dost se mi osvědčilo pro netriviální změny používat samostatné branche pojmenované podle tiketů v bugzille.

Celý tento proces opakuju postupně pro další a další části problému.

(Pokud je jakákoli nejasnost - konzultace se zadavatelem)

Release early, release often. Jakmile něco aspoň trochu funguje, ukážu to zadavateli, s tím, co od toho očekávám, co to už umí a hlavně co ještě ne - když si s tím může hrát, často přijde na další věci a požadavky, které si na začátku neuvědomil, nebo na něco, kde jsme se vzájemně nepochopili zcela dokonale. Čím dřív na to příjde, tím snáz se to dá opravit.

Logování se snažím dělat tak, aby se dalo rozumně číst a snadno interpretovat

2014-02-04 03:13:03,979	log.make_plan	INFO	================================================================================
2014-02-04 03:13:04,081	log.make_plan	MILESTONE	--force => Nebudu čekat na dokončení skladby, plánuju tvrdě od TEĎ
2014-02-04 03:13:04,096	log.make_plan	MILESTONE	--check => Budu počítat pouze pokud nejsou plány
2014-02-04 03:13:04,103	log.make_plan	MILESTONE	Počítám pro datum 2014-02-04
2014-02-04 03:13:04,111	log.make_plan	MILESTONE	Startuji vytváření plánů (2014-02-04 00:00:00 .. 2014-02-04 23:59:59) 
2014-02-04 03:13:04,118	log.make_plan	INFO	casy: 00:00:00 .. 23:59:59, den: 2014-02-04 00:00:00; 2 (úterý)
2014-02-04 03:13:04,140	log.make_plan	INFO	Připojení k databázi OK
2014-02-04 03:13:04,146	log.trace	INFO	Připojení k databázi OK
2014-02-04 03:13:04,159	log.make_plan	INFO	Jsem box 400
2014-02-04 03:13:04,165	log.trace	INFO	Jsem box 400
2014-02-04 03:13:04,201	log.make_plan	MILESTONE	Jsem klient kli_00338: 'XX: Testbox2 u Gilhada PI', hlasitost (0.79,0.79,0.79)
2014-02-04 03:13:04,209	log.trace	INFO	Jsem klient kli_00338: 'XX: Testbox2 u Gilhada PI', hlasitost (0.79,0.79,0.79)
2014-02-04 03:13:04,216	log.make_plan	INFO	casy: 00:00:00 .. 23:59:59, den: 2014-02-04 00:00:00; 2 (úterý)
2014-02-04 03:13:04,241	log.make_plan	MILESTONE	CHECK: OK, mám 471 řádků, nemusím nic dělat = KONEC
2014-02-04 03:13:04,248	log.trace	INFO	The End

Konfigurace nechávám vytvářet i s komentáři

...

dbhost	= u"localhost"	# databáze je zde na boxu
dbname	= u"xxxyyyzzz"	# zde mám tabulky
dbuser	= u"username_for_db" # pod jakým jménem se hlásím do databáze
dbpasswd = u"super_mega_heslo" # heslo 

cron_offset	= 0	# o kolik sekund se má opozdit oproti cronu (odvozuju z čísla boxu)

...

Pokud něco může nabývat dvě a více hodnot, použiju minimálně int. Pokud počítám s časem, tak aspoň na milisekundy. Nevyužít v praxi celý rozsah možných hodnot není hanba, natahovat původně příliš omezený rozsah je vždy strašný opruz a vede to k chybám. Ušetřit pár bitů za cenu toho, že údržba bude násobně dražší je ekonomický nesmysl, čas programátora stojí mnohem víc, než pár bitů RAM/disku. (Zase neplýtvám zbytečně.) Pokud se ukáže, že je potřeba ušetřit, je to snažší udělat v přehledném odladěném programu, kde lze předchozí verzi použít pro kontrolu správnosti výsledků.

Pokud je možno, opisuju od lepších, nebo aspoň od sebe. Vymýšlet pokaždé kolo je velice pracné, zdržuje a odvádí od hlavní myšlenky. (Ale nelze opisovat něco, čemu člověk sám nerozumí, protože to je skoro jistě stavěné na jiných předpokladech a dělá trochu něco jiného, než je potřeba zde). Optimalizovat se dá, až když program bezchybně funguje a je vidět, kde je optimalizace potřeba.

Testuju všechny chybové stavy, zvláště ty, co nemůžou nastat (ty nastanou v 90% případů, obzvláště pozdě v noci před deadlinem) Odhadem 80-90% kódu ošetřuje zda je zadání správné, zda nenastala chyba, zda je výsledek logický a konzistentní ... ten zbytek něco počítá.

Ono je toho ještě hodně a toto je jenom lehké dotknutí se tématiky. Člověk se učí pořád a pořád se zlepšuje v tom, co dělá - přečíst jednoduchý návod vážně nestačí.