Új hozzászólás Aktív témák
-
CyberPunk666
senior tag
"Nem magától értetődő eljutni az architect szintig, viszont ez leginkább az ambíción múlik."
Az én tapasztalataim szerint a fejlesztők többsége SOHA nem jut el a senior szintig sem. Megkapja a titulust x év után, de amúgy a cégek már azoknak is örülnek, akik nem örök juniorok.
Amúgy ez hangosan nincsen kimondva, bátyám vezetőként dolgozik giga multi IT részlegén és a színfalak mögött létező beszédtéma, hogy nincsen elég senior és sokan csak névileg azok, hogy ne menjenek el máshova meg mert muszáj valamerre haladnia. Mármint a cég vezetésében ez rendszeresen téma, csak a halandónak nem kommunikálják ki.
Ahogy az is tény, hogy tilos negatív értékelést adni, hiába ostoba kókler valaki. Aztán meg el van ájulva magától, pedig kamu az értékelése... -
nagyúr
válasz CyberPunk666 #22951 üzenetére
> Az én tapasztalataim szerint a fejlesztők többsége SOHA nem jut el a senior szintig sem.
+1
es ez kb. minden szakmaban igy van
while (!sleep) sheep++;
-
CyberPunk666
senior tag
Én elég savanyú vagyok a kérdésben, de nehezen tudom feldolgozni a beleszaró kollégákat.
Szerintem tömeges probléma, hogy a legnagyobb réteg az alapvető elveket sem tudja, maximum hebegve-habogva elmondani, foszlányokat, hibásan, éppen csak dereng.
(félreértés ne essék, nem bemagolni kell, hanem ha valamit rendesen megértettél, akkor el tudod mondani a saját szavaiddal)Aztán vannak akik el tudják mondani, de igazából nem értik. Kötik az ebet a karóhoz, meg ökölszabály, de igazából nem tudja alkalmazni, nem tud trade off-okban gondolkozni, félreérti. Frázisokat pufogtat, amit hallott, maga sem tudja igaz-e, nem érti, csak jól hangzott és a többi nem értőnek hangoztatva piedesztálra kerülhet. ez a réteg remekül él az agy nélküli copy-pasteből. Majd a process megfogja a bajokat.
Alig van olyan fejlesztő, aki ha valamit már használtak négyszer, de amúgy rossz, akkor nem ötödször is megcsinálja a rosszat, hanem felismeri, hogy az rossz. Hogy megkeresi az értelmét egy processnek és hasznosnak próbálja megcsinálni a letudott helyett...>
Engem rettenetesen kiéget, ha olyan kollégáim vannak, akik trógerek a munkájukban. -
Madwe
nagyúr
válasz CyberPunk666 #22953 üzenetére
Ez van akkor ha a szakma jól fizet s olyanokat vonz be akiknek amúgy közóük nem kéne hozzá legyen s amúgy rohadtul nem is érdekli pket az amit csinálnak. én is elég sokat keseregtem már itt is h a mai “seniorok” elképesztőek sokszor… de ez van, nem érdekli őket a szakma, nem is értenek hozzá, fizu tetszik, kiseggelik a melót, minimum szintet megütik h ne rúgják ki őket, x évente kicsit felnyalják magukat állásinterjúra meg az első 1-2 hónapot próbaidő alatt megtolják, majd visszatespednek
[ Szerkesztve ]
-
Ursache
senior tag
és ez minek tudható be? mi az issue ezzel? amíg van szar, addig légy is. ha megteheti, miért ne tegye? úgy tűnik nem fogja meg a process, vagy mégsem annyira szar amit csinál.
jöhet a jolly joker: nincs más helyette. mint ahogy a burkoló szaki is szarhat bele, ő úgy is pénzénél van/lesz, mert nincs más helyette?! ettől zeng az egész magyar piac/média, és mégis van munkájuk. hogy? ne tegyünk már úgy mintha nem önként vetnénk magunkat a szakadékba és az aljáról jajgatunk: de fáj!
[ Szerkesztve ]
https://www.youtube.com/watch?v=eIri9YLHpOg
-
kexksz
addikt
"fizu tetszik, kiseggelik a melót, minimum szintet megütik h ne rúgják ki őket, x évente kicsit felnyalják magukat állásinterjúra meg az első 1-2 hónapot próbaidő alatt megtolják, majd visszatespednek"
Visszas ez, de ez kvazi racionalis gazdasagi viselkedes, igy a legnagyobb az oradijad.
-
Madwe
nagyúr
válasz Ursache #22955 üzenetére
Nincs ezzel issue, azon túl hogy zavaró tud lenni ha valaki elhivatott a munkájával kapcsolatban s igényes arra amit alkot s közben ilyenekbe fut bele.
nincs azzal baj, ha valakinek ez csak egy letudandó dolog. Az kicsit zavaró hogy már akkora a hiány a piacon hogy nemhogy munkájuk van de már senior meg egyéb jelzőket is aggatnak rájuk. A szememben egy senior nem csak az eltöltött idő miatt senior. De még csak nem is a tudása miatt. Kellenek mellé jó softskillek, processek ownolása, juniorok tanítása is. S igen, szerintem egy seniortól az igényes munkavégzés is elvárható kéne legyen. Igazából már juniortól is, azért 5-10 éve legtöbb helyen tőlük is elvárták, ma meg már seniortól seettől függetlenül ez azon túl hogy zavaró az egyszeri munkavállalót nem kell hogy érdekelje (engem se érdekel azon túl s legalább könnyebb kitűnni) max a munkáltatót - de ahogy elnézem őket se zavarja. S ameddig ez így van addig ez a csoport maxolja ki legjobban a helyzetet tulajdonképpen, ahogy kexksz is írja
[ Szerkesztve ]
-
CyberPunk666
senior tag
Az a helyzet, hogy ha valaki ezt a melót szereti, és ez érdekli, akkor egyszerűen nem lehet nem seniorrá válni, max van, akinek sokáig tart, és nyilván ak örnyezet is komolyan befolyásol. De a többségnek ez olyan munka, mint a sor mellett állni a gyárban, csak többet fizet.
Azt gondolom, hogy a munkaholista és a teljes beleszarás között azért van sok, bőven vállalható, átmenet.
De a hiány miatt semmiféle szűrő nincsen és mindenki projektre kerül, aki látott már falon pókot.
Az a példám valós volt, igazi, éppen most is történik itt Budapesten, hogy nagy global IT cégnél a vezetésben ki lett adva utasításnak, hogy mindenkinek pozitív értékelést kell adni. Az egyik vezető informálisan a karácsonyi bulin elmondta a nagyszájú beosztottjának, hogy valójában a munkája szar és a vezetőt vették elő ezért.Ez az oka annak, ami történik.
Illetve ennek van gazdasági racionalitása egy darabig. Szerintem már a projektek jelentős része fut úgy, hogy pár emberrel kevesebb, jobban haladna. -
CyberPunk666
senior tag
Btw azt sem értem, hogy IT-ban miért nincsen soha semminek következménye. Miért nincsenek standardek, amiket tudni KELL és ha elcseszed, akkor felelős vagy érte. Safety critical területen dolgozom és mindegy mekkora hibát vétesz, az se biztos, hogy a hír eljut hozzád egyáltalán, nem hogy megkérdezze valaki, hogy ezt mégis hogy gondoltátok.
Olyan emberek auditálnak, akik mivel nem értenek hozzá és nem látják át, így lényegtelen semmit sem befolyásoló dokumentálási nüanszokon lovagolnak, hogy legalább imitálják a munkát.
Ez a safety critical terület is kicsit olyan, mint a párizsi, ha tudnád hogy készül, eszedbe nem jutna soha...
De én is látom, hogy a világ mégis működik, szóval lényegtelen az én véleményem, de engem nagyon zavar, mert utálok velük (utánuk) dolgozni. Csak annyit tennének meg legalább, hogy a napi telex adagjuk helyett (munkaidőben) szakmai oldalt olvasnának, már előrébb lennénk.
[ Szerkesztve ]
-
veterán
válasz CyberPunk666 #22959 üzenetére
Az a baj, hogy ilyen mentalitással nagy a veszélye a kiégésnek. Kevesen lelkesednek egy dolog iránt egész életükön át. Inkább telexezzen, lazuljon picit, de végezze el a munkáját átlagos szinten, és maradjon a cégnél/szakmában hosszú ideig!
-
weiss
addikt
válasz CyberPunk666 #22958 üzenetére
a vezetésben ki lett adva utasításnak, hogy mindenkinek pozitív értékelést kell adni.
Fizuemeléskor hogy megy: "Józsi nagyon jó vagy meg minden, de az idén nincs pénz"?
I did nothing, the pavement was his enemy!
-
adrian14
tag
válasz CyberPunk666 #22953 üzenetére
Minek megtanulni bármilyen elvet és miért kellene precíznek lenni, ha pl egy indiai dev felülcsapja egy rossz módosítással a kódodat.
A custmernek úgyis az a lényeg, hogy működjön a program. Az, hogy milyen gányolás van mögötte őt már nem érdekli. A számok számítanak és azokat most azonnal kell hozni. Én úgy gondolom, ha mindenki precíz és pontos embereket alkalmazna, akkor soha nem lenne kész egy feature. + Úgy látom, hogy az üzleti világban az aktuális negyedév legyen fasza nagyon (bármi áron), majd a kövi negyedévet a jövőbeni énünk megoldja. Sz@rjunk bele mindenbe. Az a durva, hogy ez működik és tényleg nem érdemes agyonhajszolnod magad, ahogy látom.
Félreértések elkerülése végett ez kicsit irónia, kicsit az igazság. Mindenki döntse el maga[ Szerkesztve ]
-
Madwe
nagyúr
válasz Vision #22960 üzenetére
Mondjuk az szerintem se függ össze hogy valaki igényes e a munkájára azzal hogy a munkaidejében még telexet se olvas csak dolgozik vagy képzi magát. Mert abból pár éven belül tényleg kiégés lesz. Persze tanulni kell, de időt kell szánni egyebekre is, nem lehet egészségesen 1 seggel 8h intenzíven végigdolgozni… sőt, hatékonyabb is lesz az ember ha szúneteket tart, van magánélete, hobbijai, stb
adrian14 persze, a határidők gyakran backlog növelő, quickfix dirty hack dolgokat szülnek. Ez már csak ilyen sajnos, de egy normálisabb menedzsment azt ki tudja harcolni h olyan deadline legyen ami mind a productnak is megfelel s a szarcubami amit termel az is mérsékelt
-
veterán
válasz adrian14 #22962 üzenetére
Nem értek egyet. Erre van tech lead, senior, architect és a code review a csapatban. Ezek ilyen bullshit válaszok, hogy gányolás lesz úgyis belőle. Nem igaz, csak jó módszertant kell erre építeni. Aki gányol, azt képezni, mentorálni. Ha nem fejlődnik, kirakni. Láttam erre példát, nem is egyszer. Nem lehet mindent az üzletre ráhúzni, és kikiáltani bűnbaknak. Az üzletnek működő feature kell, de nem is a ő feladata, hogy a kód minőségét garantálja. Arra jó esetben fenntart egy szervezetet, az elején már említett szereplőkkel. És nyilván hozni kell a negyedéves számokat, különben mi másért készülne a termék?
-
adrian14
tag
De van, csak valamiért a csapatunkat mindig kifelejtik belőle. Talán most kezd előrelépés történni ebben a témában, de sokáig így dolgoztunk.
@Tapsi: persze túloztam az előző hozzászólásomnál. De én úgy láttam sokszor, ha valami nagyon időigényes és szép megoldás, akkor azt a customer oldalról elvetették az idő miatt. Persze nem mindegy, hogy milyen a domain amiben dolgozik az ember, mennyire lehet elsumákolni a dolgokat, mennyire számít az adott feature. Szóval lehet én voltam rosszkor rossz helyen.[ Szerkesztve ]
-
veterán
válasz adrian14 #22966 üzenetére
ha valami nagyon időigényes és szép megoldás, akkor azt a customer oldalról elvetették az idő miatt
Azt kell megértened, hogy ez nem bug, hanem feature! Egy normális szervezetben van cost/benefit elemzés. Ha valaminek a költsége x, a várható benefit pedig kisebb ennél, akkor azt a feature-t nem szabad lefejleszteni! És itt a benefit alatt ne feltétlenül árbevételt érts, lehet az bármi, ami számszerűsíthető haszon!Biztosan te is dolgoztál már olyasmin, aminek nem láttad semmi értelmét, és végül nem is volt tényleg semmi haszna, miközben ölték bele az embernapokat. Ezt meg kell előzni bármi áron.
-
adrian14
tag
válasz Vision #22967 üzenetére
Igen ezt értem természetesen. De pl.: azt is mondhatja a customer több tárgyalás és mérlegelés után, hogy "oké, ez tök fontos feature lenne, de kaptok rá max ennyi hónapot/hetet. Menni fog?" És a válasz az, hogy persze lehetséges (de egyébként a megoldás kicsit nyakatekert, vagy nem túl szép). Akkor mindenki happy. Itt kanyarodok vissza az első eltúlzott hozzászólásomhoz. Lehet egy dev nagy tudással, clean code-al, mindenféle patternnel meg tudná csinálni az adott feature-t, de van, hogy nincs rá idő. Általában nem úgy működnek a dolgok, mint az elméletben. Simán lehetnek nem várt hátráltató tényezők is, amiket nem lehet minden sprintbe belekalkulálni.
-
CyberPunk666
senior tag
Teljesen félreértitek a mondanivalómat. Szó nincsen a végtelen refaktorról és hasonlókról. Nem a végtelen preiczitás és tökéletesség a téma.
Szerintem NYILVÁNVALÓ, hogy ár / érték arány alapon vizsgálunk mindent egy projekten.
Ha egy modul gány, de megy és nem kell hozzányúlni, akkor felesleges beleölni egyetlen percet is.Én arról beszélek, amikor a munka alacsony minősége lassítja a munkát és pénzbe kerül. A munkák jelentős részét ugyanannyi idő (idő = pénz) alatt meg lehetne csinálni jobban, főleg ha mondjuk egy aktívan fejlesztett dologról van szó.
Egy pillanatig sem arról beszéltem, hogy vegyük elő az ezer éve működő nem fejlesztett projektet és refaktoráljuk. Nyilván semmi értelme.
Munka közben kell pihenni, de egy nem a feladathoz kapcsolódó szakmai cikk nem fog kiégetni szerintem. Meg a telex csak egy példa volt.
-
GeeForGolf
junior tag
válasz adrian14 #22969 üzenetére
Lehet egy dev nagy tudással, clean code-al, mindenféle patternnel meg tudná csinálni az adott feature-t, de van, hogy nincs rá idő. Általában nem úgy működnek a dolgok, mint az elméletben. Simán lehetnek nem várt hátráltató tényezők is, amiket nem lehet minden sprintbe belekalkulálni.
véleményem szerint nagyjából ez a végkövetkeztetése a fenti eszmecserének. rengetegszer tényleg azért nincs clean code meg pattern-ek, mert ott várja még 5 másik ticket a kedves kollegát, amikből 1 egyszerű bug fix, 2 egy új feature, 2 meg olyan komplikált h simán lehetne darabonként 3-4 ticket-et készíteni belőle. természetesen minden tegnapelőttre kell. rutinos dev a létező legrövidebb utat fogja választani az implementációra, törvényszerűen azt ami már éppen nem gányolás, de a sokkal több munkával járó szép megoldásokat hanyagolni fogja, mert ott áll mögötte a PM az ostorral meg a határidőkkel. jaja, tudom, ez nem mindenhol van így stb stb, de azért kellőképpen sok helyen ahhoz, h eszébe se jusson a kedves kollegának nagyon húzni az időt a tankönyv szerinti kódolással. -
M.Úr
tag
válasz GeeForGolf #22971 üzenetére
Egyetértek, szerintem kevés cég van ahol tényleg van idő code reviewkra és hasonlókra. Kis cégeknél ahol 4-5 dev a teljes csapat és folyamatosan sürgős minden, ott a saját dolgaimra sincs időm, nem hogy máséra.
A "Ne telexezzé" dolgot meg nem is kommentálom inkább... Kifolyna az agyam a fülemen ha napi 8 órát a szakmával kéne foglalkoznom. 10 év tapasztalattal, külföldi lead dev pozícióból mondom ezt. -
M.Úr
tag
válasz Vision #22973 üzenetére
Rendben, nem feltétlen a csapat méretén múlik, hanem hogy mennyire ér rá a társaság. Mióta én a mostani helyemen dolgozok, egyszer nem volt olyan hogy ne lennénk 6-12-18 hónapos késésben, súlyos emberhiányban. Kurvasok a projekt és így is nullszaldós a cég. Az okok a vezetésben keresendők... Előző munkahelyem dettó. Heti 10 kötelező túlóra hónapokon keresztül, hogy legalább a késés csak 10 hónap legyen 12 helyett... Ilyenek mellett nincs code review-ra se kedv, se idő. Félreértés ne essék, ez nem követendő példa.
-
Lortech
addikt
Ez azért megmosolyogtató. Code review, de az automatizált tesztelés és clean code is nem úri huncutságok, amik csak az időt viszik, hanem konkrétan azért vannak, hogy időt, tehát pénzt spóroljunk alkalmazásukkal, más-más időtávban persze. Code review már rövidtávon időt spórolhat. Egy fegyelmezett, összeszokott csapatnál, jó coding és style guideline megléte esetén, megfelelően definiált és megfelelő méretű változtatásoknál általában csak formalitás. Ha sokáig tart vagy sok körös, akkor ott van egyéb baj is.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
section9
őstag
Code review normalisabb helyeken mar a compliance miatt is alapnek kellene hogy legyen.
-
Lien
tag
En orulok neki, hogy ezt megirtad! Mivel 90%-ban IT a forum sokan nem tudjak, hogy van ilyenis.
A sorba meg beletennem magunkat is, mint a gepeszmernoknek az epuletgepesz szakiranya akik szinten az epitoiparban dolgoznak de egy picivel(es tenyleg csak egy picivel) jobb fizetest kapnak, mint az epito/epitesz.
A videkkel total egyetertek, diplomas minimalberen voltam, feketezes nem volt de tulora sem tervezesben. Budapest viszont… rengeteg tulora, sok helyen ki sem fizetnek, feketezes(!). Emellett ott a kivitelezes, meg nem voltam benne de szeretnem kiprobalni es latni, az a 2 epitkezes amin voltam nem sok.
Ha pedig valaki epitesz neki az a konnyebb, hogy 5 ev utan siman csinalhatja a kis magan tervezeset, ahogy az epito, epuletgepesz es epuletvillamos szaki is! Onnantol tortenik az, hogy beindul a buli vagy sem. En nekem meg 1 evem van a tervezoihez de sok szaktarsammal ellentetben en nem valoszinu, hogy mostanaban kivaltom(tapasztalatom is nesze semmi fogd meg jol).
Arakat is annyira leadjak, hogy a hivatalos mernoki kamarai tablazati arak alatt (!!!!) terveznek csak azert, hogy Ok kapjak a munkat de ezt nem kell bemutatni.
Sajnos nalam ismet nyilik a bicska kulfold fele, voltam kint fel evet rajzolo kent, teljesen mas az elet ebben a tekintetben, mint itthon.(persze jo nemet cegnel is voltam kikuldetesen kismokus kent, ahol a tulorat nem dijaztak annyira) -
OPiiPO
addikt
válasz Lortech #22976 üzenetére
+1, láttam már projektet bedőlni pár év alatt mivel a code review-t csak úri huncutságnak tartották és megbíztak a drága kontraktor fejlesztőben, hisz ha ennyire drága akkor csak jó lehet. Hát nem, be is dőlt szépen a projekt pár év alatt,a mikor a BAU üzemeltetés emelkedő költségeit már nem bírta el, amelyeket a szarkupac belapátolt kód okozott.
Ha már középtávon is csökkenteni akarod az üzemeltetési költségeket, ahhoz az egyik legjobb alap a 100% code review, ez több projektes tapasztalat. Vicces volt nézni ahogy az egyik beszállítónk, amint bevezettem a 100% code review-t, utána nagyságrendileg jobb minőségű kódot kezdtek el szállítani, és nekiálltak kijavítani ingyen az eddig version control alá betoltat[ Szerkesztve ]
"Felesleges szigetelni a nyílászárókat, ha az ereszcsatornán szökik a meleg."
-
Drizzt
nagyúr
válasz OPiiPO #22980 üzenetére
Én hosszú idő óta először vagyok olyan helyen, ahol code review elvárás nincs. Alapvetően mégis elég jól működnek a dolgok. Regresszió elenyésző mértékben van, code rotting azért jobban. Viszont ha valaki meg szeretné, hogy review-zák a kódját, akkor annak review-zuk. Meg ha valaki tök új és valami fontosabb dolgot csinál, akkor is szoktuk. De a "törzstagoknak" nem. Csak kérésre. Furcsa érzés, mert én is úgy voltam vele, hogy code review nélkül nem lehet élni, de most mégis olyan rendszerben vagyok, ami elég jól működik nélküle is. Mondjuk kurvasok microservice van és olyan 5 embernél több egyen nem dolgozik, de inkább 2 az átlag. Szóval maguk a code base-ek se döbbenetesen nagyok. Ha valami olyan code base van, amin egyszerre 10-nél többen dolgoznak, az szerintem is élhetetlen code review nélkül.
I am having fun staying poor.
-
veterán
válasz OPiiPO #22980 üzenetére
és megbíztak a drága kontraktor fejlesztőben, hisz ha ennyire drága akkor csak jó lehet.
Ettől teljesen falnak tudok menni. Egy contractor nem azért "drága", mert jó, hanem mert nem vetted állományba, és annak az árát meg kell fizetni, hogy bármikor kirakhatod zokszó nélkül. Egy alkalmazottat meg nem. -
M.Úr
tag
válasz Lortech #22976 üzenetére
Konkrétan hárman vagyunk fejlesztők + 1 kontraktor, nagyjából egy tucat projekttel évente. Mindenki senior szinten, a kontraktort leszámítva évek óta összeszokott csapat. Kérdem én, mit code reviewzzak akkor amikor van hogy egy nap 3-4 különböző "sürgős" megoldandó feladatom van? Amikor gyakorlatilag egy éve nem volt senki más az én projektjeimen? Clean code alap, aki nem képes rá az nem marad nálunk. Automatizált tesztelés a tesztelők dolga, nem a fejlesztőké.
Új ember ha van, a kommitjait nézegetem egy ideig, de el nem tudom képzelni miért kéne még évek múlva is azt lesnem hogy a kolléga hogyan színezett át egy feliratot egy gombon... Ti komolyan minden commitot átnézettek másokkal? Önállóság, bizalom? Persze lehet ilyenekkel szórakozni ha van pénz és idő és nem sürget a főnök hogy mikor lesz már kész a feature amit múlt héten ígért meg az ügyfélnek két héttel ezelőttre...
Ha sok a junior vagy fogalmatlan kolléga akkor értem hogy kell a gyakori code review. De hogy ezzel minden nap órákat töltsünk, minden apró változtatást átnézve? Eh.... -
M.Úr
tag
válasz Domonkos #22975 üzenetére
Pénzzel. Értelme persze nem volt a túlóráknak, mert napi 10 órán át senki nem tud koncentrálni huzamosabb ideig. Viszont jól jött a +30% fizu és a csapat ott főleg huszonévesekből állt. Most 35 évesen már biztos nem vállalnám. Mindez Ausztriában volt egy német cégnél, úgyhogy nem volt mutyizás a túlóra kifizetése körül.
-
CyberPunk666
senior tag
Sok apróság szúrt nekem szemet a hozzászólásaidban:
"egy nap 3-4 különböző "sürgős" megoldandó feladat"
"egy éve nem volt senki más az én projektjeimen"
"Automatizált tesztelés a tesztelők dolga"
"hogyan színezett át egy feliratot egy gombon"
"minden commitot átnézettek másokkal? Önállóság, bizalom?"
"ezzel minden nap órákat töltsünk"Amiket kiemelnék, hogy a leírás alapján nem tudod, hogy a code review mire jó és hogyan kell csinálni. Ebben az esetben azt sem csodálom, ha feleslegesnek tartod.
[ Szerkesztve ]
-
MODERÁTOR
Code review az nem az önállóság és a bizalom hiányát jelenti - holott nagyon sok helyen ilyenkor élik ki magukat a fejlesztők a másikon.
Akármi miatt lehet, hogy hibát hagysz a kódban és annak a kiszűrése a lényeg. Pl.: összevesztél az asszonnyal, beteg a gyerek akármi nem vagy ott 100%-ban és ennek a kiszűrése. llletve ha megfelelően van kezelve nagyon sokat lehet tanulni.
Nagyon jó olvasmány a témában: [link]
[ Szerkesztve ]
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
CyberPunk666
senior tag
Én kitaláltam, meggyőztem és leadeltem egy komolyabb code review process changet egy multicégnél. 4 projekt 3 országban háromszámjegyű ember.
Ehhez anno előadást tartottam a vezetésnek, hogy szerintem mit és miért kellene másként csinálni (adatokkal alátámasztva). Ennek keretében elolvastam egy rakás kutatást/cikket arról, hogy milyen hatása van a code reviewnak a fejlesztésre. Voltak tanulmányok, amiket az amazon, microsoft és hasonló cégek csináltak saját termékeiken. Voltak olyan tanulmányok, ahol vizsgáltak mindig is csinálták - sosem csinálták - részlegesen csinálták és menet közben vezették be eseteket és összehasonlították őket.
Nagyon széles körben kutatott témáról van szó, és sok jó anyag van belőle, bár több közülük fizetős sajnos.Egy gyors kivonat amire emlékszem fejből:
- A fejlesztők azt hiszik, hogy a code review-n bugokat kell találni, de a mérések szerint alig találnak ilyet valójában
- A code review mégis nagyban csökkenti a bugok számát, pedig nem találnak közben túl sok bugot
- A code review lényege az olvashatóság tesztelése és a tudás átadása, így a code review úgy csökkenti a bugkat, hogy azokat nem megtalálják, hanem létre sem hozzák, mert nem jönnek létre azok a félreértések, amik a bug létrejöttéhez vezettek volna
- A code review több időt spórol meg az el nem követett bugokon keresztül, mint amennyi időt a review elvisz (azért nyilván értelmes process is kell ehhez mögé és nem exceles baromság)
- A codereview hatékonysága az elején és iteratívan kicsi adagokban jó, az X sornál több módosítás és az Y időnél hosszabb review teljesen eliminálja a dolgot. (Nem emlékszem, de ilyen 1 óra kellene legyen a nagyon maximum hossz, de igazából a 15-20 perc kéne legyen az átlagos, hogy hatékony maradjon, és ehhez a nagyobb módosítást is apró részleteiben, a készülés folyamatában kellene reviewzni és nem a végén egyben).Amikor bevezettünk egy normális review processt, ami az ilyen tanulmányok tanácsai alapján készült, akkor toronymagasan a legkedveltebb változás lett mindenhol. Imádták a fejlesztők nálunk.
Azokba már bele sem mentem, hogy például a modulban amit én reviewztam úgy tudtam dolgozni, mikor a tulaja szabadságra ment, mint a sajátomban. Hogy a kb 1% hatákonyságú átadást-átvétel meetingek helyett szinte szükség sincs handoverre, ami a fluktuáció hatását minimalizálja.
Más ember egész napi munkáját az esetek többségében meg le kellene tudni reviewzni 15-20 percben egyébként.[ Szerkesztve ]
-
OPiiPO
addikt
válasz CyberPunk666 #22987 üzenetére
+1, minden projectemen ezt erőltetem hogy a code review nem egymás baszogatására van, hanem egy interaktív tanulási folyamat ahol a tudás átadásán van a hangsúly és azon hogy egy másik fejlesztő szemszögéből is megvizsgáld a kódod.
"Felesleges szigetelni a nyílászárókat, ha az ereszcsatornán szökik a meleg."
-
MODERÁTOR
válasz OPiiPO #22988 üzenetére
Én megkaptam már CR során, hogy fogjam be a számat, a másiknak van igaza akkor is mert régebbóta dolgozik a cégnél mint én.
Azóta számomra minden jó volt
[ Szerkesztve ]
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
axioma
veterán
válasz CyberPunk666 #22987 üzenetére
Ha nem a jovedelem topicban lenne, azt mondanam hogy temaosszefoglaloba vele. Bar nem vettem reszt ilyen projektben amibe menet kozben vezetik be, de kozben me'gis a hosszu evek tapasztalata bennem most erosen bologat.
Annyi kiegeszitest tennek, hogy a sajat megfigyelesem szerint a nem codereview-ra szant de valamilyen szempontbol jo kodok (esetemben: prog.versenyre kuldott kodok: gyorsabban bekuldott vagy gyorsabban futo) olvasgatasabol is lehet hasznositani. -
nagyúr
Sziasztok!
Ugy adodott a dolog, hogy a cegtol felallt par ember es a projekt kulcsemberei meg lettek kerdezve (koztuk en is), hogy milyen csomag lenne olyan, amiert az elkövetkező 2-3 evben maradnek.
Alapvetően nem terveztem felallni, januarban kaptam uj role-okat, eddig 3.5 even at csak fejlesztettem, ev elejetol kezdve oktatassal, modellezessel, reviewozassal is foglalkozom, illetve egy ujabb kisebb projektet a nyakamba akasztottak.
A tervem az volt, hogy egesz evben szo nelkul teszem amit tennem kell, (volt idoszak amikor tuloraztam, hetvegen is nyomtam a hataridos projekt miatt), aztan majd a szokasos januari bertargyalason eloallok egy ~25%-os berigennyel. Ezt most boritotta a főni, hamarabb megkerdezett.
A felev ertekelon nagyon elegedettek voltak velem.
Br. 800 bér, évi netto 1M bonusz van jelenleg.
4 év relevans tapasztalatom van.
Adjatok tippeket milyen csomagot kerjek, evekre vetitve. Kocsim van 2, alapvetően nem akartam cserelni (egyiket se hasznaljuk sokat, motorozom az ev nagy reszeben), de ki kellene szamolnom megeri-e x penz helyett a ceges auto...
Ilyen macbook, iphone nem igazan erdekel.
Mi az amit szokás ilyenkor még kérni? (reszveny nincs)
[ Szerkesztve ]
-
Jhonny06
veterán
válasz tboy93 #22991 üzenetére
Mármint olyan ajánlatot kell mondanod, hogy azért 2-3 évig fixen maradni fogsz emelés nélkül, vagy évről-évre is lesz valami? Plusz felelősséged lesz, vagy ugyanaz a munkakör, csak maradásra akarnak bírni?
Én csak a kp-ra mennék, a többi juttatás általában bullshit, a pénzből meg úgyis megveszed, ha kell. A céges autót semmiképp nem ajánlom, ha már van 2, amit amúgy is alig használtok.
A 25-30% szerintem reális.
[ Szerkesztve ]
-
JoinR
senior tag
válasz tboy93 #22991 üzenetére
Elégedettek veled, terhelhető vagy, újabb kisebb projekt..stb. Én ilyen kérdésnek olyan meredeken mennék neki, amit nem szégyellnék.
Eleve a nettó 530k azért elég vékony 4 év tapasztalattal, szerintem vállalható, hogy a jelenlegi felelősségi szinten maradva, a fejlődési potenciált és ambícióid figyelembe véve az évi 25% emelés mellett valszeg maradnál. DE egyébként te magadtól többet vársz el, és reméled hogyha 2-3 év múlva team lead/vezető/akármi leszel, akkor a fizu is majd ennek megfelelően változik. -
lacos001
senior tag
Adj isten mindenkinek.
Poltopikba kérdeztem, ide küldtek. 14+ éve nem tudtam erről...
Nincs hozzá közöm, csak egy eNberke kérdését másolnám ide, ha nem gond. Válasz adására én kevés vagyok, nem élek Magyarországon. Kérdéséből kiindulva neki sincs fogalma e téren a loveszről..."Holnap megyek állásinterjúra 1 kínai tulajdonú céghez, az ajánlott állás kicsit “mindenes”: HR, adminisztráció, beszerzés, még csak most alakítják a belső struktúrát, ezért több területre be kell segíteni. Mi egy reális bérigény ilyen esetben?"
Thx ha vmi megközelítést tudtok írni. Semmi egyebet nem tudok jelenleg... ami jobban utalna az állásra...
max ide irányítom ha van rá lehetősége -
nagyúr
-
inferno88
őstag
válasz tboy93 #22998 üzenetére
Ő volt kíváncsi arra, hogy mennyiért maradnál fixen 3-4 évre és nem véletlenül, szóval ne gondold magad pofátlannak, úgyis alkudni fog.
Nem egyszerű jó munkaerőt találni a piacon és az is benne van a pakliban, hogy 3-4 év alatt könnyedén ráunhatsz az ottani dolgokra és lehet, hogy már nagyon viszketni fog a feneked, hogy arrébb ülj, amit a magas összeg tud megvakarni vagy sok esetben az sem.Semper fi!
-
djgeg
őstag
válasz tboy93 #22998 üzenetére
Csak arra figyelj, hogy véletlenül se írj alá olyat ami ezt tényleges szerződésként magábfoglalja (maradni 3-4 évig X ért, kül visszajár vagy kötbér).
Hallottam én már ilyen próbálkozásokat mostanában olyan helyen pl ahol kicsit félrenézték a HO hatásait és most vissza akartak mindenkit rángatni.
Aztán a fél csapat felállt erre a cég, bepróbálkozott egy 20% -os emeléssel és lazább HO val + szabadnapokkal mindezt, kölön szerződésként és a pénz is meg napok is visszajárnak + KÖTBÉR ha lelépsz x idővel korábban. Fel is állt a csapat másik része, csak 1-2 idióta írta alá.[ Szerkesztve ]
"640 kByte memória mindenre elegendő"
Új hozzászólás Aktív témák
- Mini PC
- Vezetékes FEJhallgatók
- Luck Dragon: Asszociációs játék. :)
- Apple iPhone 15 Pro Max - Attack on Titan
- Mibe tegyem a megtakarításaimat?
- Milyen okostelefont vegyek?
- Olimpia: az AI majd törli a sértő bejegyzéseket
- Diablo IV
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Épített vízhűtés (nem kompakt) topic
- További aktív témák...
- Steelcase acélvázas íróasztal/számítógépasztal 120x80x70cm kábelrendezővel 40kg
- Felújított Asus rog strix G15 G1512LI + ajándék, 2025.02.20-ig garis! /INGYEN FOXPOST!/
- BenQ PD3205U 4K Tervezői Monitor!32"/99% sRGB/Pantone/AQCOLOR/Type-c/Mac Ready/Beszámítás!
- Samsung Odyssey G8 Ívelt Ultrawide Oled Monitor!34"/Oled/WQHD/175hz/0,1ms/Freesync-G-sync/Beszámítás
- Ahh! DELL Latitude 3410 Tartós Profi Laptop -60% 14" i5-10210U 4Mag 16GB 512GB SSD FHD IPS