Як надати відгук після перегляду коду

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

1. Чи повинен я сам виправити код?

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

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

Коротка відповідь

Чи повинен я сам виправити код?

Немає.

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

Так. За вашими пропозиціями , а не за вказівками . Інструкції звучать занадто авторитетно.

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

Використовуйте інструмент для надання відгуку. Ви можете використовувати Visual Studio.

Довга відповідь

Раніше я використовував Visual Studio, але мені постійно доводилося питати інших розробників: "Ей, чи можете ви надіслати мені свою роботу, щоб я міг її переглянути?" Мені це не подобалося, і це ніколи не вийшло дуже добре. Зараз я використовую помічник з огляду, оскільки я можу розпочати огляд, переглядаючи чеки. Мені не потрібно покладатися на іншого розробника, який надсилає мені роботу на розгляд. Це також допомагає мені позначити елементи як дефекти або просто позначити предмети, які слід переглянути автором. Це працює для нашої команди, оскільки щойно ми починаємо огляд, він залишається прямо там на рецензійній дошці і не втрачається при перекладі. Це інтегровано з Visual Studio. Як я вже згадував, Visual Studio також має свій власний процес перегляду, але я вважаю, що він має обмеження, і процес не є природним; тому я використовую помічник з огляду.

Цей інструмент також допомагає в процесі назад і назад, дискусіях тощо.

Процес, більш-менш, такий:

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

Огляди коду є чутливою областю, тому будьте дуже уважні до вибору формулювань. Я нікому нікому не кажу

Поганий вибір формулювань

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

Я замість цього кажу:

Кращий вибір формулювань

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

Це змушує автора думати:

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

Ці прості варіанти слова дуже допомогли мені.

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

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

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

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

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

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

Вони чудово відчувають, що мають сили дивитись на мою роботу і говорити: "Так, ваші зміни хороші. Я закрив питання".

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

1. Автор з цього не навчиться.
2. Це так, як я кажу: "Відсуньтесь, дозвольте мені показати вам, як це робиться. Мій код кращий за ваш".
3. Чому б я? Це більше робота для мене.

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

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

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

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

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

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

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

Відповідь на деякі нумеровані питання

1 - чи повинен я сам виправити код?

Ні, будь ласка, дивіться причини, які я вказав вище.

2 - чи повинен я надіслати їм відгуки про процес перегляду та дозволити їм виправити відповідні інструкції?

Так, спробуйте використовувати пропозиції та тон, який є доброзичливим, але все ж вимагає уваги. Будьте максимально чіткими. Вкажіть, у чому полягає проблема з кодом, як його вдосконалити. НЕ просто просити її змінити. Але наведіть причини.

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

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

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

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

Фінальні думки

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

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

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

1. Нехай розробники виправлять код. Це дозволить їм краще зрозуміти ваші коментарі (або зрозуміти, що вони не повністю їх розуміють і не задають), а виконання завдання - кращий спосіб навчання, ніж лише читання про нього.
2. Програмне забезпечення для перегляду коду - це шлях. Існує безліч варіантів, як відкритих, так і фірмових. Більшість це працює з git. Моя команда використовує BitBucket (раніше відомий як Stash), є також GitLab та GitHub, Герріт (який я особисто не шанувальник) та ще безліч інших. Більшість цих додатків веб-базировані, тому не має значення, яким IDE ви користуєтесь, але є також плагіни для багатьох IDE, тому я впевнений, що вони є і для Visual Studio. Таке програмне забезпечення дозволяє переглянути код до його об'єднання в основну гілку (як правило, через Pull Requests), і вона показує модифіковані частини та деякі рядки контексту навколо кожної зміни. Це робить огляд коду вільним та безпроблемним.

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

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

Я голосую за другий варіант. Юніори можуть мати кращу "криву лернінгу" при проведенні самих змін.

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