Jak se neztratit ve vlastním kódu?

[vyvojar]

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.

[Reklama]

[Inkvizitor]

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.

[Kit]

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ě.

[Karel]

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.

[Kit]

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.

[Reklama]

[DK]

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

[Kit]

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.

[Ondra Satai Nekola]

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.

[to_je_jedno]

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.

[Phi]

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?

[Phi]

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ý).

[Kit]

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

[Phi]

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á.

[Kit]

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.

[BoneFlute]

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.