Přidat otázku mezi oblíbenéZasílat nové odpovědi e-mailem Ako programuješ?

Ak je tu nejaký programátor zaujíma ma proces ako píše program... proste všetky detaily od myšlienky až po realizáciu aby som mal prehľad ako to funguje v praxi

Jsou zobrazeny jen nové odpovědi. Zobrazit všechny
Předmět Autor Datum
Získám zadání. Promyslím si, proč je takové, jaké je a co asi skutečně potřebuje zadavatel. (Málokdy… poslední
gilhad 05.02.2014 20:22
gilhad

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čí.

Zpět do poradny Odpovědět na původní otázku Nahoru