Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Robert 06. 05. 2017, 10:00:07
-
Muze se clovek naucit slusne vyvijet software (schvalne pisu vyvijet software a ne jen programovat) v Jave, kdyz nema nikoho kdo jej muze mentorovat? (at uz v praci nebo ve skole). Prohrabovat se tunami blogu - ktere beztak pisou indove o svych prasarnach nebude zrejme 2x efektivni. Nejake knihy se ucite vzdycky daji najit nicmene ty budou zrejme rychle zastarale.
-
Dobré knihy kupodivu nezastarávají tak rychle, jak by se mohlo zdát.
-
Muze se clovek naucit slusne vyvijet software (schvalne pisu vyvijet software a ne jen programovat) v Jave, kdyz nema nikoho kdo jej muze mentorovat? (at uz v praci nebo ve skole). Prohrabovat se tunami blogu - ktere beztak pisou indove o svych prasarnach nebude zrejme 2x efektivni. Nejake knihy se ucite vzdycky daji najit nicmene ty budou zrejme rychle zastarale.
Nemůže.
-
Chapu to tedy spravne ze jediny mozny zpusob je, jit delat do takove firmy, ktera ma schopne vyvojare a od nich se ucit?
-
Neposlouchej průměrné lidi jako zboj. Samozřejmě může. Pokud ale potřebuješ mentora, je to trochu problém. Takže je to hlavně o tobě.
Firma se schopnými vývojáři u nás asi ani není, tak bych si moc nedělal naděje.
-
Chapu to tedy spravne ze jediny mozny zpusob je, jit delat do takove firmy, ktera ma schopne vyvojare a od nich se ucit?
Asi ne jediný, jen nejspolehlivější. Začít dobrou školou (nebo ještě raději olympiádami a semináři na SŠ) a pak dělat tam, kde jsou schopní lidé. Schopní nejen prgat ale i předat zkušenost dál.
-
Co to kecáš, jaké tuny blogů které "beztak píšou Indové o svých prasárnách"? Jaké knihy které budou rychle zastaralé? Člověče ty seš úplně mimo, jestli máš práci, tak buď rád, že ji vůbec máš, si myslíš, že tě nekdo někde bude chtít tahat za ručičku, nebo co? Co máš za školu, že seš tak mimo, ty asi nebudeš z IT. Buď rád že jsi rád.
-
Chapu to tedy spravne ze jediny mozny zpusob je, jit delat do takove firmy, ktera ma schopne vyvojare a od nich se ucit?
Nejlepší je škola, kvalitní školení, případně konference, workshopy... Chytří kolegové ve firmě jsou samozřejmě taky plus a mohou mnohému naučit, pokud sami chtějí.
-
K tomu, abyste se učil slušně vyvíjet software, potřebujete především hodně vyvíjet software a umět se poučit ze svých i cizích chyb. Všechno ostatní (škola, knížky, mentoři, články) vám může pomoci, ale vlastní zkušenost to nenahradí.
-
K tomu, abyste se učil slušně vyvíjet software, potřebujete především hodně vyvíjet software a umět se poučit ze svých i cizích chyb. Všechno ostatní (škola, knížky, mentoři, články) vám může pomoci, ale vlastní zkušenost to nenahradí.
+1
-
K tomu, abyste se učil slušně vyvíjet software, potřebujete především hodně vyvíjet software a umět se poučit ze svých i cizích chyb. Všechno ostatní (škola, knížky, mentoři, články) vám může pomoci, ale vlastní zkušenost to nenahradí.
Presne tohle jsem si celou dobu myslel. Dekuji :-) myslim ze jste mi zachranil zivot :-)
-
K tomu, abyste se učil slušně vyvíjet software, potřebujete především hodně vyvíjet software a umět se poučit ze svých i cizích chyb. Všechno ostatní (škola, knížky, mentoři, články) vám může pomoci, ale vlastní zkušenost to nenahradí.
Presne tohle jsem si celou dobu myslel. Dekuji :-) myslim ze jste mi zachranil zivot :-)
Nicméně, konzultace s (místní) javalopatou javamanem tě rozhodně dostanou na netušený level.
Ty jsou prostě nenahraditelné...
-
K tomu, abyste se učil slušně vyvíjet software, potřebujete především hodně vyvíjet software a umět se poučit ze svých i cizích chyb. Všechno ostatní (škola, knížky, mentoři, články) vám může pomoci, ale vlastní zkušenost to nenahradí.
Presne tohle jsem si celou dobu myslel. Dekuji :-) myslim ze jste mi zachranil zivot :-)
Nicméně, konzultace s (místní) javalopatou javamanem tě rozhodně dostanou na netušený level.
Ty jsou prostě nenahraditelné...
Javaman podle všeho právě nemůže být běžná lopata jako třeba já (pod sto tisíc by nevstal z postele apod.), tak pochybuji, že bude ztrácet čas s nějakou budoucí lopatou (s autorem dotazu). Každopádně souhlasím, že úplně nejlepší je zeptat se na Javu zde na rootu a nechat si poradit od opravdových odborníků odkojených mnohem kvalitnějšími jazyky, a tudíž i většími a lepšími znalci Javy než samotní javovští specialisté ;-)
-
Muze se clovek naucit slusne vyvijet software (schvalne pisu vyvijet software a ne jen programovat) v Jave, kdyz nema nikoho kdo jej muze mentorovat? (at uz v praci nebo ve skole). Prohrabovat se tunami blogu - ktere beztak pisou indove o svych prasarnach nebude zrejme 2x efektivni. Nejake knihy se ucite vzdycky daji najit nicmene ty budou zrejme rychle zastarale.
Z vlastnej skusenosti viem, ze dobry mentor je na nezaplatenie. Oplati sa mentora vyhladat, najcastejsia prilezitost je na skole.
Co sa tyka knih, ucil som sa z Handbuch der Java-Programmierung, tu je aktualizovana verzia pre JSE7, cize pouzitelne:
https://www.amazon.de/Handbuch-Java-Programmierung-HTML-Version-Standard-Programmers/dp/3827327512/ref=sr_1_1?s=books&ie=UTF8&qid=1494105625&sr=1-1&keywords=Handbuch+der+Java-Programmierung
A z knihy Thinking in java. (Ta je trochu starsia, ale na zakldy dobre)
http://www.mindview.net/Books/TIJ4/
-
Ne, nemůže. Důvod je velmi prostý. "Slušně vyvíjet" znamená, že se to libí mentorovi. Bez mentora se to nemá komu líbit. Mentor má svůj styl formátování zdrojového textu, svůj oblíbený framework, svůj způsob testování atd. Pokud jde o optimalizace, pro někoho je slušný vývojař, ten kdo použije vždy algoritmus s nejnižší asymptotickou složitostí a nepoužívá "kanón na vrabce". Opačný extrém je všechno tlačit přes frameworky, konfigurační xml soubory a databáze.
-
Po žních jdi k Turkovi, teda k javamanovi.
-
Tohle není omezeno jen na Javu.
Být otevřený všemu, ale vše podrobovat kritice. Hodně psát (kód), hodně číst, hodně studovat referenční implementace, snažit se zapojit do virtuálního týmu. Nebát se codereview. Kvalitní mentor vše výrazně zrychlí, ale kde ho sebrat, že?
-
K tomu, abyste se učil slušně vyvíjet software, potřebujete především hodně vyvíjet software a umět se poučit ze svých i cizích chyb. Všechno ostatní (škola, knížky, mentoři, články) vám může pomoci, ale vlastní zkušenost to nenahradí.
Presne tohle jsem si celou dobu myslel. Dekuji :-) myslim ze jste mi zachranil zivot :-)
Nicméně, konzultace s (místní) javalopatou javamanem tě rozhodně dostanou na netušený level.
Ty jsou prostě nenahraditelné...
Nemůžeš vyhrát hádku s blbcem. Nejdřív tě stáhne na svojí úroveň, a potom utluče zkušenostmi ;D
-
Tohle není omezeno jen na Javu.
Být otevřený všemu, ale vše podrobovat kritice. Hodně psát (kód), hodně číst, hodně studovat referenční implementace, snažit se zapojit do virtuálního týmu. Nebát se codereview. Kvalitní mentor vše výrazně zrychlí, ale kde ho sebrat, že?
Mentor za úplatu, to by mohla být dobrá on-line služba ;D
-
K tomu, abyste se učil slušně vyvíjet software, potřebujete především hodně vyvíjet software a umět se poučit ze svých i cizích chyb. Všechno ostatní (škola, knížky, mentoři, články) vám může pomoci, ale vlastní zkušenost to nenahradí.
Jsou lidi co vyviji roky a porad stejne spatne. Ucit se z vlastnich chyb je pomale.
Kdysi jsem dostal tuhle radu: "Cist zdrojaky, cist zdrojaky, cist zdrojaky, cist prumyslove standarty".
-
K tomu, abyste se učil slušně vyvíjet software, potřebujete především hodně vyvíjet software a umět se poučit ze svých i cizích chyb. Všechno ostatní (škola, knížky, mentoři, články) vám může pomoci, ale vlastní zkušenost to nenahradí.
Jsou lidi co vyviji roky a porad stejne spatne. Ucit se z vlastnich chyb je pomale.
Kdysi jsem dostal tuhle radu: "Cist zdrojaky, cist zdrojaky, cist zdrojaky, cist prumyslove standarty".
Co z těch vlajek vyčteš? :)
-
K tomu, abyste se učil slušně vyvíjet software, potřebujete především hodně vyvíjet software a umět se poučit ze svých i cizích chyb. Všechno ostatní (škola, knížky, mentoři, články) vám může pomoci, ale vlastní zkušenost to nenahradí.
Jsou lidi co vyviji roky a porad stejne spatne. Ucit se z vlastnich chyb je pomale.
Kdysi jsem dostal tuhle radu: "Cist zdrojaky, cist zdrojaky, cist zdrojaky, cist prumyslove standarty".
Asi je to dobre na odkukanie niektorych veci. Ale lepsie je informovane citanie zdrojakov. Ze si precitas zdrojaky ale aj nieco popri a vies obcas identifikovat, kedy nieco vyriesili nie zrovna najlepsie. Alebo ak tam naopak pouzili nejaku vychytavku a kod vyzera trosku "WTF". Aj v priemyslovych standardoch sa prasi z roznych dovodov.
-
Proč v zrovna v Javě a ne C#?
-
Proč v zrovna v Javě a ne C#?
Dotaz je položen dost obecně. Klidně si místo Javy dosaď C#, Python nebo PHP a vyjde to nastejno.
-
Nejake knihy se ucite vzdycky daji najit nicmene ty budou zrejme rychle zastarale.
Nebudú, napr. tieto knihy boli, sú a budú aktuálne veľmi dlho:
- Design Patterns: Elements of Reusable Object-Oriented Software
- Clean Code: A Handbook of Agile Software Craftsmanship
- Effective Java
-
Nejake knihy se ucite vzdycky daji najit nicmene ty budou zrejme rychle zastarale.
Nebudú, napr. tieto knihy boli, sú a budú aktuálne veľmi dlho:
- Design Patterns: Elements of Reusable Object-Oriented Software
- Clean Code: A Handbook of Agile Software Craftsmanship
- Effective Java
Knihy o jave SE su aj starsie aktualne. Od 5-ky sa java vyrazne nemenila. Zaklady sa daju naucit aj zo starsej knihy, ostatne staci potom dostudovat z internetu.
Naproti tomu knihy o frameworkoch zastaravaju rychlo.
A tie knihy, co ste spominali, samozrejme nezostarnu, to su nadcasove klasiky.
-
IMHO, je to jako s matematikou. Nejlip se naucis nejaky konkretni podobor, kdyz zkusis neco tezsiho.
Programovat dobre v Jave te nauci znalost jinych jazyku a stylu programovani. Muzu doporucit treba Haskell, ale uzitecny je treba i Lisp, Prolog, Smalltalk atd.
-
IMHO, je to jako s matematikou. Nejlip se naucis nejaky konkretni podobor, kdyz zkusis neco tezsiho.
Programovat dobre v Jave te nauci znalost jinych jazyku a stylu programovani. Muzu doporucit treba Haskell, ale uzitecny je treba i Lisp, Prolog, Smalltalk atd.
Samozrejme pred tim nez jsem zacal delat Javu jsem delal primarne v Pythonu, Ruby, JS, (Swift+ObjC protoze jsem zhnusen z *buntu utekl k osx, pac jsem byl liny udrzovat Gentoo a chtel jsem se zabyvat primarne vyvojem SW a ne sveho OS). Ale nejak mi unika souvislost J2EE, Springu a Prologu, Smalltalku...
Muzete to prosim nejak objasnit? Dekuji :-)
-
Jeste jsem zapomel dodat jednu vec minimalne Lisp a Prolog je soucast vyuky na beznych IT VS v CR. V nekterych pripadech se tam clovek setka i s tim Haskellem (mozna i se Smalltalkem - ale o takove v CR nevim). Temito jazyky jsem byl tedy take dotcen.
Duvod proc jsem toto vlakno zalozil neni ten abych se naucil zaklady Java SE, ale experienced veci specificke pro Javu a jeji best practices. Znalost jineho jazyka muze byt v nekterych pripadech uzitecna nekdy ne - zalezi od kontextu.
-
IMHO, je to jako s matematikou. Nejlip se naucis nejaky konkretni podobor, kdyz zkusis neco tezsiho.
Programovat dobre v Jave te nauci znalost jinych jazyku a stylu programovani. Muzu doporucit treba Haskell, ale uzitecny je treba i Lisp, Prolog, Smalltalk atd.
Ale nejak mi unika souvislost J2EE, Springu a Prologu, Smalltalku...
U Smalltalku je to jasné, tam se člověk naučí "čisté" OOP (i když praktičtější je v tomto ohledu ObjC). Prolog zase dost usnadní řešení určitých (nedeterministických) problémů a jde v něm "psát" v jakémkoliv jazyce, co má buď monády, nebo uzávěry (viz Yield Prolog).
-
Jeste jsem zapomel dodat jednu vec minimalne Lisp a Prolog je soucast vyuky na beznych IT VS v CR. V nekterych pripadech se tam clovek setka i s tim Haskellem (mozna i se Smalltalkem - ale o takove v CR nevim). Temito jazyky jsem byl tedy take dotcen.
Duvod proc jsem toto vlakno zalozil neni ten abych se naucil zaklady Java SE, ale experienced veci specificke pro Javu a jeji best practices. Znalost jineho jazyka muze byt v nekterych pripadech uzitecna nekdy ne - zalezi od kontextu.
Java není určená pro "experienced věci", ale pro co nejsnadnější psaní kódu. Různé "best practices" a vzory jsou často zbytečné a dost kontraproduktivní. Chce-li se někdo naučit idiomatickou Javu, měl by prostě hodně číst kódy a hodně psát s použitím vlastní hlavy, tj. bez ohledu na něčí "best practices".
-
Jeste jsem zapomel dodat jednu vec minimalne Lisp a Prolog je soucast vyuky na beznych IT VS v CR. V nekterych pripadech se tam clovek setka i s tim Haskellem (mozna i se Smalltalkem - ale o takove v CR nevim). Temito jazyky jsem byl tedy take dotcen.
Duvod proc jsem toto vlakno zalozil neni ten abych se naucil zaklady Java SE, ale experienced veci specificke pro Javu a jeji best practices. Znalost jineho jazyka muze byt v nekterych pripadech uzitecna nekdy ne - zalezi od kontextu.
Java není určená pro "experienced věci", ale pro co nejsnadnější psaní kódu. Různé "best practices" a vzory jsou často zbytečné a dost kontraproduktivní. Chce-li se někdo naučit idiomatickou Javu, měl by prostě hodně číst kódy a hodně psát s použitím vlastní hlavy, tj. bez ohledu na něčí "best practices".
Tak tohle me hodne zajima :-) zrovna na nekolika pohovorech pro Javisty jsem se setkal uplne s opacnym pristupem a doslova cloveka zkouseli z patternu a ruznych best practices (cca 100 otazek stahnutych z netu a s kazdym uchazecem to pri pohovoru prosli osobne).
A ano chapu ze kdyz clovek bude bezmyslenkovite pouzivat nejake design patterny nebo best practices, tak bude psat doslova sra***y :-)
-
Java není určená pro "experienced věci", ale pro co nejsnadnější psaní kódu. Různé "best practices" a vzory jsou často zbytečné a dost kontraproduktivní. Chce-li se někdo naučit idiomatickou Javu, měl by prostě hodně číst kódy a hodně psát s použitím vlastní hlavy, tj. bez ohledu na něčí "best practices".
Také jsem býval odpůrcem návrhových vzorů, než jsem pochopil jejich smysl.
-
Jeste jsem zapomel dodat jednu vec minimalne Lisp a Prolog je soucast vyuky na beznych IT VS v CR. V nekterych pripadech se tam clovek setka i s tim Haskellem (mozna i se Smalltalkem - ale o takove v CR nevim). Temito jazyky jsem byl tedy take dotcen.
Duvod proc jsem toto vlakno zalozil neni ten abych se naucil zaklady Java SE, ale experienced veci specificke pro Javu a jeji best practices. Znalost jineho jazyka muze byt v nekterych pripadech uzitecna nekdy ne - zalezi od kontextu.
Java není určená pro "experienced věci", ale pro co nejsnadnější psaní kódu. Různé "best practices" a vzory jsou často zbytečné a dost kontraproduktivní. Chce-li se někdo naučit idiomatickou Javu, měl by prostě hodně číst kódy a hodně psát s použitím vlastní hlavy, tj. bez ohledu na něčí "best practices".
A ano chapu ze kdyz clovek bude bezmyslenkovite pouzivat nejake design patterny nebo best practices, tak bude psat doslova sra***y :-)
Jo, tomu se říká cargo cult programming. Návrhové vzory mají v jistých případech smysl, ale málokdo ví, kdy to je. Zkušený vývojář používá "best practices" intuitivně. Super čtení je v tomto směru Knuth (známý svým despektem k "software engineering").
-
Zkušený vývojář používá "best practices" intuitivně.
Ale pred tim se halt hodi tech par let, kdy je pouziva vedome, nez mu prejdou do krve.
-
Zkušený vývojář používá "best practices" intuitivně.
Ale pred tim se halt hodi tech par let, kdy je pouziva vedome, nez mu prejdou do krve.
Pokud se je musí učit od někoho, tak je to k ničemu. Akorát z něj bude právě ten týpek na pohovoru, který ptá na "důležité" znalosti. Tohle není lepení bot, kde potřebuješ mít věci v krvi. Kit moc nepřekvapuje, protože stejně vyvíjet neumí a vzory jsou pro něj dobrá schovka.
Na návrhové vzory se má cenu ptát jen úplných začátečníků.
-
Zkušený vývojář používá "best practices" intuitivně.
Ale pred tim se halt hodi tech par let, kdy je pouziva vedome, nez mu prejdou do krve.
Pokud se je musí učit od někoho, tak je to k ničemu.
A jak jinak? Pokus - omyl? Neni to ztrata casu? (nerikam, ze to nejde, ale otazka je, zda to neni plytvani)
-
Pokud se je musí učit od někoho, tak je to k ničemu. Akorát z něj bude právě ten týpek na pohovoru, který ptá na "důležité" znalosti. Tohle není lepení bot, kde potřebuješ mít věci v krvi. Kit moc nepřekvapuje, protože stejně vyvíjet neumí a vzory jsou pro něj dobrá schovka.
Na návrhové vzory se má cenu ptát jen úplných začátečníků.
Návrhové vzory používám i pro komunikaci s těmi začátečníky. Když mu řeknu, aby tuto část udělal přes Simple Factory a tuhle přes Observer, tak předpokládám, že mi rozumí. Pokud ne, musí si to nastudovat.
-
Zkušený vývojář používá "best practices" intuitivně.
Ale pred tim se halt hodi tech par let, kdy je pouziva vedome, nez mu prejdou do krve.
Pokud se je musí učit od někoho, tak je to k ničemu.
A jak jinak? Pokus - omyl? Neni to ztrata casu? (nerikam, ze to nejde, ale otazka je, zda to neni plytvani)
To je dobrá otázka.
Pokud se je musí učit od někoho, tak je to k ničemu. Akorát z něj bude právě ten týpek na pohovoru, který ptá na "důležité" znalosti. Tohle není lepení bot, kde potřebuješ mít věci v krvi. Kit moc nepřekvapuje, protože stejně vyvíjet neumí a vzory jsou pro něj dobrá schovka.
Na návrhové vzory se má cenu ptát jen úplných začátečníků.
Návrhové vzory používám i pro komunikaci s těmi začátečníky. Když mu řeknu, aby tuto část udělal přes Simple Factory a tuhle přes Observer, tak předpokládám, že mi rozumí. Pokud ne, musí si to nastudovat.
Pokud jste všichni začátečníci, tak je to asi fajn. Obvykle je lepší použít návrh problému, který se řeší. Těžko ti vzor něco sám vyřeší.
-
Návrhové vzory používám i pro komunikaci s těmi začátečníky. Když mu řeknu, aby tuto část udělal přes Simple Factory a tuhle přes Observer, tak předpokládám, že mi rozumí. Pokud ne, musí si to nastudovat.
Pokud jste všichni začátečníci, tak je to asi fajn. Obvykle je lepší použít návrh problému, který se řeší. Těžko ti vzor něco sám vyřeší.
Jak chceš použít návrh problému, který se řeší, když ho ještě nemáš?
-
Muze se clovek naucit slusne vyvijet software (schvalne pisu vyvijet software a ne jen programovat) v Jave, kdyz nema nikoho kdo jej muze mentorovat? (at uz v praci nebo ve skole). Prohrabovat se tunami blogu - ktere beztak pisou indove o svych prasarnach nebude zrejme 2x efektivni. Nejake knihy se ucite vzdycky daji najit nicmene ty budou zrejme rychle zastarale.
Samozrejme. Kazdou chvili tu (v Praze, a mozna i v Brne, ale tam to nesleduju) nekdo otevira vyvoj. A funguje to vzdycky stejne - nejdriv se nabere tucet hodne kvalifikovanych lidi a kdyz se ukaze, ze vyvoj v Praze ma smysl, otevrou se dalsi pozice, kde se nabiraji lopaty. A to je vase prilezitost. Chytnout nejakou takovou rozjizdejici se R&D pobocku ve fazi, kdy jeste ty Acka nabrana za tezke penize jeste neodesla budovat neco jineho (coz obvykle po trech az peti letech udelaji).
-
Java není určená pro "experienced věci", ale pro co nejsnadnější psaní kódu. Různé "best practices" a vzory jsou často zbytečné a dost kontraproduktivní. Chce-li se někdo naučit idiomatickou Javu, měl by prostě hodně číst kódy a hodně psát s použitím vlastní hlavy, tj. bez ohledu na něčí "best practices".
Také jsem býval odpůrcem návrhových vzorů, než jsem pochopil jejich smysl.
to zni dost spiritualne ... blahopreju kite
-
Návrhové vzory používám i pro komunikaci s těmi začátečníky. Když mu řeknu, aby tuto část udělal přes Simple Factory a tuhle přes Observer, tak předpokládám, že mi rozumí. Pokud ne, musí si to nastudovat.
Pokud jste všichni začátečníci, tak je to asi fajn. Obvykle je lepší použít návrh problému, který se řeší. Těžko ti vzor něco sám vyřeší.
Jak chceš použít návrh problému, který se řeší, když ho ještě nemáš?
Obvykle problem vystane uz pri navrhu, alebo pri programovani. Pripadne ten problem ma clovek aspon v hlave. Ak sa pouzije vzor defaultne, bez toho ho bolo treba, tak to je priklad overengineeringu. V knizkach, napriklad tej od gang of four je vysvetlene, aky je relevantny kontext a aky poroblem sa riesi. (Ano a treba aj hlavu pouzit, knizka tiez nepozna vsetky situacie :) )
-
Obvykle problem vystane uz pri navrhu, alebo pri programovani. Pripadne ten problem ma clovek aspon v hlave. Ak sa pouzije vzor defaultne, bez toho ho bolo treba, tak to je priklad overengineeringu. V knizkach, napriklad tej od gang of four je vysvetlene, aky je relevantny kontext a aky poroblem sa riesi. (Ano a treba aj hlavu pouzit, knizka tiez nepozna vsetky situacie :) )
Ty návrhové vzory nejsou tak komplikované, jak na první pohled vypadají. Třeba implementace Singletonu představuje jen cca 3 řádky ve třídě a vůbec nemusí být statická. Simple Factory má kdekdo ve formě jedné statické metody - Laravel je toho plný.
Použití návrhového vzoru nemusí znamenat napsání celé samostatné třídy nebo dokonce několika tříd. Většina z těch vzorů se dá implemenovat v jediné krátké metodě do 10 řádek. O overengineering se tedy rozhodně nejedná.
-
Obvykle problem vystane uz pri navrhu, alebo pri programovani. Pripadne ten problem ma clovek aspon v hlave. Ak sa pouzije vzor defaultne, bez toho ho bolo treba, tak to je priklad overengineeringu. V knizkach, napriklad tej od gang of four je vysvetlene, aky je relevantny kontext a aky poroblem sa riesi. (Ano a treba aj hlavu pouzit, knizka tiez nepozna vsetky situacie :) )
Ty návrhové vzory nejsou tak komplikované, jak na první pohled vypadají. Třeba implementace Singletonu představuje jen cca 3 řádky ve třídě a vůbec nemusí být statická. Simple Factory má kdekdo ve formě jedné statické metody - Laravel je toho plný.
Použití návrhového vzoru nemusí znamenat napsání celé samostatné třídy nebo dokonce několika tříd. Většina z těch vzorů se dá implemenovat v jediné krátké metodě do 10 řádek. O overengineering se tedy rozhodně nejedná.
Laravel neni napsany v Jave, to jak ty prasis kod v PHP nevykladej ostatnim jako Java best practices dekuji :-)
-
Obvykle problem vystane uz pri navrhu, alebo pri programovani. Pripadne ten problem ma clovek aspon v hlave. Ak sa pouzije vzor defaultne, bez toho ho bolo treba, tak to je priklad overengineeringu. V knizkach, napriklad tej od gang of four je vysvetlene, aky je relevantny kontext a aky poroblem sa riesi. (Ano a treba aj hlavu pouzit, knizka tiez nepozna vsetky situacie :) )
Ty návrhové vzory nejsou tak komplikované, jak na první pohled vypadají. Třeba implementace Singletonu představuje jen cca 3 řádky ve třídě a vůbec nemusí být statická. Simple Factory má kdekdo ve formě jedné statické metody - Laravel je toho plný.
Použití návrhového vzoru nemusí znamenat napsání celé samostatné třídy nebo dokonce několika tříd. Většina z těch vzorů se dá implemenovat v jediné krátké metodě do 10 řádek. O overengineering se tedy rozhodně nejedná.
Taktiez sa daju pouzit pri refactorovani, ked vznikne potreba. Vzory predsa len pridavaju nejaky ten kod naviac a pridavaju nejake spravanie, ktore nemusi byt ziadane. Ak nemam problem, nemusim ho riesit. Ok, uz koncim, lebo sa do mna pusti zboj, ze nepoznam pytagorovu vetu :)
-
Laravel neni napsany v Jave, to jak ty prasis kod v PHP nevykladej ostatnim jako Java best practices dekuji :-)
GoF neřeší implementaci, ale metodiku užití návrhových vzorů.
-
Muze se clovek naucit slusne vyvijet software (schvalne pisu vyvijet software a ne jen programovat) v Jave, kdyz nema nikoho kdo jej muze mentorovat? (at uz v praci nebo ve skole).
"Slusne vyvinuty software" je podla mna nedobra definicia. Z jednoducheho dovodu, ze je to subjektivne hodnotenie zavisle na kontexte. Vysvetlim na extremnom priklade.
Napr. taky Jake2 (port Quake2 do Javy) je podla vsetkeho uber-neslusny, pretoze su tam porusene vsetky zakladne principy "dobreho java programovania", t.j. encapsulacia cez gettery/settery, znasilnene staticke fieldy a metody, nazvy metod a fieldov (skoro ziaden CamelCase), pomaly ziadne asserty atd. Napriek tomu Jake2 funguje... Preco je ten kod taky hnusny? Pretoze je to port z C-cka a team, ktory ho portoval, si uvedomil, ze keby ho chceli portovat "pekne javovsky", tak pravdepodobne este dnes pisu iba gettery a settery a akurat by zacinali rozmyslat, kde by sa sikol singleton a kde nejaky ten visitor... takze sa na celu tu javovsku nomenklaturu vykaslali a vacsinu riesili automatizovane s nejakymi minimalnymi modifikaciami tak, aby to bolo aspon skompilovatelne.
Obdobny problem riesil autor Mocha Dooma (port Dooma do Javy), ktory sa o svojom projekte vyjadril takto:
several concepts have been "borrowed" from Jake 2, especially regarding the methods used to port complex game C code to Java, how to map structs to classes, how to implement binary loaders etc.
Klucovy vyraz: complex C code.
Fuguje Jake2? Funguje. Je slusne vyvinuty? Je, ved ho pisal sam Carmack. Zvladla by ho napisat bezna Java lopata (cize ja) od nuly a pekne javovsky? Nie...
Samozrejme, ked si clovek potom zoberie zdrojaky Springu, to sa cita ako krasny enterprise grade Java kod a kde tu narazite aj na poctivy WrapperHolder z 2002ho - v tomto smere JDKcko na tom nie je o nic lepsie. Ale v podstate je pri Springu dolezite, ze sami Springove komponenty su pisane s tym, ze budu mat dostupne vsetky "bells and whistles" dependency injection. Projekt, ktory nema k dispozicii Spring bude zase strukturovany a napisany inak.
Co je ale uplna hlupost je pisanie vlastneho Springu na projekte bez Springu alebo naopak, nevyuzivat DI na projekte, ktory je cely Springovy...
S mentorom ci bez, hlavne treba vela citat, citat, citat a citat.
-
Moj mentor bol Aslak Knutsen, dvojnasobny Java Champion od Oraclu, robil som pod nim tri roky open source framework Arquillian, chodil som na hackatony, robil som pod nim diplomovku, bol som na google summer of code a pisal som o tom blogy, chodil som na konferenvie s tym co robim ... potom som si nasiel job u jedneho americkeho startupu a podarilo sa im predat ho twittru ... tak sa naucis kodit v jave, Aslak je strasny zver a mam neskutocne stastie ze som pod nim robil, teraz som karierne uplne niekde inde jak vacsina
-
Slušný kód neposuzuji podle toho, jestli zrovna teď funguje správně (to považuji za samozřejmost), ale zda jej lze rozumně rozvíjet i do budoucna. Nejsem si jist, zda poloautomatizovaný přepis z céčka toto splňuje. Samozřejmě účel světí prostředky a je to tak správně. Pokud nepotřebují na té hře dále dělat, byla by chyba jej nevyužít.
Pořád jsem víc a víc přesvědčený, že slušný vývoj vůbec není o vychytávkách v daném jazyce, ale o dobře udělané analýze a návrhu modulů/tříd/objektů. Čím víc odpovídá skutečné realitě a obsahuje méně "hacků", tím je kód udržovatelnější a z mého pohledu lepší. Rovněž čím je víc typově svázaný, tím je udržovatelnější, mimo jiné i protože v něm nelze dělat tolik hacků (čuňáren). Když se přitom využijí možnosti javy 8 pro zkrácení zápisu (lambdy, streamy), neuškodí to. Jejich používání není žádná věda.
Např. často se tu řeší dědičnost. IMO jsou "problémy" s dědičností jen důsledkem špatné dekompozice problému, kdy třída řeší více funkcionalit najednou, místo aby se skládala z více objektů, které již samy mají smysluplnou dědičnou posloupnost odpovídající realitě a výsledný objekt mohu poskládat z komponent ve vhodné funkční "verzi". V legacy kódu to řeším každý den.
Z pohledu těchto věcí posuzuji kvalitu softwaru/vývoje v javě. Úplně stejné požadavky budou při vývoji v jakémkoliv jazyce. S mladými kluky na domácím programování děláme v pythonu a musí kolem tříd řešit úplně to samé, jen díky chybějící typovosti dělají v kódu mnohem více chyb. A platí to i v neobjektových jazycích, protože i třeba v plain C sakra moc záleží, jak se ty structy navrhnou.
-
Napr. taky Jake2 (port Quake2 do Javy) je podla vsetkeho uber-neslusny, pretoze su tam porusene vsetky zakladne principy "dobreho java programovania", t.j. encapsulacia cez gettery/settery, znasilnene staticke fieldy a metody, nazvy metod a fieldov (skoro ziaden CamelCase), pomaly ziadne asserty atd. Napriek tomu Jake2 funguje... Preco je ten kod taky hnusny? Pretoze je to port z C-cka a team, ktory ho portoval, si uvedomil, ze keby ho chceli portovat "pekne javovsky", tak pravdepodobne este dnes pisu iba gettery a settery a akurat by zacinali rozmyslat, kde by sa sikol singleton a kde nejaky ten visitor... takze sa na celu tu javovsku nomenklaturu vykaslali a vacsinu riesili automatizovane s nejakymi minimalnymi modifikaciami tak, aby to bolo aspon skompilovatelne.
Zapouzdření se dá elegantně dělat i bez *etterů. Stačí umět používat DI.
-
IMHO, je to jako s matematikou. Nejlip se naucis nejaky konkretni podobor, kdyz zkusis neco tezsiho.
Programovat dobre v Jave te nauci znalost jinych jazyku a stylu programovani. Muzu doporucit treba Haskell, ale uzitecny je treba i Lisp, Prolog, Smalltalk atd.
Samozrejme pred tim nez jsem zacal delat Javu jsem delal primarne v Pythonu, Ruby, JS, (Swift+ObjC protoze jsem zhnusen z *buntu utekl k osx, pac jsem byl liny udrzovat Gentoo a chtel jsem se zabyvat primarne vyvojem SW a ne sveho OS). Ale nejak mi unika souvislost J2EE, Springu a Prologu, Smalltalku...
Pak si myslim, ze si s tim delas zbytecnou hlavu. Ja mam za to, ze neexistuje vseobecne prijimana definice toho, co v Jave znamena programovat "slusne" - viz treba ty nekonecne diskuse o tom, jestli vubec dedicnost nebo OOP ma nejaky smysl. (Krome toho, je otazka, jestli to, co nekdo povazuje za slusny pristup, bude taky tobe pak vyhovovat.)
Ona takova definice neexistuje skoro v zadnem jazyce, vsude jsou ruzne pristupy, ktere nekomu pripadaji kontroverzni. Python se takove definici trochu blizi svym "Pythonic".
Mne osobne dnes treba vyhovuje FP pristup, takze bych v Jave programoval asi trochu abnormalne (kdybych musel). Co vidim, tak Javisti hodne daji prave na Design Patterns, coz mne naopak prijde jako zbytecna intelektualni onanie.
Takze nejlepsi je asi brat vsechno s rezervou a jit nejakou stredni cestou, mozna s obcasnym experimentalnim vystrelkem. To je ale dovednost, kterou se muzes naucit v jakemkoli jazyce, a v jakemkoli jinem ji okamzite pouzit.
-
Návrhové vzory používám i pro komunikaci s těmi začátečníky. Když mu řeknu, aby tuto část udělal přes Simple Factory a tuhle přes Observer, tak předpokládám, že mi rozumí. Pokud ne, musí si to nastudovat.
Pokud jste všichni začátečníci, tak je to asi fajn. Obvykle je lepší použít návrh problému, který se řeší. Těžko ti vzor něco sám vyřeší.
Jak chceš použít návrh problému, který se řeší, když ho ještě nemáš?
Problém mám a řešení se neví. Nepotřebuju tam lempla, kterému řeknu vzor. Podíváme se na to spolu a nebo to bude řešit sám. Ale místo pro vzory tam nikde nevidím.
Napr. taky Jake2 (port Quake2 do Javy) je podla vsetkeho uber-neslusny, pretoze su tam porusene vsetky zakladne principy "dobreho java programovania", t.j. encapsulacia cez gettery/settery, znasilnene staticke fieldy a metody, nazvy metod a fieldov (skoro ziaden CamelCase), pomaly ziadne asserty atd. Napriek tomu Jake2 funguje... Preco je ten kod taky hnusny? Pretoze je to port z C-cka a team, ktory ho portoval, si uvedomil, ze keby ho chceli portovat "pekne javovsky", tak pravdepodobne este dnes pisu iba gettery a settery a akurat by zacinali rozmyslat, kde by sa sikol singleton a kde nejaky ten visitor... takze sa na celu tu javovsku nomenklaturu vykaslali a vacsinu riesili automatizovane s nejakymi minimalnymi modifikaciami tak, aby to bolo aspon skompilovatelne.
Zapouzdření se dá elegantně dělat i bez *etterů. Stačí umět používat DI.
Metodu setColor() nahradí DI jak?
Mne osobne dnes treba vyhovuje FP pristup, takze bych v Jave programoval asi trochu abnormalne (kdybych musel). Co vidim, tak Javisti hodne daji prave na Design Patterns, coz mne naopak prijde jako zbytecna intelektualni onanie.
Právě ti, kteří moc vyvíjet neumí, protože za vzory se jde dobře schovat. Jako to dělá Kit tady. Místo, aby ti řekl, jak něco vyřešit, tak zablekotá tři vzory, k tomu přihodí tři banky, kde to viděl a konec debaty :D Za to nemůže ale Java, ale právě ty hloupé pozice v bankách, kde se neřeší reálný vývoj, ale hlavně ta administrace kolem. Výsledný projekt nikoho moc nezajímá. Čím více kódu, tím lépe. Je to přece drahé.
-
Zapouzdření se dá elegantně dělat i bez *etterů. Stačí umět používat DI.
Metodu setColor() nahradí DI jak?
Mne osobne dnes treba vyhovuje FP pristup, takze bych v Jave programoval asi trochu abnormalne (kdybych musel). Co vidim, tak Javisti hodne daji prave na Design Patterns, coz mne naopak prijde jako zbytecna intelektualni onanie.
Právě ti, kteří moc vyvíjet neumí, protože za vzory se jde dobře schovat.
To je ale prapůvodní účel vzorů (aspoň podle Knutha), umožnit jakž takž programovat i lidem, kteří to neumí ("how to program if you can't").
-
Wow, tak pak to funguje dobře :D I Kit tady si může hrát na programátora. Je ale otázkou, proč se to často používá jako filtr u Javy. Asi nehledají vývojáře...
-
Wow, tak pak to funguje dobře :D I Kit tady si může hrát na programátora. Je ale otázkou, proč se to často používá jako filtr u Javy. Asi nehledají vývojáře...
Hledající není vývojář ;)
-
Právě ti, kteří moc vyvíjet neumí, protože za vzory se jde dobře schovat. Jako to dělá Kit tady. Místo, aby ti řekl, jak něco vyřešit, tak zablekotá tři vzory, k tomu přihodí tři banky, kde to viděl a konec debaty :D Za to nemůže ale Java, ale právě ty hloupé pozice v bankách, kde se neřeší reálný vývoj, ale hlavně ta administrace kolem. Výsledný projekt nikoho moc nezajímá. Čím více kódu, tím lépe. Je to přece drahé.
Sorry, ale v kolika bankach a jakych jste delal ? :D Banky neresi realny vyvoj ? Ale penize ji sverite, ne ? Nebo mate vsechno pod slamnikem ?
Banka neni e-shop a tomu odpovida infrastruktura. Realtime vyhledavani zprav pet dni nazpatek pri provozu jednotek mld zprav denne, monitoring tisicovek stroju, reporty regulatorum, routovani a transformace zprav a generovani alertu pro mimoradne stavy (opet v jednotkach miliard denne), vse auditovatelne, vse s disaster recovery managementem. A to vse pokud mozno rychleji nez konkurence. - TO je banka.
Takze kdyz nekdo zacne mlit o spatne urovni vyvoje v bankach, muzu si pomyslet jen to, ze nevi o cem mluvi.
-
Jak chceš použít návrh problému, který se řeší, když ho ještě nemáš?
Problém mám a řešení se neví. Nepotřebuju tam lempla, kterému řeknu vzor. Podíváme se na to spolu a nebo to bude řešit sám. Ale místo pro vzory tam nikde nevidím.
Problém se zpravidla dá rozdělit na podproblémy, které se dají pojmenovat podle vzorů. Řešení je pak snadné.
Zapouzdření se dá elegantně dělat i bez *etterů. Stačí umět používat DI.
Metodu setColor() nahradí DI jak?
Například tak, že tu barvu dáš do konstruktoru jako objekt. Máš ji pak dostupnou z daného objektu i z objektu, který ji vytvořil. Tím tu barvu hezky zapouzdříš.
-
Právě ti, kteří moc vyvíjet neumí, protože za vzory se jde dobře schovat. Jako to dělá Kit tady. Místo, aby ti řekl, jak něco vyřešit, tak zablekotá tři vzory, k tomu přihodí tři banky, kde to viděl a konec debaty :D Za to nemůže ale Java, ale právě ty hloupé pozice v bankách, kde se neřeší reálný vývoj, ale hlavně ta administrace kolem. Výsledný projekt nikoho moc nezajímá. Čím více kódu, tím lépe. Je to přece drahé.
Sorry, ale v kolika bankach a jakych jste delal ? :D Banky neresi realny vyvoj ? Ale penize ji sverite, ne ? Nebo mate vsechno pod slamnikem ?
Banka neni e-shop a tomu odpovida infrastruktura. Realtime vyhledavani zprav pet dni nazpatek pri provozu jednotek mld zprav denne, monitoring tisicovek stroju, reporty regulatorum, routovani a transformace zprav a generovani alertu pro mimoradne stavy (opet v jednotkach miliard denne), vse auditovatelne, vse s disaster recovery managementem. A to vse pokud mozno rychleji nez konkurence. - TO je banka.
Takze kdyz nekdo zacne mlit o spatne urovni vyvoje v bankach, muzu si pomyslet jen to, ze nevi o cem mluvi.
Problém je v tom, že většina funcí ve velkých bankách není v Javě. Jasně, nějaké trapné bankovnictví a tooly. Většina podstatných věcí jsou koupené krabice, které se akorát přes Javu propojí.
-
Jak chceš použít návrh problému, který se řeší, když ho ještě nemáš?
Problém mám a řešení se neví. Nepotřebuju tam lempla, kterému řeknu vzor. Podíváme se na to spolu a nebo to bude řešit sám. Ale místo pro vzory tam nikde nevidím.
Problém se zpravidla dá rozdělit na podproblémy, které se dají pojmenovat podle vzorů. Řešení je pak snadné.
Zapouzdření se dá elegantně dělat i bez *etterů. Stačí umět používat DI.
Metodu setColor() nahradí DI jak?
Například tak, že tu barvu dáš do konstruktoru jako objekt. Máš ji pak dostupnou z daného objektu i z objektu, který ji vytvořil. Tím tu barvu hezky zapouzdříš.
Radši pojmenovávám problémy přesně a ne abych pro ně hledal nevhodné škatulky.
Takže kam mi utekl ten setter? Prostě chci nastavovat barvu a ty mi říkáš něco o konstruktoru :D
-
Takže kam mi utekl ten setter? Prostě chci nastavovat barvu a ty mi říkáš něco o konstruktoru :D
Nepopsal jsi událost, při které se ta barva objektu má změnit. Volající objekt tu novou barvu nezná, chce jen tomu volanému objektu sdělit nějakou zprávu, na základě které si volaný objekt kromě jiného může změnit i tu barvu.
Proč tedy chceš měnit barvu? Má to nějakou souvislost s nějakou jinou akcí, kterou s objektem provádíš? Barva je přece privátní vlastností objektu, která by se zvnějšku měnit neměla.
-
Problém je v tom, že většina funcí ve velkých bankách není v Javě. Jasně, nějaké trapné bankovnictví a tooly. Většina podstatných věcí jsou koupené krabice, které se akorát přes Javu propojí.
Vy budete jeden z tech chlapu, co vysvetluje zenskym, jak rodit, ne ? :) Fakt by mne zajimalo, kdy a jestli vubec jste delal v bance. FYI, z krabic je messaging a tooling, protoze to jsou prave ty veci ktere v krabicich sezenete. Algo pro posouzeni klienta nebo na slajcovani orderu na exchange se v krabicich fakt neprodavaji.