Kérések lehívása

A vállalat növekedésével a módszertanok és a munkamódszerek is változnak. Ez a cikk néhány irányelvet és bevált gyakorlatot mutat be, amelyeket hasznosnak találtunk lekérési kérés (PR) végrehajtása során – ellenőrzőként és felülvizsgálóként is –, amelyek megkönnyítik a verziókezelési folyamatot, és segítik a konzisztenciát az összes projektben. A Moveo HLS-nél azt találtuk, hogy ezen alapelvek követése elősegítette az erős kultúra kialakítását.

Pull Request – mi az, és szükségünk van rá?

A PR egy Git-tárhoz benyújtott kérés egy kódrészlet egy meglévő projektbe való egyesítésére. A PR egy elképesztő konvenció, amely számos projekt szokásos működési eljárásává vált. Lényegében ez egyfajta szakértői értékelés, amely meghatározza a kód megfelelőségét egy nagyobb projekt sémáján belül. Ez a „szoftverfejlesztési ciklus nagyon fontos része”, mivel a PR jóváhagyása után beolvasztható a kódbázisba.

Miért olyan nehéz?

A kód felülvizsgálata az egyik legnehezebb és legidőigényesebb feladat a fejlesztési folyamatban. Mindenki más, és minden fejlesztőnek megvannak a saját stílusai és szabványai.

Ellenőrzőként az Ön felelőssége, hogy megbizonyosodjon arról, hogy a kód helyes és jó minőségű, és megőrzi a kód konzisztenciáját és megbízhatóságát, mielőtt egyesítené a fő ággal.

A cél az, hogy mindenki megértse, mit kíván elérni a PR a többszörös fájlmódosítások áttekintésével. Az Ön kötelessége, hogy jobb megoldásokon és különböző megközelítéseken gondolkodjon – és előfordulhat, hogy figyelnie kell az elírási hibákat vagy a stílusproblémákat. A PR szerzőjeként a kihívás az, hogy a bíráló életét a lehető legkönnyebbé tegye. Hasonlóképpen, a felülvizsgálók felelősek a kód megfelelő és időben történő áttekintéséért, mielőtt az életbe lépne.

Miért olyan fontos?

Végső soron a PR-ok azért fontosak, mert biztosítják, hogy a minőségi, ellenőrzött kód összekerüljön a Git-tárolókba. PR-ok nélkül rendetlen és zavaros kód besurranhat és áthatolhat a kódbázison.

A tömör és kiváló minőségű PR-ok lehetővé teszik a fejlesztők számára, hogy hatékonyan áttekintsék és gyorsan egyesítsék a kódot a fő kóddal.

Tehát hogyan fejleszthető az ember a bíráló szerepében?

#1. Olvassa be a kódot, és ellenőrizze élőben

Mindig tartsa szem előtt ezeket az alapvető szabályokat:

  • Mit próbál elérni a kód?
  • Megfelel a tiszta kód és a magas minőség projektszabványainak?
  • Van-e jobb megközelítés a megoldáshoz?

Azt is javaslom, hogy nézze meg az ágat helyileg, nyomja meg a build gombot, és hagyja futni a buildet, miközben visszavált a böngészőre, és tesztelje az új változtatásokat, ha relevánsak.

#2. Tedd a pénzed oda, ahol a szád van

Tegyük fel, hogy beolvassa a kódot, és kezdi azt hinni, hogy jobb megközelítése van, mint amit a PR kínál. Sajnos nem biztos benne, hogy működni fog – mit tegyünk? Érvényesítse javaslatait helyben!

Ha talál valamit, amin javítható, próbálja meg végrehajtani a változtatást a helyi klónjában. Ne javasoljon olyan kódmódosítást, amely nem lehetséges, és nem is fordítható le; állj ellen a késztetésnek, hogy kommentálj, csak a kedvedért.

#3. Írjon hasznos megjegyzéseket kontextussal

Mindig törekednie kell arra, hogy kritikus legyen, és ideális esetben a PR-ben szereplő észrevételek és javaslatok jól fogadják, és minimális oda-vissza valósulással valósulnak meg.

Amikor kommentál, légy kritikus és kihívásokkal teli – de ezt professzionálisan tegye, ne személyesen. Próbáljon meg tanítani és bővíteni mások tudását.

