Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: OTO 22. 11. 2017, 16:32:30

Název: Jak se neztratit ve vlastním kódu?
Přispěvatel: OTO 22. 11. 2017, 16:32:30
Ahoj, když děláte fakt velký projekt, jak si zapamatovat celou strukturu kódu? Neexistuje nějaká grafická aplikace, ve které by se daly vytvořit třeba názvy souborů s propojením? Děkuji za tip. O.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Ondrej.T 22. 11. 2017, 16:41:33
Doporucuji opustit Vim a pouzivat poradne IDE  8)
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Kit 22. 11. 2017, 16:55:32
Ahoj, když děláte fakt velký projekt, jak si zapamatovat celou strukturu kódu? Neexistuje nějaká grafická aplikace, ve které by se daly vytvořit třeba názvy souborů s propojením? Děkuji za tip. O.

Napsal jsem si skript, který mi generuje diagram tříd z dostupných zdrojáků. Není to nic složitého.

Hodně však pomáhá správná organizace namespace, tedy současně i adresářové struktury. Na to se hodí např. Freemind. Jistě, většina IDE to umí, ale podstatné je, jak to zvládá architekt aplikace.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Vykook 22. 11. 2017, 17:48:18
Doporucuji opustit Vim a pouzivat poradne IDE  8)
Naprasit a ať se s tím popere IDE za mě. Chce se mi plakat.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Ladislav Jech 22. 11. 2017, 17:53:07
Ja pouzivam IntelliJ Idea, ale prevazne se hrabu v Java, Scala nebo node.js. Taky uz jsem stal pred podobnym problemem, kterej ale neprichazi ve chvili tvoreni, to mam vsechno v hlave, ale az kdyz se k tomu mam po par mesicich vratit a treba delat upravy. Pak se ptam, kdo tohle kurva psal :-)))

Ja si na vsechno pisu i minimalisticky knihovny, nebo projekt rozdelim do maven modulu. Kazdopadne celkove mi to pripada, ze si stavim lego kosticky (kdyz jsem byl malej, tak u nas byla cenove dostupna Cheva, tu jsem miloval) a pak z nich nekde slozim vetsi celky, atd. Koncept lega je pri psani kodu uplne stejnej a funguje vytecne.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: andy 22. 11. 2017, 19:15:15
Popozeram co su tam priblizne za package/classy, potom pouzivam eclipse call hierarchy, object hierarchy atd. Obcas kreslim na stary dobry papier. Skusal som aj xmind, ale nevyhovuje mi to, lebo papier mozem mat polozeny vedla klavesnice a nemusim ho hladat medzi 30 oknami..
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Ondra Satai Nekola 22. 11. 2017, 19:58:05
Doporucuji opustit Vim a pouzivat poradne IDE  8)
Naprasit a ať se s tím popere IDE za mě. Chce se mi plakat.

Ale houby - pouzivat vyhod IDE k tomu, aby byl kod co nejlepsi.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Kit 22. 11. 2017, 20:15:03
Doporucuji opustit Vim a pouzivat poradne IDE  8)
Naprasit a ať se s tím popere IDE za mě. Chce se mi plakat.

Ale houby - pouzivat vyhod IDE k tomu, aby byl kod co nejlepsi.

No jo, ale kdo to dělá? IDE klidně připustí, že třída Controller je třeba potomkem třídy Config. Od takových a podobných hovadin nás ani IDE nezachrání.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: aaa158 22. 11. 2017, 20:40:36
man cscope
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Ondra Satai Nekola 22. 11. 2017, 20:42:32
Doporucuji opustit Vim a pouzivat poradne IDE  8)
Naprasit a ať se s tím popere IDE za mě. Chce se mi plakat.

Ale houby - pouzivat vyhod IDE k tomu, aby byl kod co nejlepsi.

No jo, ale kdo to dělá? IDE klidně připustí, že třída Controller je třeba potomkem třídy Config. Od takových a podobných hovadin nás ani IDE nezachrání.

A hasicí přístroj ti nepomůže při vaření. Ergo hasicí přístroj je k ničemu.

Prostě je IDE jeden z řady nástrojů a technik, co programátor používá, aby dosáhnul nějakých výsledků. Že to neumíš je tvůj problém, ne problém IDE.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Ladislav Jech 22. 11. 2017, 20:45:07
Doporucuji opustit Vim a pouzivat poradne IDE  8)
Naprasit a ať se s tím popere IDE za mě. Chce se mi plakat.

