Új hozzászólás Aktív témák

• #22987 CyberPunk666 senior tag mobal #22986

  Új Válasz 2021-08-23 14:43:30 #22987

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  CyberPunk666

  senior tag

  válasz mobal #22986 üzenetére

  É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.

Új hozzászólás Aktív témák