Який найефективніший спосіб перевірити код? [зачинено]

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

Що було найефективнішим для вас для перевірки коду?

Наприклад:

• Чи одна людина вважається воротарем якості та переглядає код, чи команда має стандарт?
• Ви робите перегляд коду як командної вправи за допомогою проектора?
• Це робиться особисто, електронною поштою або за допомогою інструменту?
• Чи відмовляєтесь від оглядів і використовуєте такі речі, як парне програмування та колективне володіння кодом для забезпечення якості коду?

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

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

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

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

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

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

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

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

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

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

Думаю, погана ідея мати єдиного рецензента коду воротаря з багатьох причин. Ця людина стає вузьким місцем, і їм доводиться робити занадто багато перегляду коду (лише для того, щоб проект рухався), щоб дійсно бути ефективним у цьому (60-90 хвилин за один раз - це межа ефективності). Огляди коду - прекрасний спосіб ділитися ідеями та знаннями. Незалежно від того, скільки суперзірок у вашому воротаря, вони можуть навчитися у інших в команді. Крім того, наявність всіх перевірок коду також створює середовище "колективного володіння кодом" - люди відчувають, що вони володіють якістю коду (це не лише QA або воротаря).

У нас є безкоштовна довідка на тему " Найкращі практики перевірки експертного коду ", яка містить 11 порад щодо ефективного перегляду коду. Значна частина цього є тим самим змістом із книги, який Джон згадував у більш дистильованій формі.

Немає виправдання. Практикуйте парне програмування. Його найкращий огляд коду можливий. Будь-який інший механізм призводить до винної гри. Парне програмування викликає командний дух та колективну власність. Крім того, ви обговорюєте ідеї зі своєю парою, швидко провалюєтесь, вживаєте коригувальних дій, і в систему управління конфігурацією (CMS) вводяться лише закодований і переглянутий код. Щаслива пара програмування!

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

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

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

Якщо функція невірна, ми розмовляємо з власником, так само з класом і т.д.

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

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

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

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

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

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

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

YMMV

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

Критична галузь інфраструктури дуже зацікавлена ​​в надійності та повторюваності цього ж. :-)

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

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

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

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

Ми робимо те, що кожен раз, коли нам здається, що огляд коду буде корисним, ми додаємо до модифікованого коменту коментар "// todo: перегляд коду Джо". Зазвичай ми вибираємо Джо, оскільки він володіє модифікованим кодом, але якщо цей критерій вибору не застосовується (як правило, він є), ми просто вибрали когось іншого випадковим чином. І звичайно, якщо Джо на той час є доступним, ми використовуємо старий хороший метод огляду за плечима.

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

Якщо виникає проблема, ми переходимо до традиційних методів спілкування (пошта / чат / тощо).

Цей метод надає нам дві основні якості, які ми прагнемо до системи перегляду:

• дуже легкі накладні
• простежуваність

Ми знаходимо найефективніший спосіб зробити огляд коду - це «1 на 1», використовуючи github, щоб показати відмінності у галузі.

• Чи одна людина вважається воротарем якості та переглядає код, чи команда має стандарт?

  • Залежить від чисельності команди - команда з 3 осіб матиме 1 старшого, який найкраще знає добрі практики, тоді як в команді з 12 осіб може бути 3 або 4 людини, які виконають цю роль.

• Ви робите перегляд коду як командної вправи за допомогою проектора?

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

• Це робиться особисто, електронною поштою або за допомогою інструменту?

  • Персонально. Ми використовуємо git і github, і це чудовий огляд коду та різні інструменти порівняння для полегшення огляду коду.

• Чи відмовляєтесь від оглядів і використовуєте такі речі, як парне програмування та колективне володіння кодом для забезпечення якості коду?

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

Як і у всіх елементах кодування, правильна відповідь повинна враховувати:

• Тип компанії (наприклад, стартап проти великої корпорації)
• Розмір компанії
• Кількість розробників
• Бюджет
• Період часу
• Навантаження
• Складність коду
• Можливість рецензента
• Наявність рецензентів

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

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

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

Потім ми помічаємо розробника для перевірки. У Github є система коментарів, яка дозволяє комусь прямо коментувати відповідний рядок коду. Потім Github надсилає електронний лист до дистрибутива, тому іноді ми отримуємо додаткові очі від інших наших команд.

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

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

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