Ale houby - pouzivat vyhod IDE k tomu, aby byl kod co nejlepsi.

No jo, ale kdo to dělá? IDE klidně připustí, že třída Controller je třeba potomkem třídy Config. Od takových a podobných hovadin nás ani IDE nezachrání.

1. SonarQube - tuna checku out-of-the box a muzes si psat svoje
2. Muzes si vytvorit nejaky project archetype jako sablonu
3. Muzes pouzit sablony - ja jsem to pouzival na generovani completni generovani plne funkcnich REST API nad entitama - FreeMarker, nebo low-level -> JavaPoet na githubu
4. Muzes si napsat vlastni quality checking parsovanim zdrojovyho kodu -> javaparser na githubu
apod.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Kit 22. 11. 2017, 21:31:35
Prostě je IDE jeden z řady nástrojů a technik, co programátor používá, aby dosáhnul nějakých výsledků. Že to neumíš je tvůj problém, ne problém IDE.

Problém je v tom, že uživatelé IDE ho považují za "silver bullet", který vyřeší problémy s architekturou aplikace. Nevyřeší, pouze je zamaskuje a zašmodrchá. Proč nepoužít čtyřnásobnou dědičnost, když to IDE umožňuje? Vůbec je netrápí, že to nemá logiku a aplikaci to činí nepřehlednou. Výsledkem jsou polofunkční aplikace, které pak musím po nich opravovat.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Kit 22. 11. 2017, 21:37:45
No jo, ale kdo to dělá? IDE klidně připustí, že třída Controller je třeba potomkem třídy Config. Od takových a podobných hovadin nás ani IDE nezachrání.

1. SonarQube - tuna checku out-of-the box a muzes si psat svoje
2. Muzes si vytvorit nejaky project archetype jako sablonu
3. Muzes pouzit sablony - ja jsem to pouzival na generovani completni generovani plne funkcnich REST API nad entitama - FreeMarker, nebo low-level -> JavaPoet na githubu
4. Muzes si napsat vlastni quality checking parsovanim zdrojovyho kodu -> javaparser na githubu
apod.

5. Napsat testy
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: RDa 22. 11. 2017, 21:39:47
Jak klasifikujes "vetsi projekt" ? Ve svych neco pres 600k LoC se porad dokazi orientovat (one man show), staci to pojmenovavat logicky a nemusim veci pak hledat - vzdy vim kde by co mohlo byt.

Pokud jsi ale neporadny sam, tak ti zadny tool nepomuze.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Ladislav Jech 22. 11. 2017, 22:00:36
Prostě je IDE jeden z řady nástrojů a technik, co programátor používá, aby dosáhnul nějakých výsledků. Že to neumíš je tvůj problém, ne problém IDE.

Problém je v tom, že uživatelé IDE ho považují za "silver bullet", který vyřeší problémy s architekturou aplikace. Nevyřeší, pouze je zamaskuje a zašmodrchá. Proč nepoužít čtyřnásobnou dědičnost, když to IDE umožňuje? Vůbec je netrápí, že to nemá logiku a aplikaci to činí nepřehlednou. Výsledkem jsou polofunkční aplikace, které pak musím po nich opravovat.

Ano, testy mi sice nepomuzou k tomu, abych se v kodu neztratil a udrzel nejakou stabni kulturu, ale jasne, souhlasim. Exituji napr. EvoSuite nebo randoop jako generatory unit testu, ale ani v kombinaci nepokryjou vice nez ~60% funkcionality.

Take doporucuju se kouknout na AspectJ, typicky pres to resim genericke logovani a error handling, takze tim nezasiras kod, ale aktivujes to typicky pres anotace, nebo bez anotaci enforcujes vsude. AOP je uz posledni dobou spise out hlavne v high performance java architekturach a spis se to resi pres. tzv "event middlewary"

Dalsi toolou pro zprehledneni kodu je urcite Lombok - zadny get/set, zadny konstruktory, zadny equeal, gethash, apod. Lombok dogenerovava kod on background, ale v *.java souboru ho nevidis, dynamicky generuje boiler-plate.

Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: PetrM 23. 11. 2017, 08:16:44
Ahoj, když děláte fakt velký projekt, jak si zapamatovat celou strukturu kódu? Neexistuje nějaká grafická aplikace, ve které by se daly vytvořit třeba názvy souborů s propojením? Děkuji za tip. O.

