Programování

O nás, o lidech, o okolním světě. Všechna témata, která se netýkají her, patří do této sekce. Zapomeňme chvíli na RPG a pojďme předstírat, že jsme normální lidé.

Moderátor: Faskal

Sosacek
Příspěvky: 21577
Registrován: 14. 7. 2004, 18:30

Re: Programování

Příspěvek od Sosacek » 2. 12. 2017, 00:15

Psycho je ten kod, co dela vypocet stage + stara data -> nova data. Nebo, ne v pricnipu, ale je to dobry protipriklad na "sql neni programovani" (coz clovek slycha od typku, co videli akorat mysql, pac wordpress vic nepotrebuje).

Ale fakt je, ze me tu kluci z Petrohradu vyrobili divny hybrid kobinujici
- scd1
- snapshoty ulozene v partisnach
- to, ze hard deleted data zustavaji
coz me nebavi, pac to ted musim refaktorovat.

EDIT: ta cast kdy si na konci loadu vyrabi viewcko, kde si zapamtuji posledni partition, protoze ji neumi najit (tj. select * from bla b where b.execution_date = (select max(execution_date) from bla b1) takze pokud nekdo spusti loady ve spatnem poradi, coz se testerum deje asi tak jednou tydne, tak nam data cestuji pozpatku v case ... eh.

EDIT: diskusi o jazycich bych mozna posunul do it pro otrle.

Sosacek
Příspěvky: 21577
Registrován: 14. 7. 2004, 18:30

Re: Programování

Příspěvek od Sosacek » 2. 12. 2017, 11:05

Eleshare, tohle by mohlo byt pro tebe https://automatetheboringstuff.com/

Uživatelský avatar
Pieta
sofistikovaný troll
Příspěvky: 13335
Registrován: 6. 9. 2006, 18:08
Bydliště: Praha, ale původem jsem z Hostivaře
Kontaktovat uživatele:

Re: Programování

Příspěvek od Pieta » 2. 12. 2017, 14:09

K Yorkovu refaktoringu: U nás v práci se kolem toho spíš z praxe vyvinul takový přístup, že čím automatizovanější a "samozřejmější" nějaký kód je, tím spíš bude striktně rozsekaný na metody. Čili různá loadData a beforeUpdate a afterUpdate a poZkopirovaniObjektuAaaPoresJehoPotomkyTypuBbb mají standardní jména a obsah a při čtení kódu jsou víceméně přeskočitelné; individuální logika je často proud kódu jen zhruba rozdělený do oblastí. Není mi to proti srsti - když se na kód musím víc soustředit, abych ho chápal, tak to, že nemusím přeskakovat od metody k metodě, mi docela pomáhá tu pozornost udržet. Chápu, že ideál je, že kód bude rozdělený do metod tak, že už z jejich jmen budu mít dobrou představu o tom, co kód dělá; v praxi mám dojem, že dobře pojmenovat metody a přitom mít jejich jména použitelně krátká je zhusta těžko splnitelné.
Cicho żono, deszczyk padał, ja nie słyszał kto to gadał.
Cicho żono, deszczyk rosił, ja nie słyszał kto to prosił.

Uživatelský avatar
York
Příspěvky: 11950
Registrován: 24. 2. 2012, 17:31

Re: Programování

Příspěvek od York » 6. 12. 2017, 16:43

Ta stránka o refactoringu, kterou jsem linknul v prvním příspěvku, je fakt dobrá. Je tam toho ale hodně a většinou to asi nebude moc dávat smysl bez praktických zkušeností. Zkusím z toho vytáhnou to nejdůležitější do začátku.

Replace Nested Conditional with Guard Clauses

Jde o trik, jak výrazně zjednodušit mnohanásobně zanořené podmínky a cykly. Tohle:

Kód: Vybrat vše

public double getPayAmount()
{
  double result;

  if (isDead)
  {
    result = deadAmount();
  }
  else
  {
    if (isSeparated)
    {
      result = separatedAmount();
    }
    else
    {
      if (isRetired)
      {
        result = retiredAmount();
      }
      else
      {
         result = normalPayAmount();
      }
    }
  }

  return result;
}
se například dá napsat takhle:

Kód: Vybrat vše

public double getPayAmount()
{
  if (isDead)
    return deadAmount();

  if (isSeparated)
    return separatedAmount();

  if (isRetired)
    return retiredAmount();

  return normalPayAmount();
}
Trik spočívá v použití klíčového slova "return". Kromě toho, že je výsledný kód kratší a méně zanořený, je taky typicky mnohem jednodušší na pochopení, zvlášť pokud ty podmíky testují něco rozumně pojmenovaného, jako v tom příkladu. Bývá taky zvykem "očekávanou" nebo defaultní variantu dát jako poslední - proto se to v tom příkladu jmenuje normalPayAmmount().

Podobně jde zjednodušovat cykly - kromě "return" se na to dají použít klíčová slova "break" a "continue". Vnořené cykly je taky dobré nahradit voláním funkce.

Uživatelský avatar
Resurrection
Příspěvky: 4722
Registrován: 26. 9. 2006, 10:34

Re: Programování

Příspěvek od Resurrection » 6. 12. 2017, 17:15

2York: RIP cache...

Jinak spravne reseni toho vyse jsou metody na ty logicke bloky, nejen na podminky.
Secrets are power.

Uživatelský avatar
York
Příspěvky: 11950
Registrován: 24. 2. 2012, 17:31

Re: Programování

Příspěvek od York » 6. 12. 2017, 17:53

Resurrection píše:
6. 12. 2017, 17:15
RIP cache...
?

Resurrection píše:
6. 12. 2017, 17:15
Jinak spravne reseni toho vyse jsou metody na ty logicke bloky, nejen na podminky.
"Správné řešení" obvykle záleží na kontextu a kromě toho se typicky mění v čase. To by měl bejt hlavní smysl mého sdělení - kód v drivé většině není něco, co se jednou napíše a zůstane to tak na věky, obvykle se rozšiřuje a updatuje. Stejně tak refactoring není věc, kterou bys jednou udělal a bylo to "správné řešení", ale krok, který v určité míře dělat musíš pokaždé, když na kódu něco měníš a není od věci si čas od času udělat revizi, kdy nic nového nepřidáváš.

Kromě toho to není jen nástroj k údržbě kódu, ale taky způsob myšlení a velmi užitečná pomůcka při psaní kódu, když se to naučíš používat. Když dokážeš stejnou funkčnost napsat bez vnořených podmínek, tak se nad tím už od začátku mnohem snáz přemýšlí.

Uživatelský avatar
Resurrection
Příspěvky: 4722
Registrován: 26. 9. 2006, 10:34

Re: Programování

Příspěvek od Resurrection » 6. 12. 2017, 20:30

Predstav si, ze si procesor. Mas cache, do ktere si davas veci k okamzite potrebe (jako instrukce co mas vykonat). V prvni verzi te funkce by sis pripravil instrukce pro getPayAmount() a s pomoci nejakeho toho branch predictingu by sis tam nejspis dal i isntrukce pro ty vnitrni veci. Mel bys jistotu, ze at uz se bude volat cokoliv v tomto uzavrenem okruhu, vzdycky projedes celou sadu getPayAmount(). Ve druhe verzi to udelas stejne, jenomze taky z toho muzes vyletet na 4 ruznych mistech. Takze s vysokou pravdepodobnosti nedojedes cely instrukcni set, ale budes nucen se nekde v jeho prostredku presunout jinam. To ale nevis. A kdyz to nastanes, nahle jsi vystrelen kamsi a tahas si novy instrukcni set pro to, kam ses dostal. Pokud toho mas takhle napsaneho vic, tak tam budes mit cache misses fakt hodne. A jak na letosnim cppconu ukazoval Chandler Garruth, tak 0,001 % L2 cache missess = 20 % performance cost. To pokud by sis myslel, ze na tom nezalezi. :-) Nastesti te kompilator umi vetsinou ochranit pred takovymi vecmi. Ale i tak je lepsi delat to jako single point of exit.

