Чи повинні брати участь молодші програмісти як переглядачі кодів у проектах старших програмістів?

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

І під час перегляду коду я вірю в наголос на навчанні, не вказуючи на помилки.

Але чи повинні брати участь молодші програмісти в оглядах коду для старших програмістів? Або в оглядах коду повинні брати участь лише програмісти з відповідним досвідом?

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

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

Крім досвіду роботи в інструментах та технологіях, також враховуйте досвід роботи в області застосувань. Хтось із 20-річним досвідом роботи, але лише 1 або 2 у фінансовій галузі, може допомогти, маючи загалом менш досвідченого розробника, який має лише 5-річний досвід роботи у фінансовій галузі, переглядають його роботу.

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

Це дійсно стосується будь-якого виду огляду - вимог, дизайну, коду ...

Чи повинні брати участь молодші програмісти як переглядачі кодів у проектах старших програмістів?

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

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

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

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

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

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

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

• У них взагалі більше часу.
• Вони швидше сприймають це повільно, по черзі, з необхідності розуміння коду.
• Якщо ви говорите про те, щоб код був доступним, це означає всі компанії, а не лише ваші найкращі програмісти. Це означає, що ваші молодші програмісти повинні вміти розуміти код, щоб оголосити його доступним.
• Вони часто рідше роблять погані припущення, довіряючи, що щось працює так, як вони вважають, що має працювати.
• Їх освіта мовою програмування є більш пізньою, і вона менш заплутана разом із багаторічним досвідом іншої мови. Наприклад, старший може випадково скористатися звичкою, яку він взяв із C ++, яка компілює, але працює дуже тонко в Java. Юніори легше підбирають такі помилки.
• Рецензентам коду потрібно лише виявити проблеми, а не обов'язково пропонувати краще рішення. Вони часто коментують: "Я не можу зрозуміти, як зробити це краще, але ця частина справді заплутана через все повторення". Досвідченіший програміст може потім легко вдосконалитись, навіть якщо спочатку вони не помітили проблеми.

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

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

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

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

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

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

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

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

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

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

Юніори, які переглядають код старшого віку, можуть викликати більшу професійну повагу у вашій організації. Старші можуть усвідомити, що вони недооцінювали юніорів, а юніори можуть усвідомити, що старші люди знають більше, ніж їм дали кредит. Юніори іноді думають, що вони мають більші навички, ніж вони. Піддаючись коду, який вони не вміють писати, це добре для цих людей, оскільки вони починають розуміти, що їм ще багато чому навчитися. Це також сприятиме кращому з них, щоб отримати навички. У школі іноді учні B не розуміють, чому вони не отримали А, поки хтось не покаже їм зразок рівня роботи A. Те саме з юніорами та старшими в огляді коду.

Моя відповідь: Іноді . Він буде відрізнятися від програміста до програміста і від завдання до завдання.

Для:

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

Проти:

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

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

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

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

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

Абсолютно молодші інженери повинні хоча б деякий час переглянути код старших інженерів.

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

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

• Ділиться знаннями про те, що відбувається насправді в кодовій базі - "Зачекайте, я думаю, у Білла був клас, який робить X, нам не потрібно писати новий".
• Обмін знаннями хороших методик та стилю програмування.

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

Молодші програмісти повинні абсолютно виконувати перевірку коду для своїх старших колег!

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

Є безліч переваг:

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

• Автор знайде слабкі місця у своєму коді. Молодший дев, швидше за все, буде плутати деякі більш просунуті шматки. Часто вони є "занадто хитрими" для власного блага, і можуть отримати користь від спрощення.

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

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

• Молодший розробник матиме глибші знання про кодову базу. Будьте егоїстичними! Затягнувши молодших дияволів на ранніх термінах, ви зможете швидше передати їх їм.

• Молодший дев буде відчувати себе більш причетним. Молодший розробник почне сприймати "старший" код (та їх колег) як менш чужий та залякуючий. Це надзвичайна і часто недооцінена користь перегляду коду.

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

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

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

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

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

Дві альтернативи можуть бути:

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