Code Reviews, які переваги? [зачинено]

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

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

Ми робимо огляди коду дещо інші (можливо).

Ми збираємось всі програмісти разом (щоп’ятниці) і дивимось, що ми зробили за тиждень. Тоді ми обирали, які проекти ми хочемо переглянути, щоб кожен готовий / незавершений проект мав принаймні одного або кількох людей. Потім за годину або близько того ми дивимося на зміни, які були зроблені, шукаємо помилки, як працюють інші проекти тощо. Потім ми обговорюємо, повідомляємо про помилки, як це робити (ми не виправляємо помилок, ми просто вказуємо на них і спам-код з FIXME). Загалом, це зазвичай для нас (10 програмістів) займає близько 2 годин.

Плюси:

• Кожен учасник знає, що відбувається в компанії
• Помилки знаходять швидше
• Це змушує нас писати читабельний код (код, який можна читати без пояснень чи введення!)
• Методи оптимізації / хитрощі / продуктивні програми поширюються швидше
• Програміст як фахівець «еволюціонує» швидше
• Це весело

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

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

Ви можете прочитати цю безкоштовну книгу:

http://smartbear.com/best-kept-secrets-of-peer-code-review/

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

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

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

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

Чи варто робити офіційні огляди коду?

Абсолютно

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

Я б представив дві форми оглядів коду:

Огляди експертних кодів

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

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

Огляди експертного коду (в моєму світі) проводяться до кожного подання. Як це переймається у світі парного програмування, я не впевнений.

Огляди коду групи

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

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

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

Я виявив, що використання цих двох методів збільшує швидкість розвитку інженерів, а також значно знижує кількість помилок :)

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

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

Ми проводили в середньому один сеанс на тиждень, беручи участь 3-5 осіб. Кожен сеанс займав приблизно 3-4 години на людину (включаючи підготовку) та переглядав 200-300 рядків коду (LOC) *. У такому темпі за період, що перевищує 6 місяців, нам вдалося переглянути близько 5 тис. LOC, із приблизно 50K.

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

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

* Це нормальний темп офіційного перегляду коду.

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

Цитується з Вікіпедії (наголос на мене).

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

Ви не згадуєте жодних проблем із якістю, тому, здається, ваша команда вже робить достатню кількість оглядів коду через їх парне програмування. Дивовижно!

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

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

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

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

Які переваги? Що ж, було б краще, якщо врахувати ризики цього не зробити.

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

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

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

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