Na Doxygen jsi koukal?

Jinak základ je mít nějakou logickou strukturu programu a pak se v tom dá hledat docela dobře...
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Ondra Satai Nekola 23. 11. 2017, 09:31:49
Prostě je IDE jeden z řady nástrojů a technik, co programátor používá, aby dosáhnul nějakých výsledků. Že to neumíš je tvůj problém, ne problém IDE.

Problém je v tom, že uživatelé IDE ho považují za "silver bullet", který vyřeší problémy s architekturou aplikace.

Hezky pěkně strašák!
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: perceptron 23. 11. 2017, 10:09:00
no jo... to sa vo vim programuje ked mate jednoclenny team... ze kite
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: dustin 23. 11. 2017, 10:19:22
I v jednočlenném týmu se kvalitní IDE hodí (třeba pro domácí projekty), např. když se chci zorientovat v novém kódu, prozkoumat kód použitých knihoven atd (IDE rovnou u zabalených knihoven stáhne jejich zdrojáky, kam mohu dávat breakpointy a sledovat proměnné), atd.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: OTO 23. 11. 2017, 11:35:50
Nehledám něco, co generuje automaticky nějaký výstup.
Našel jsem tento "dead" projekt, škoda.. https://jaredforsyth.com/treed/ (https://jaredforsyth.com/treed/) ale hledám něco bez nodejs. Rychlé vkládání a přehledný výstup.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Kit 23. 11. 2017, 11:54:04
I v jednočlenném týmu se kvalitní IDE hodí (třeba pro domácí projekty), např. když se chci zorientovat v novém kódu, prozkoumat kód použitých knihoven atd (IDE rovnou u zabalených knihoven stáhne jejich zdrojáky, kam mohu dávat breakpointy a sledovat proměnné), atd.

K čemu jsou dobré breakpointy? :D
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: borekz 23. 11. 2017, 12:03:12
K čemu jsou dobré breakpointy? :D
Pokud si vystačíš s logováním, tak se aspoň hodí hw breakpoint při přepsání paměti. Konkrétně v C++. V pomalých jazycích se tyto kontroly provádí za běhu programu.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Ondra Satai Nekola 23. 11. 2017, 12:04:22
I v jednočlenném týmu se kvalitní IDE hodí (třeba pro domácí projekty), např. když se chci zorientovat v novém kódu, prozkoumat kód použitých knihoven atd (IDE rovnou u zabalených knihoven stáhne jejich zdrojáky, kam mohu dávat breakpointy a sledovat proměnné), atd.

K čemu jsou dobré breakpointy? :D

To je jenom realny zivot, toho si nevsimej, samotari :-D
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Kit 23. 11. 2017, 12:17:46
I v jednočlenném týmu se kvalitní IDE hodí (třeba pro domácí projekty), např. když se chci zorientovat v novém kódu, prozkoumat kód použitých knihoven atd (IDE rovnou u zabalených knihoven stáhne jejich zdrojáky, kam mohu dávat breakpointy a sledovat proměnné), atd.

K čemu jsou dobré breakpointy? :D

To je jenom realny zivot, toho si nevsimej, samotari :-D

Já jen, že jsem kdysi breakpointy dělával v assembleru, ale tuto metodu jsem v modernějších jazycích opustil jako neefektivní a divím se, že ji ještě někdo provozuje.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: jpu 23. 11. 2017, 12:18:12
dobre IDE akym visual studio bezpochyby je, dokaze velke veci. zmapovat kod, povytvarat diagramy, analyza kodu. Samozrejme u Kita toto vsetko dokaze aj VIM :D
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Ondra Satai Nekola 23. 11. 2017, 12:22:38
I v jednočlenném týmu se kvalitní IDE hodí (třeba pro domácí projekty), např. když se chci zorientovat v novém kódu, prozkoumat kód použitých knihoven atd (IDE rovnou u zabalených knihoven stáhne jejich zdrojáky, kam mohu dávat breakpointy a sledovat proměnné), atd.

K čemu jsou dobré breakpointy? :D

To je jenom realny zivot, toho si nevsimej, samotari :-D

Já jen, že jsem kdysi breakpointy dělával v assembleru, ale tuto metodu jsem v modernějších jazycích opustil jako neefektivní a divím se, že ji ještě někdo provozuje.