Példa rossz megjegyzésre:

Példák egy jó megjegyzésre:

#4. Olvassa el a címet és a leírást

Ha valaki igyekezett leírást írni a PR-jához, kötelessége, hogy időt szánjon a cím és a leírás elolvasására. Így teljesülnek a felülvizsgálatra váró elvárásai.

Hogyan javíthatom a saját PR-emet?

Az egyszerű válasz az, hogy belépsz a bíráló helyébe, és tedd fel magadnak a kérdést: „Hogyan lehetne ez könnyebb számomra?”

#1. Készítsen kisebb PR-okat

Könnyű nagy PR-t létrehozni. Nehéz apró darabokra bontani őket.

A kisebb PR-ok összeállítása nagyszerű módja annak, hogy felgyorsítsa a felülvizsgálati időt és megkönnyítse a projekt folytatását. A kisebb PR-ok megkönnyítik a bírálók számára, hogy megértsék a kontextust és a logikával kapcsolatos indoklást.

És végül, sokkal könnyebb nem tönkretenni semmit így.

#2. Írjon hasznos leírásokat, címeket és megjegyzéseket

Ahogy korábban említettem, helyezze magát a bíráló helyébe. A hasznos és világos leírás írása nagyon hatékony lehet a bíráló számára, mivel több kontextust biztosít a változás körül, és a PR-t dokumentációként kezeli.

Ha megjegyzéseket fűz hozzá a saját PR-jához, nagyon hasznos lehet a véleményező útmutatása: segíthet a navigációban, indoklhatja a változtatásokat, és sokkal több betekintést nyújthat.

Ennek a tippnek az a legnagyobb előnye, hogy sok időt takarít meg az értékelőnek, mivel világossá teszi a véleményező számára, hogy mi történik magasabb szinten.

#3. Zaj – El!

A PR benyújtása előtt mindig törekedjen a redundáns és szükségtelen kódrészek eltávolítására. Ezenkívül mindig ügyeljen az alkalmazás formázásának fontosságára.

Ezenkívül ne nyomjon le olyan kódot, amely nem releváns a funkcióhoz: tisztelje értékelőjének idejét és energiáját!

#4. Először értékeld magad!

Véleményem szerint ez az egyik legfontosabb folyamat egy fejlesztő számára. Még azt is mondhatnám, hogy az önellenőrzés jobb fejlesztővé tesz.

Azt javaslom, hogy készítsen egy PR-tervezetet, és kezelje úgy, mintha valaki más írta volna. Tudom, hogy nagyon csábító, ha hagyjuk, hogy mások megtalálják a hibákat, de ez a folyamat nem csak a valódi értékelői időt takaríthatja meg – e folyamat során akár jobb megközelítéseken és megoldásokon is gondolkodhat, és saját maga is megtalálhatja a hibákat!

Végül ez az önreflexiós folyamat beépül a mindennapi kódolásodba.

#5. Képzeld el

Ez egy kicsit specifikusabb a front-end fejlesztők számára, de ha megváltoztatta a felhasználói felületet, mindenképpen fontolja meg annak bemutatását! Ez sokkal könnyebbé teheti az értékelő életét – és ha van ideje, akár GIF-et vagy videót is biztosíthat, amely bemutatja a funkciót.

Javaslom az operációs rendszer beépített eszközeinek használatát a képernyőképekhez és a videofelvételekhez.

Mac operációs rendszer:



Windows operációs rendszer:



Befejezés

APR egy csodálatos egyezmény, és a fejlesztési ciklus döntő része. Ez a cikk csak néhány olyan módszert mutat be, amelyek segíthetnek javítani bírálóként és értékelőként a PR-környezetben. Bízom benne, hogy ezek a pontok javítják a PR-élményt mind az Ön, mind a vállalata körüli értékelők számára – és végső soron beágyazzák ezeket a módszereket a vállalata növekedésével párhuzamosan az új csapattagok kódellenőrzési ciklusába.

Van még néhány ötlet vagy tipp, amit megosztana saját tapasztalatai alapján? Kérjük, hagyjon megjegyzést alább!

Köszönöm, hogy elolvasta!