Як бути кращим при перегляді коду?

По-перше, я твердо вірю в процес перегляду коду і завжди хочу, щоб хтось інший переглянув мій код. Моє запитання дійсно орієнтоване на те, як я можу зробити кращу роботу, виконуючи перевірку коду для когось іншого?

Я знаю, що для перевірки коду необхідно знати, як працює існуючий код, і знати, що таке місцевий стандарт, і обидва я вважаю, що це я дуже добре знаю. І все-таки я відчуваю, що ніколи не роблю достатньо хорошого перегляду коду для інших людей. Також я знаю, що певні люди, здається, роблять кращий код перегляду роботи, ніж інших, тому мені цікаво для тих, хто є прекрасними переглядачами кодів, які методи ви використовуєте?

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

Зазвичай речі, які я слідую

- Use variables judiciously
- Keep things in scope loose boundaries will generate more errors
- Orient your language of coding in domain specific terms, they make more sense
- Keep loops to minimum 2 for each method if needed
- use ternary operators
- Arrange methods alphabetically
- Keep errors at handling ease
- write less but efficient code

Я думаю, що там можна додати багато.

запитайте себе, що робить інших хорошим рецензентам для вас?

також під час проходження коду;

• зупиніться на чомусь, чого ви зараз не розумієте, напишіть, що коментар потрібен
• визначте, чи відповідає він стандартам кодування: пробіли, дужки, camelCase..etc
• переконайтеся, що він містить усі функціональні можливості
• зробіть просте тестування логіки, щоб побачити, чи проходить вона граничні умови тощо.

Я просто прагну

• пояснення, чому потрібна запропонована зміна. Переконайтесь, що я знаходжу причину не лише у вирішенні
• домовитися про форматування коду - таким чином, щоб кожен виглядав однаково / звично
• обмін списком кодових ознак, які ви хочете зберегти. Розмістіть його на вікі, щоб всім не довелося один раз помилятися. Оновлюйте його часто.

Крім того, "знати, на що звернути увагу" - це просто досвід, практика та читання.

На мій досвід найкращий спосіб - дозволити команді дірок зробити перегляд коду. У кожному проекті ми використовуємо список розсилки комітів, де ви можете відстежувати всі зміни коду в системі контролю версій. Більшість наших розробників підписалися на розсилку розсилки для конкретного проекту, оскільки вони зацікавлені у зміні коду.

Коли хтось помічає поганий шлях у новому вихідному коді, він або пояснює виконавцю, як він може зробити це кращим чином, якщо вчитель є стажистом, або він починає дискусію про це, якщо це був більш досвідчений вчитель.

Звичайно, цей метод не гарантує перегляду нового коду, особливо в стресові періоди, коли ніхто з членів команди не має дозвілля стежити за кожною зміною коду. Крім того, не кожен розробник відповідально ставиться до того, щоб кожен розробник зробив свою роботу добре, тільки за це ви не можете гарантувати її перевірку. Але, принаймні, в наших командах завжди є технічний менеджер, який відповідає за технічну якість.

Я справжній шанувальник оглядів кодів, якщо вони відповідають наступним показникам:

• кожен розробник має можливість переглянути весь код та аргументувати свою думку
• ніхто не має права зловживати іншим кодом
• не тільки поганий код активує дискусію, але й хороший код
• обговорення закінчуються щасливими для кожного залученого
• огляд відбувається майже в режимі реального часу, принаймні до завершення функції

Що я дізнався, це те, що якщо ви хтось, хто переглядає кожен рядок коду і думає, що вам доведеться контролювати такі речі, як якість коду з точки зору форматування коду чи ефективності коду, то ви самостійно дуже неефективні, оскільки ви робите те, для чого можуть робити машини. ти. Вашою метою має бути використання системи безперервної інтеграції, яка контролює якість збірки та коду кожного внеску коду. Якщо ця система створює звіти та надсилає їх учасникам, все ідеально.

Я мушу визнати, що якщо вам доведеться переглянути код, тому що ви повинні контролювати чи оцінювати якість програміста, то мої пропозиції не мають сенсу. У цьому випадку я б також не переглядав вихідний код рядок за рядком. Я б переглянув такі речі, як:

• чи є питання щодо безпеки
• призначені API, що використовуються
• чи застосував код вказаної архітектури
• він писав корисні тести (але тільки якщо він неявно пройшов інструктаж, я повинен був навчитися)
• Документація
• збір-процес
• ... і ще деякі, напевно

Якщо ви досвідчений розробник, ви завжди знайдете такі речі, як петлі, які ви могли б зробити з кращою продуктивністю. Звичайно, корисно пояснити іншим такі знання, але це не повинно бути частиною сеансу огляду. Якщо існують значні проблеми з продуктивністю, то не тому, що він (або вона) використовував менш ефективний варіант типу списку.

Оскільки початкове питання полягало в тому, чому деякі люди, здається, роблять кращий огляд, як інші, я відповів би, що ці люди, можливо, роблять попередній перегляд до початку реального огляду, означає, що вони, ймовірно, підготовлені самі, щоб вони точно знали, що хочуть переглянути. .

[H] ой я можу зробити кращу роботу, виконуючи перевірку коду для когось іншого?

Задайте їм багато запитань

Я знаю, що для перевірки коду необхідно знати, як працює існуючий код ...

Насправді ні, вам не потрібно заздалегідь знати код, щоб бути хорошим рецензентом.

Пару завдань тому мій роботодавець почав вимагати, щоб усі перевірки кодів підписували рецензент. Я в основному робив роботу з графічним інтерфейсом у С, і одним з найкращих рецензентів для мене був мій приятель Білл. Він знав C, але ніколи не робив багато роботи з графічним інтерфейсом, і, заглиблюючись в огляди, не мав уявлення про те, як міг працювати мій код.

Але він задавав багато запитань з цього приводу і мусив пояснювати, щоб він зрозумів, що робив мій код і чому стимулював багато думок з мого боку. Це змусило мене знайти багато дивних маленьких помилок із крайовими кейсами, а також розглянути інші підходи, які я міг би застосувати. Крім того, хоча я писав C протягом 22 років і вважав, що я досить досвідчений, це швидко покращило якість мого коду.

Незважаючи на те, що я більше не працюю там, я все-таки переглядаю різниці перед реєстрацією і запитую себе: "Які питання у Білла виникнуть з цього приводу?" І досить часто я закінчую щось, що змінюється.