Ruzne situace si vyzaduji ruzne nastroje. Samozrejme clovek sam pise bezchybny kod... ale neni jenom vlastni kod. V realnem zivote, kdyz mas trebas kolegy. Kapis?
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: jpu 23. 11. 2017, 12:33:21
Kit asi pouziva toto :D:
Citace
__asm int 3
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: gll 23. 11. 2017, 12:44:28
Ruzne situace si vyzaduji ruzne nastroje. Samozrejme clovek sam pise bezchybny kod... ale neni jenom vlastni kod. V realnem zivote, kdyz mas trebas kolegy. Kapis?

Proč sem pletete kolegy? Téma vlákna je "Jak se neztratit ve vlastním kódu?". Debugger je samozřejmě užitečný i pro vlastní kód.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Ondra Satai Nekola 23. 11. 2017, 13:13:41
Ruzne situace si vyzaduji ruzne nastroje. Samozrejme clovek sam pise bezchybny kod... ale neni jenom vlastni kod. V realnem zivote, kdyz mas trebas kolegy. Kapis?

Proč sem pletete kolegy? Téma vlákna je "Jak se neztratit ve vlastním kódu?". Debugger je samozřejmě užitečný i pro vlastní kód.

To je takovy Kituv nevyrceny problem...

Kazdopadne ono i minule a budouci ja je, pokud mne od nej deli dost casu, v mnohem spis kolega.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Kit 23. 11. 2017, 13:45:15
Já jen, že jsem kdysi breakpointy dělával v assembleru, ale tuto metodu jsem v modernějších jazycích opustil jako neefektivní a divím se, že ji ještě někdo provozuje.

Ruzne situace si vyzaduji ruzne nastroje. Samozrejme clovek sam pise bezchybny kod... ale neni jenom vlastni kod. V realnem zivote, kdyz mas trebas kolegy. Kapis?

Nikde jsem se nezmiňoval o bezchybném kódu, ovšem na hledání chyb debugger opravdu nepotřebuji. Připadá mi to poněkud zastaralé a dávno překonané.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: vyvojar 23. 11. 2017, 14:12:31
Chce to psát kód tak, aby v něm bylo co nejméně závislostí :). Viděl jsem přednášku, jmenovalo se to myslím nějak Simplicity made easy, bylo to od autora Closure a říkal tam, že problém není počet řádků kódu, ale právě ty závislosti mezi jednotlivýi částmi. Ono když má člověk metodu, co má 1000 řádků, tak je to sice možná prasárna, ale v ifech a forech se člověk nějak dramaticky neztratí, prostě to čte shora dolů a postupně to pochopí. Jenže když máš metodu a ta volá dalších 10 metod a každá zas dalších 10, to už je trošku problémek. Já se snažím volit nějaký kompromis.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Inkvizitor 23. 11. 2017, 14:47:27
Chce to psát kód tak, aby v něm bylo co nejméně závislostí :). Viděl jsem přednášku, jmenovalo se to myslím nějak Simplicity made easy, bylo to od autora Closure a říkal tam, že problém není počet řádků kódu, ale právě ty závislosti mezi jednotlivýi částmi. Ono když má člověk metodu, co má 1000 řádků, tak je to sice možná prasárna, ale v ifech a forech se člověk nějak dramaticky neztratí, prostě to čte shora dolů a postupně to pochopí. Jenže když máš metodu a ta volá dalších 10 metod a každá zas dalších 10, to už je trošku problémek. Já se snažím volit nějaký kompromis.

Problem snad neni v tom, kolik metod vola ktera metoda, ale jestli nazev, parametry a popis volane metody poskytuji vhled do toho, co ta volana metoda dela. Nevidim zadnou zvlastni vyhodu v "cteni odshora dolu", naopak to s velkou pravdepodobnosti zavani napriklad porusenim DRY a je primarnim zdrojem ruznych chyb, protoze clovek neco zmeni na dvou mistech a treti neporesi. Urcite existuje duvod udelat vyjimku a napsat metodu treba dlouhou 100 radku a vic, ale je to obecne spatny napad.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Kit 23. 11. 2017, 14:52:53
Chce to psát kód tak, aby v něm bylo co nejméně závislostí :). Viděl jsem přednášku, jmenovalo se to myslím nějak Simplicity made easy, bylo to od autora Closure a říkal tam, že problém není počet řádků kódu, ale právě ty závislosti mezi jednotlivýi částmi. Ono když má člověk metodu, co má 1000 řádků, tak je to sice možná prasárna, ale v ifech a forech se člověk nějak dramaticky neztratí, prostě to čte shora dolů a postupně to pochopí. Jenže když máš metodu a ta volá dalších 10 metod a každá zas dalších 10, to už je trošku problémek. Já se snažím volit nějaký kompromis.

