Proč se cpe JavaScript na backend?

[listoper]

Tohle fakt není na mně a ani nechci aby bylo.

To teda je...
Nikdo jinej tomu nerozumi... to je jako kdyby se mel manazer v bance rozhodovat jestli budou delat podvojne ucetnictvi...
Nebo aby se majitel servisu rozhodoval jestli se po prezuti kol bude kontrolovat utazeni sroubu.
Nebo abych se ja jako zakaznik rozhodoval jestli bude instalater delat kontrolu tesnosti....

Blbost... Testy jsou kod a kod je tvoje zodpovednost. A jestli vis ze jsou potreba a presto nechas zamestnavatele krvacet protoze si o ne nerekl tak to nemuzes moralne nijak obhajit.

(Mluvim o unit testech... ostatni jsou k diskuzi podle situace... )

[Reklama]

[Mudvy]

Musím se přiklonit na stranu Martina s tím, že realita je taková že když se tlačí na čas a cenu tak testování je první co se ořezává. Já to třeba vysvětluji tak, že pokud nebudou unit testy tak si musí zákazník dodaný software otestovat uživateslky sám a chyby mu opravím bezplatně pokud se bude jednat o minutovky nebo se domluvíme na vícepracích.

Ve výsledku to většinou dopadne dobře a zákazník ušetří tím že nemá testy ode mě. Spíš mi vzniknou výcepráce protože si to projde podle jeho zadání ale zjistí že něco si nedomyslel, nebo že by to šlo ještě vylepšit a spíš dělám úpravy, které nikdo neuvažoval, za což si zaplatí.

S tím se pojí další komplikace udržovat unit testy aktuální. Dost často něco ladím, zrychluji, refactoriji a pod. Nepíšu nic zas tak super složitého že bych tomu nerozumněl a nemohl to přeskládat jako lego. Pak je to pain udržovat testy ...

Podle mě hrozně záleží na konkrétním případu vývoje podle technologií / použití / životnosti / rozšířitelnosti / počtu vývojářů / integraci CD/CI

Je hezký pushnout z visual studia - udělat pull request a po schválení to letí rovou na release a unit testy to zastaví pokud selžou. Nicméně někdy je potřeba jen zkopírovat exáč z binu na vzdálenou plochu ...

Myslím si že je dobrý být versatilní s tím vysvětlovat rizika i výhody zákazníkům.

Jen pro kontext
Žiju v prostředí - visual studio, c#, desktop aplikace, automatizace, asp.net, git, devops, azure
Projekty od 0 v rozsahu 1-3 týdny do nasazení.

[listoper]

za což si zaplatí.

Takze si podojis zakaznika... super. Kdybys mel napsany unit testy tak treba dokazes prijit za zakaznikem driv nez to dodas a reknes mu, ze to nedava moc smysl a jestli nahodou by to nebylo jinak lepsi...
Cim driv odhalis problem tim levnejsi je ho odstranit.

S tím se pojí další komplikace udržovat unit testy aktuální. Dost často něco ladím, zrychluji, refactoriji a pod. Nepíšu nic zas tak super složitého že bych tomu nerozumněl a nemohl to přeskládat jako lego. Pak je to pain udržovat testy ...

Ladeni, zrychlovani a refactoring by typicky nemeli vezt ke zmenam v unit testech.

Podle mě hrozně záleží na konkrétním případu vývoje podle technologií / použití / životnosti / rozšířitelnosti / počtu vývojářů / integraci CD/CI

Je hezký pushnout z visual studia - udělat pull request a po schválení to letí rovou na release a unit testy to zastaví pokud selžou. Nicméně někdy je potřeba jen zkopírovat exáč z binu na vzdálenou plochu ...

Myslím si že je dobrý být versatilní s tím vysvětlovat rizika i výhody zákazníkům.

Ano je dulezite byt flexibilni...
Ale taky je potreba si uvedomit, ze kdyz nechas nekoho kdo tomu nerozumi rikat ti jak mas delat praci a kde usetrit tak jsi amater. A ohanet se tim ze "oni plati => oni rozhoduji" je nemoralni.

[cznarg]

> S tím se pojí další komplikace udržovat unit testy aktuální. Dost často něco ladím, zrychluji, refactoriji a pod. Nepíšu nic zas tak super složitého že bych tomu nerozumněl a nemohl to přeskládat jako lego. Pak je to pain udržovat testy ...

