Прегледът на кода е съществена част от създаването на висококачествен софтуер.

Едно от нещата, които разочаровах, докато преглеждах кода на колегите по време на работа преди няколко години, беше отношението. При преглед на кода, проведен с няколко души, ако един от тях говори емоционално, лицето, което получава прегледа, вероятно ще бъде уморено и разстроено. Без значение как се преглежда кодът, за да се направи по-добър софтуер, но кой би го харесал, ако чуе садистични думи, когато направи всичко възможно?

Така че ще обобщя 5-те неща, които според мен биха били добре, ако се познавахме.

1. Избягвайте агресивните въпроси

„Защо го написахте така?“

Този тип въпроси карат слушателя да се чувства неудобно. И това смущава хората, които гледат прегледа на кода. Запомнете целта на прегледа на кода. Правим това, не за да критикуваме кода на други хора и/или да запечатаме кой е по-добър, а за да открием грешки предварително и да направим по-добър софтуер.

„Какво ще кажете за този?“

Нека започнем да говорим така. Трябва обаче да изясним, че това не е личен вкус, като дадем подходящо обяснение или причина.

2. Слушайте първо и говорете последен

Ако рецензентът продължава да прави коментари, докато той/тя обяснява кода и намерението, потокът ще прекъсва многократно. И не само тези, които получават преглед на кода, но и тези, които гледат прегледа на кода, се уморяват. Воденето на бележки или запомнянето, вместо незабавното обсъждане на подобрения или въпроси относно кода, е много по-ефективно за избягване на емоционални коментари. Защото те кара да мислиш отново.

В този момент човекът, който е написал кода, ще се нуждае от трика да го отреже правилно, така че да не отнема твърде много време, както по отношение на файл на клас или малка бизнес единица.

3. Похвалете и насърчете незабавно

„Мисля, че този код е много добър.“

„Като гледам кода, който сте написали, сигурно ви е било трудно...“

Какво повече трябва да се каже?

4. Избягвайте ненужните аргументи

Няма по-лош преглед на кода от обсъждането на „Деклариране на променливи в множество редове срещу. Деклариране на променливи една до друга със запетаи”. Разбира се, това не беше основният проблем на прегледа на кода, но нека уважаваме вкусовете на другите хора. Въпреки това, ако ви притеснява, дефинирането на кодови конвенции след получаване на съгласие на мнозинството може да бъде добър начин да избегнете ненужни спорове.

5. Дайте насоки за добър код, но не го насилвайте

„Трябва да промените този ред така.“

Индустриален стандарт ли е? Тогава го приемете. Това основно правило ли е във вашия екип? Приеми го и ти. Има ли потенциална възможност за грешка, ако не го промените? Оправи го веднага.

Това, което имам предвид, е да не налагате промени в кода, който работи независимо от промените. Ако това не е нарушение на индустриален стандарт или основно правило, тогава трябва да бъде техен избор дали да го променят или не. Ако рецензентът наложи такъв код, така че членовете да получат отрицателен резултат като Неуспешен или Отхвърлен, тогава членовете на екипа ще обвинят себе си. Освен това моралът на целия екип ще падне в един момент. Тези заплахи трябва да бъдат елиминирани, когато е възможно.

Първоначално публикувано в https://dev.to на 25 януари 2022 г.