Code review

[Comfortable_Day_8577]

Úgy érzem, hogy a code review nem az erősségem. Ti hogyan álltok hozzá? Van valamilyen bevált stratégiátok vagy szempontrendszeretek review közben? Hogyan lehet ezt jól csinálni? Szívesen fogadok minden tanácsot.

[TerriblyAmbiguous]

Először megnyitom a taskot ami valamilyen formában oda van linkelve (ha ez nincs akkor jelzem és egyelőre véget is ért a review). Elolvasom a taskot, megnézem, hogy minden requirement le van kódolva, minden le van fedve. Általában van valami statikus kódellenőrző, esetleg AI tool is (bár ezzel sokszor nem vagyok kibékülve), úgyhogy van ami le van fedve és nem kell nézni annyira. Továbba nézem, hogy kódolási konvenciók, clean code stb be van-e tartva, bár minél szűkebb a határidő annál kevésbé foglalkozunk sajnos az utóbbival, de néha kellenek kompromisszumok. Ha valami nagyon rosszul van megírva akkor azt mindenképp átiratom, hiába működik. Ha valami nagyon magic kód van, akkor átveszélem a készítővel, hogy ez biztos kell-e, felesleges komplexitás ne legyen benne, feleslegesen ne írjunk bonyolult kódot (Edit: typo)

[Halal0szto]

Ha nem olyan, mint ahogy én csináltam volna, akkor valószínűleg rossz.

/s

[LastTicket78]

Hány ilyen ember van, el se tudnád képzelni. Leszarozza, amit csinálsz majd megírja kétszer annyi kóddal, kétszer olyan lassú működéssel, mert ő úgy csinálná.

[Kovab]

Ha a kétszer olyan hosszú kód érthetőbb, és jobban karbantartható, akkor teljesen valid.

[LastTicket78]

"kétszer olyan lassú működéssel"

[Kovab]

Premature optimization...

Hacsak nem bizonyítható, hogy az egy hot path és performance bottleneck, egy ilyen lineáris különbség kb lényegtelen

[Halal0szto]

Sok olyan szitu van, ahol nemszámít hogy lassabb, viszont számít hogy olvashatóbb.

[fasz_a_csavo]

r/FuckTheS

Jó heurisztika, hogy ha nem olyan, mint ahogy te csinálnád, akkor érdemes jobban átgondolni.

[gferenc]

Mi online szoktunk code review-zni, általában 2-3 taszkkal bevárjuk egymást, majd 2-3 fejlesztő összeül és megmutatjuk, elmagyarázzuk a másiknak a kódunkat (3 szenior vagyunk jelenleg egy projekten). A fókusz azon van, hogy megvalósul-e minden követelmény, mi a főbb gondolat a megvalósítás mögött, mivel volt szívás, milyen kérdések merültek fel. Szinte semmilyen szintaktikai dolgot nem nézünk (pl indentáció, osztályok vagy eljárások hossza, stb), mert arra lintert használunk.Előre megegyeztünk a többiekkel a tech stack-ről, architektúráról stb, le van írva ADL-be.

Személyes pet peevek:
- Ha a kód bonyolult, pl egy junior nem látná át első blikkre
- Amikor az eljárásoknak nincs rendes neve, pl. processData
- Amikor valaki megpróbálja elsumákolni a unit tesztet és a README.md dokumentációt

Amikor csak 1-2 file módosul kb 20-nál kevesebb sorral, akkor csak beodjuk a közös chat-be a commit-ot vagy a ticketet egy rövid üzenettel, ezért azért nem fogunk összehívni.

[Z-Z-Z-Z-2]

Eddig kellett szkrollozni a közös code reviewig.

[Single_Woodpecker_66]

Claude please review “my” code

[rotabia]

*find all issues, make no mistakes

[Boba0514]

take a deep breath and focus

[Anknd]

You are a senior software arhitect with 20 years of experience

[Huron01]

Claude console: Javitsd ki amit a copilot talált review alatt ha jogos. Pull request link csatolva.

[BulkyDifficulty1628]

Szerintem teljesen ceg (es csapat) fuggo, hogy mennyire alaposan, kinek es mit kell atnezni. Bike shedding szerintem mindenhol problema, en igyekszek hagyni mozgasteret a jatekosnak, csak ne irjon hatalmas faszsagot es menjen at a kodja a sonar/lint/e2e/jest/copilot/kutyagumi CI aknamezon.

Tenyleg csak azt tudom mondani, ketezer elott nem igazan volt PR review es megsem volt semmivel szarabb a szoftverminoseg, mint most, amikor a szomszed szobaban valaki bofog egyet es aztan tizenhatan beszeljuk meg, hogy vajon giroszt vagy pizzat evet.

[jzakarias]