Naopak, když děláte refactoring, tak testy za mě jsou to nejlepší co může být. Od unitů přes funkcionální. Funkcionální by měli být zelené i po refactoringu, na unity by se mělo šahat jen v těch co testují refaktorovaný kód. Všechny ostatní by měli projít (tj. nezměnil jsem náhodou interface na který spoléhá zbytek programu etc. -- a pokud jsem interface změnil, víte kam se přesně podívat, jaké další části na to spoléhaly).

> Podle mě hrozně záleží na konkrétním případu vývoje podle technologií / použití / životnosti / rozšířitelnosti / počtu vývojářů / integraci CD/CI -- Je hezký pushnout z visual studia - udělat pull request a po schválení to letí rovou na release a unit testy to zastaví pokud selžou. Nicméně někdy je potřeba jen zkopírovat exáč z binu na vzdálenou plochu ...
Osobně si i na svých soukromých projektech dělám CI, CD a testy. Říká mě to jednoduchou věc: rozbil si to. Rád dělám programátora, ne testera klikače -- abych po večerech zjišťoval manuálně kde mi co funguje (nebo nefunguje). Navíc až Vás bude někdo zastupovat, může se velice lehce stát že ten exáč v binu prostě nedokáže zbuildit (protože env, verze kompilátoru chybějící přístup někam, whatever)

> Myslím si že je dobrý být versatilní s tím vysvětlovat rizika i výhody zákazníkům.
Osobně bych zákazníka co nechce testy poslal někam. Tj. takový vývoj po pár letech končí tragicky -- lidé se bojí někam šáhnout aby nerozbili nějakou jinou funkčnost -- protože jim to neřeknou právě testy. Možná že u drobných projektů se to dá, ale jakmile na projektu pracuje víc programátorů a je to něco long-term, nedá se to udržet.

[Mudvy]

Takze si podojis zakaznika... super.

Tohle není úmyslný a unit testy s tím nemají nic společnýho. Například se díky mojí automatizaci příjde při testování na to, že by bylo vhodné změnit konstrukční metodiku. Někdy i sám při vývoji dělám návrhy na změny a úpravy, které nejsou původně plánované. Nebo přijdou nové požadavky protože když to viděl management tak mu to otevřelo oči.

Jsou firmy co žijou v pravěku a excelu a když jim ukážete že 50% činností s informacemi lze pohodlně a rychle automatizovat tak jim to změní realitu, navíc když si můžou žít dál v tom co znají.

Naopak si myslím že můj přístup k zákazníkům je velmi skromny. ... Jeden projekt byla jednoduchá konverze dat z formátu do formátu ... jednalo se o několik tisíc souborů. Za týden se na to napsala malá aplikace co to pochroupala za pár dní. Tu práci si ten zákazník odhadoval na 2000 hodin (ruční klikání soubor po souboru (save as)). Zaplatili nám týden vývoje a konec ...

Nevidím tu žádné dojení zákazníků, spíš dělám charitu.

[Reklama]

[Kit]

S tím se pojí další komplikace udržovat unit testy aktuální. Dost často něco ladím, zrychluji, refactoriji a pod. Nepíšu nic zas tak super složitého že bych tomu nerozumněl a nemohl to přeskládat jako lego. Pak je to pain udržovat testy ...

Testy jsou aktuální vždy. Pokud mám opravit chybu, tak nejprve upravím test tak, aby při nahlášeném vstupu selhal. Pak teprve hledám, kde je ta chyba. Výsledkem je aktuální test i jednotka.

[Martin Poljak]

Tohle fakt není na mně a ani nechci aby bylo.

To teda je...
Nikdo jinej tomu nerozumi... to je jako kdyby se mel manazer v bance rozhodovat jestli budou delat podvojne ucetnictvi...
(Mluvim o unit testech... ostatni jsou k diskuzi podle situace... )

Ne, není. Dělám to, za co mě zaplatí. Pokud výslovně nezaplatí, nedělám to. Takhle jednoduché to je. Nedělám ucelenou zakázku, nedodávám komplexní řešení. Tohle prostě není můj problém a pracuju pro ty, kteří to neočekávají. A vyhovuje mi to tak. Nemám důvod se snažit o víc, něco prodávat, někoho přesvědčovat. Proč bych to dělal? Co by mi to přineslo? Víc práce s něčím, co dotyčný ani neočekává ani nechce a když ho přesvědčím o tom, že chce, bude to jen zátěž pro mě a on bude jen o to víc vrčet nad každou fakturou, ve které si to zaplatí s pocitem, že je to prý potřeba ale on stejně neví k čemu a jen za to platí?

Teoretiky jako vy miluju.

[Martin Poljak]

za což si zaplatí.

