Ako programuješ?

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