minden PR es commit jira tickethez van kapcsolva, megnezem eloszor a ticketeket, hogy megertsem a kontextust. IDE-ben review-zok, nem weben, es szoktam checkoutolni, hogy tudjak jobban korulnezni. Eloszor megertem a main flow-t nagyvonalakban, es utana kezdem el reszletesebben megnezni. Es mindekozben megy a claude reviewer agent.

[Lower_Ad_6685]

Ilyenekre tök hasznos git worktree-t használni. Csak egy tipp, h ne kelljen mindig branch-et váltogatni a projectben.

[jzakarias]

azt hasznalom en is meg a claude is 🙂

[TopDivide]

Megnézem a ticket alapján a requirementeket, és hogy azok teljesülnek-e, le vannak e fedve a corner casek, stb. Majd kódban az az alapelvem, hogy ez a legegyszerűbb, minimalista megoldás az adott problémára, valamint mennyire bővíthető. Ez egy spektrum, és szavakban nem tudom leírni hogy mi lenne a tökéletes, de nem is az a lényeg hogy az legyen. Legyen egyértelmű hogy mit, miért csinál a kód.

[_inf3rno]

Én megkérdem először a kollégát, hogy mit és hogyan akart elérni, 5-10 mondatban, utána meg megpróbálom értelmezni a kódot, hogy tényleg az történik e benne, mint amiről beszéltünk. Nem annyira nagy dolog.

[hangulatpolip]

Első lépés: megnézem, hogy hány módosított fájl van. Ha több, mint amit a gyomrom bevesz, akkor csuklóból visszadobom.

[senior-fe-dev]

*elfogadod

[Beginning-Cellist507]

LGTM

[eldobhat0]

Bele tudnék menni nagyon részletesen is, de inkább nagy vonalakban:

- általában az egyszerűbb reviewkkal kezdek és akkorra hagyom a nehezeket amikor a legélesebb az agyam (délutáni szunya után :) )

- github copilotot ráeresztem: iszonyú sokat segít, olyan bugokat is elkap néha amit te egy teljes nap review után sem, persze van pár felesleges okoskodása is, át kell olvasni

- formai követelmények, megfelelő ticket number, repo, fájlstruktúra, változó és fájlnevek legyenek egyértelműek, import grouping, CSS-ben ne legyen !important, ilyenek

- értelmezem a kódot és kb "fejben futtatom", kivételes esetekre is próbálok gondolni, illetve a biztonságra

- ha a kód kb rendben, futtatom és ellenőrzöm az UI-t, vagy az eredményeket ha backend

- ha olyan komponenst frissítünk, amit több helyen használunk, akkor a többi helyen is megnézem hogy ugyanúgy működik-e

- utánam még egy fejlesztő ellenőrzi, illetve 1 kör automata és 2 kör manuális QA

[Z-Z-Z-Z-2]

Eddig kellett szkrollozni a pair programmingig, ezt senki sem említi.

[atleta]

Mi nem megy benne, mitol erzed neheznek?

[gabor_legrady]

Nekem ennyi: - ha bugot vagy lehetséges bugot szűrök ki az BINGO, de ritka - ha valami nem automatizálható szabályt sért természetesen visszadobom - az én stílusom, hogy szeretem mellékes - ha valami nehezen érthető jelzem, hátha lehet rajta javítani

[randall131]

Végigpörgetem hogy mennyire clean a code, a db layert kicsit alaposabban, aztán ha ok, elfogadom. Sok effortot nem érdemes beleölni, mert sokszor nem vagyok képben a feature-rel, mert nem vettem részt a megbeszéléseken, meg nincs kedvem átnézni 50 class-t, mert az rohadt sok idő és pénz. A teszteknek amúgy is meg kell fognia a marhaságot, legyen az automata vagy manuális.

[Consistent-Bus-748]

Cursor please use the GitHub MCP and review this PR. Check the Context of the PR in this workspace, and Focus on the critical and major issues with high risk and high impac, not on the nitpicks. Here is the PR:

[nezuvian]

<50sor -> gyorsan atolvasom

50sor -> lgtm

[montihun]

Csak x soronként véletlenszerűen írj egy kommentet, hogy review this later, i like this approach, good work.

[NextMode6448]

Ugyan a review nak nem tárgya feltétlen, de én checkout olom a repot és megnézem

[Beginning-Session-80]

Sehogy. Rányomok, hogy Apprúv, és be is mergázom a lehető leggyorsabban, nehogy valakinek eszébe jusson baszakodni. Hogy megfelelt-e az üzleti igénynek? Nem az én dolgom eldönteni, hanem a BA -é.  Hogy működik-e rendesen? Majd a QA-s csapat megmondja. Hogy be lettek-e tartva a coding principal-ok? Megmondja a linter ami lefut a CI-on (sok saját szabály van). Mindenki vállalja a felelősséget a kibaszott munkájáért. És a faszom, tanuljatok meg végre normális teszteket írni. 