Takze si podojis zakaznika... super. Kdybys mel napsany unit testy tak treba dokazes prijit za zakaznikem driv nez to dodas a reknes mu, ze to nedava moc smysl a jestli nahodou by to nebylo jinak lepsi...

Reálně mi spíš zákazník zaplatí tolik, kolik chce. To je na něm. A já mu podle toho odvedu práci.

Ale taky je potreba si uvedomit, ze kdyz nechas nekoho kdo tomu nerozumi rikat ti jak mas delat praci a kde usetrit tak jsi amater. A ohanet se tim ze "oni plati => oni rozhoduji" je nemoralni.

Nemorální to není. A nazývat si to můžete jak chcete. Je mi to dost srdečně jedno. Stejně, jako těm, pro koho dělám to, co potřebují. Až budou chtít vás, najmou si vás, upřímně

[Martin Poljak]

N/A

[Martin Poljak]

Pokud bys mu řekl, že to bude trvat jeden týden bez testů nebo jeden týden s testy, co by si vybral?

Neřekl bych mu to protože by to nebyla pravda.

Aha, takže neumíš efektivně psát testy.

Vy nedojedete za hodinu z Prahy do Brna? Ha, takže neumíte efektivně řídit! Plácáte úplné kraviny, upřímně. Tyhle prázdné výkřiky do tmy, kterými se prostě snažíte dokázat vlastní ideovou nadřazenost si nechte někam na Novinky.cz, tam zapadnou.

[Martin Poljak]

> Podle mě hrozně záleží na konkrétním případu vývoje podle technologií / použití / životnosti / rozšířitelnosti / počtu vývojářů / integraci CD/CI -- Je hezký pushnout z visual studia - udělat pull request a po schválení to letí rovou na release a unit testy to zastaví pokud selžou. Nicméně někdy je potřeba jen zkopírovat exáč z binu na vzdálenou plochu ...
Osobně si i na svých soukromých projektech dělám CI, CD a testy. Říká mě to jednoduchou věc: rozbil si to. Rád dělám programátora, ne testera klikače -- abych po večerech zjišťoval manuálně kde mi co funguje (nebo nefunguje).

A já rád dostávám za svou práci zaplaceno. A to za to, co chce zákazník udělat. Pokud nechce testy, nebude mít testy. Chce-li testy, dostane testy. To je celé. Soukromé projekty jsou něco úplně jiného.

> Myslím si že je dobrý být versatilní s tím vysvětlovat rizika i výhody zákazníkům.
Osobně bych zákazníka co nechce testy poslal někam. Tj. takový vývoj po pár letech končí tragicky -- lidé se bojí někam šáhnout aby nerozbili nějakou jinou funkčnost -- protože jim to neřeknou právě testy. Možná že u drobných projektů se to dá, ale jakmile na projektu pracuje víc programátorů a je to něco long-term, nedá se to udržet.

To sice máte pravdu, ale rozhodnutí je na tom, kdo mě platí co bude a nebude chtít. Já mu mohu sdělit svůj vlastní názor ale zbytek řešit nechci. Nemám zapotřebí ho přesvědčovat. Nejsem firma. Jsem námezdní síla, se kterou to může zkonzultovat a která mu udělá to, za co si zaplatí. Ani méně, ani více. Samozřejmě by člověk mohl pracovat tam, kde bude mít větší odpovědnost ale atokonto taky o dost víc starostí, za (snad) lepší peníze, prostě reálně podnikat. Ale potřebuji to? Co mě nutí? Co by to přineslo mně?

A pokud mi zákazník zaplatit plánuje, nemám důvod ho kamkoliv posílat pokud je jeho projekt něco, co mě z jakéhokoliv důvodu zajímá nebo baví. Celé je to prostě o úrovni a způsobu angažovanosti. Kdybych byl firma a dělal vyloženě větší zakázky s následnou údržbou další roky, budu tlačit na udržitelnost. Jsem-li prostý námezdní programátor na volné noze pracující tu pro toho, tu pro onoho, je moje angažovanost ve správě projektu nastavená zase úplně jinak a správa a fungování projektu a to, co v tomto ohledu chce je na zadavateli.

[BoneFlute]

Ve výsledku to většinou dopadne dobře a zákazník ušetří tím že nemá testy ode mě. Spíš mi vzniknou výcepráce protože si to projde podle jeho zadání ale zjistí že něco si nedomyslel, nebo že by to šlo ještě vylepšit a spíš dělám úpravy, které nikdo neuvažoval, za což si zaplatí.

