Чи потрібні огляди коду для молодших розробників?

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

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

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

Тож я розгублений. Чи дійсно потрібен процес перегляду коду? Якщо так, то чому? А якщо ні, то чому б ні?

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

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

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

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

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

EDIT: Причина полягає в тому, що рецензент коду сьогодні перебуває в точно такій же ролі, як пізніше утримувач. Якщо код для нього сьогодні не має сенсу, пізніше він також не матиме сенсу, що робить помилки дорожче виправляти. Отже, ЗРОБИТИ це зрозуміло сьогодні, поки розробник все ще пам’ятає код. Також рецензент може побачити помилки або упущення, які розробник пропустив.

На жаль, мало хто хоче це зробити, але з точки зору бізнесу це має бути обов'язковим.

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

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

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

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

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

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

Швидкий хлопець сказав би: "Вам не потрібен огляд коду, просто робіть програмування пар і пишіть хороші тести" :)

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

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

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

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

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

Огляди коду можуть виявити дефекти раніше в життєвому циклі програмного забезпечення, коли проблеми легше (і дешевше) виправити. У SmartBear ми розробили інструмент перевірки коду експертного коду, а також провели багато досліджень, як зробити ефективні огляди коду. На підставі даних наших клієнтів дефекти, знайдені в огляді коду, на 8-12X дешевше знайти та виправити, ніж дефекти, знайдені в QA. Економія коду сама по собі робить огляд коду вартим, але є більше значення, ніж просто це. Перегляд коду - це відмінний спосіб для того, щоб усі в команді дізналися та вдосконалювалися як розробники програмного забезпечення.

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

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

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

А як щодо тих компаній, які не переглядають код? Вони, мабуть, компанії, у яких багато проблем із технікою, і, як кажуть споживачі, "збоїв" ;-).

Тож дозвольте мені відповісти на всі ваші запитання:

• Так, Процес огляду необхідний.
• Чому? Через причини, про які я говорив вище.

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

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

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

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

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

Яка різниця у втручанні у ваші ідеї перед тим, як перевірити код (огляд) чи пізніше через помилку, бути занадто розумним / важким для розуміння чи недотриманням прийнятих стандартних практик? Це твоє его?

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

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

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

Огляд коду подібний нічого не вартий, але огляд коду з компетентною командою часто може висвітлити щось про дизайн (наприклад, чому слід робити X і Y, але не Z) або вказувати на фактичний недолік (наприклад, виконання Do X призведе до відмови Y з невірних причин).

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

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

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

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

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

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

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

Вони абсолютно необхідні, оскільки у них мало досвіду.