Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: 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.
-
Doporucuji opustit Vim a pouzivat poradne IDE 8)
-
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.
-
Doporucuji opustit Vim a pouzivat poradne IDE 8)
Naprasit a ať se s tím popere IDE za mě. Chce se mi plakat.
-
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.
-
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..
-
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.
-
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í.
-
man cscope
-
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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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...
-
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!
-
no jo... to sa vo vim programuje ked mate jednoclenny team... ze kite
-
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.
-
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.
-
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
-
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.
-
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
-
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.
-
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
-
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?
-
Kit asi pouziva toto :D:
__asm int 3
-
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.
-
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.
-
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é.
-
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.
-
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.
-
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ě.
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
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?
-
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ý).
-
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í...
-
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á.
-
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.
-
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.
-
...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ě.
-
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ý.
-
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.
-
debuger vam userri spoustu casu vy bejci, jak pri vyvoji tak pri hledani chyb
-
debuger vam userri spoustu casu vy bejci, jak pri vyvoji tak pri hledani chyb
V Assembleru už dávno nedělám.
-
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.
-
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).
-
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?
-
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 ;-)