S tím se pojí další komplikace udržovat unit testy aktuální. Dost často něco ladím, zrychluji, refactoriji a pod. Nepíšu nic zas tak super složitého že bych tomu nerozumněl a nemohl to přeskládat jako lego. Pak je to pain udržovat testy ...

Podle mě hrozně záleží na konkrétním případu vývoje podle technologií / použití / životnosti / rozšířitelnosti / počtu vývojářů / integraci CD/CI

Tak ono umět psát testy je samozřejmě skill. Když ten skill není, tak...

To co tu popisuješ je klasický mýtus o testech. Ve skutečnosti testuješ. (Nevěřím ti, že napíšeš změnu v kódu, projekt přebuildíš, a pak to jen tak pošleš.) Jen vždycky ty testy uděláš a pak je zahodíš.

Každopádně testy nejsou drahé. Testy jsou o mentálním nastavení. Jakmile přičuchneš k tomu, že ti ty testy začnou pomáhat, tak začneš přemýšlet jinak. Samozřejmě, pokud na ně pohlížíš jen jako na komplikaci a nutnost, kterou nechápeš, tak tě k tomu nikdo nedonutí.

[BoneFlute]

A já rád dostávám za svou práci zaplaceno. A to za to, co chce zákazník udělat. Pokud nechce testy, nebude mít testy. Chce-li testy, dostane testy. To je celé.

No jo, ale stejnou optikou můžete říct, že zákazník chce špagety, dostane špagety, zákazník chce rozumný kód, dostane rozumný kód.

Vy nemáte potřebu napsat kód nejlíp jak umíte?

Taky se tu už skloňovala věc: proč bych do tohoto rozhodování měl zákazníka vůbec zatahovat. Testy nejsou jeho starost.


Uvedu příklad ze života: Mám zákazníka, který chtěl jednoduchou aplikaci pro transformaci xml. Vysvětlil mi k čemu to, jakej je budget, jeho usecase. Já jsem to zhodnotil, že ha, ideální kandidát na xslt. Tak jsem to udělal, odladil, napsal README, a poslal mu to. Poděkoval, zaplatil, a spokojenost.
Jenže po nějaké době chtěl úpravy. Taky popisoval, že občas zapomínají na nějaké kroky z README. Občas je něco jinak. Špatná data, špatné ruce.
A tak jsem to celé přepsal do Rustu a šel spát.

Můžete si všimnout, že nikde jsem se ho neptal na to, zda to chce napsat v xslt, nebo v Rustu, nebo dokonce zda to mám otestovat.

[kate]

Dokud jsem psala čistý backend, a občas nějakou soukromou aplikaci s trochou Javascriptu, přišlo mi to taky trochu uhozené. Teď se mi díky dobré podpoře wasm všude otevřela i možnost psát si složitější fullstack projekty v Rustu (používám Leptos FE + Axum BE) a některé výhody jsou mi zjevné, i když JS by nebyl moje volba.

- dost zjevná výhoda je sdílení datových struktur a funkcí kolem nich. Obě strany API jsou jedna knihovna. Pro mě to v jednom případě zašlo i do extrému části kódu sdíleného mezi MCU (ESP32C3), server BE a frontendem.

- Server side rendering. Zvlášť když píšu webovou aplikaci, je obrovská výhoda když dovede frontend komponenty ze stejného kódu vygenerovat klient i server. Crawlery dostanou rychle kompletní stránku (což zlepšuje ranking ve vyhledávačích), lidi bez zaplého JS mohou dostat část nebo i celou funkcionalitu (I když celá funkcionalita je asi o dost složitější udržet), a ti co mají JS zaplý vidí výsledek prakticky okamžitě, a client side kód zajišťující interaktivitu se donačte na pozadí.

[Martin Poljak]

A já rád dostávám za svou práci zaplaceno. A to za to, co chce zákazník udělat. Pokud nechce testy, nebude mít testy. Chce-li testy, dostane testy. To je celé.

No jo, ale stejnou optikou můžete říct, že zákazník chce špagety, dostane špagety, zákazník chce rozumný kód, dostane rozumný kód. Vy nemáte potřebu napsat kód nejlíp jak umíte?

Mám. Ale charita nejsem.

Taky se tu už skloňovala věc: proč bych do tohoto rozhodování měl zákazníka vůbec zatahovat. Testy nejsou jeho starost.

Nejsou. Ale charita nejsem.

Můžete si všimnout, že nikde jsem se ho neptal na to, zda to chce napsat v xslt, nebo v Rustu, nebo dokonce zda to mám otestovat.

Mohu. Ale charita nejsem. A navíc jsem (a chci být) námezdní síla, nikoliv dodavatel kompletních řešení.