Като младши софтуерен инженер винаги съм разгледал коментарите за преглед на кода, които получих, за да науча как да стана по-добър кодер. Но когато дойде време да опитам първия си код за преглед, разбрах, че опитът ми не ме е подготвил да бъда от другата страна.
Развих тежък случай на синдром на imposter, спирала надолу с въпроси: Трябва ли да коментирам този ред код или не си струва? Трябва ли да намеря статии, които да подкрепят всеки коментар? Ще срича сайта, като одобря това? Ще ме мразят? Добре, признавам, че спирала доста бързо. Но след като говорих с някои колеги, разбрах, че не съм сам в притесненията си.
По-младите софтуерни инженери могат да бъдат подложени на преглед на код с предположение, аналогично на „вие знаете как да четете книга, така че да знаете как да напишете книга, което не е вярно“, казва Джесика Рудър, опит инженер в GitHub.
Има очаквания, които идват с преглед на кода и процесът може да бъде нервен. Така че аз интервюирах седем други софтуерни инженери, за да събера съвети как да се изгради рецензионно мислене.
1. Помислете за цялостното въздействие
Като цяло, добрата заявка за изтегляне (PR) трябва да засяга само ограничена част от кодовата база. Ограниченият обхват обаче не трябва да ви пречи да мислите за промяна на кода в контекста на по-голямата кодова база.
Найджъл Муноз, бивш пълен стек инженер в The Muse и настоящ софтуерен инженер на свободна практика, насърчава рецензента да помисли за „как тази промяна се отразява на по-голямата и по-малка картина.“ Като се има предвид, че по-голямата картина включва намирането на технически дълг - потърсете код това е повтарящо се, немодулно или не се придържа към най-новите стандартни конвенции - както и анализ на модификации на архитектурата на кодовата база.
Сам Доун, основен разработчик в Hudson River Trading, смята, че „няма нищо твърде голямо или твърде малко за коментиране. Предложенията за малки подобрения могат да доведат до по-големи подобрения в множество части на кодовата база. “
Можете да използвате PR коментар за GitHub, за да предоставите положителни отзиви, както и да посочите къде кодът може да се различава от стандартните конвенции на рамката React.
Например, по време на един от моите собствени прегледи на код, получих коментар, че някои свойства на компонента React са объркващи, което предизвика по-широки въпроси за това как компонентът се използва. В крайна сметка премахнах свойствата от оригиналния компонент и създадох отделен компонент, за да изясня поведението на всеки един и да гарантирам, че и двете могат да се използват на повече места.
2. Помислете за сигурността
Не забравяйте, че някои промени могат да засегнат нещо повече от кодовата база. Рудър препоръчва да се оцени дали потребителят „би могъл да използва тази функционалност, за да тормози някого или би могъл да злоупотреби със системата.“ Например, ако новата функция в заявката за изтегляне включва въвеждане на потребител, потърсете инжектиране на SQL, достъп до данни, скриптове на различни сайтове и други уязвимости в сигурността.
3. Съсредоточете се върху бъгове
Вашите сътрудници на код за колеги - независимо колко роботизирани изглеждат - са хора и хората могат да нарушат или забравят функционалностите си. Така че не забравяйте да „прегледате тестовете със същото значение като останалата част от кода“, съветва Абхишек Пилай, технически лидер в Teachers Pay Teachers. „Те ще предотвратят нови грешки и ще служат като форма на документация на всеки друг, който работи по този въпрос в бъдеще.“
Четенето на тестовете може да ви помогне да разберете функционалността на нова функция и да видите различните случаи, които тя ще въведе, докато анализирането на тестовете може да ви помогне да посочите липсващи случаи и да намерите функции, които не се съдържат в този PR. Ако в промяната на кода не са включени тестове и те изглеждат уместни, е подходящо да ги поискате в рамките на прегледа.
Но тестовете не са всичко. „Не влагайте твърде много вяра в системата“, предупреждава Доунов. „Само защото тестваните тестове не означава, че няма грешки.“
Можете също така да искате да „стартирате приложението локално, за да го тествате функционално и да се уверите, че то работи. Ако не работи, няма смисъл от по-нататъшен преглед ”, казва Райън Вернер, разработчик на софтуер в 8th Light. Въпреки че някои рецензенти не смятат, че ръчното тестване трябва да бъде част от процеса на преглед на кода - отчасти заради времето, отнемащо - Вернер смята, че това е бърз начин да се определи дали трябва да инвестирате повече време за преглед, както и стратегия, която да помогне за ограничаване нарастването на изоставането на бъгове.
4. Бъдете отбор играч
Клишето придобива ново значение, когато става въпрос за преглед на код. „Отделете време за преглед, защото това е кодовата база на всеки“, казва Върнър, който се застъпва за усещането за „колективна собственост“. Вие, като рецензент, трябва да работите за защита на изоставането на бъговете от увеличаване на целите, за да дадете своя екип по-малко работи по линията.
Pillai използва gifs, за да отпразнува одобрените и готови за сливане PR-та на своите съотборници.
В същото време Чарлз Лукстън, технологичен лидер в The Muse, насърчава рецензента да разбере и запомни приоритетите на екипа. С наближаването на крайни срокове и несъгласия, които понякога се създават, понякога се създава предмет на задачата за изоставането, което гарантира, че ще бъдат направени подобрения в бъдеще, а междувременно да добавите коментар към въпросния код е Band-Aid, от който се нуждаете, за да поддържайте екипа си щастлив.
И накрая, да си зададете въпроса дали кодът би имал смисъл за някой, който току-що се присъедини към екипа и го чете в рамките на първите си седмици, ще ви помогне да запазите кода си четим и разбираем.
5. Използвайте процеса за учене и споделяне на знания
Процесът на преглед дава на всички участващи място, за да получат по-добра представа за кодовата база, езиците, рамките и най-добрите практики.
Мат Джефъри, технически лидер в The Muse, съветва рецензента да „разбере промените в архитектурно отношение. Един от начините е да четете имена на файлове, тъй като те помагат да се даде контекст. Например, ако гледате на промяна в слоя за достъп до данни знаете, че не се занимавате с бизнес логика или потребителски интерфейс. "
Можете да използвате PR коментар на GitHub за споделяне на документация.
Когато се учите от промените в кода, вие също имате възможност да споделяте знания. „Най-добре е да обясните мнението си и да го подкрепите с документация“, казва Луксън. Връзките, които предоставяте в подкрепа на доказателства и надеждни статии, не само помагат на рецензента и писателя на кодове да проучат различни подходи, докато вземат окончателно решение, но и укрепват знанията си за програмиране.
Макар да имате предвид тези съвети, не забравяйте също, че прегледът е време да упражнявате уменията на хората си. „Накарайте хората да се възползват от съмнението, че са мислили за техния подход и посочете различни възможности, докато се опитвате да разсеете отбранителността“, казва Рудър. „Оставям коментари навсякъде и завършващ коментар - ето какво е страхотно, ето какво може да се подобри, ето какво трябва да се промени преди сливането.“
С този подход не само ще защитавате базата от кодове от технологичен дълг, заплахи за сигурността и грешки, но и ще изграждате своя екип.