Krome single-point-of-exit by tomu taky jeste napomohlo pouzit if-else, nicmene to je ta vec, co za tebe udela kompilator (pokud nevypnes optimalizaci).
Secrets are power.

Uživatelský avatar
York
Příspěvky: 11950
Registrován: 24. 2. 2012, 17:31

Re: Programování

Příspěvek od York » 6. 12. 2017, 20:51

Resurrection píše:
6. 12. 2017, 20:30
Predstav si, ze si procesor.
Krásně mi nahráváš na další kapitolu ;-)


Optimalizace

:arrow? V drtivé většině praktických aplikací není limitní výkon procesoru, ale čas strávený vývojem.

:arrow? Pokud přece jen výkon hraje roli, tak v drtivé většině případů jde o omezení bandwithem, tzn. nejde o to, jak rychle procesor chroustá instrukce, ale kolik se toho posílá po netu - nejčastěji kolik se toho musí poslat před tím, než se poprvé zobrazí další stránka. Dneska se hodně mluví o optimalizacích (reactive design), ale týká se to načítání webových stránek.

:arrow? Další velkou oblastí, kde stojí za to optimalizovat, jsou chyby ve stylu, že dáte nejdřív stahovat data a až pak se udělá render - takže uživatel má pocit, že se mu stránka zasekla. To opět nemá nic společného s procesorem.