V principu souhlasím, ale 1000 řádek špagety je moc. I desetina je už moc. Ovšem pokud ten kus kódu dělá jen jednu věc, tak se to dá obhájit.

Pokud metoda volá dalších 10 metod a každá zas dalších 10 (and deeper and deeper), tak je to také špatně. V takovém případě je ta třída prostě moc velká a zpravidla je vhodné ji nějak rozdělit. Jako optimum vidím 4-6 metod ve třídě.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Karel 23. 11. 2017, 15:27:00
Nikde jsem se nezmiňoval o bezchybném kódu, ovšem na hledání chyb debugger opravdu nepotřebuji. Připadá mi to poněkud zastaralé a dávno překonané.

Ne, není. Stále je to velmi využíváné při běžném aplikačním programování, v databázích, UI apod. Když to umíte používat, tak to šetří hodně času, protože vás to rychle navede k tomu, co je špatně. Tedy ne k samotné chybě v programu, ale k chybnému stavu - například že v proměnné A je něco jiného, než by v té chvíli podle vás být mělo, případně že se IF přeskakuje, když by neměl, atd. Zjistit proč je v A něco jiného je pak už samozřejmě na vás.

Kolegové, co neradi používají debugger, místo toho na vybraná místa píší sérii debug hlášek, kterými si vypíší stav proměnných. Což je obvykle o dost pracnější, protože to jsou často seznamy nebo pole. To vám pak deset minut píší dbms_output.put_line jen aby zjistili, že jim jeden select vrací NULL a to pak blbne IF, protože porovnání s NULL není nikdy TRUE ani FALSE. S debuggerem by to byla práce na minutu, zjistit že v nDefaultContactTypeID mají NULL. Pak už vědí kam jít, že problém není v programu samotném ale v tom, že někdo aktivní odškrtnul v seznamu typů kontaktů "Default". Což byl problém už před patnácti lety, jenže až do letošního listopadu to nikoho nenapadlo udělat.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Kit 23. 11. 2017, 15:41:11
Nikde jsem se nezmiňoval o bezchybném kódu, ovšem na hledání chyb debugger opravdu nepotřebuji. Připadá mi to poněkud zastaralé a dávno překonané.

Ne, není. Stále je to velmi využíváné při běžném aplikačním programování, v databázích, UI apod. Když to umíte používat, tak to šetří hodně času, protože vás to rychle navede k tomu, co je špatně. Tedy ne k samotné chybě v programu, ale k chybnému stavu - například že v proměnné A je něco jiného, než by v té chvíli podle vás být mělo, případně že se IF přeskakuje, když by neměl, atd. Zjistit proč je v A něco jiného je pak už samozřejmě na vás.

Kolegové, co neradi používají debugger, místo toho na vybraná místa píší sérii debug hlášek, kterými si vypíší stav proměnných. Což je obvykle o dost pracnější, protože to jsou často seznamy nebo pole. To vám pak deset minut píší dbms_output.put_line jen aby zjistili, že jim jeden select vrací NULL a to pak blbne IF, protože porovnání s NULL není nikdy TRUE ani FALSE. S debuggerem by to byla práce na minutu, zjistit že v nDefaultContactTypeID mají NULL. Pak už vědí kam jít, že problém není v programu samotném ale v tom, že někdo aktivní odškrtnul v seznamu typů kontaktů "Default". Což byl problém už před patnácti lety, jenže až do letošního listopadu to nikoho nenapadlo udělat.

Místo debugování je mnohem jednodušší napsat si testy. Jejich významnou výhodou je, že se dají spouštět opakovaně a přitom nepřekážejí v kódu.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: DK 23. 11. 2017, 15:58:39
Nikde jsem se nezmiňoval o bezchybném kódu, ovšem na hledání chyb debugger opravdu nepotřebuji. Připadá mi to poněkud zastaralé a dávno překonané.

Ne, není. Stále je to velmi využíváné při běžném aplikačním programování, v databázích, UI apod. Když to umíte používat, tak to šetří hodně času, protože vás to rychle navede k tomu, co je špatně. Tedy ne k samotné chybě v programu, ale k chybnému stavu - například že v proměnné A je něco jiného, než by v té chvíli podle vás být mělo, případně že se IF přeskakuje, když by neměl, atd. Zjistit proč je v A něco jiného je pak už samozřejmě na vás.

