Už delší dobu mě nepřestávají udivovat různí vývojáři ve firmách (ne že by to v Devops byla nějaká sláva). Sám dělám DevOps, a u vývojářů v Javě mi občas přijde, že se divím, že dokážou zapnout počítač, od toho kdy si skoro nejsou schopni zprovoznit VPN, po to, že nevědí co je to výchozí brána, přes to, že nerozumí DNS a je zázrak když si dokáží nastavit hosts file jsem prostě celkově rozčarovaný, a prošel jsem si víc firmami, a fakt to vidím.
Obecný pohled na vývojáře jako na tichého génia mi přijde sci-fi. Jsem trošku i z pozice DevOps naštvaný, když vidím kolik mám zodpovědnosti, pohotovosti, nutnosti komunikace a obrovský rozhled a za de fakto stejné prachy, dřív i vývojáři brali víc, což si myslím, že se už konečně začalo obracet.
Navíc, když si dělám vlastní projekty, tak teď s AI vidím, že jsem na tom relativně skvěle, protože ten velký rozhled a nadhled mi dává schopnost u aplikací nastavit bezpečnost, deployment, architekturu vlastně de fakto líp než to umí vývojáři, a kód mi napíše Claude. Jediný důvod, proč jsem nikdy na vývojářskou pozici nepřešel byly pohovory, které byly nesmysl na entou, všichni píšou jednoduché CRUD byznys aplikace (nalijme si čistého vína) a na pohovorech se řeší algoritmus o log (n) a nesmrtelnost chrousta, s čímž se 99% vývojářů ve formuláři byznysové aplikace nepotkává, a kdyby náhodou jo, tak si to zrovna vygooglí či se doptaj.
Přiznám se, že jsem trošku nahlodanej, že u sousedovy zahrádky je tráva zelenější, a chybějící praxe ve vývoji mě začla s AI hodně nahlodávat, že vlastně do budoucna se stejně budou nastavovat jen AI agenti, a do kódu se za rok dva stejně nikdo nepodívá. Do toho mě fakt nahlodává ta zkušenost, co prostě fakt co jsem si prošel firmama vidím, že hodně těch vývojářů, že se divím že si dokážou sami zajít na záchod a nemaj dudlík, neříkám že každý ale obecný pocit z toho takový dost mám. A ano, samozřejmě dneska každej co dělá na supportu a radí lidem jak vyměnit toner v tiskárně si říká DevOps, samozřejmě to vidím taky.
Je to o úhlu pohledu. Když vývojáři svěříš jeho krabici, ve které buduje svůj projekt, tak se nemusí koukat na infrastrukturu. Vím jaký to byl pro mne problém, když jsem měl jako vývojář migrovat z GitHubu do začínajícího Azure. Bylo to peklo a tenkrát bych byl rád, pokud by to za mne vyřešil nějaký DevOps, protože jsem se kvůli těm klackům pod nohy (hlavně byl problém s cache) nemohl věnovat vývoji samotné aplikace.
Takže důležitý je nejen vývojář, ale i DevOps a je perfektní, když spolupracují.
To se tak brát fakt nedá. V každé profesi jsou fachidioti, lidé podprůměrní, průměrní i nadprůměrní nebo dokonce lidé, co umí na jakž takž použitelné úrovni obojí. DevOps bylo vždy méně a často to nejsou žádní tiší géniové ale jsou prostě divní. Čemuž se moc nedivím protože k tomu, aby z některých věcí v DevOps člověk nezešílel musí být divný. Vývojáři jsou zase něco mezi kopáči příkopů a umělci -- a až překvapivě často jinak dost primitivní lidé. Ale někoho prostě baví DevOps (takových je méně), někoho vývoj (takových je víc protože je to přece jenom víc tvůrčí práce). Jednoduché jak facka.
S těmi pohovory to tak jak píšete není. Jsou firmy, kde to tak skutečně je ale ty stačí poslat do háje a ignorovat; těch je jen dost malá menšina. A do kódu se nikdo pořádně nedivá už dnes. A natolik, nakolik se do něj dívá se do něj nejspíš bude dívat i v budoucnu.
Celkově je z toho, co jste vyjmenoval nejlepší jít sázet a kácet stromy v lese.
Kefalín, povedzte mi, čo si vy predstavujete pod takým slovom "vývojář"?
To je nejaka blbost ne? DevOps je prece o tom, ze mam devika a opsika v jednom tymu a jeden od druheho se uci a spolecne jsou zodpovedny za dodavku.
Takze pokud jak rikas "delas DevOps" pak gratuluju. Uz ses naucil od svyho vyvojare dost na to abys byl aspon z 50% vyvojar.
Pokud ovsem delas jenom operations(infrastrukturu, platformu), ale mas to zautomatizovany tak si porad jen operations. To dev si zaslouzis az tim, ze si cuchnes k businessu.
Jo a mimochodem. Z "druhe strany" to vypada uplne stejne. Si nainstaluju AWZ/AZ cli a agenti vysivaji...
jenže devops je prostě takový školník/opravář, bez něj to nefunguje, ale nepřináší velkou přidanou hodnotu (když je dobrý, tak věci fungují plynule). Naopak vývojář právě primárně dělá ty věci, co jdou vidět, dává přidanou hodnotu.
Devops je nevděčná pozice. Když aplikace je rychlá a stabilní, je to zásluhou geniálního vývojáře, když nefunguje, může za to neschopný devops, který není schopný vyřešit saturovanou databázi, když jí aplikace šikanuje.
Sice si můžeš myslet, že jako devops máš těch zvířátek strašně moc, ale u vývojářů to je ještě horší, zejména, pokud přechází mezi projekty nebo firmami, mění se toho strašně moc a pořád něco dělají znovu nebo se musejí lameři v tunách cizího "špatného" kódu.
Devops oddělení, počty pozic a agenda je relativně stabilní proti tomu co vidím u vývojářů, tam se to mění snad na týdenní bázi a pořád někde plaveš. Přibývají a mizí celé týmy jak nic. Na tohle bych se spíše zaměřil, pokud si najdeš jako vývojář stabilní tým a dlouhodobý projekt, bude ti hej.
Za mě nejlepší vývojáři jsou právě ty, kteří přešli z devops, protože aspoň tuší jak věci fungují.
Citace od: Exceptions kdy 20. 10. 2026, 09:26:46
jenže devops je prostě takový školník/opravář, bez něj to nefunguje, ale nepřináší velkou přidanou hodnotu (když je dobrý, tak věci fungují plynule). Naopak vývojář právě primárně dělá ty věci, co jdou vidět, dává přidanou hodnotu.
Devops je nevděčná pozice. Když aplikace je rychlá a stabilní, je to zásluhou geniálního vývojáře, když nefunguje, může za to neschopný devops, který není schopný vyřešit saturovanou databázi, když jí aplikace šikanuje.
Přijde mi to přesně tak, že DevOps je náročnější a ve výsledku víc nevděčná práce, i jak to píšeš, že to nepřináší přidanou hodnotu, to bych neřekl, spíš to není tak vidět, když dojdeš do obchodu na kasu a nezaplatíš protože nejede systém, hned si tu přidanou hodnotu uvědomíš, ale když to jede, tak je to neviditelné.
U těch feature, kort v dnešní době AI, sám to vidím když si něco pro sebe vyvíjím, je to otázka 2 vět přidat feature. Zas osobně v dnešní době AI nechápu, kde přidává tu hodnotu vývojář.
Citace od: Exceptions kdy 20. 10. 2026, 09:26:46
Devops oddělení, počty pozic a agenda je relativně stabilní proti tomu co vidím u vývojářů, tam se to mění snad na týdenní bázi a pořád někde plaveš. Přibývají a mizí celé týmy jak nic. Na tohle bych se spíše zaměřil, pokud si najdeš jako vývojář stabilní tým a dlouhodobý projekt, bude ti hej.
Za mě nejlepší vývojáři jsou právě ty, kteří přešli z devops, protože aspoň tuší jak věci fungují.
To je dané politkou firmy. Developeri sú pre firmu záťaž, keď nie je projekt.
Devops developeri s nimi mám opačné skúsenosti, často veľké ego, ale vhľad malý. Vedia robiť so všetkými tými orchestráciami, ale vývoj robia na úrovni juniorov. Juniori sa ale aspoň nechajú poučiť.
Ano, u devops jde vidět přidaná hodnota jen, když se řeší nefunkčnost, jenže nefunkčnost je buď věcí náhody nebo neschopnosti. Málokdo oceňuje funkční systém jako přidanou hodnotu, ale bere to jako standard, bohužel.
Vlastní vývojáře nemáš od toho, že potřebuješ udělat jednorázovou aplikaci, ale že jí potřebuješ udržovat roky. Tam AI dnes také pomáhá, ale vývoj aplikací přes AI jde spíše proti dlouhodobému provozu a údržbě. Velmi rychle se to začne lámat a náklady zvyšovat.
balkovic: no, samozřejmě toho devops musíš naučit nějak rozumně programovat, ale to, že aspoň tuší, že linux na na fs fsync, že thread není zadarmo a python má GIL a java GC je daleko přínosnější, než že zná různé paradigma a patterny z hlavy.
Citace od: Exceptions kdy 20. 10. 2026, 12:00:21
balkovic: no, samozřejmě toho devops musíš naučit nějak rozumně programovat, ale to, že aspoň tuší, že linux na na fs fsync, že thread není zadarmo a python má GIL a java GC je daleko přínosnější, než že zná různé paradigma a patterny z hlavy.
Developer to ovláda taktiež, mňa sa šéfovci často pýtajú až na úroveň procesora, pritom to nie je to, čo som študoval. Nejaké "neviem ako to funguje" si nemôžem dovoliť. Paradigmy a patterny sú dôležité, lebo inak vzniknú strašné špagety a nikto sa potom nechce dotknúť kódu ani metrovou palicou. Dáš devops spraviť biznis analýzu, doménový model, alebo plán testovania, tak ti vynadá, že malovánky kresliť nebude.
Citace od: greenlinuxguru kdy 20. 10. 2026, 09:48:02
U těch feature, kort v dnešní době AI, sám to vidím když si něco pro sebe vyvíjím, je to otázka 2 vět přidat feature. Zas osobně v dnešní době AI nechápu, kde přidává tu hodnotu vývojář.
Určitě by se spoustě lidem líbilo, kdyby ta AI fungovala úplně sama jenomže to tak fakt není. U nějakého greenfield vývoje ještě jakž takž ale jakmile dojde na maintenance, potřebujete někoho, kdo říka co, jak, co je správně a co není. Včetně implementací nových features v existující codebase. Nemluvě o tom, že tak čtvrtinu práce dnešního vývojáře tvoří krotit a vytvářet harness, ne ten vývoj sám o sobě. Ani to se samo fakt neudělá. Pokud to má celé fungovat efektivně, opravdu to není o tom napsat prompt a jít vypít další kafe.
musis jit za svym sefem. tady tvuj problem (chces vic penez) nevyresime. tak jednoduchy to je
Citace od: greenlinuxguru kdy 19. 10. 2026, 19:35:05
Už delší dobu mě nepřestávají udivovat různí vývojáři ve firmách (ne že by to v Devops byla nějaká sláva). Sám dělám DevOps, a u vývojářů v Javě mi občas přijde, že se divím, že dokážou zapnout počítač, od toho kdy si skoro nejsou schopni zprovoznit VPN, po to, že nevědí co je to výchozí brána, přes to, že nerozumí DNS a je zázrak když si dokáží nastavit hosts file jsem prostě celkově rozčarovaný, a prošel jsem si víc firmami, a fakt to vidím.
Obecný pohled na vývojáře jako na tichého génia mi přijde sci-fi. Jsem trošku i z pozice DevOps naštvaný, když vidím kolik mám zodpovědnosti, pohotovosti, nutnosti komunikace a obrovský rozhled a za de fakto stejné prachy, dřív i vývojáři brali víc, což si myslím, že se už konečně začalo obracet.
Navíc, když si dělám vlastní projekty, tak teď s AI vidím, že jsem na tom relativně skvěle, protože ten velký rozhled a nadhled mi dává schopnost u aplikací nastavit bezpečnost, deployment, architekturu vlastně de fakto líp než to umí vývojáři, a kód mi napíše Claude. Jediný důvod, proč jsem nikdy na vývojářskou pozici nepřešel byly pohovory, které byly nesmysl na entou, všichni píšou jednoduché CRUD byznys aplikace (nalijme si čistého vína) a na pohovorech se řeší algoritmus o log (n) a nesmrtelnost chrousta, s čímž se 99% vývojářů ve formuláři byznysové aplikace nepotkává, a kdyby náhodou jo, tak si to zrovna vygooglí či se doptaj.
Přiznám se, že jsem trošku nahlodanej, že u sousedovy zahrádky je tráva zelenější, a chybějící praxe ve vývoji mě začla s AI hodně nahlodávat, že vlastně do budoucna se stejně budou nastavovat jen AI agenti, a do kódu se za rok dva stejně nikdo nepodívá. Do toho mě fakt nahlodává ta zkušenost, co prostě fakt co jsem si prošel firmama vidím, že hodně těch vývojářů, že se divím že si dokážou sami zajít na záchod a nemaj dudlík, neříkám že každý ale obecný pocit z toho takový dost mám. A ano, samozřejmě dneska každej co dělá na supportu a radí lidem jak vyměnit toner v tiskárně si říká DevOps, samozřejmě to vidím taky.
1. Pozor, to ze skvele rozumis devops, jeste neznamena, ze bys byl schopen implementovat slozitou business logiku. Developer musi taky byt schopny reagovat na nejasne pozadavky, lepsi vytvaret architekturu a spoustu dalsi veci...
2. Jsi schopny pracovat v tymu?
3. Jake svoje projekty vyvijis?
4. Fakt u nas CRUD nevyvijime a pokud, tak je to asi 0.01% kodu. Zbytek jsou obcas hardcore algoritmy. Budes schopny se naucit slozitou domenu?
Citace od: Exceptions kdy 20. 10. 2026, 12:00:21
... než že zná různé paradigma a patterny z hlavy.
No zrovna znalost patternů z hlavy je důležitá. Patterny jsou často se opakující boilerplate kód. Není to žádná business logika, nic co ta aplikace "dělá" z pohledu užívání. Je to nutné zlo, které je potřeba aby se ty zajímavé části daly poskládat dohromady.
A u téhle nezajímavé vaty chcete, aby vývojář koukl, viděl a a dál o tom nemusel přemýšlet a nijak to řešit.
Dle popisu DevOps neděláš. DevOps je ideologie, která dává důraz na boření sil, observabilitu a automatizaci. Pokud by náhodou někde vznikl DevOps tým, tak jeho jediným cílem je poskytnout nástroje které tu ideologii umožní implementovat, zaškolit a předat vývoji a S(R)E a následně zaniknout, rozhodně za nic nemá držet pohotovost :D. To co popisuješ je klasický "marketing" firem, který hledají adminy pro dev a nazvou to DevOps, protože to zní víc kůl.
Dokážu si představit že to co si ty myslíš o java vývojářích si myslí oni o tobě... Píšou si ten kód kterýmu rozmí a infrastrukturu jim napíše Claude. Tím pádem původní nadpis můžes upravit "Claude nebo Claude, co je lepší?"
Ještě bych si dovolil reagovat na
> Devops je nevděčná pozice. Když aplikace je rychlá a stabilní, je to zásluhou geniálního vývojáře, když nefunguje, může za to neschopný devops, který není schopný vyřešit saturovanou databázi, když jí aplikace šikanuje.
Pokud už teda vznikl DevOps tým za účelem implementace DevOps, tak řešení saturované databáze rozhodně není jeho práce... Databázi si provzují a "vlastní" admini/se/sre/whatever, to co se do ní posílá za dotazy je zase věc vývoje. DevOps tam figuruje jen v tom, že obě dotčené strany mají nástroje, které umožní vizualizaci, jednoduchý debug a proces, který vede k rychlému dostání fixu do provozu.
Citace od: greenlinuxguru kdy 19. 10. 2026, 19:35:05
Navíc, když si dělám vlastní projekty, tak teď s AI vidím, že jsem na tom relativně skvěle, protože ten velký rozhled a nadhled mi dává schopnost u aplikací nastavit bezpečnost, deployment, architekturu vlastně de fakto líp než to umí vývojáři, a kód mi napíše Claude.
No a právě protože nejsi vývojář, tak nedokážeš poznat, jestli ti to Claude napsal dobře nebo ne. To, že to funguje, fakt nestačí.
Situace na foru je opravdu kriticka, že se nenašel jediný člověk, který by zakladeteli vlákna vysvětlil, že kdyby každý vývojář věděl, jak nastavovat host files atd., tak ten daný daný Devops je bez práce. Buď rád, že to nejen neví, ale i se to nenaučí, protože potom máš alespoň ty co dělat. Pokud máš IQ alespoň 100, tak jistě dokážeš pochopit, že tě nikdo sedět na zadeki a nic v práci nedělal nenechá.
Vzhledem k tomu, že to zakladatel tématu neví, je dost možné, že je v nějaké žumpě, kde jsou podobně neschopní vývojáři, jako on je neschopný devopsák.
To je jako kdyby byl někdo strojní inženýr specialista na vývoj motorů, a nějaký automechanik s vysokou školou života by si klepal na čelo, co jsou ti inženýři za blbce, když ani neví, jak používat zouvačku na pneu. Přitom vývojář motorů může tak akorát kašlat na nějakou pitomou zouvačku, kterou zvládne obsluhovat hotentot s vystudovanou základkou.
Btw, pokud něco pokazí vývojář, a přetíží to v produkci databázi, tak je samozřejmě vždy vina na tom vývojáři, pokud devops něco nepokazil. Jestli v tom týmu toto není jasně dané, tak jsi v blbém týmu, který je vedený nějakými pitomci v případě, že jim nedochází, a šmejdy v případě, že jim to dochází (a dělají ti to tím pádem schválně).
Citace od: Jiří Havel kdy 20. 10. 2026, 15:30:36
Citace od: Exceptions kdy 20. 10. 2026, 12:00:21
... než že zná různé paradigma a patterny z hlavy.
No zrovna znalost patternů z hlavy je důležitá. Patterny jsou často se opakující boilerplate kód. Není to žádná business logika, nic co ta aplikace "dělá" z pohledu užívání. Je to nutné zlo, které je potřeba aby se ty zajímavé části daly poskládat dohromady.
A u téhle nezajímavé vaty chcete, aby vývojář koukl, viděl a a dál o tom nemusel přemýšlet a nijak to řešit.
Já to nechtěl zbytečně více rozepisovat, ale patterny nemusí být jen třeba decorator, adapter, composite, singleton, ale třeba i to jak správně pracovat s proměnnými, kde je cena a desetinná čárka, ják psát konkurenční, paralelní nebo asynchronní kód atd.
Citace od: registrovany123 kdy 20. 10. 2026, 22:18:38
Btw, pokud něco pokazí vývojář, a přetíží to v produkci databázi, tak je samozřejmě vždy vina na tom vývojáři, pokud devops něco nepokazil. Jestli v tom týmu toto není jasně dané, tak jsi v blbém týmu, který je vedený nějakými pitomci v případě, že jim nedochází, a šmejdy v případě, že jim to dochází (a dělají ti to tím pádem schválně).
v realitě to je ale deleko komplexnější, z venku totiž jen tak nevidíš, jestli vývojář dělá 3 sql dotazy na stránku nebo 10, jestli si znovu načítá věci vícekrát nebo prostě je špička, protože děti mají prázdniny atd. Nebo klasická chyba, retry, který při delších problémech či špatném použití ti znásobí tok dat. Na tohle už musíš udělat analýzu, ale viník se zpravidla označuje v podstatě v prvních minutách problému a ne až po dnech zkoumání. To už se spíše dělá nějaké nápravné opatření nebo limity a jak to tak bývá, to implementuje svědomitě devops a pokud vznikl problém, devops musel na něj vynaložit čas, aby se už příště nestal a vývojář nemusel nic změnit hned, protože opravu udělá při další implementaci, je každému výš velmi rychle "jasné", že problém byl u devops, že jo.
Citace od: Exceptions kdy 21. 10. 2026, 00:25:56
Citace od: Jiří Havel kdy 20. 10. 2026, 15:30:36
Citace od: Exceptions kdy 20. 10. 2026, 12:00:21
... než že zná různé paradigma a patterny z hlavy.
No zrovna znalost patternů z hlavy je důležitá. Patterny jsou často se opakující boilerplate kód. Není to žádná business logika, nic co ta aplikace "dělá" z pohledu užívání. Je to nutné zlo, které je potřeba aby se ty zajímavé části daly poskládat dohromady.
A u téhle nezajímavé vaty chcete, aby vývojář koukl, viděl a a dál o tom nemusel přemýšlet a nijak to řešit.
Já to nechtěl zbytečně více rozepisovat, ale patterny nemusí být jen třeba decorator, adapter, composite, singleton, ale třeba i to jak správně pracovat s proměnnými, kde je cena a desetinná čárka, ják psát konkurenční, paralelní nebo asynchronní kód atd.
To máte poněkud vlastní definici slova pattern. Mícháte jabka s hruškama.
Citace od: balkovic kdy 21. 10. 2026, 04:23:03
To máte poněkud vlastní definici slova pattern. Mícháte jabka s hruškama.
A kde je ustálená definice? Můžeš odkázat? :)
Pattern je v překladu vzor a znamená způsob/princip jak v kódu řešit opakující se problém/postup, tuhle definici najdeš ve spoustě vysokoškolských skript už desítky let. Já záměrně nezmínil třeba sousloví design patterns, který asi myslíš ty.
Zralý programátor má právě v hlavě spousty šablon, principů, vzorů jak řešit ten a ten problém v daném jazyce nebo prostředí. To získáš buď neúnavným biflováním, čtením cizích kódů nebo programováním různých věcí. V tom se ukazuje praxe a zkušenost.
Klasický problém, který opakovaně zažívám je třeba počítání s finančními hodnotami, v sql to definuje rozdíl mezi double a decimal, v javě to je double a bigDecimal. Při výpočtu trasy taxikáře použiji double, při výpočtu ceny za jízdu bigDecimal. Bys ani nevěřil, kolik programátorů v tom je schopné udělat chybu a při velkém objemu udělat opravdu velký problém. A nejen programátoři, tohle se nám znovu dostává do popředí kvůli AI, dělá úplně stejné chyby, řeší kód a ne kontext kolem něho a klidně na vytěžování faktur použije double.
Citace od: balkovic kdy 21. 10. 2026, 04:23:03
Citace od: Exceptions kdy 21. 10. 2026, 00:25:56
Já to nechtěl zbytečně více rozepisovat, ale patterny nemusí být jen třeba decorator, adapter, composite, singleton, ale třeba i to jak správně pracovat s proměnnými, kde je cena a desetinná čárka, ják psát konkurenční, paralelní nebo asynchronní kód atd.
To máte poněkud vlastní definici slova pattern. Mícháte jabka s hruškama.
To jeho je obecný význam a je naprosto v pořádku, Že ho někdo později vzal a udělal z toho škatulky je druhá věc.
Ostatně celá tahle patternová ideologie byl taky strašný úlet. Na otázky na patterny u pohovorů jsem vždycky odpovídal, že slušný vývojář patterny používá a zná přirozeně a opravdu běžně nepotřebuje vědět, že tomuhle někdo přiřadil zrovna tenhle název a onomu tamten název. A vždycky to prošlo protože je to koneckonců pravda.
Citace od: Martin Poljak kdy 21. 10. 2026, 10:05:23
Citace od: balkovic kdy 21. 10. 2026, 04:23:03
Citace od: Exceptions kdy 21. 10. 2026, 00:25:56
Já to nechtěl zbytečně více rozepisovat, ale patterny nemusí být jen třeba decorator, adapter, composite, singleton, ale třeba i to jak správně pracovat s proměnnými, kde je cena a desetinná čárka, ják psát konkurenční, paralelní nebo asynchronní kód atd.
To máte poněkud vlastní definici slova pattern. Mícháte jabka s hruškama.
To jeho je obecný význam a je naprosto v pořádku, Že ho někdo později vzal a udělal z toho škatulky je druhá věc.
Ostatně celá tahle patternová ideologie byl taky strašný úlet. Na otázky na patterny u pohovorů jsem vždycky odpovídal, že slušný vývojář patterny používá a zná přirozeně a opravdu běžně nepotřebuje vědět, že tomuhle někdo přiřadil zrovna tenhle název a onomu tamten název. A vždycky to prošlo protože je to koneckonců pravda.
Není to úlet, je to dobrá věc. Jima Copliena, co zaváděl architektonické vzory Christophera Alexandra od IT osobně poznám, řekněme že je to byl můj známý. ( Celkem tak ne, ale víte jak to myslím. Pár krát jsme se viděli, na pivo spolu nechodíme, možná už neví, jak se jmenuju, LOL ) Každá blbost nebo best practice není vzor. Vzor by mal obstát zkouškou časem. Vzor je vysokoúrovňový jazyk, když neumíš jazyk, tak ti nikdo nerozumí.
Jako když řeknu o kedlubnu, že je to parní stroj. No je to blbost, stejně jako ledabylé používání slova pattern.
Citace od: Exceptions kdy 21. 10. 2026, 09:24:46
Citace od: balkovic kdy 21. 10. 2026, 04:23:03
To máte poněkud vlastní definici slova pattern. Mícháte jabka s hruškama.
A kde je ustálená definice? Můžeš odkázat? :)
Pattern je v překladu vzor a znamená způsob/princip jak v kódu řešit opakující se problém/postup, tuhle definici najdeš ve spoustě vysokoškolských skript už desítky let. Já záměrně nezmínil třeba sousloví design patterns, který asi myslíš ty.
Zralý programátor má právě v hlavě spousty šablon, principů, vzorů jak řešit ten a ten problém v daném jazyce nebo prostředí. To získáš buď neúnavným biflováním, čtením cizích kódů nebo programováním různých věcí. V tom se ukazuje praxe a zkušenost.
Klasický problém, který opakovaně zažívám je třeba počítání s finančními hodnotami, v sql to definuje rozdíl mezi double a decimal, v javě to je double a bigDecimal. Při výpočtu trasy taxikáře použiji double, při výpočtu ceny za jízdu bigDecimal. Bys ani nevěřil, kolik programátorů v tom je schopné udělat chybu a při velkém objemu udělat opravdu velký problém. A nejen programátoři, tohle se nám znovu dostává do popředí kvůli AI, dělá úplně stejné chyby, řeší kód a ne kontext kolem něho a klidně na vytěžování faktur použije double.
https://en.wikipedia.org/wiki/The_Timeless_Way_of_Building
https://en.wikipedia.org/wiki/A_Pattern_Language
https://christopher-alexander-ces-archive.org/wp-content/uploads/2025/04/DOC.20250425.32751.1996.VI_.K6.1.pdf
https://www.goodreads.com/book/show/79767.Pattern_Languages_of_Program_Design
Citace od: balkovic kdy 21. 10. 2026, 17:47:17
Citace od: Martin Poljak kdy 21. 10. 2026, 10:05:23
Ostatně celá tahle patternová ideologie byl taky strašný úlet. Na otázky na patterny u pohovorů jsem vždycky odpovídal, že slušný vývojář patterny používá a zná přirozeně a opravdu běžně nepotřebuje vědět, že tomuhle někdo přiřadil zrovna tenhle název a onomu tamten název. A vždycky to prošlo protože je to koneckonců pravda.
Není to úlet, je to dobrá věc. [...] Vzor je vysokoúrovňový jazyk, když neumíš jazyk, tak ti nikdo nerozumí.
Úlet je to, co se z toho posléze stalo, kdy vás u pohovorů doslova nutili ty patterns vyjmenovávat jako kdyby to samo o sobě k něčemu bylo. Byl to v té době také takový hype. Nikoliv původní myšlenka; ta je v pořádku. Naštěstí je to už dlouho pryč.
Citace od: balkovic kdy 21. 10. 2026, 17:47:17
Jako když řeknu o kedlubnu, že je to parní stroj. No je to blbost, stejně jako ledabylé používání slova pattern.
Vy si tak nějak neuvědomujete, že slovo "pattern" je mnohem starší než Jim Coplien natož cokoliv co napsal. To, že vy ho nějak užíváte ještě opravdu neznamená, že jeho obecnější význam přestal existovat.
Citace od: Martin Poljak kdy 21. 10. 2026, 18:18:58
Citace od: balkovic kdy 21. 10. 2026, 17:47:17
Citace od: Martin Poljak kdy 21. 10. 2026, 10:05:23
Ostatně celá tahle patternová ideologie byl taky strašný úlet. Na otázky na patterny u pohovorů jsem vždycky odpovídal, že slušný vývojář patterny používá a zná přirozeně a opravdu běžně nepotřebuje vědět, že tomuhle někdo přiřadil zrovna tenhle název a onomu tamten název. A vždycky to prošlo protože je to koneckonců pravda.
Není to úlet, je to dobrá věc. [...] Vzor je vysokoúrovňový jazyk, když neumíš jazyk, tak ti nikdo nerozumí.
Úlet je to, co se z toho posléze stalo, kdy vás u pohovorů doslova nutili ty patterns vyjmenovávat jako kdyby to samo o sobě k něčemu bylo. Byl to v té době také takový hype. Nikoliv původní myšlenka; ta je v pořádku. Naštěstí je to už dlouho pryč.
To můžu jenom souhlasit, o vzorech by se mělo přemýšlet a učit se používaním, ne se je memorovat. Některé vzory už stratili smysl, tudíž nejsou vzory.
Citace od: Martin Poljak kdy 21. 10. 2026, 18:18:58
Citace od: balkovic kdy 21. 10. 2026, 17:47:17
Jako když řeknu o kedlubnu, že je to parní stroj. No je to blbost, stejně jako ledabylé používání slova pattern.
Vy si tak nějak neuvědomujete, že slovo "pattern" je mnohem starší než Jim Coplien natož cokoliv co napsal. To, že vy ho nějak užíváte ještě opravdu neznamená, že jeho obecnější význam přestal existovat.
U slov rozhoduje také kontext, pattern může být také kravičkový vzor na pyžamu, nebo vlny na vodě, ale v kontextu developmentu to má význam jasný.
Když to použijete ledabyle, tak prostě vám lidé nerozumí. Dotyčný může akorát tak hádat, co myslíte. Formátování čísel není pattern, možno tak nejvíc idiom, nebo best practice.
Citace od: Exceptions kdy 21. 10. 2026, 00:25:56Na tohle už musíš udělat analýzu, ale viník se zpravidla označuje v podstatě v prvních minutách problému a ne až po dnech zkoumání. To už se spíše dělá nějaké nápravné opatření nebo limity a jak to tak bývá, to implementuje svědomitě devops a pokud vznikl problém, devops musel na něj vynaložit čas, aby se už příště nestal a vývojář nemusel nic změnit hned, protože opravu udělá při další implementaci, je každému výš velmi rychle "jasné", že problém byl u devops, že jo.
:o Já bych teda řekl, že v prvních minutách se nehledá viník, ale SRE otvírají se příručky s krizovými kuchařkami. V prvních desítkách minut se shání lidi, co o problému ví něco víc, čili vývojáři, co s tím mají aspoň vzdáleně něco společného, hledá se příčina a bezpečné dočasné řešení pokud nestačilo jít podle krizové kuchařky. No a pokud se nějaké dočasné řešení našlo, tak to možná znamená dočasnou práci navíc pro SRE nebo Ops (třeba několikrát za den ty servery preventivně restartovat), a začíná práce vývojářů. Ale velmi pravděpodobně se to absolutně netýká DevOps, pokud zrovna nejde o problém s interní instancí Jiry nebo BitBucketu.
No a pak v řádu dnů/týdnů se teprv začne řešit, co se stalo, proč se to stalo, kde selhal nějaký proces, a tak dál, aby se to pokud možno už nemohlo znovu stát bez ohledu na chyby nějakého jednotlivce. Jestli pracujete někde, kde se někde v tomhle akorát plýtvá čas na hledání viníka a jeho veřejné lynčování, tak je mi to líto.