:arrow? Další v pořadí jsou chybně zvolené algoritmy (typicky exponenciální složitost, když by mohla být lineární nebo třeba n*log(n)) nebo datové struktury. Rozdíl mezi exponenciální a lineární složitostí fakt nezachráníš pár procentama ušetřenejma na L2 cache misses.

:arrow? Když už fakt potřebuješ optimalizovat na výpočetní výkon, tak typicky drtivou většinu výkonu žere mizivé procento tvých funkcí. To znamená, že optimalizací většiny svého kódu získáš absolutně minimální zvýšení výkonu. Z toho plyne, že když už musíš optimalizovat, tak si nejdřív pusť profiler, abys věděl, co je vlastně optimalizovat potřeba.

A v neposlední řadě - týmy, které pracují na překladačích (např. gcc) nebo enginech (např. v8 javascriptový engine) jsou v tom o dost lepší než ty, takže s největší pravděpoboností to, co ti přijde neoptimalizované, v browseru běží úplně stejně jako ta druhá varianta (a někdy i rychleji, protože tyhle týmy se celkem logicky zaměřují hlavně na kód, který skutečně reálně někdo napsal).
Naposledy upravil(a) York dne 6. 12. 2017, 21:06, celkem upraveno 1 x.

Sosacek
Příspěvky: 21577
Registrován: 14. 7. 2004, 18:30

Re: Programování

Příspěvek od Sosacek » 6. 12. 2017, 21:02

Jak rikal Knuth, predcasna optimalizace je korenem vseho zla.

Nevim, jestli jsem to uz nerikal, ale dulezity je, ze kod clovek nepise pro pocitac, ale pro cloveka, ktery ho bude cist a upravovat v budoucnu. Pocitac ten kod nemusi pochopit, jmena a struktura ho nezajima, a tak. Pocitac kod jenom vykonava.

Uživatelský avatar
York
Příspěvky: 11950
Registrován: 24. 2. 2012, 17:31

Re: Programování

Příspěvek od York » 6. 12. 2017, 21:05

Sosacek píše:
6. 12. 2017, 21:02
kod clovek nepise pro pocitac, ale pro cloveka, ktery ho bude cist a upravovat v budoucnu.
Přesně tak.

(Dost často tím člověkem bývá autor sám, takže i když nemáte rádi své kolegy, dělejte to aspoň pro sebe ;-)).