Kolegové, co neradi používají debugger, místo toho na vybraná místa píší sérii debug hlášek, kterými si vypíší stav proměnných. Což je obvykle o dost pracnější, protože to jsou často seznamy nebo pole. To vám pak deset minut píší dbms_output.put_line jen aby zjistili, že jim jeden select vrací NULL a to pak blbne IF, protože porovnání s NULL není nikdy TRUE ani FALSE. S debuggerem by to byla práce na minutu, zjistit že v nDefaultContactTypeID mají NULL. Pak už vědí kam jít, že problém není v programu samotném ale v tom, že někdo aktivní odškrtnul v seznamu typů kontaktů "Default". Což byl problém už před patnácti lety, jenže až do letošního listopadu to nikoho nenapadlo udělat.

Místo debugování je mnohem jednodušší napsat si testy. Jejich významnou výhodou je, že se dají spouštět opakovaně a přitom nepřekážejí v kódu.

Testy nenahrazuji debugger
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Kit 23. 11. 2017, 16:10:01
Místo debugování je mnohem jednodušší napsat si testy. Jejich významnou výhodou je, že se dají spouštět opakovaně a přitom nepřekážejí v kódu.

Testy nenahrazuji debugger

Pokud někdo píše špagety, tak samozřejmě debugger potřebuje.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Ondra Satai Nekola 23. 11. 2017, 16:16:40
Místo debugování je mnohem jednodušší napsat si testy. Jejich významnou výhodou je, že se dají spouštět opakovaně a přitom nepřekážejí v kódu.

Testy nenahrazuji debugger


Pokud někdo píše špagety, tak samozřejmě debugger potřebuje.

Obracena implikace vsak neplati.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: to_je_jedno 24. 11. 2017, 00:43:27
Místo debugování je mnohem jednodušší napsat si testy.
Kite ty ses vazne hlupak s nulovyma znalostma a jeste mensima zkusenostma. Debugovani a testy jsou dve dost zasadne jine veci.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Phi 24. 11. 2017, 09:47:48
Jenže když máš metodu a ta volá dalších 10 metod a každá zas dalších 10, to už je trošku problémek. Já se snažím volit nějaký kompromis.
To je jako trolling? Snad si ty metody pojmenuju tak, abych nemusel bádat co dělá, ne?
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Phi 24. 11. 2017, 09:52:39
Ahoj, když děláte fakt velký projekt, jak si zapamatovat celou strukturu kódu? Neexistuje nějaká grafická aplikace, ve které by se daly vytvořit třeba názvy souborů s propojením? Děkuji za tip. O.
Nepamatuji si celou strukturu kódu, protože mne nemusí zajímat, co je pod jednotlivými API.
Pamatuji si co je v jakém namespace, jaký jsou tam vystavené interfejsy a že když jsem ten kód psal, komentoval jsem to jako by to měl číst někdo jiný (protože já po třech měsících je někdo jiný).
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Kit 24. 11. 2017, 09:54:29
Jenže když máš metodu a ta volá dalších 10 metod a každá zas dalších 10, to už je trošku problémek. Já se snažím volit nějaký kompromis.
To je jako trolling? Snad si ty metody pojmenuju tak, abych nemusel bádat co dělá, ne?

Pojmenování věcí je v programování nejtěžším úkolem a mnozí ho prostě nezvládají...
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Phi 24. 11. 2017, 10:04:23
Místo debugování je mnohem jednodušší napsat si testy. Jejich významnou výhodou je, že se dají spouštět opakovaně a přitom nepřekážejí v kódu.

Testy nenahrazuji debugger

Pokud někdo píše špagety, tak samozřejmě debugger potřebuje.
Nesmysl. Testy jedou proti api, upozorní na neočekávaný výsledek, ale neřeknou proč se kód chová tak jak se chová.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Kit 24. 11. 2017, 10:37:55
Místo debugování je mnohem jednodušší napsat si testy. Jejich významnou výhodou je, že se dají spouštět opakovaně a přitom nepřekážejí v kódu.

Testy nenahrazuji debugger

Pokud někdo píše špagety, tak samozřejmě debugger potřebuje.
Nesmysl. Testy jedou proti api, upozorní na neočekávaný výsledek, ale neřeknou proč se kód chová tak jak se chová.

