2016 van, sokan még mindig azt csinálják, amit tavaly, ugyanazokat a régi hétköznapi és triviális feladatokat, ugyanazt a régi unalmas kódrészletet írják kódolási gyakorlatokkal, ugyanazzal a régi unalmas és nem hatékony módon. Az embereknek javítaniuk kell, és változtatniuk kell azon, ahogyan néha szórakozásból csinálnak dolgokat, máskor pedig a hatékonyság és a minőség érdekében. Van valami, amivel mindhármat a csapata számára biztosítom.
Beszéljünk a „kódellenőrzésről”,az egyik legfontosabb kódolási gyakorlatról, és arról, hogyan tehetjük érdekesebbé és hatékonyabbá, és hogyan lehet minden nap új dolgokat tanulni.
NYILATKOZAT: Sokan közületek használnák a fent említett technikákat, így nem kell sikoltoznia, tudom, hogy igen, ez egy informatív módja annak, hogy elmagyarázzuk a dolgokat Önnek és azoknak, akik még nem követik azokat. Személyes nézet, hogy ezek a technikák nagymértékben segítik a fejlesztői csapatokat, ha másként érzed, nyugodtan hagyd figyelmen kívül ezt (a tetveseknek úgy tűnik, semmi sem segít! ;) ).
Rendben, tehát a klasszikus magyarázatot követem a WWH(What, Why and How?)módon.
A mi?
TL;DR – A kód áttekintése több, mint a forráskód áttekintése, ez a szerző áttekintése, a bíráló áttekintése, az üzleti követelmények áttekintése, és mindig a csapat felülvizsgálata.
A Code Review definíció szerint a számítógépes forráskód szisztematikus vizsgálata (gyakran peer review néven is ismert). De várjunk csak, többről van szó, mint egy „Wiki-cikkről”, a cikkben szereplő semmi olyasmi, amit esetleg még nem tud. A kód áttekintése több, mint a forráskód áttekintése, ez a szerző áttekintése, a felülvizsgáló felülvizsgálata, az üzleti követelmények áttekintése, és mindig a csapat felülvizsgálata. Vegyük őket egyenként – Áttekintés a
- Szerző
A szerző a fő ellenőrzött személy, akit a folyamat során felülvizsgálnak. Az ő képességei adják át a kritikus hőjét, és kódja, aminek a tűzbe kell lépnie, és tisztán és tökéletesnek kell lennie ahhoz, hogy minden hibától megszabaduljon. De sajnos ez ritkán fordul elő. Mindig van egy rés a páncélban, egy bonyolult darab megjegyzések nélkül, nincs értelme változónévvel vagy valami mással. A szerzőnek kell gondoskodnia arról, hogy ne csússzon bele annak a csapdájába, amit én „Fejlesztői illúziónak” nevezek. Ez egy olyan mentális állapot, amikor a fejlesztő egy hosszú órán keresztül kódol, és tévedésbe kerül. legyőzhetetlennek látja magát és kódját, különben elmulasztja a követelmény nagy részét, mert túlságosan egy fontos probléma megoldására vagy egy összetett logika megírására összpontosított.
- Recenzens
Az a személy, aki megkérdőjelezi a kódexben szereplő etikát és erkölcsöt. Nagyon fontos a nyitottság, mivel a kódellenőrzési folyamat nemcsak a szerzőt, hanem a lektort is érinti. Minden kódrészletre úgy tekintek, mint a tudás óceánjára, új gyakorlatokkal és nézőpontokkal egy konkrét cél eléréséhez. Bár a recenzensnek kell a betekintést nyújtania, úgy érzem, ugyanolyan felelősséggel tartozik a szerző tiszteletben tartásáért, gondolkodásáért, és megpróbálja a szerző megvalósítását egy másik megközelítésnek tekinteni, és tanulni belőle az ő javára. A felülvizsgálati folyamat soha nem válhat amano a mano helyzetté.
- Üzleti követelmény
Az ok, amiért a kódrészlet odakerült az első helyre. A kód megkérdőjelezésekor nagyon fontos szem előtt tartani azt a követelményt, hogy a kód teljesítse, és ellenőrizze, hogy a kódsorok száma igazolja-e a követelményt, és a követelmény valóban pluszt jelent-e az ügyfél számára. Ha nem ez a helyzet, akkor vagy kérje meg a vállalkozást, hogy vizsgálja felül a követelményt, vagy módosítsa a kódsorok mennyiségének csökkentését. Ez ugyanolyan fontos, mint a kóddal kapcsolatos többi szabványos probléma.
- Csapat (a legfontosabb)
Nem lehet figyelmen kívül hagyni azt a tényt, hogy a nem túl jó megjegyzéseket tartalmazó kódellenőrzés (kerülték a „rossz” szó használatát, mivel sok véleményezőnek nagy az énje) kivétel nélkül rosszul tükrözi a csapatot. De van ennek egy másik oldala is, mindig is szerettem az idézetet – „A csapatod olyan erős, mint a leggyengébb értékelőd!”, tartsd észben az idézetet, ahogy a továbbiakban bemutatom. ezt később az írásban.
FONTOS: A kódellenőrzést nem csak az alkalmazásfejlesztés-specifikus kódra szabad elvégezni, hanem olyan dolgokra is, mint például az egység, az integráció, az automatizálás, a kézi tesztek stb. Mindent, ami az alkalmazáshoz kapcsolódik, át kell tekinteni, mielőtt elfogadná. Ez egy nagy félreértés a kód áttekintése során, ügyeljen arra, hogy ne essen a gödörbe, mert egy egységteszt rontott, ugyanolyan káros, mint egy rosszul felülvizsgált fejlesztési kód.
Tehát a kód áttekintése mindezt és még sok minden mást tartalmaz, de ez lefedi a lényeget. Most pedig a „Miért?” része.
A Miért?
TL;DR – „a tervezési és kódellenőrzések átlagos hatékonysága 55 és 60 százalék”.
Igen, tudom, hogy elég hülyeség a miértről vitatkozni, de a miértben több is van. A kódellenőrzés által kínált nyilvánvaló előnyökön kívül néhány további dolog van, amelyet nem hangsúlyoznak eléggé, vagy egyáltalán nem tárgyalnak:
- Jobb megértést tesz lehetővé a csapattagoknak, amint egymás szemszögéből és gondolkodásából tanulnak.
- Segít fenntartani a konzisztencia szintjét a kódalap, a tervezés és a minőség között.
- Segít az egységesség elérésében a csapaton belül azáltal, hogy minden tagot egyformán jártas.
- Az egységesség ezután még akkor is konzisztens minőséget eredményez, ha kevés a tagok elérhetősége.
- Mechanikus szolidaritást épít a csapat tagjai között.
- Alacsonyan tartja a csapat technikai adósságát.
Ezeken a fantasztikus okokon kívül szeretném idézni a „Code Complete”-t – egy remek szöveget a kódolási képességekről: „a tervezési és kódellenőrzések átlagos hatékonysága 55 és 60 százalék”. Azt hiszem, ez megfelel azoknak, akik számokat keresnek.
A Hogyan?
Itt válik érdekessé, ezért gondoltam először a cikk megírására. A „mit” és a „miért” csak a kód felülvizsgálatának „hogyan” prológja volt. Térjünk rá.
TL;DR – „A csapatod olyan erős, mint a leggyengébb értékelőd!”
Csakúgy, mint a főzés megkezdése előtt, itt is szüksége van az összes összetevőre, itt is szüksége van egy sor eszközre, amelyek elengedhetetlenek ahhoz, hogy átvészelje a kódellenőrzési folyamatot:
- A kódellenőrzés fókuszterületei azok súlyosságával együtt
A fókuszterület olyan dolog, amelyre a projektnek több figyelmet kell fordítania, mint például a biztonság, a teljesítményproblémák stb. Ez nagyon eltérő lehet projektenként. Tehát menj előre, és dönts a sajátod mellett.
- Kód-ellenőrző lista
Az ellenőrzőlista általában olyan dolgokat tartalmaz, amelyeket meg kell jegyezni és meg kell erősíteni, mielőtt végül bejelentkezne az adott kódrészletnek a tárolóba. Ezek olyan dolgokat tartalmazhatnak, mint a szerzői megjegyzések, az összeállítási figyelmeztetések eltávolítása stb. Az ellenőrzőlista projektenként, sőt csapatonként is változhat. Keresse ki a Google segítségével, ötleteljen a csapattal, vagy repüljön egyedül, és készítsen ellenőrzőlistát csapatának és projektjének.
- A csapattagok listája kódkompetenciájuk szerint rangsorolva az összes fejlesztési típusra és területre vonatkozóan (én ezt nevezemLektori osztályzatok listája).
Most ezt részletesen kifejtem, nehogy rossz módon keresztbe vágjak. Ezek a listák többé-kevésbé nagyon ingadozóak, mivel gyakran frissülhetnek, amikor a csapat tagjai elkezdenek tanulni és fejlődni. Ezek nem célja, hogy csapást mérjenek az egyén egójára, vagy kétségbe vonják képességeiket. Ennek megértéséhez egy paradoxont állítok fel: "az emberek különböző szintű hatalmat birtokolhatnak, és mégis mindenki lehet erős". Tehát hozzon létre n számú listát, amelyben felsorolja a csapattagok képességeit. Mindegyik lista más fejlesztési tartományt jelezhet, mint például a felhasználói felület tervezése, a webszolgáltatások stb. FONTOS: Beszélje meg ugyanezt a csapattal, és hajtsa végre a szükséges változtatásokat, ha a csapat úgy akarja.
Ezek birtokában megkezdhetjük a kódellenőrzési folyamatot.
A kód áttekintése akkor kezdődik, amikor a vonakodó fundamentalista (kódoló) elkezdi lőni az ujjait a billentyűzeten, hogy groteszk kódot állítson elő. Túl sok vita folyik arról, hogy a kódolónak folyamatosan felül kell-e néznie a kódját, még akkor is, amikor leírja?, én amellett állok, hogy igen, igen, meg kell tennie, mivel ez nagymértékben lerövidíti a felülvizsgálati folyamat idejét, miközben kissé növeli a fejlesztési erőfeszítést, és mivel ez egy A megszokás ereje a fejlesztési erőfeszítés vissza fog térni arra, ami volt. Ebben a felülvizsgálati szakaszban a fejlesztőnek a fejlesztői ellenőrzőlistát kell használnia, és szem előtt kell tartania a fejlesztéssel foglalkozó fókuszterületeket.
A fejlesztés befejeztével kezdődik a felülvizsgálat következő fázisa, ahol a kódolónak fel kell keresnie a ellenőri osztályzatlistát, hogy megtudja, ki a leggyengébb a tartományban (kivéve önmagát), és rá kell vennie a kód felülvizsgálatára. Ezt nevezem „újonc műveltségnek”nek, ahol a legtöbb kisebb problémát és hiányosságot meg kell szüntetni. A legjobb része ennek a fázisnak, hogy a gyenge bíráló ötletbörze jut a kódolóval és elemzi a hibákat, ha vannak, és ez lehetőséget ad a recenzensnek, hogy új perspektívát lásson, és megvitassák a problémával kapcsolatos egyéb megközelítéseket.
Amint a újonc műveltségifázis befejeződik, a következő és az utolsó szakasz kezdődik, amit én "bölcs öröklésnek" nevezek, ahol a felülvizsgálatot a tartomány legjobb véleményezője végzi. Itt ragadnak meg a logikaibb és funkcionálisabb hibák és problémák, és részletesebb betekintést kaphatnak a kódolótársak. Ez egy fontos tudásöröklési szakasz a kódolótársak számára, amíg el nem érik ugyanazt a jártassági szintet.
Most, hogy válaszoljak néhány olyan kérdésre, amelyek szerintem felmerülhetnek:
1. A bírálók száma az utolsó két szakaszban?
Személy szerint úgy gondolom, hogy véleményenként egy értékelő elég tisztességes, de ez nem kőbe vésett, mindig összekeverheti az igényeinek megfelelően.
2. Miért kell átmenni a két vélemény miatti gondon? Miért nem tartunk egyszerűen egy nagy csapat áttekintő megbeszélést?
Ez az, amin sokat gondolkodtam, mielőtt elkezdtem írni. Az agilis folyamatkörnyezetben dolgozva úgy érzem, nagyon értékes a csapat ideje, amit egyszerre kell eltölteni, és megkockáztatom, hogy az áttekintés még mindig nem lesz csiszolt. Az ehhez hasonló találkozókon a sikeres és eredményes pontok száma, amelyeket fel kell hozni és át kell jutni, fordítottan változik a találkozón jelenlévők számával, ami szomorú, de kemény és igaz tény!
További kérdéseit/javaslatait írja meg megjegyzéseiben, szívesen segítek/tanulok.
Nyugodtan használja/módosítsa/dicsérje ezt a technikát, és ahogy Bolygó kapitány mindig mondta, „Tiéd az erő!”
Béke!