Uživatelský avatar
Pieta
sofistikovaný troll
Příspěvky: 13335
Registrován: 6. 9. 2006, 18:08
Bydliště: Praha, ale původem jsem z Hostivaře
Kontaktovat uživatele:

Re: Programování

Příspěvek od Pieta » 6. 12. 2017, 21:53

Za mých studií nám jeden z vyučujících říkal, že komentovat kód to chce ani málo, ani moc, a jako odstrašující protipříklad uváděl

Kód: Vybrat vše

i++;  // raise i by one
Dneska, s velkým odstupem, jsem dospěl k tomu, že tohle není příklad toho, jak někdo komentoval moc, ale jak někdo stejně komentoval málo. S jakou radostí dneska v kódu potkám něco jako

Kód: Vybrat vše

totalPrimeTimeTrans ++;  // we have to check the total against licence limits
protože pokud nevím, co ta proměnná dělá, tak mi to ušetří 1) dát si do kódu záložku 2) hledat kolem dokola, kde se tahle proměnná používá 3) přijít na to, jaký má vlastně smysl, a 4) vybavit si znovu, co jsem vlastně řešil za problém, než jsem musel vyrazit na celou tuhle odbočku.
Cicho żono, deszczyk padał, ja nie słyszał kto to gadał.
Cicho żono, deszczyk rosił, ja nie słyszał kto to prosił.

Uživatelský avatar
Resurrection
Příspěvky: 4722
Registrován: 26. 9. 2006, 10:34

Re: Programování

Příspěvek od Resurrection » 6. 12. 2017, 22:00

Pokud vam 20 % pri naprosto zanedbatelnem mnozstvi cache missu pripada jako nesmyslne se tim zabyvat... On to clovek malokdy doceni na malem mnozstvi dat nebo v aplikaci co bezi jednou za cas a chvili. Pro veci co bezi 24/7 nebo pres ne tece hodne dat (nebo oboji) je to dulezite dost. Kdyz si Facebook udelal small string optimalizaci, zvysil performance svych sluzeb o 4 %. Nebo o nejakych 20 milionu dolaru.

Ale dobre, z hlediska cteni kodu. Pokud mate vice points of exit, tak mate:
- code smell, protoze vase funkce dela vic jak jednu vec
- hur se to debuguje (mate v tu chvili stejny problem jako kompilator, kdykoliv muze prijit intergalakticke goto kamsi)
- hur se to cte, protoze trackujete ty ruzne podminky, ruzne konce, kdy se neprovede to za tim a taky ruzne navratove hodnoty a zpusob jejich vzniku

Nemluve o tom, ze plno lidi to klidne napise takto:

Kód: Vybrat vše

  if (isDead)
    return deadAmount();
  if (isSeparated)
    return separatedAmount();
  if (isRetired)
    return retiredAmount();
A ani jim to neprijde divny. To se pak cte uplne perfektne, kdyz si na treti cteni uvedomite, ze v te 6radkove funkci nejsou if else, ale jen zbudnlovane ify.
Secrets are power.

Sosacek
Příspěvky: 21577
Registrován: 14. 7. 2004, 18:30

Re: Programování

Příspěvek od Sosacek » 6. 12. 2017, 22:25

Jsi na uplne jiny urovni abstrakce, nez York. Ten jeho kod je business logika, ne vnitrek databaze nebo 3d enginu. Ty funkce, mezi kterymi rozhoduje ifem, muzou klidne spoustet sql dotazy, nebo volat nejake api nebo service bus

Uživatelský avatar
Pieta
sofistikovaný troll
Příspěvky: 13335
Registrován: 6. 9. 2006, 18:08
Bydliště: Praha, ale původem jsem z Hostivaře
Kontaktovat uživatele:

Re: Programování

Příspěvek od Pieta » 6. 12. 2017, 22:58