Konečně rozumný argument.

Pokud je však třída napsána s ohledem na SRP a maximum závislostí je injektováno, vystačím si i s testy. Hodně pomáhá používání immutable proměnných a redukce vnoření struktur na minimum.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: BoneFlute 27. 11. 2017, 13:17:58
a spis se to resi pres. tzv "event middlewary"
Můžeš to prosím trochu rozvést?

Teď právě jsem zakopl o jeden legacy kód, kde se Eventy hodně používají. Bohužel velice špatným způsobem takže při refactorování jsem to prostě vzdal a budu doufat, že jsem to nerozbil. Díky tomu na mě sousloví "event middlewary" působý velice tísnivým dojmem.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: standa12345 28. 11. 2017, 01:03:04
...Ono když má člověk metodu, co má 1000 řádků, tak je to sice možná prasárna, ale v ifech a forech se člověk nějak dramaticky neztratí, prostě to čte shora dolů a postupně to pochopí....

Baví se 2 programátoři: Franto, ty používáš na kodění netbook? A nemá to nějak příliš malý display?
Franta: Ani né, Pepo. Když se mi totiž metoda nevleze na obrazovku, tak dělám něco špatně.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Petr 05. 12. 2017, 10:15:24
Každému vyhovuje něco jiného. Také záleží od jazyka a úlohy.

Takže já třeba preferuji Vim a na Python nebo PHP debugger nepoužívám, na javascript občas ano. Ale obecně dávám přednost logu. V realtime aplikacích imho ani debugger používat nejde, protože chod aplikace nelze pozastavit a krokovat. Ale průběh lze zalogovat a log analyzovat. Stejně tak nelze debugger použít u občasných náhodných chyb. Takže loguji do paměti a když dojde k jednou začas k chybě, log uložím do souboru. Jako všechno, musí se to umět, správné logování. U mě je přirozenou součástí programování, dělám ho automaticky, preventivně, ne až když je nějaký problém. Debugger je pro mě spíše obezlička pro jednoduché případy.

Co se týče otázky, jak se neztratit ve vlestním kódu, tak rada je jednoduchá. Psát kód přehledně. To znamená v první řadě kód dobře rozdělit na části (moduly, třídy, metody, funkce, ...) a tyto dobře pojmenovat. Naplnit tuto radu není jednoduché, chce to praxi a zkušenosti. Pak už mi stačí propracovaná práce s foldingy ve vimu, používám výhradně ruční metodu marker. A nejsem vyznavač krátkých metod/fýnkcí za každou cenu. Zvláště větvící metody je zbytečné rozdělovat, takže ty mohou být dlouhé stovky řádků, pokud větvících eventů je hodně. A obecně se neřídím délkou, ale funkčností. Základ je, že část kódu by měla dělat jednu věc, aby šla dobře poumenovat a že by se kód neměl opakovat. takže mohou vzniknout i jednořádkové metody. Prostě jak je potřeba.

Druhá rada je tvorba kvalitní dokumentace. Nebo aspoň komentářů. V tomto jsou dobrá pomůcka samodokumentující docstringy pythonu.

Ale to všechno je individuální, každému vyhovuje něco jiného. Takže se tím můžeš nechat inspirovat, ale stejně si nakonec musíš najít svou vlastní cestu. Pokud nejdeš do korporátu nebo nepracuješ na velkém formalizovaném projektu, kde ti cestu určí někdo jiný.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: andy 05. 12. 2017, 15:16:34
Ty jo, debugger... tak nějak vzhledem k tomu, že větší část mých projektů je taková, že to pořádně nejde, tak jsem si nějak odvykl. A vůbec mi to nechybí. Při pár příkladech jsem to teda skousnul a to gdb spustil, ale to byla fakt výjimka. Ale vzpomínám na začátky programování, kdy bych se bez debuggeru nepohnul....

Pamatuju, jak hardwarové watchpointy na přepsání paměti byly fakt vychytávka. Za posledních 10 let jsem něco takového nepotřeboval ani jednou. A říkám si, že to možná bude tím, že používám jiné jazyky, používám je jinak a ve výsledku dělám "jiné chyby", resp. ty "staré" chyby jsem schopen diagnostikovat poměrně slušně i bez debuggeru.