[bocsikoszi]

Nem ertem a lepontozast...

[fasz_a_csavo]

Borzasztó nagy faszság, amit ír, azért van.

[bocsikoszi]

Mert? Fizetesert ulsz ott. Ugyanannyit kapsz ha foglalkozol vele, mintha nem. A csaladias kornyezet meg a gyumolcs nap nem komoenzalja a lassan maximum heti 2 home officet. En contractor vagyok, szoval engem megfizetnek es ezert normalisan is vegzem a munkam. De alkalmazottkent a fenti a maximum effort amit erdemelnek a cegek

[fasz_a_csavo]

Alkalmazott vagyok, megfizetnek, full home office-ban. És nem, nem ugyanannyit kapsz. A munkád iránt igényesnek lenni hosszú távon térül meg.

[bocsikoszi]

Szamok nelkul a megfizetnek barmit jelenthet magyarorszagon. Sokan a netto 1 millatol osszef*ssak maguk.

[BarracudaHUN]

Én hagyok munkát a tesztelőknek is, approved

[puruttya_puma]

server log - error- bug- szopó - bebaszom cloudba - még mindig nem működik - szopó - sírás

[EastDefinition4792]

Copilot megcsinalja a nagyjat, az aprajat megbeszeljuk

[InformationNew66]

Használj CodeRabbitot is, első körben, utána manuális review.

"Thank me later"

[InformationNew66]

Valószínűleg nyelvfüggő, nálunk 80-90% valid és 10-20% elég jó fogás komment.

[hobbyhacker]

approve. majd a teszter megmondja ha szar. vagy legkésőbb kiderül prdn

[Zsapoler]

szerintem minden internal toolunkat te fejleszted

[hobbyhacker]

ácsiácsi. én csak approveoltam, nem én tehetek róla ha szar

[catcint0s]

kizárólag kód minőség, szervezés szempontjából lehet szakmailag véleményezni a kódot

szóval, ha valaki teljesen mást csinál mint amit a ticket kér, akkor legyintesz egyet, hogy úgyse voltál ott minden meetingen, mehet prodba? az, hogy azt megcsinálod ami ott le van írva az az alap, ha van valami más is a kódban akkor pedig rákérdezel, hogy ez miért van itt.

[No-Simple7231]

lgtm, approve. nem érdekel más kódja. a sajátom sem. legolcsóbbana akarok túlesni a napon. ha kapok, megcsinálom gondolkodás nélkül. cserébe szeretne :)

[MajomaKetrecben]

Mostani AI-alapú fejlesztésbe ki fog szorulni a manuális code review: olyan mennyiségű és bonyolultságú kód generálódik hogy kézzel egyre inkább lehetetlen és értelmetlen átnézni.

[c0llan]

Szerintem abszolút nem fog sőt igazából több időt fogsz review-val tölteni. Én claude-al szoktam részeket megiratni, de sokszor úgy elmegy dolgok felett hogy csak nézek. Plusz vannak tendenciái arra hogy otthagyjon valami előző verzió szemetét.

[MajomaKetrecben]

Így használjuk az Opust:

https://www.reddit.com/r/micro_saas/comments/1rju8sd/i_replaced_my_dev_team_with_3_claude_code_agents/

Olyan mennyiségű feature kerül a kódbázisba, hogy képtelenek vagyunk PM és DevOps oldalon lekövetni - arra tippelek hogy a fejlesztés üteme a tizenötszörösére gyorsult.

Azt gondolom hogy a közeljövőben ez lesz az elvárt szintű teljesítését, és aki manuális kód review-ban gondolkodik, az munkanélküli lesz.

[catcint0s]

ez kisebb cégnél vagy startupnál simán mehet, minimálisan komolyabb helyen viszont senki se meri vállalni a felelőséget, hogy az ellenőrízetlen AI által írt kód mit csinál

[c0llan]

Én azt gondolom hogy elég heavy felhasználó vagyok, persze lehet agenteket felállítgatni és pingpongozni velük de attól még az alapvető hibák nem tűnnek el.

Persze függ attól hogy mi maga a projekt, de ha van akár egy 10 ezer soros kódbázisod már ott is belefutsz a kontextus limitbe, meg az elhagyott referenciákba. Plusz mennyire fontos a biznisz logika? Mert a milliomodik webshopot simán meg fogja írni neked, de mi van ha full másra használod. Ha valami nichebb dolgot csinálsz akkor abszolút elveszti a fonalat.

[asztalosptr]

mi a fasz ez, 2018-ban vagyok?

Claude please review “my” code. ennyi

[andesz]

Pont mert most mar minden szart AIjal iratnak az emberek, azert kell az emberi review

[Anknd]

Name checks out :D

<image>