Sosacek píše:
6. 12. 2017, 22:25
Jsi na uplne jiny urovni abstrakce, nez York. Ten jeho kod je business logika, ne vnitrek databaze nebo 3d enginu. Ty funkce, mezi kterymi rozhoduje ifem, muzou klidne spoustet sql dotazy, nebo volat nejake api nebo service bus
Souhlas - co je a není důležitý optimalizovat se sakra liší podle toho, co přesně člověk vyrábí. Moje oblíbené databáze jsou úplně extrémní případ - když se podaří chytře postavit tabulky a rychle z nich vytáhnout data, která právě potřebuju, tak nad každým získaným řádkem tabulky můžu v paměti pustit sto tisíc řádků zbytečného kódu a jsem pořád, co se rychlosti týče, za vodou, natož abych se řádek po řádku trápil tím, jak přesně se můj kód realizuje v procesoru.
Resurrection píše:
6. 12. 2017, 22:00
Nemluve o tom, ze plno lidi to klidne napise takto:

Kód: Vybrat vše

  if (isDead)
    return deadAmount();
  if (isSeparated)
    return separatedAmount();
  if (isRetired)
    return retiredAmount();
A ani jim to neprijde divny. To se pak cte uplne perfektne, kdyz si na treti cteni uvedomite, ze v te 6radkove funkci nejsou if else, ale jen zbudnlovane ify.
Tohle nechápu. Pokud je tenhle kód to jediné, co v metodě máš, tak přece funguje stejně, jako by tam elsify byly, ne?
Cicho żono, deszczyk padał, ja nie słyszał kto to gadał.
Cicho żono, deszczyk rosił, ja nie słyszał kto to prosił.

Uživatelský avatar
York
Příspěvky: 11950
Registrován: 24. 2. 2012, 17:31

Re: Programování

Příspěvek od York » 7. 12. 2017, 13:59

Pieta píše:
6. 12. 2017, 21:53
Za mých studií nám jeden z vyučujících říkal, že komentovat kód to chce ani málo, ani moc, a jako odstrašující protipříklad uváděl

Kód: Vybrat vše

i++;  // raise i by one
Dneska, s velkým odstupem, jsem dospěl k tomu, že tohle není příklad toho, jak někdo komentoval moc, ale jak někdo stejně komentoval málo. S jakou radostí dneska v kódu potkám něco jako

Kód: Vybrat vše

totalPrimeTimeTrans ++;  // we have to check the total against licence limits
protože pokud nevím, co ta proměnná dělá, tak mi to ušetří 1) dát si do kódu záložku 2) hledat kolem dokola, kde se tahle proměnná používá 3) přijít na to, jaký má vlastně smysl, a 4) vybavit si znovu, co jsem vlastně řešil za problém, než jsem musel vyrazit na celou tuhle odbočku.
Já jsem poměrně dlouho komentoval fakt hodně důkladně, poslední dobou se to ale snažím hodně omezit. Jedním z důvodů jsou nástroje na refactoring - přejmenovat něco hromadně ve všech souborech strašně šetří čas, ale rozbíjí to komentáře. Obdobně mám problém s tím, že teď vymýšlím základní architekturu aplikace a dost často z gruntu měním to, jak věci fungují - tím jdou zas do háje vysvětlující komentáře. Další žhavý kandidát na desync jsou chybová hlášení - a když mám v kódu error message a k němu ještě komentář, tak je slušná šance, že po čase říkají každý něco jiného a ani jedno z toho nesedí k aktuálnímu kódu.

Poslední dobou to dělám tak, že při prvním psaní komentuju hodně (často píšu nejdřív komentáře a pak až vlastní kód) a v rámci čistění kódu a refactoringu pak komentáře reviduju: Když kódu s delším časovým odstupem rozumím i bez nich, nebo ho dokážu refactorovat tak, aby nebyly potřeba, tak je nemilosrdně mažu.

Odpovědět

Zpět na „Rozličný pokec“

Kdo je online

Uživatelé prohlížející si toto fórum: Žádní registrovaní uživatelé a 1 host