Navíc dneska když dojde k nějaké chybě, tak už u toho typicky má člověk třeba traceback, takže se ex-post dozví spoustu věcí a velmi často je schopen problém diagnostikovat aniž by potřeboval přímo něco testovat. Tím neříkám, že debugger je na nic, ale případů, kdy jsem ho opravdu potřeboval, bylo docela málo.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: ghost 06. 12. 2017, 01:20:53
debuger vam userri spoustu casu vy bejci, jak pri vyvoji tak pri hledani chyb
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: Kit 06. 12. 2017, 02:03:26
debuger vam userri spoustu casu vy bejci, jak pri vyvoji tak pri hledani chyb

V Assembleru už dávno nedělám.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: dcfcxx 06. 12. 2017, 03:36:01
debuger vam userri spoustu casu vy bejci, jak pri vyvoji tak pri hledani chyb

Debugovani je jako detektivka, kde vysetrujete zlocin.
A sam jste zaroven i vrahem.
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: jablon 06. 12. 2017, 09:12:47
Je to poměrně jednoduché. Musíte psát podle standartu, dodržovat code style. Pokud vás dělá více, pak by nemělo jít poznat, kdo jakou část psal (krom anotace @author).
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: gll 06. 12. 2017, 09:25:20
Je to poměrně jednoduché. Musíte psát podle standartu, dodržovat code style. Pokud vás dělá více, pak by nemělo jít poznat, kdo jakou část psal (krom anotace @author).

jaký smysl má používáni @author, když tu stejnou informaci máte ve verzovacím systému?
Název: Re:Jak se neztratit ve vlastním kódu?
Přispěvatel: JmJ 06. 12. 2017, 11:05:21
Je krasne, jak se vetsin z vas tvari hrozne profesionalne a pritom tvrdi takove veci jako ze debuger je na nic, ze ho nahradi logovani a ze tamhleto je blbost a dokonale a spravne je neco uplne jineho atd.

Ze trida ma mit 6 metod, nebo zase ze metoda muze mit i 1000 radku se zanorovanim a je to ok atd. Kazdy si halt obhajuje tu svoji prasecinu a nejhorsi jeste je, kdyz se na netu od nejakeho jinehou joudy docte to, co se mu hodi do kramu, to pak zacne tuto myslenku vydavat za svetonazor a nuti do toho i ostatni.

Neni nad to, kdyz nejaky blbec zacne programovat podle tehle doporuceni. Pak se program nepis pro to, aby fungoval, ale proto, aby splnil nejaka nesmyslna kriteria na podobu kodu.


Kod ma mit svou fazonu, v ramci projektu idealne jednotnou. Nazvy metod a parametru by mely fungovat ve velke vetsine pripadu jako napoveda a metody by se mely chovat rozumne podle toho, jak se jmenuji a jake parametry zerou.  Kod je vhodne (nikoliv nezbytne nutne) psat tak, aby byl citelny a pochopitelny. Mista, ktera tak napsat nejdou napr. z duvodu optimalizace by mela byt rozumne okomentovana. Naopak psat komentar ke konstruktoru bez parametru, ze je to konstruktor, je nemysl. Ale jsou taci, co to vyzaduji.  Kod by se nemel zbytecne opakovat a to jak z duvodu prehlednosti, tak udrzovatelnosti. Vyjimkou jsou opet napr. optimalizace.

Cele "reseni" ma byt rozdeleno na mensi celky, ktere maji byt si s sebou maji tahat co nejmene zavislosti a maji byt co nejvice znovupouzitelne. Pri tvorbe trid, sluzeb, komponent atd. vzdy hledime na to, jak by danou vec asi chtel znovupouzit uplne cizi programator, resp. si vzpomeneme, co nas stve na cizich komponentach a sami to udelame pokud mozno lepe.

Ve celem "reseni" dodrzujeme jednotny styl nazvu pro ruzne casti, od namespacu po promenne. Dorzet jednotnost u namespacu je rozhodne dulezitejsi, nez ji dodrzet u lokalni promenne v privatni metode tridy pro praci se stringy.

Vcas reseni refaktorizujeme, pokud je to nutne, nikdy (az na uplne krize) nelepime kod jako prasata. Nekdy muze refaktorizace zabrat hodne casu. Je lepsi ji delat vcas, treba po te, co se zhotovi nejake reseni, udela se zakladni test, ze to jede. Nechvastame se, jak sme dobri, ale venujeme cas tomu, abychom tohle reseni ucesali, uklidili kod po prekotnem vyvoji atd.

Za chyby v textu se omlouvam, nechce se mi to po sobe cist ;-)