- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Projektor topic
- Milyen CPU léghűtést vegyek?
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- A kánikula elviseléséhez hardverek is kellhetnek a napernyő mellé
- Kormányok / autós szimulátorok topicja
- HiFi műszaki szemmel - sztereó hangrendszerek
- Azonnali notebookos kérdések órája
- Kezdő fotósok digitális fényképei
- Milyen házat vegyek?
Hirdetés
-
Filléres Redmi érkezett
ma Az A3x nem kapott nagy bemutatót, egyszer csak felbukkant.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
Computex 2024: szimpatikus Montech billentyűzetek a porondon
ph A vállalat egy olcsóbb fajta, két színben választható, vezetékmentes modellel és két érdekesen festő koncepcióval jelentkezett.
Új hozzászólás Aktív témák
-
Szmeby
tag
Én is én is én is!
String[] arrayOfStrings = { "alma", "körte", "banán", "cseresznye", "áfonya" };
String longest = Arrays.stream(arrayOfStrings).reduce((a, b) -> a.length() > b.length() ? a : b).orElse(null); -
axioma
veterán
-
#68216320
törölt tag
válasz Szmeby #10701 üzenetére
Ez mennyire BestPactice? Én még úgy tanultam, hogy próbáljuk kerülni a lambda-t, mert a forráskód nehezebben olvasható majd. Nem "nyúlfarknyi" példákra, gondolok, hanem nagyobb osztályokra például. Persze most nem azt mondom, hogy 1-1 forEach vagy hasonló nem kerülhet bele csak például nálam egy-egy komplexebb sor átláthatósága debug esetén nehezebb/lassabb.
Persze tény, hogy elegánsabbVagy ez teljesen rendben van és marhaságot tanultam?
-
axioma
veterán
válasz #68216320 #10704 üzenetére
Engem meg code review-n (prod.code) direkt felszolitottak, hogy lambda-sitsak. Szerintem attol fugg, hogy hol mi a szokas, en egyebkent nem tartom olvashatatlanabbnak (csak az adott esetben kovettem a korabbi kodstilust). Szerintem nem art megszokni, peldaul a sonarlint ezt nem veszi elagazasnak es extra bonyolitaspontnak ha jol remlik
-
Lortech
addikt
válasz #68216320 #10704 üzenetére
A best practice az olvasható kód. Ez persze bizonyos mértékig szubjektív.
Az olvashatóság lambda esetében még inkább az, erősen függ attól, hogy ki az olvasó. Ki mihez van szokva, kinek már állt rá jobban az agya. Már csak azért is, mert a lambda nem volt mindig alap nyelvi elem, és máig rengeteg kódbázis van, ami nem ilyen szemléletben íródott. Ha a csapat, aki a kódot írja és karbantartja, lambdát preferálja, akkor menjen a lambda, de azért ne ész nélkül.
Az adott problémától függ, hogy lambdával olvashatóbb lesz-e a kód, esetleg hatékonyabb vagy elegánsabb.[ Szerkesztve ]
Thank you to god for making me an atheist
-
Szmeby
tag
válasz #68216320 #10704 üzenetére
Egy adott fajta kód vagy stílus azok számára nehezen olvasható, akik nem szoktak hozzá. Kezdőként én is nehezen dekódoltam, hogy mi van. Aztán megszoktam és már nem nehéz.
A fenti kód nyúlfarknyi. Ebbe belemagyrázni azt, hogy ez azért nem jó, mert lehet nem nyúlfarknyit is írni, hát, jó, de a fenti kód továbbra is nyúlfarknyi marad, minden más csak a kivetített félelmeid. Vagy valaki más félelmei, nem célom személyeskedni.
A lambda nem egy kalapács, hogy mindenre IS használható, ahogy egyébként semmi sem az, nincs ultimate weapon minden problémára. Természetes, hogy a 200 soros förmedvényt nem egy lambda blokkban kódolja le az ember, hanem elgondolkozik, hogy miért lett ez 200 sor, aztán egyszerűsít, absztrahál, és kitalál egy a probléma megoldására optimálisnak tűnő módszert, stílust, eszközt, stb. Ami nem KELL, hogy egyáltalán tartalmazzon lambdát végül.A lambda (meg lényegében a stream api) azért jó, mert egységet képez, egy komplexebb folyamatot is atomi egységbe zár, nincs mellékhatása, ergo "bugmentes". Ha matekosabb beállítottságúnak érzed magad, olvass kicsit a monad-ról. Ha kevésbé matekosnak, akkor inkább ne, nehogy eret vágj magadon.
Nyilván ezt is el lehet cseszni, ha mondjuk egy a lambdán kívül létrehozott listát piszkálunk a lambda belsejében, annak már lesz mellékhatása, de az nem is a lambda hibája.Én személy szerint azért nem szeretem a stream apit, mert lassú. Egy forEach lassabb egy for ciklusnál, és ez engem időnként zavar.
Nehéz debugolni? A régi eclipse valóban elég körülményesen működött, a closure környezetének csak egy részét látta. Hogy most jól működik-e, nem tudom. Mint mondtam, nem illik 200 soros lambda törzseket produkálni, és akkor nem kell debugolni sem. Problem solved. Érthető, hogy a határidő szűkössége miatt folyamatosan megy a
gányolás... khm... képződik tech dept, de akkor is a fejlesztő felelőssége marad, hogy jól olvasható kódot produkáljon a végén. Ha valaki elég igénytelen arra, hogy egy egyszerű lambda kifejezést túlbonyolítva ott hagy, refakt nélkül, oké, de nem az eszközt kellene ilyenkor hibáztatni az olvashatatlan és debugolhatatlan kód miatt. Gondolom.
Egyébként meg a 200 soros blokk metódusba szervezésével és egy jól irányzott method ref beillesztésével máris nagyot léptünk előre a tisztánlátás útján. Az már más kérdés, hogy sok esetben ez csak a probléma elfedésére jó és nélkülözi az igazi optimalizálást.Az olvashatóságot egyébként tengernyi más dolog is befolyásolja, csak hogy a legkézenfekvőbbet említsem, a nevek. Ha semmitmondó változó és metódus neveket használ a fejlesztő, akkor az olvasó arra kényszerül, hogy belenézzen a metódusba. Ha kifejező neveket használ, akkor erre nincs szükség. Innentől kezdve meg már teljesen mindegy, hogy igazi metódusokat, vagy névtelen metódusokat használunk a megoldásban. De akkor sem illik túlbonyolítani egy lambda kifejezést.
--------
@floatr: Sajnos nem értem a kérdést, kifejtenéd? A reduce egy darab string optional-t ad vissza, azon nem tudok már sokmindent gyűjtögetni. -
floatr
veterán
válasz Szmeby #10707 üzenetére
Szokás enterprise körökben túltolni a legegyszerűbb dolgokat is. Ha reduce helyett egy collectort használtál volna, no meg persze factory-kat, akkor lehetne kelteni kisebbfajta pánikot a juniorok között
Amúgy az első kérdésére csak egy reduce nem fog megoldást adni, vagy két streamet használsz, vagy egy collectorral párban gyűjtöd a min/max értékeket. De akkor meg minek...
Amúgy szerintem nincsen különösebb baj a streamekkel, amíg olvashatóan és ésszerűen van szervezve. A hármas operátort sokan nem szeretik, mert rontja az olvashatóságot. Én egyedül azt a gányolást utálom, amikor mindent be akarnak szuszakolni egy sorba. Na meg az enterprisify kódot
-
Szmeby
tag
válasz floatr #10708 üzenetére
Oh, az első kérdést nem olvastam, az már tényleg nem lenne egyszerű.
Ilyesmire gondoltál? Persze ha a pánikkeltés a cél, akkor biztosan cifrázható tovább.
String[] arrayOfStrings = { "alma", "körte", "banán", "cseresznye", "áfonya" };
String longest = Arrays.stream(arrayOfStrings)
.collect(Collectors.maxBy(Comparator.comparing(String::length)))
.orElse(null);
(a kedvedért több sorba törtem )A reduce nekem valamiért testhezállóbb volt, talán azért is, mert ritkán használok spéci collectorokat. Hirtelen nem is tudnám most rövidebben leírni collectorral, és ezt már én is túlzásnak érzem. Ízlés dolga. A for ciklus a tuti, azt mindenki érti és villámgyors.
-
Sirpi
senior tag
válasz Szmeby #10709 üzenetére
Én így írnám, felesleges a reduce meg a collect is:
String[] arrayOfStrings = { "alma", "körte", "banán", "cseresznye", "áfonya" };
String longest = Arrays.stream(arrayOfStrings)
.max(Comparator.comparingInt(String::length))
.orElse(null);Hazudnék, ha cáfolnám annak tagadását, hogy ez az ital nem nélkülözi a koffeinmentesség megnemlétének hiányát. Na most akkor van benne koffein, vagy nincs?!
-
floatr
veterán
válasz Szmeby #10709 üzenetére
Alakul... A végén szét lehet szerelni komponensekre, és lehet hozzá majd YAML konfigot írni
A reduce a legegyszerűbb, de akkor hadd húzzak lapot 19-re
Arrays.sort(arrayOfStrings, Comparator.comparing(String::length));
String shortest = arrayOfStrings[0];
String longest = arrayOfStrings[arrayOfStrings.length - 1];[ Szerkesztve ]
-
#68216320
törölt tag
Remek végigolvasni ezt a refactor-t
Esküszöm jobb tapasztalat, mint egy tanfolyam.A lambda témához:
Ezek szerint nem ördögtöl való...
Csak tudnám a régi melóhelyemen miért ellenezték annyira? Akkor sem értettem. Azt mondjuk soha nem vizsgáltam, h mondjuk egy forEach lassabb a for-nál. Sajnos nálam kényelmi beidegződés a forEach, használom. -
-
floatr
veterán
válasz sztanozs #10713 üzenetére
Már rég nem a sebességről szól a dolog
De ha már fun, akkor egy kis kihívás
Adott egy film (vagy bármilyen műalkotás), írjátok meg egy jellegzetes részletét Java-banDeathStar.getInstance()
.getGarbageMashers()
.stream()
.filter(gm -> gm.getLevel().equals(Level.DETENTION))
.forEach(GarbageMasher::shutdown); -
Szmeby
tag
válasz floatr #10714 üzenetére
// given
Universe universe = Universe.getInstance();
long expectedLivingBeingCount = universe.getLivingBeingCount() / 2;
// when
universe.getInfinityGauntlet()
.apply(InfinityStone.MIND)
.checkStonesAvailable(InfinityStone.values())
.snap();
// then
Assert.assertEquals(expectedLivingBeingCount, universe.getLivingBeingCount());
Hát, nem túl kényelmes ez a forráskód szerkesztő.[ Szerkesztve ]
-
sztanozs
veterán
válasz floatr #10714 üzenetére
public class Dream implements Consciousness {
protected List<MindState> inceptors;
protected Object thought2Inject;
protected Stack<MindState> dreamStates;
/* */
public String observe(Object o){
if (o instanceof Spinner && !dreamStates.empty())
return "Spins forever";
else
return super.observe(o);
}
}
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
floatr
veterán
válasz Szmeby #10709 üzenetére
Ebbe most futottam bele teljesen véletlenül
@Getter
@AllArgsConstructor
public class MinMax {
Optional<String> min, max;
public static MinMax of(String[] arrayOfString) {
var length = comparing(String::length);
return stream(arrayOfString)
.collect(
teeing(
minBy(length),
maxBy(length),
MinMax::new));
}
}
[ Szerkesztve ]
-
suits
tag
üdv!
Egy nagyon egyszerü kérdésem lenne.
Ha van egy változó mondjuk egy if ágon vagy egy metóduson belül akkor arra hogyan lehet hivatkozni a metóduson kivülről?Vagy ilyet a java-ban nem lehet? -
axioma
veterán
Abban a blokkban ervenyes, ahol letrehoztad. Ha bezarod a blokkot, eltunik, es ez pont igy van jol.
Ha kivul is akarod hasznalni, akkor ket dologra van szukseged:
1. kint deklaralni - nyilvan a felhasznalas helyetol fuggo mertekben "kintebb" (ez me'g ugye nem jelent feltetlen ertekadast is)
2. ezutan vagy csak olyan helyzetben lekerdezni, mikor ugyanazon feltetelben vagy (de egyreszt ezert minden normalis IDE kiabalni fog, hogy lehetseges hogy inicializalatlan valtozo, masreszt valoban lehet hogy itt-ott kicsit modositgatva kesobbi igenyek miatt pl. az if-eket ez nem fog mar fennallni), vagy pedig kell neki valami ertelmes ertek akkor is, ha nem az if-en beluli erteket kapja (ugy ertve hogy olyan amit feltetelezve valoban jol fog vegigmenni minden lepes). -
Orionk
senior tag
Sziasztok,
Java junior fejlesztő pozíció interjún azt kérdezték, hogy szerintem milyen egy jó, minőségi Java Osztály implementációja?
Szerintetek mi a minél tömörebb, jó válasz erre? Milyen a jó felépítésű Java Osztály? Ha van köztetek nagyobb tapasztalatú, Senior fejlesztő, akkor milyen felépítésű, tartalmú választ szeretnétek hallani?köszönöm
-
Drizzt
nagyúr
válasz Orionk #10725 üzenetére
Tömör, egy felelőssége van, se többet, se kevesebbet nem csinál mint ami a célja. Magas a koherencia a az adattagok és a metódusok között, meg az összes SOLID principle felsorolása, kifejtése, 1-2 design patternen keresztüli elmagyarázása. Én ezt várnám el egy interjúzótól. Bár juniortól lehet nem ilyet kérdeznék, hanem inkább alapvetőbb algoritmus kérdéseket, adatstruktúrákat.
I am having fun staying poor.
-
#68216320
törölt tag
Egy saját hobby project kapcsán merült fel pár kérdés, amiben szeretném a közösség véleményét kérni.
1. Maven build-et használok. Mikor szokás parent-child project-et csinálni?
Most van egy parent pom.xml-em, amiben jelenleg két child pom.xml van. Perzisztens réteg és üzleti réteg, de harmadikként menne majd a WebUI még ide (esetleg más UI ha lesz)2. Mit szoktatok előbb elkészíteni? Az osztályt vagy a unit tesztet? Mert ugye ha a tesztet írom előbb, kevesebb esélye van szerintem, hogy bizonyos elemek tesztelése kimarad. Tudom mit akarok csinálni, mik lesznek a funkciói, mik lesznek a paraméterei és ez alapján mik lesznek a buktatók. Ez alapján meg tudnám csinálni az osztályt ami hibátlanul elvégzi a feladatokat. Vagy célszerűbb sorban? Osztály aztán hozzá a teszt?
3. Servlet-WebUI elkészítéshez mit ajánlotok? Nem lenne komplex a feladat, HTML/CSS/JS ismeretem van. Framework vagy inkább valami saját JSP?
-
#68216320
törölt tag
válasz #68216320 #10728 üzenetére
4. Ha van egy már meglévő model amiből leszármaznék, mert mert az új model tartalmaz még pár tulajdonságot, de van olyan is amit a parent igen, de a child nem, akkor azt hogyan szokás megoldani? Obj esetén mondjuk lehet NULL, de például int vagy boolean esetében mit csinálok vele? Ha adok értéket akkor azt hihetem, hogy az valós.
-
Szmeby
tag
válasz #68216320 #10728 üzenetére
Csak annyit tudok a prjektedről, amennyit most leírtál róla, így lehet, hogy valamit félreértek.
1. Én most microservice bűvkörökben élek és a selfcontained alkalmazás a kedvenc, vagyis semmit sem vágok, cserébe viszont pici a cucc, és nincs benne ui. Természetesen a komponensek közti kommunikációt megvalósító DTO-kat, külön, közös projektbe teszem, hogy mindegyik komponens ugyanazt lássa.
Ha látod értelmét a vágásnak (mert mondjuk több egymástól eltérő modul is használná), akkor vágj. Ha nincs értelme, akkor ne vágj. A legrosszabb, amit tehetsz, hogy túl korán vágsz és később szívsz, hogy hát lehet, nem is ott kellett volna, ajaj.
A több UI, több modul felállás szimpi.2. A tesztet. Nincs hibátlan osztály. A tesztet. Leginkább párhuzamosan. TDD. Mondtam már, hogy a tesztet? Amúgy meg a te dolgod, ahogy jobban esik. Főleg, ha a teszttel kezded.
3. Ha valami nem komplex, én nem frameworközök, mert csak megköti a kezet, lassít, bonyolít. Amúgy passzolom a kérdést, nem tartom magam frontend gurunak. Persze lehet az, hogy mondjuk valaki csak az angulart ismeri és semmi mást, neki érezhetően könnyebb dolga lesz abban megcsinálni, mint szenvedni egy fura jsp-vel.
4. Ne származz le. Oké, hogy a nyelv megengedi, de attól még nem jó.
Én nem osztom azt a nézetet, hogy ami úgy néz ki mint egy kacsa és olyan hangot ad ki, mint egy kacsa, az egy kacsa. [link]
Az egy másik osztály.
Ha mégis van némi közük egymáshoz, akkor még a composition-t tudom elképzelni, vagyis az osztály egy tagja lesz a meglévő cucc, és az osztályod csak az értelmes mezőket engedi ki az apiján. -
#68216320
törölt tag
válasz Szmeby #10730 üzenetére
Köszönöm a válaszokat
1. Akkor lehet annál maradok, hogy minden marad egy projectben. Igazából pont azért kérdeztem, mert jelenleg tényleg nem indokolja semmi, hogy szétszedjem. Csak valahol láttam egy ilyen project-et és gondoltam, hátha ... de akkor nem csinálom egyelőre.
2. Akkor hogy is? A tesztet?
3. Az igazság az, hogy nem ismerek egy framewörköt sem. Tudom, kellene csak próbáltam elodázni. De nagyon úgy tűnik, hogy nincs mese... Angular? Meglesem.
4. Nem túl komplex. Anno úgy olvastam még, hogy ilyenkor ezt kell tenni. Persze tényleg megoldás a 2 külön osztály. Vagy gondoltam, hogy barkácsdolom picit:
- átnevezném az eredeti osztályt
- absztrakt lenne az eredeti osztály
- kivenném az eredeti osztályból azokat a tulajdonságokat, amik nem közösek
- leszármaznék 2 osztállyal belőle. az 1. kapná az eredeti nevet és megkapná a saját tulajdonságát. a 2. kapna egy új nevet és a saját tulajdonságaitÍgy az eredeti néven meglenne az osztályom az eredeti member-ökkel és lenne egy új az új member-ökkel de csak azokkal amik neki kellenek.
Persze lehet marhaság amit akarok, sajnos kuka vagyok még a programozáshoz.Vagy túlkombináltam valamit megint
-
axioma
veterán
válasz #68216320 #10731 üzenetére
Biztos kozos ososztaly kell neked, nem lenne jobb a kozos interface? Mar persze ha arrol van szo hogy azert szeretned oket valahogy kozositeni, mert kesobb egyforman kezelned a kettot (az egyforma tulajdonsagokkal). Ha most sehol nem kezeled egyutt, akkor meg siman ket osztaly, az nem akadalyozza hogy kesobb kozos interface is legyen, ha valos indok lesz ra.
-
#68216320
törölt tag
válasz axioma #10732 üzenetére
Nagyon hasonlóan kezelném őket, de még csakbaz egyik van meg. A különbség köztük annyi lenne, hogy az egyik saját projecten belüli adatokkal jön létre, a másik külső (request) és egyben néhány másik adattal jön létre. A perzisztens rétegben is külön vannak tárolva. Ezen kívül közösen kezelem. Például együtt listázom, stb.
Ennek ellenére semmi akadálya nincs, hogy teljesen külön osztály legyen, hamár külön is tárolom őket.
-
Drizzt
nagyúr
válasz M_AND_Ms #10734 üzenetére
Nem, én ezt rendkívül fontos dolognak tartom. Ha ez nincs végig az ember fejében, amikor kódol, akkor jó eséllyel gányolt minőséget fog kiadni. Az meg most, hogy konkrétan a SOLID betűit feloldja-e valaki, vagy a lényegét elmondja a mozaikszónak, igazából mindegy, de számomra mozaikszót megjegyezni és felidézni sokkal egyszerűbb, mint bármi más módszer.
Juniortól nem ezt kérdezném, mert szinte biztos, hogy nem fogja tudni. Ott nyomatnám az egyszerűbb adatstruktúrák kérdéseit. Senior szinten viszont szerintem ez alapelvárás, akármikor.
I am having fun staying poor.
-
Drizzt
nagyúr
Persze hogy nem. De az mas kerdes, hogy erdemes-e, illetve miert. Az esetek nagy tobbsegeben akkor is kell refaktoralni, ha amugy a kod jo. Pl. ha jon valami olyan uj feature, vagy meglevo modositasa, ami a refaktoralas eredmenyekeppen sokkal egyszerubb lesz, dinamikusabb, kivulrol konfiguralhato, vagy neha epp fixebb, merevebb. Nem veletlenul van tele a refaktoring katalogus olyan lepesekkel, aminek az inverze is benne van. Az egesz refaktoring az agilehoz hasonloan azert terjedt el es lett fontos modszer, mert az it ipar rajott, hogy feature stability szinte semmilyen realis szoftverfejlesztesi projektben nincs.
I am having fun staying poor.
-
#68216320
törölt tag
Azt hiszem megkeveredtem picit a Model és DAO/DTO fogalmakkal. Ha DTO-t használok a perzisztens rétegem és a service között, akkor azt csak ott használhatom? Például nincs értelme mondjuk view-nak küldeni, igaz? Hiszen tartalmaz számára nem publikus adatokat is. Oda kellene a model, ami csak a user számára érdekes adatokat tartalmazza?
Service-ek között mivel viszek át adatokat? Ott DTO vagy Model van?
És mi van ORM esetén?Picit segítenétek átlátni a dolgot? Keresgélek infot magam is, de csak belekeveredtem eddig
[ Szerkesztve ]
-
M_AND_Ms
addikt
válasz Szmeby #10736 üzenetére
"Konkrétan a hozzászólás melyik részét tartod bullshitnek és miért"
Azt, amit kérnek, hogy felmondjon a jelentkező a hr-esnek, mint a leckét az iskolában. Ez számomra a tudás hibás és teljesen felesleges visszakérdezése: fejből tudni és visszamondani az elméleti anyagot, még "ha álmodból keltenek is fel. " Az ilyen tudás megszerzése jön a "magolásból", és nem a gyakorlatból, vagy a rátermettségből. Ez alapján tuti nem a megfelelő és alkalmas embert fogják felvenni.
A tapasztalatom (20 aktív IT, + 10 év egyéb terület) az, hogy az elméleteket halmozó emberek aszok, akik a megbeszéléséken a szót viszik, az elveket hangoztatják és az időt rabolják, de a tényleges munkát már képtelenek elvégezni.
Az ilyen szintű elméleti alaptéziseket nem kell hangoztatni, hanem azoknak megfelelően kell dolgozni. Egy kovács se tudja fejből elsorolni, hogy mi a helyes kalapálás alapelmélete és hogy milyen rácsszerkezetű a vas...egy kovács alkalmazásakor se kell ilyeneket kérdezni ... Vagy egy anesztes orvosnál se kérdeznek az állásinterjún olyat, hogy miből, mennyit adagol a lumbális érzéstelenítésnél és azt milyen szempontok alapján dönti el.Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
Szmeby
tag
válasz M_AND_Ms #10740 üzenetére
Hmm. Azt hiszem, te többet láttál bele a kérésbe, mint én.
Ha neked tennék fel a kérdést egy interjún, hogy szerinted milyen egy jó, minőségi java osztály implementációja, akkor mit válaszolnál?---
A felhozott példákat én egy lehelletnyit túlzónak tartom, a vas rácsszerkezetét inkább hasonlítanám mondjuk a gépi kódhoz, mintsem a kódminőség megítéléséhez. Az meg igazán örvendetes lenne, ha az IT iparban is olyan képzésük lenne az embereknek, mint orvosi fronton, mentoring, sokéves rezidenskedés, stb. Én se kérdezném meg tőle az adagolást, mert feltételezném, hogy pontosan tudja. Na meg a beteg halálozások száma is jó indikátora a hozzáértésnek. -
M_AND_Ms
addikt
válasz Szmeby #10741 üzenetére
"Hmm. Azt hiszem, te többet láttál bele a kérésbe, mint én."
Ez igaz....én csak a vaskalapos, merev és felesleges kérdéseket nem szeretem...
"Ha neked tennék fel a kérdést egy interjún, hogy szerinted milyen egy jó, minőségi java osztály implementációja, akkor mit válaszolnál?"
Megkérdezném a kérdést feltevőt, hogy valóban, ezt az interjúra szánt 10 percet akarja arra felhasználni, hogy megtárgyaljuk, mitől lesz szép egy java kód? Vagy inkább ténylegesen ki akarja deríteni fogok-e tudni hatékonyan együtt dolgozni abban a csapatban, vagy annak az élén ahova épp embert keresnek. Mert pl én azért vagyok épp ott, hogy megtudjam ezt (a java kódkonferenciára ki se öltöztem volna).
Hála égnek, ilyen interjún nem voltam soha, és nem is voltam kényszerhelyzetben, hogy bele kellet volna mennem ilyenbe...Eddig mindig egy kötetlen, informális beszélgetésbe csöppentem, ahol a szűk szakmai dolgokról nem volt szó. Alapértelmezett volt, hogy ha kovácsnak jelentkezem és ők kovácsot keresnek, akkor nem kérdés, hogy mindketten tudjuk, milyen a felpattanó szikrába belenézni (ha ez nem így volna, úgyis kiderülne, egy héten belül)
20 éves tapasztalattal a hátam mögött pedig az a véleményem, hogy egy IT projekt legutolsó, szinte lényegtelen része, hogy mennyire szépen, mennyire jó minőségben (sic) vannak implementálva a java osztályok. (nyilván számít a kód milyensége, de nem ezen fogunk elbukni... mielőtt valaki visszadobná a labdát)
"A felhozott példákat én egy lehelletnyit túlzónak tartom"
A példák, mindig valami túloznak...Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
Szmeby
tag
válasz M_AND_Ms #10742 üzenetére
Értelek, egy 20 éves tapasztalattal rendelkező jelentkezőnél valóban béna dolog a kódminőség felől érdeklődni, tiszta sor. Ezer ennél relevánsabb kérdést is feltehetnének. Ugyan korrigálhatnám a neked feltett kérdésemet úgy, hogy mit válaszolnál a kérdésre akkor, ha junior lennél egy junior pozira, de érzem, hogy a válaszod ugyanaz lenne.
Nekem nincs ennyi év a hátam mögött, de úgy vélem 20 éves múlttal sem feltétlenül sértődnék meg egy ilyen kérdésen, szerintem ha ez érdekli az interjúztatót a legjobban, akkor szíve joga rákérdezni. Nyilván annak is tudatában van a HR (ha meg nincs akkor így járt), hogy egy ilyen kérdés feltevése milyen színben tünteti fel őket. Szerencsére az állásinterjún a felvételizőnek is van lehetősége arról beszélgetni, amiről konkrétan ő szeretne, és én jelöltként is ugyanúgy elvárom a felvételiztetőtől, hogy készséggel válaszoljon a kérdésemre, mint fordított helyzetben. Nem kellemes, amikor megítélik az embert a feltett kérdése alapján. De legalább hamar kiderül, hogy nincs meg az összhang, próbaidő sem kell ennek a megállapításához.
Talán azért ez a véleménykülönbség, mert sokat szívtam legacy kóddal, és sokkal jobban megérint a kódminőség (hiánya), mint másokat. És mivel eddig szinte minden kollégámmal jól kijöttem, annyira nem szokott érdekelni, mennyire jól tudok velük együtt dolgozni... eddig mindig sikerült jól együtt dolgoznunk. Esetedben meg talán máshol vannak a hangsúlyos pontok.
Ez az oka annak is hogy ráugrottam a hozzászólásodra, mert mérhetetlenül sajnálatosnak tartom, hogy a menedzserek mellett sok fejlesztő is tesz a minőségre (szinte lényegtelen összetevőnek tartják), és nem látják, hogy ezzel a saját vagy sorstársaik életét teszik pokollá hosszú távon. Azt hiszem a válaszaimmal igazából csak keresem a megerősítést, hogy valóban az a jó irány, ha a határidőt, a rövid távú sikereket tartja az ember szem előtt. Egyelőre nem sikerült meggyőznöm vagy meggyőzetnem magam, de igyekszem.----
PeachMan:
Hogy ON is legyek, nálam a model az entitás réteget jelenti - vagy perzisztens réteget, ahogy te fogalmazol. POJOk, amelyek már jávául íródtak, de közvetlenül a DB-be mentjük őket és DB-ből töltjük fel őket. Az ORM akítvan használja őket, lévén ők képezik az O-t az ORM-ben.
A DTO (Data Transfer Object) pedig adatok továbbításáért felel a komponensek között, ez jellemzően magasabb rétegekben jelenik meg (ha a perzisztens réteg van alul és a view felül).Hogy mennyire szép elfelejteni a DTO-kat és mindenhol csak a modelt használni, nos, szerintem ez komplexitás kérdése. Egy szép világban nem lenne szükség DTO-ra, mert minek lekopizni valamit pusztán azért, hogy 2 service beszélgetni tudjon egymással. De van egy rakás oka, amiért mégis van létjogosultsága.
Lehet technológiai oka, mondjuk az ORM meg tud zavarodni, ha egy entitásban több collection is van, DTO-k bevezetése jó workaround tud lenni. Te is említetted, hogy a view-nak nincs szüksége minden mezőre, ez is egy valid ok. Főleg akkor, ha nemcsak nincs szüksége, hanem egyenesen tilos egy view-nak látnia minden adatot. Lehet ok a sebesség optimalizálás. Ha egy view-nak csak 1-2 mező kell egy 20 oszlopos táblából, nagyon nem mindegy, hogy mind a 20 mezőt áttolod-e egy microservice-ből a másikba, vagy csak a szükségeseket. Egy DTO-t létre lehet hozni azzal a 2 szükséges mezővel és azt passzolgatni. Az sem mindegy, hogy egy entitásban a kapcsolódó táblák adatai is feltöltésre kerülnek vagy sem, és erre a view-nak szüksége van-e vagy sem. Van, hogy az ORM-et megkerülve jpql vagy akár natív sql végrehajtásával kell felszívni bizonyos adatokat, mert annyira tetü lassú lenne máskülönben, hogy a user megunja az életét. Ez már egy optimalizációs indok lehet, és nem is a fejlesztés legelején kell erről gondolkodni, hanem a végén, de akkor marha nehéz lesz átállni DTO-ra, ha eddig végig az entitásokat passzolgattuk a komponensek között.
Gondolom vannak érvek a model használata mellett is, de most nem jut eszembe ilyen, és biztosan jön valaki, aki arról is tud mesélni. Ja igen, az ORM is nyújthat megoldásokat az általam fentebb felvetett indokokra, csak nem ismerem annyira mélyen őket, hogy mindegyikre tudnék mondani valami dögös annotációt.
DTO-t használni nekem könnyebbség. Nagyobb rugalmasságot ad. Ha változik a model, nem feltétlenül kell a service rétegen keresztülverni a változásokat pl.[ Szerkesztve ]
-
axioma
veterán
válasz Szmeby #10743 üzenetére
Egy kicsit a kodminoseghez. Ez is olyan, hogy at lehet esni boven a lo tuloldalara. Lassan mar hulyenek nezes esete forog fent, amikor rankeroltetik a 16-os complexity-t (vayg mennyire van allitva), nem beszelve az abbol adodo extra feladatokrol (a complexity miatt letrehozott kulon fuggvenynek vajon kell-e ujra parameter-ellenorzest csinalnia, es a unit test-jenek kell-e olyan eseteket is lefednie, ami az egyetlen hivasi helyen nem fordulhat elo?). Szoval en egyetertek az elvekkel altalaban, de nagyon durva amikor valaki nem azt nezi hogy milyen egy masik - az adott feladattal megbizhato! ha valami komplex cucc kozepe, akkor nem egy most esett ki a bootcamp-bol - fejleszto megerti-e, hanem hogy a szintetikus pontozassal mibe tud belekotni.
Nyilvan ez nem jelenti azt, hogy nincs szarul megirt kod. Csak hogy neha annyira de annyira tullihegik... en 20+ ev multtal pont nem tudnam felsorolni a solid betuszo feloldasat, ettol fuggetlenul azert lehet megis annak megfeleloen dolgozni. Kicsit olyan mint a torvenyek betartasa: egyreszt a torveny a tarsadalmi normak osszegyujtese, megfogalmazasa; masreszt meg senki nem tudja beteve a BTK-t, megis tud esetekrol zsigerbol jo ertekelest adni. A solid is nem csak ugy kinott es tanitjak, hanem a "termeszetesen" kialakult best practice-nek egy szaraz, es megis gumiszabaly osszefoglaloja. Kb. arra jo hogy indokolni tudd, hogy a masiknak (vagy plane kezdonek) az elkepzelese miert nem jo, de nem ugy adsz ki tervet a kezedbol hogy elotte gyorsan leellenorzod, hogy vajon stimmel-e minden betu.
Szerintem. YMMV.[ Szerkesztve ]
-
sztanozs
veterán
Így van, viszont ahogy a piacot (illetve a végtermékeket) elnézem, a szoftverfejlesztő cégek legtöbbször csak a kódminőség ismeretét követelik meg, nem az alkalmazását...
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
Taoharcos
aktív tag
Sziasztok!
JPQL lekérdezést szeretnék egy olyan táblából, ami nem tartalmaz egyedi id-t. A táblát nem lehet módosítani. Elvileg a JPA ezt nem támogatja. Van valakinek valami ötlete, hogy lehetne ezt a problémát megkerülni? -
senior tag
válasz Taoharcos #10749 üzenetére
Ha van olyan oszlophalmaz, amiből lehet kulcsot képezni (azaz pl. lehet(ne) rájuk unique indexet definiálni az adatbázisban), akkor az ezen oszlopoknak megfelelő objektumváltozóból lehet összetett kulcsot (composite key) gyártani. (Pl. az
@EmbeddedId
annotációval.)Ha Oracle az adatbázis, akkor lehet próbálkozni azzal is, hogy a ROWID-et rámapeljük valamilyen dummy változóra:
@Id @Column(name="ROWID") String id;
(Magam sohasem próbáltam, de lekérdezésnél akár működhet is... Persze a hordozhatóságnak ilyenkor annyi.)''The third planet is incapable of supporting life. Our scientists have said there's far too much oxygen in their atmosphere.''
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen