Junior szoftvermérnökként mindig áttekintettem a kód-áttekintési megjegyzéseket, amelyeket megkaptam, hogy megtanuljam, hogyan lehet jobb kódoló. De amikor eljött az idő, hogy megpróbáljam az első kód-áttekintést, rájöttem, hogy a tapasztalataim nem készítették elő, hogy a másik oldalon legyek.
Fejlesztettem egy súlyos csalóbetegség-esetet, lefelé fordulva a kérdésekkel: Kommentálnom kellene ezt a kódsorot, vagy nem érdemes? Találjak-e cikkeket minden kommentár alátámasztására? Összeomlok a weboldalt, ha ezt jóváhagyom? Utálnak engem? Oké, beismerem, hogy elég gyorsan spirális vagyok. Miután néhány munkatárssal beszélt, tudtam, hogy nem vagyok egyedül a gondjaimban.
Az ifjúsági szoftvermérnökök a következőkhöz hasonlóan feltételezik, hogy „tudod, hogyan kell elolvasni egy könyvet, így tudod írni egy könyvet, és ez nem igaz”, azzal a feltételezéssel, hogy a kódok felülvizsgálatába kerüljenek - mondja Jessica Rudder, a GitHub tapasztalati mérnöke.
Vannak olyan elvárások, amelyek a kód áttekintésével járnak, és a folyamat ideges lehet. Tehát hét másik szoftvermérnökkel interjút készítettem, hogy tippeket gyűjtsenek arról, hogyan lehet felépíteni egy áttekintő gondolkodásmódot.
1. Gondoljon az általános hatásra
Általánosságban elmondható, hogy a jó lehívási igénynek (PR) csak a kódbázis korlátozott részére kell vonatkoznia. A korlátozott hatály azonban nem akadályozhatja meg, hogy a nagyobb kódbázis összefüggésében gondolkodjon a kódváltozásról.
Nigel Munoz, a The Muse egykori teljes stack mérnöke és a jelenlegi szabadúszó szoftvermérnök arra ösztönzi a recenzort, hogy gondolkozzon azon: „Hogyan befolyásolja ez a változás a nagyobb és kisebb képet.” A nagyobb kép figyelembe vétele magában foglalja minden technikai adósság megtalálását - keresse a kódot ez megismétlődik, nem moduláris vagy nem felel meg a legfrissebb szokásos egyezményeknek, valamint elemzi a kódbázis architektúrájának módosításait.
Sam Donow, a Hudson River Trading központi fejlesztője úgy véli, hogy „nincs semmi túl nagy vagy túl kicsi ahhoz, hogy kommentálhassa. A kisebb fejlesztésekre vonatkozó javaslatok nagyobb javításokhoz vezethetnek a kódbázis több részében. ”
Használhat egy PR-megjegyzést a GitHub-on pozitív visszajelzéshez, valamint rámutat arra, hogy a kód eltérhet a React keretrendszer szokásos konvencióitól.
Például az egyik saját kódértékelésem során megjegyzést kaptunk arról, hogy a React összetevő bizonyos tulajdonságai zavaróak, ami szélesebb kérdéseket váltott ki az összetevő használatáról. Végül eltávolítottam a tulajdonságokat az eredeti alkotóelemből, és külön komponenst készítettem, hogy tisztázza mindegyik viselkedését és biztosítsa, hogy mindkettőt több helyen felhasználhassák.
2. Fontolja meg a biztonságot
Ne felejtsük el, hogy néhány változtatás nem csupán a kódbázist érintheti. Rudder azt ajánlja, hogy értékelje, vajon a felhasználó „felhasználhatja-e ezt a funkciót valakinek zaklatására, vagy visszaélhet-e a rendszerrel”. Például, ha a pull kérésben az új szolgáltatás tartalmaz felhasználói belépést, keressen SQL-befecskendezést, adathozzáférést, webhelyközi szkriptálást és egyéb biztonsági rések.
3. Összpontosítson a hibákra
Kódtársai - függetlenül attól, hogy robotoknak tűnnek - emberi lények, és az emberek megszakíthatják vagy elfelejthetik a funkciókat. Ezért ügyeljen arra, hogy „olvassa át a teszteket ugyanolyan jelentőséggel, mint a kód többi része” - tanácsolja Abhishek Pillai, a Teachers Pay Teachers műszaki vezetője. "Megakadályozzák az új hibákat, és dokumentációként szolgálnak bárki más számára, aki a jövőben ezen dolgozik."
A tesztek elolvasása segít megérteni egy új szolgáltatás funkcionalitását és megnézheti a bevezetett különféle eseteket, míg a tesztek elemzése segíthet a hiányzó esetek feltárásában és a jelen PR-ben nem szereplő funkciók megtalálásában. Ha nincsenek tesztek a kódváltozásban, és relevánsaknak tűnik, helyénvaló kérni őket a felülvizsgálaton belül.
De a tesztek nem minden. „Ne hagyjon túl sok hitet a rendszerben” - figyelmeztet Donow. "Csak azért, mert a tesztek futottak, nem azt jelenti, hogy nincsenek hibák."
Érdemes lehet azt is, hogy „futtassa az alkalmazást helyileg, hogy funkcionálisan tesztelje és ellenőrizze, hogy működik-e. Ha nem működik, akkor nincs értelme további áttekintést végezni ”- mondja Ryan Verner, a 8th Light szoftverfejlesztője. Noha néhány értékelő szerint a kézi tesztelésnek nem szabad része a kód-ellenőrzési folyamatnak - részben a szükséges idő miatt -, a Verner úgy véli, hogy ez egy gyors módszer annak meghatározására, hogy kell-e több időt fordítania a felülvizsgálatra, valamint egy stratégiát, amely segít a korlátozásban a hibák elmaradásának növekedése.
4. Legyen csapatjátékos
A klisé új értelmet nyer, amikor a kód átnézi. „Szánjon időt a felülvizsgálatra, mert ez mindenki kódja.” - mondja Verner, aki a „kollektív tulajdonjogot” támogatja. Önnek, mint recenzentnek, arra kell törekednie, hogy megvédje a hibákat, hogy megmaradjanak a hibák, és növekedjenek azzal a céllal, hogy a csapat kevesebb munkát végez.
Pillai gif-ek segítségével ünnepli csapattársainak jóváhagyott és egyesülésre kész PR-eit.
Ugyanakkor Charles Luxton, a The Muse műszaki vezetője arra ösztönzi az értékelőt, hogy megértse és emlékezzen a csapat prioritására. A gyorsan közeledő határidőkkel és a nézeteltérésekkel sokkal később felállíthatók a lemaradáshoz szükséges tennivalók, amelyek biztosítják a jövőbeni fejlesztéseket, és időközben a kérdéses kódra vonatkozó megjegyzés elküldése a Band-Aid, amire szüksége van tartsa boldog a csapatot.
Végül, ha megkérdezi magától, hogy van-e értelme a kódnak valaki számára, aki éppen csatlakozott a csapathoz, és az első néhány hét alatt elolvasta, akkor a kód olvasható és érthető lesz.
5. Használja a tanulás és a tudás megosztásának folyamatát
A felülvizsgálati folyamat minden résztvevő számára lehetőséget ad arra, hogy további betekintést nyerjen a kódbázisba, a nyelvekbe, a keretekbe és a bevált gyakorlatokba.
Matt Jeffery, a The Muse műszaki vezetője azt tanácsolja a recenzensnek, hogy "értse meg a változásokat építészeti szempontból. Az egyik módszer a fájlnevek olvasása, mivel ezek segítenek a kontextust adni. Például, ha az adathozzáférési réteg változását vizsgálja tudod, hogy nem foglalkozol üzleti logikával vagy felhasználói felülettel. "
Használhat egy PR-megjegyzést a GitHub-on a dokumentumok megosztására.
Ha a kódváltozásból tanul, akkor lehetősége van megosztani az ismereteket. "A legjobb, ha elmagyarázza véleményét, és dokumentációval készíti azt." - mondja Luxton. Az Ön által alátámasztott bizonyítékokhoz és a megbízható cikkekhez fűződő linkek nemcsak segítik az értékelőt és a kódírót a különböző megközelítések felfedezésében a végső döntés meghozatalakor, hanem megerősítik a programozási ismereteiket is.
Miközben szem előtt tartja ezeket a tippeket, ne feledje, hogy a felülvizsgálat ideje az emberek készségeinek gyakorlására. "Adja az embereknek azt a kétséget, hogy gondolkodtak a megközelítésükről, és rámutattak a különböző lehetőségekre, miközben megpróbálták eloszlatni a védekezőképességet" - mondja Rudder. "Az egész megjegyzést és egy összefoglaló megjegyzést hagyok - itt van, ami nagyszerű, itt van, amit javíthatunk, itt van, amit meg kell változtatni az egyesítés előtt."
Az ilyen típusú megközelítés mellett nemcsak a kódot védi a technológiai adósságtól, a biztonsági fenyegetésektől és a hibákatól, hanem a csapatot is felépíti.
