Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: novomente 23. 08. 2026, 04:35:53
-
Když jsem se učil z knížek programovat, autoři ve vztahu k syntaxi většinou říkali, aby si programátor zvolil svůj styl a toho se pak držel. Programovací jazyky však dovolují nejen styl syntaxe, ale i styl programování. Existují však konvence anebo doporučení, jak programovat v tom či onom jazyce.
Nejsem profesionální programátor, ale zajímalo by mě, jestli se těchto doporučení držíte, anebo máte raději (i kromě těchto doporučení) nějakou volnost a svobodu rozhodnout se, jak budete programovat. Zajímá mě praxe jak freelancerů, tak profesionálů v týmu malém i velkém.
-
me uz prestaly bavit nejake vysoke abstrakce v proceduralnim programovani, nakonec se mi libi primocarost assembleru nebo c. vyssi mira abstrakce ve funkcionalnich jazycich mi zase pripada spravna.
-
Proc te to zajima?
-
Proc te to zajima?
Navrhuji techniku programování, kde jsou užity již hotové technologie, ale ta technika zatím vyžaduje určitá doporučení, která by se měla dodržovat. Chtěl bych zjistit, jestli profesionální vývojáři dávají přednost svobodě v programování, nebo jestli je praxe dosti omezuje ve způsobu, jak programují.
-
My sme používali Clean Code od Robert C. Martin a Gang of four vzory. Len už sú tie knihy trochu staré, medzitým sa jazyky a best practices posunuli. Dosť veľa vecí platí doteraz, ale treba to brať s rezervou.
-
Záleží na zvoleném paradigmatu. Začínal jsem s procedurálním Pascalem, na PHP jsem postupně přesedlal na OOP a později na funkcionální. Teď mě baví deklarativní s XSLT, nejlépe v kombinaci s PHP. Na každou vrstvu aplikace mám jiné paradigma tak, aby kód byl co nejkratší, nejsrozumitelnější a také znovupoužitelný.
Můžeš se nechat inspirovat stylem, který ti nabídne AI.
-
Za mňa záleží na použitom frameworku, alebo architektúre... Napríklad som zažil reálny projekt s java ee frameworkom. Borci si hashovaciu funkciu, i saltenie hesla používatela nakódili sami. Session management, celkom vlastný kvetnatý kus kódu. A nehovorím o tom, že používali JSB (java server pages), akokeby to boli CGI skripty. Proste printf do stringu a to sa vracalo. Ich jediný, main.jsp súbor obsahoval jeden riadok: new MojFramework(request, response).renderHtmľ()...
Takže tak... Záleží, či ideš k profesionálom, alebo k profesionálom. Nevidel som vela programátorov, ktorí by riešili veci podľa best practices. Problém je budget a nekompetencia developrov (neochota povedat, ze to zozerie viac casu)...
-
mi se libi jak ro rikal linus, ze mas navrhnout dobre datove struktury a kod kolem toho uz je pak jednoduchy, coz se mi libi a na to staci c.
nejake hracicky navic jako zapouzdreni a objekty, public/private, templates uz mi pripadaji jen jako hracicky.
treba je dobre mit peknou datovou strukturu pro vektory, matice, quaterniony, kod a vypocty uz se pak k tomu pisou samy.
-
Takže tak... Záleží, či ideš k profesionálom, alebo k profesionálom. Nevidel som vela programátorov, ktorí by riešili veci podľa best practices. Problém je budget a nekompetencia developrov (neochota povedat, ze to zozerie viac casu)...
Taky zalezi, zda tam nekdo vi dopredu kudy se to bude vyvijet. Treba moje one-man show je vzdy takova prijemna prace, protoze se uz vcas pripravuji na to, ze tam bude neco jinak / rozsireno, takze buduji zaklady.
Oproti tomu spoluprace s kolegou, co dela vsechno jen aby bylo, je strasne narocna a vycerpavajici, kdyz vidim jak tam dela cicoviny, ktere bude pak predelavat v X souborech.
-
mi se libi jak ro rikal linus, ze mas navrhnout dobre datove struktury a kod kolem toho uz je pak jednoduchy, coz se mi libi a na to staci c.
nejake hracicky navic jako zapouzdreni a objekty, public/private, templates uz mi pripadaji jen jako hracicky.
treba je dobre mit peknou datovou strukturu pro vektory, matice, quaterniony, kod a vypocty uz se pak k tomu pisou samy.
Datové struktury jsou dobrým základem. Se skaláry je to cesta do pekel. Na quaterniony je třeba mít tu správnou knihovnu a pak je ta práce také snadná.
V OOP se také dobře programuje, pokud zapomenete na protected a public proměnné a také se vyvarujete použití getterů a setterů.
-
Proc te to zajima?
Navrhuji techniku programování, kde jsou užity již hotové technologie, ale ta technika zatím vyžaduje určitá doporučení, která by se měla dodržovat. Chtěl bych zjistit, jestli profesionální vývojáři dávají přednost svobodě v programování, nebo jestli je praxe dosti omezuje ve způsobu, jak programují.
Záleží na spoustě faktorů. Některé jazyky (C++, Java) umožňují psát objektově, bez objektu (procedurálně), funkcionálně. C++ má i šablony. Takže tam programátor může být hodně kreativní.
Tým vs jednotlivec. V týmu bývají nějaké psané a nepsané konvence a odchylky se dozvíš pri code review.
Osobnost programátora. Někdo má talent psat čistý efektivní, rozšiřitelný kód. (SOLID principy). Někdo má toho talentu méně...
Co je vstupem. Dostanes už nějakou architekturu nebo vše vymyslíš sám? Tam může docházet k velkým divergencim mezi programátory.
Atd...
-
Nevidel som vela programátorov, ktorí by riešili veci podľa best practices. Problém je budget a nekompetencia developrov (neochota povedat, ze to zozerie viac casu)...
Na best practices na většině projektů fakt není čas. Výsledkem je skoro vždy nějaký kompromis. Vývojáři se obvykle snaží o alespoň nějaké best practices a ten, kdo to platí se zase snaží aby byl vývoj co nejlevnější. Obojí je logické a za ideální situace by to mělo vytvářet potřebnou rovnováhu. Jestli vytváří i v praxi je další věc.
"Nekompetence" je v tomto případě špatný termín, který popisuje něco jiného. Neochota? To ano, to je mnohem přesnější. Chcete se jako vývojář s někým hádat, že to, co chce nedává smysl? Pokud nejste zrovna majitelem firmy, nechcete. Chcete jen, abyste dostal zaplaceno. Některé firmy si to financovat mohou dovolit nebo poslat klienta do háje s tím, že to není reálné. Ale většina spíš ne. Takže se věci prostě lepí jak se dá.
Což je mimochodem docela marný některým teoretikům tady vysvětlovat.
-
Na best practices na většině projektů fakt není čas. Výsledkem je skoro vždy nějaký kompromis.
Jasny. to je jako rozepinat poklopec kdyz jdes na zachod... Kdo na to ma cas? Navic si jako bonus ani nemusis umejvat ruce kdyz odchazis.
-
Šlo by dát nějaké příklady "best practices" a kde to jde a nejde používat. Mně přijde, že s použitím LLMs už jde často spíš o výmluvy...
-
Na best practices na většině projektů fakt není čas. Výsledkem je skoro vždy nějaký kompromis.
Jasny. to je jako rozepinat poklopec kdyz jdes na zachod... Kdo na to ma cas? Navic si jako bonus ani nemusis umejvat ruce kdyz odchazis.
Tenhle příměr kapku kulhá. Když už nic jiného, tak to nejsou tvoje kalhoty.
-
Na best practices na většině projektů fakt není čas. Výsledkem je skoro vždy nějaký kompromis.
Jasny. to je jako rozepinat poklopec kdyz jdes na zachod... Kdo na to ma cas? Navic si jako bonus ani nemusis umejvat ruce kdyz odchazis.
Tenhle příměr kapku kulhá. Když už nic jiného, tak to nejsou tvoje kalhoty.
Mozna, ale kalhoty menim casteji nez projekty.
-
Šlo by dát nějaké příklady "best practices" a kde to jde a nejde používat. Mně přijde, že s použitím LLMs už jde často spíš o výmluvy...
To jsem původně chtěl také napsat, že to platí spíš pro minulost a LLM to dnes už dost kompenzují ale nechtěl jsem to víc rozmazávat. Takže ano, s tím částečně souhlasím.
Na druhou stranu něco naprasit s LLM je v některých ohledech snažší a hlavně rychlejší než dřív. Což pochopitelně neví jenom vývojáři ale i ti, co to něco chtějí platit. Což se ovšem typicky projevuje tak, že dnes kdekdo bohužel začal s poukazem na AI tlačit na rychlost na úkor kvality ještě víc než dřív. A bohužel i na projektech, kde se dřív na kvalitu dbalo protože všude se najde nějaký idiot, co o vývoji softwaru sice neví doslova nic (a občas to ani není vývojář) ale má dojem, že když mu Claude vygeneroval pár jednoduchých jakž takž použitelných PR, může teď mít plnou hubu řečí jak bychom měli s AI vyvíjet. A na podobné pitomce vedení často slyší protože je to pochopitelně mnohem atraktivnější než slyšet, že když budeme takhle pokračovat, budeme mít za rok za dva z aplikace hromadu slopu. Už proto, že to druhé se narozdíl od rychlosti dodání nedá měřit a nekoukají z toho žádné výroční prémie.
-
Mně přijde, že s použitím LLMs už jde často spíš o výmluvy...
Mě přijde, že s použitím LLMs se šíleně přesunul focus na review. Což v důsledku znamená, že se i posunuli best-practice: větší důraz na čitelnost, na to, aby LLMko nerozebíralo furt všechno, etc.
-
Mě přijde, že s použitím LLMs se šíleně přesunul focus na review. Což v důsledku znamená, že se i posunuli best-practice: větší důraz na čitelnost, na to, aby LLMko nerozebíralo furt všechno, etc.
Ovšem bohužel to zase skryje ten zbytek.
-
Mě přijde, že s použitím LLMs se šíleně přesunul focus na review. Což v důsledku znamená, že se i posunuli best-practice: větší důraz na čitelnost, na to, aby LLMko nerozebíralo furt všechno, etc.
Ovšem bohužel to zase skryje ten zbytek.
Asi nerozumím.
-
Mně přijde, že s použitím LLMs už jde často spíš o výmluvy...
Mě přijde, že s použitím LLMs se šíleně přesunul focus na review. Což v důsledku znamená, že se i posunuli best-practice: větší důraz na čitelnost, na to, aby LLMko nerozebíralo furt všechno, etc.
Větší důraz je i na testy, se kterými LLM také rád pomůže. Právě testy jsou dnes důležitější než kdy dříve.
-
Větší důraz je i na testy, se kterými LLM také rád pomůže. Právě testy jsou dnes důležitější než kdy dříve.
Právě klasické unit testy funkčnost v rámci workflow naopak ztratily.
-
Jak je zapsáno v posvátných svitcích:
Opravdový programátor dokáže psát fortranské programy v jakémkoli jazyce.
-
Větší důraz je i na testy, se kterými LLM také rád pomůže. Právě testy jsou dnes důležitější než kdy dříve.
Právě klasické unit testy funkčnost v rámci workflow naopak ztratily.
Jak jinak než testy ověřím funkčnost programu, pokud nechci detailně zkoumat zdrojáky od AI?
-
Právě klasické unit testy funkčnost v rámci workflow naopak ztratily.
Větší blbost jsem hodně dlouho nečetl.
-
Jak jinak než testy ověřím funkčnost programu, pokud nechci detailně zkoumat zdrojáky od AI?
Co asi tak testujou testy ktery ti napise stejny AIcko jako ten kod ...
-
Jak jinak než testy ověřím funkčnost programu, pokud nechci detailně zkoumat zdrojáky od AI?
Co asi tak testujou testy ktery ti napise stejny AIcko jako ten kod ...
Třeba to, jestli program splňuje zadání pro různé okrajové podmínky. Testy jsou i součástí dokumentace.
-
Právě klasické unit testy funkčnost v rámci workflow naopak ztratily.
Větší blbost jsem hodně dlouho nečetl.
Je to nestastne receno, ale s timhle vice mene souhlasim...
ztratili cast sve hodnoty pro cloveka... (tu sebereflexivni.. jak dobre se pouziva to API ktere jsem navrhl?)
Daleko vice ziskavaji E2E testy.. byly vzdycky drahe na udrzbu, ale ted kdyz to stoji vicemene nic tak se vyplati.
Unit testy pise AI a ja je nectu.. jestli jsou pro ni uzitecny tak at je pise.. ale pro me jsou dulezity vystupu e2e(business scenario testu) a NFR testu
-
Jak jinak než testy ověřím funkčnost programu, pokud nechci detailně zkoumat zdrojáky od AI?
Co asi tak testujou testy ktery ti napise stejny AIcko jako ten kod ...
Co asi tak testujou testy ktery ti napise stejny _člověk_ jako ten kod ...
Celkem dost, ne?
-
Právě klasické unit testy funkčnost v rámci workflow naopak ztratily.
Větší blbost jsem hodně dlouho nečetl.
Je to nestastne receno, ale s timhle vice mene souhlasim...
ztratili cast sve hodnoty pro cloveka... (tu sebereflexivni.. jak dobre se pouziva to API ktere jsem navrhl?)
Daleko vice ziskavaji E2E testy.. byly vzdycky drahe na udrzbu, ale ted kdyz to stoji vicemene nic tak se vyplati.
Unit testy pise AI a ja je nectu.. jestli jsou pro ni uzitecny tak at je pise.. ale pro me jsou dulezity vystupu e2e(business scenario testu) a NFR testu
Tady bacha. Hranice mezi různými druhy testů není moc standardizovaná.
-
Právě klasické unit testy funkčnost v rámci workflow naopak ztratily.
Větší blbost jsem hodně dlouho nečetl.
Je to nestastne receno, ale s timhle vice mene souhlasim...
ztratili cast sve hodnoty pro cloveka... (tu sebereflexivni.. jak dobre se pouziva to API ktere jsem navrhl?)
Daleko vice ziskavaji E2E testy.. byly vzdycky drahe na udrzbu, ale ted kdyz to stoji vicemene nic tak se vyplati.
Unit testy pise AI a ja je nectu.. jestli jsou pro ni uzitecny tak at je pise.. ale pro me jsou dulezity vystupu e2e(business scenario testu) a NFR testu
Tady bacha. Hranice mezi různými druhy testů není moc standardizovaná.
Jj. na to tu uz par let obcas narazime, ze si nerozumime..
Ja unit testy nazyvam to jak jsou chapany v TDD. Takove ty ktere pustim jednoduse lokalne bez deploymentu cele aplikace a databaze a omacky okolo a staci mi k tomu v podstate jen ta jednotka kterou testuju (typicky class) a jeji test. Zbytek kdyz je to nevyhnutelne tak se mockuje (a kdyz se moc mockuje tak je to indikator spatneho navrhu... )
Business scenario testy jsou ty testy ktere pokryvaji usecases
A NFR jsou ty ktere pokryvaji nefunkcni pozadavky (performance, security, observability.... )
-
Právě klasické unit testy funkčnost v rámci workflow naopak ztratily.
Větší blbost jsem hodně dlouho nečetl.
ztratili cast sve hodnoty pro cloveka... (tu sebereflexivni.. jak dobre se pouziva to API ktere jsem navrhl?)
Daleko vice ziskavaji E2E testy.. byly vzdycky drahe na udrzbu, ale ted kdyz to stoji vicemene nic tak se vyplati.
Dík. Přesně tak jsem to myslel a vnímám to naprosto stejně. Jenže hrozně miluju ty neustále poněkud připitomělé TDD výkřiky některých zdejších MBA takže jsem to prostě nemohl rozepsat víc. To by se moc podobalo praxi a nezapadlo správně do té povrchnosti 8)
-
Na best practices na většině projektů fakt není čas. Výsledkem je skoro vždy nějaký kompromis.
Jasny. to je jako rozepinat poklopec kdyz jdes na zachod... Kdo na to ma cas? Navic si jako bonus ani nemusis umejvat ruce kdyz odchazis.
Pokud to jsou kalhoty od skafandru, tak to může být docela dobrý nápad.
-
Je to nestastne receno, ale s timhle vice mene souhlasim...
ztratili cast sve hodnoty pro cloveka... (tu sebereflexivni.. jak dobre se pouziva to API ktere jsem navrhl?)
Daleko vice ziskavaji E2E testy.. byly vzdycky drahe na udrzbu, ale ted kdyz to stoji vicemene nic tak se vyplati.
Unit testy pise AI a ja je nectu.. jestli jsou pro ni uzitecny tak at je pise.. ale pro me jsou dulezity vystupu e2e(business scenario testu) a NFR testu
Ak ti AI pise aj testy aj kod tak ty ani netusis, ci sa to sprava, ako sa to spravat ma. A ak su pre teba unit testy, ktore pokryvaju okrajove scenare konkretneho kusu kodu nepodstatne tak by si ich mal mat vsetky pokryte v E2E scenaroch. Tak dufam, ze E2E scenare a testy ti AI nepise tiez, lebo raz ti napise testy s "return(success)" a potom sa budes cudovat.
-
Samozrejme, ze AI pise i ty E2E a NFR testy... Vstup je nase konverzace s businessem.
Me zajimaji jejich vystupy.. a ty jsou "vytuneny"... Je to dukaz prubehu testu kazdy krok je zdokumentovany a "opakovatelny"
(Neco jako takova ta zelena sipecka v Intellij IDEA kterou se daji spustit testy tak mam v testing evidence, aby kazdy kdo cte tu evidence mohl snadno test replikovat a sledovat prubeh u sebe. )
A pokryti je idealne dostatecny na to, aby jen pomoci featurefiles dal projekt preimplementovat pomoci AI od nuly.. Mam to vyzkouseny jen castecne, ale nevidim duvod proc by to neslo...
-
Testy muze psat umela demence, ale nekdo by mel vedet, co vlastne ten test testuje, jinak je totalne k nicemu. E2E je spis takova tresnicka na dortu, protoze pokud spoleham pouze na E2E, tak musim otestovat hodne pripadu, kde mistni speky lip otestuje spravnej unit test. Vhodnej test neblize problemu je rychlejsi a efektivnejsi na chytani vsech zaludnosti (proste ta komponenta, co muze delat nejvetsi problemy, si zaslouzi vlastni sadu testu, ktery otestujou prave ji a pak vim, ze tato komplexni komponenta se chova spravne dle specifikaci).
-
E2E je spis takova tresnicka na dortu, protoze pokud spoleham pouze na E2E [...]
Tak ony hlavně nejsou jen end-to-end testy a unit testy. Což jsou dvě krabice, do kterých se během let skoro každý uzavřel a odmítá teď z toho lustru slézt. Oprávněné to bylo před AI. Ale právě v době AI začaly mít smysl testy, které nejsou vysokoúrovňové ale ani netestují jen základní units, testují větší -- ale ne úplně základní ani ne úplně velké -- funkční celky. Což může vypadat jako nesmysl ale je to přesně mitigace toho, aby AI byla dostatečně autonomní ale zároveň dostatečně pod kontrolou. Na jednu stranu to má nevýhody obojího, na druhou stranu výhody obojího. Trade-off je to vždycky tak, jako celý vývoj. Což je ostatně hlavní práce vývojáře.
-
Ak ti AI pise aj testy aj kod tak ty ani netusis, ci sa to sprava, ako sa to spravat ma.
Když použiju nějakou knihovní funkci, tak taky netuším, jestli se chová, jak má. Ty si sám píšeš testy i na každou vnější závislost, nebo taky spoléháš na to, že to otestoval někdo jiný - a šťourat do toho začneš až když nějaký test na vyšší úrovni nebo praxe ukážou problém?
-
Ak ti AI pise aj testy aj kod tak ty ani netusis, ci sa to sprava, ako sa to spravat ma.
Když použiju nějakou knihovní funkci, tak taky netuším, jestli se chová, jak má. Ty si sám píšeš testy i na každou vnější závislost, nebo taky spoléháš na to, že to otestoval někdo jiný - a šťourat do toho začneš až když nějaký test na vyšší úrovni nebo praxe ukážou problém?
já třeba jo
Zvláště u webservis oni rádi mění api a chování aniž by dali vědět.
-
Ak ti AI pise aj testy aj kod tak ty ani netusis, ci sa to sprava, ako sa to spravat ma.
Když použiju nějakou knihovní funkci, tak taky netuším, jestli se chová, jak má. Ty si sám píšeš testy i na každou vnější závislost, nebo taky spoléháš na to, že to otestoval někdo jiný - a šťourat do toho začneš až když nějaký test na vyšší úrovni nebo praxe ukážou problém?
já třeba jo
Zvláště u webservis oni rádi mění api a chování aniž by dali vědět.
Něco jiného je testovat závislost kterou nemám pod správou (web api etc.) a něco jiného je knihovna. Kterou pod správou mám přesnou verzi a když neprovedu upgrade, aplikace bude fungovat dál. Osobně to nikomu neberu, ale kde je ta hranice? Za chvíli někdo může psát testy jestli se compiler chová tak jak se chovat má...
-
kde je ta hranice?
Ekonomie?
Mám knihovnu, a pro ni mám testy.
Pak mám aplikaci, která tu knihovnu používá, a napíšu si testy znovu. Párkrát se mi to už vyplatilo.
Běžně to nedělám. Spíše výjimečně. Ale když by šlo třeba o medicínský software, nebo raketoplán...?
Pointa je v tom, že na takto kritický software použiji více jak testy. Protože testy jsou tak nějak z definice neúplné, že.
Programátor který píše "obyčejnou" aplikaci to otestuje tak, aby se mu to vyplatilo:
1/ co se testuje snadno a má největší dopad
2/ co se testuje hůř ale má velký dopad
3/ to ostatní
-
Zvláště u webservis oni rádi mění api a chování aniž by dali vědět.
Něco jiného je testovat závislost kterou nemám pod správou (web api etc.) a něco jiného je knihovna. Kterou pod správou mám přesnou verzi a když neprovedu upgrade, aplikace bude fungovat dál. Osobně to nikomu neberu, ale kde je ta hranice? Za chvíli někdo může psát testy jestli se compiler chová tak jak se chovat má...
Někdy dělám i testy na používané knihovní funkce, abych měl jistotu, že se budou správně chovat i při upgrade té knihovny.
-
Osobně to nikomu neberu, ale kde je ta hranice? Za chvíli někdo může psát testy jestli se compiler chová tak jak se chovat má...
A co třeba testovat, jestli se compiler chová tak, jak čekám? V některých jazycích má až překvapivou volnost (třeba C). Tam může update překladače udělat zajímavé věci. Ono třeba stačí aby se trochu změnila ochota inlinovat a nějaká kritická část kódu může být násobně pomalejší.
A překladačových bugů jsem už taky pár potkal. Ale tohle jsou věci tak nepředvídatelné, že tu preventivní test nepomůže.
-
Doporučuju dobré video proč nepoužívat clean code.
Clean code, horrible performance
https://youtu.be/tD5NrevFtbU?si=2NGwwfGr3vcXoUCX (https://youtu.be/tD5NrevFtbU?si=2NGwwfGr3vcXoUCX)
-
Doporučuju dobré video proč nepoužívat clean code.
Clean code, horrible performance
https://youtu.be/tD5NrevFtbU?si=2NGwwfGr3vcXoUCX (https://youtu.be/tD5NrevFtbU?si=2NGwwfGr3vcXoUCX)
Jediným argumentem je benchmark? Schválně si vybral případ, který nejlépe vyhovuje jeho záměru, pak na to aplikuje Fly Weight, ale jen na tu jeho verzi. Nevěřím benchmarkům, které si sám nezfalšuji.
-
Na best practices na většině projektů fakt není čas. Výsledkem je skoro vždy nějaký kompromis.
Jasny. to je jako rozepinat poklopec kdyz jdes na zachod... Kdo na to ma cas? Navic si jako bonus ani nemusis umejvat ruce kdyz odchazis.
Pokud to jsou kalhoty od skafandru, tak to může být docela dobrý nápad.
Ani tam se to neosvědčilo. Šlo to použít pouze při krátkých letech a s jednorázovými kalhotami.
Pro novemente - zkus to znovu, zkus to víckrát, zkus to i jinak: https://www.youtube.com/watch?v=I7CeqmFiWYY (https://www.youtube.com/watch?v=I7CeqmFiWYY)