751
/dev/null / Re:Odpovědnost za škodu? Problémový junior a zklamání z práce
« kdy: 27. 09. 2021, 15:43:35 »On teda byl rockstar, zvladal i deleni nulouNebyl to Chuck N.?
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
On teda byl rockstar, zvladal i deleni nulouNebyl to Chuck N.?
Není. Boilerplate z gRPC nebo ORM s generickými typy vůbec nesouvisí.No.. neni trochu problem, ze Go tak neprimo vybizi k psani boilerplatu, kdyz nepodporuje generika a stylem errorhandlingu? Popravde Go moc neznam.. pricichl sem k tomu davno a fakt se mi nelibil, takze jsem ho nechal...Testy jsou naprd, o tom žádná. [...] Samozřejmě typy jsou všespásnéTo právě naplatí. Jenže testy jsou o sémantice, kdežto typy kontrolují spíš syntax (je tam průnik, ale malý). Můj aktuální problém jsou tupé chyby (copy/paste překlepy) v boilerplate kódu, to je obzvlášť hnusná a v ideálním světě zbytečná kategorie. Maníci píšou v Go, ale v Rustu nebo Javě by byl stejný problém. Pro tu dnešní módu mikroslužeb asi neexistuje vhodný jazyk, boilerplate se píše všude. Přitom přesně v tomto bodě jsme už jednou byli.
Gratuluju. Sejdeme se v Bohnicíchmísto poměrně jednoduchého kola vymýšlí robotickou stonožkutak to je krásný popis toho, co teď právě dělám
Viz výše, jen doplním, že před bratru třiceti lety už tato technologie existovala (akorát se jí neříkalo mikroslužby) a technické řešení bylo mnohem příčetnější, než dnešní splácanec RPC, ORMu a RESTu. Koukám, že většina dnešních vývojářů tuhle část SW historie vůbec nezná a místo poměrně jednoduchého kola vymýšlí robotickou stonožku.Můj aktuální problém jsou tupé chyby (copy/paste překlepy) v boilerplate kódu, to je obzvlášť hnusná a v ideálním světě zbytečná kategorie. ... boilerplateMůžeš to rozvést?
Detaily nejsou moc zajímavé, problém je celková koncepce — každá entita (třeba User nebo Invoice) má jednu reprezentaci (třídu) pro komunikaci s API (veřejné endpointy), jednu pro ukládání do databáze (ORM) a další pro gRPC (zprávy pro protokol). Většina kódu dělá jen to, že převádí instance těchto nádher z jedné na druhou podle toho, co se právě volá nebo ukládá. A nejde to jednoduše sjednotit, protože velká část kódu se generuje různými nástroji.Pro tu dnešní módu mikroslužeb asi neexistuje vhodný jazykMikroslužby jsou tak trochu problém sám o sobě. Protože tím jak je to rozcapené, tak se to blbě hlídá (zda jsou dodržené kontrakty, zda je problém v dostupnosti, nebo v kódu, ...) Možná by to nemusel být technický problém, ale jsme ve fázi, kdy se snad všechny služby píšou ad-hoc, takže je snadné se na to či ono vybodnout.
Pochlub se detaily.
Více než jednouTesty verzus Typy jsme už jednou probírali. Asi netřeba to otevírat znova.Testy jsou naprd, o tom žádná. [...] Samozřejmě typy jsou všespásnéTo právě naplatí. Jenže testy jsou o sémantice, kdežto typy kontrolují spíš syntax (je tam průnik, ale malý).
Jo, netřeba. Navíc teď mě trápí něco jiného, co nevyřeší ani testy, ani typy (aspoň ne typy v běžných jazycích, že to řeší kategorie monomorfických endofunktorů osmého řádu mi asi s gRPC nepomůže).
Osobne mam pocit, ze custom bastl prosazuje "stara skola", tj ti co si umi predstavit data a pametovy/souborovy format a vi jak efektivne napsat praci s daty.Tak žádný učený z nebe nespadl...
Pak je zde tapajici "stredni" trida, kdo se to snazi lepit skrze knihovny nebo jazykove konstrukty, ale netusi uz jak to je ve skutecnosti narocne (casove/pametove).
A pak tady dobehnou decka jako vy, ktery vytasi zazracny frikulinsky jazyk/framework, ktery by to mel udelat, ale o pocitaci vedi snad jenom tolik, ze to bez internetu neudela ani tuk :-)
Testy jsou naprd, o tom žádná. [...] Samozřejmě typy jsou všespásnéTo právě naplatí. Jenže testy jsou o sémantice, kdežto typy kontrolují spíš syntax (je tam průnik, ale malý). Můj aktuální problém jsou tupé chyby (copy/paste překlepy) v boilerplate kódu, to je obzvlášť hnusná a v ideálním světě zbytečná kategorie. Maníci píšou v Go, ale v Rustu nebo Javě by byl stejný problém. Pro tu dnešní módu mikroslužeb asi neexistuje vhodný jazyk, boilerplate se píše všude. Přitom přesně v tomto bodě jsme už jednou byli.
Které třeba? Neříkám, že ne, jen by mě zajímaly podrobnosti nebo příklad.Jak kde. Nektere backend services by bez testu nebyly provozovatelne a vyvinutelne.Dříve jsem byl fanatik a dnes tak nějak zjišťuji, že testy nejsou zase tak důležité, jak se říká. Nehledě na to, že stejně nikdy nepokryjete 100% variant.Důležité je odhalovat chyby. Testy mají tu nevýhodu, že je člověk musí napsat navíc (je to mrtvý kód) a že stejně pokryjí jen poměrně malou část minového pole. Zrovna na jednom projektu vidím, jak maníci použili gRPC, ORM a JSON REST a nejvíc chyb nasekali v kódu převádějícím objekty mezi frameworky. Testy napsali tak nešikovně, že mnoho chyb neodhalily. Nejsmutnější je, že v podstatě píší jen boilerplate kód. Eliminací boilerplatu by se zbavili i těch bugů.
Po mé poslední zkušenosti s testy (v seniorním týmu) se usilovně snažím vymyslet nějaký spolehlivější způsob odhalování tupých chyb.U knihovny testy píšu (už) asi samozřejmě. U webové aplikace to je na zvážení, zda mají ekonomický smysl. Business logika určitě ano (i když taky to flákám). View výjimečně. To už musí být nějaká fakt vytížená aplikace.Mě by zajímalo, kteří "zkušení" programátoři jsou ochotni tvořit kód bez testů.myslím, že docela dost. Prošel jsem hodně firem a dost jsem testy v projektu buď vůbec neviděl, nebo byly zakomentované či tam byl assert(true).
Myslím si, že zde platí přísloví, pes který štěká nekouše, neboť pak by se jeho klienti dozvěděli, že svěřuje jejich weby juniorům bez praxe.
A jestli se pamatuji správně, tak kdysi mělo K**i průser a majitel říkal, že testy nepíšou, že je to ztráta času (rozuměj peněz), že případnou pokutu zaplatí znova a že to bude méně něž by stál čas na testy. Nevím jak je to dnes, ale částečně má pravdu. Dříve jsem byl fanatik a dnes tak nějak zjišťuji, že testy nejsou zase tak důležité, jak se říká. Nehledě na to, že stejně nikdy nepokryjete 100% variant.
V případě eshopu na zakázku by mě testy opravdu překvapili.
Dříve jsem byl fanatik a dnes tak nějak zjišťuji, že testy nejsou zase tak důležité, jak se říká. Nehledě na to, že stejně nikdy nepokryjete 100% variant.Důležité je odhalovat chyby. Testy mají tu nevýhodu, že je člověk musí napsat navíc (je to mrtvý kód) a že stejně pokryjí jen poměrně malou část minového pole. Zrovna na jednom projektu vidím, jak maníci použili gRPC, ORM a JSON REST a nejvíc chyb nasekali v kódu převádějícím objekty mezi frameworky. Testy napsali tak nešikovně, že mnoho chyb neodhalily. Nejsmutnější je, že v podstatě píší jen boilerplate kód. Eliminací boilerplatu by se zbavili i těch bugů.
Tzn. naprostí diletanti. Na druhou stranu tato firma určitě není žádnou výjimkou.V ČR jsou dva typy malých IT firem: typ z tohoto příběhu (neschopný retardovaný šéf dávající almužnu, podle toho to pak vypadá všechno, nikdo rozumný tam nevydrží) a pak takové, kde jsou vývojáři nadprůměrně schopní a firma (šéf) si jich váží (a náležitě je platí; tam ale nevezmou kdekoho). Kupodivu moc neexistuje nějaký střed.
stačí se naučit Indicky a zdrhnout do Indie, jednak tam tvůj naprasený kód nevzbudí pohoršení a jednak z tebe bude rázem senior.Ať se naučí švýcarsky nebo belgicky, to je blíž a Indů tam taky najde dost.
Mě by zajímalo, kteří "zkušení" programátoři jsou ochotni tvořit kód bez testů.Jsou i jiné metody zajištění kvality. Nicméně v tomto případě je ta firma evidentně kompletní bordel a šéf idiot.