Чи повинні мої колеги переглядати код один одного з системи керування джерелами?

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

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

PS: Ми команда лише трьох розробників, і я побоююсь, що якщо нас буде більше, колега просто не встигне переглянути весь код, який ми напишемо.

Я б сказав ТАК!

Дві швидкі причини:

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

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

Я не думаю, що ви повинні відчувати себе шпигуном. Прийміть будь-яку критику, яку вам хтось надає (якщо вона, звичайно, справедлива). І сміливо дайте іншим людям ВАЛИДНУ критику. Це те, як ми вчимося. Як тільки ми припинимо навчання (або хочемо припинити), то виникають великі проблеми.

Якщо зазначений колега надає хороші та конструктивні відгуки, це фантастична річ, і ви повинні дуже цінувати це.

Цей ВІДКРИТИ помилки, про які ви не думали, коли писали його. Це БУДЕ привести до вас писати код краще , тому що ви знаєте , що інші будуть бачити це.

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

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

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

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

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

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

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

Ви відчуваєте це як шпигунство на (!)? Але з точки зору вашого колеги я б сказав, що він робить правильні речі для свого кар’єрного розвитку. Прочитайте код інших і знайдіть, як вони розробляють та впроваджують логіку, це набагато заробить вас!

ІМХО, якщо хтось вказує на щось неправильне у вашому коді, ви повинні прийняти це та дізнатися у них про те, як написати хороший код

Протягом 6-7 місяців я робив те саме. Не шпигувати, а контролювати якість. Кожен рядок коду для активно розробленого додатку, присвяченого центральному сховищу, 2 основних мов, ще кілька мов, величезні файли для 4 платформ.

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

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

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

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

Сподіваюся, у вас є більш доросла аудиторія.

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

Не ображайтесь і не відчувайте себе спостерігаючим. Подумайте про це як безпечну мережу та досвід навчання.

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

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

Ця практика абсолютно буде ловити помилки і зробити всю вашу команду краще, якщо прийняти його.