Наскільки важливі позитивні відгуки в оглядах коду?

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

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

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

Поліпшення якості та моралі за допомогою оглядів Peer Code
http://www.slideshare.net/SmartBear_Software/improve-quality-and-morale-using-peer-code-reviews

Що потрібно робити: Перегляд коду
http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

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

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

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

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

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

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

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

"Добре, що ця частина має сенс, ах тут є магічне число. Значення цього значення наступний інженер може не зрозуміти, щоб торкнутися цього"

"Я бачу, у вас тут є контейнер DI нормально, так що ви будете мати зв'язок із цим сховищем"

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

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

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

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

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

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

Загальну формулу іноді називають "сендвіч зворотного зв'язку": хороший матеріал по-перше, поганий матеріал другий, хороший матеріал останній. Ідея полягає в тому, щоб загальний тон залишався позитивним, одночасно забезпечуючи отримання негативних відгуків. Це може допомогти запобігти стресу під час очікування огляду, а також запобігти самостійному поглинанню задуму після цього. Обидва дуже важливі щодо продуктивності та якості. Це не просто зворушлива емоційна свинка; Це поведінка людини 101.

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

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

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

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

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

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

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

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

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

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

Фрази, з яких я найбільше дізнався за ці роки:

• "Це цікавий підхід. Що станеться, якщо нам доведеться розмістити [якийсь інший випадок використання]?"
• "Приємна спроба! Чи знаєте ви, що у нас вже є метод для цього? Можливо, нам слід зробити порівняльний аналіз, щоб побачити, який підхід є більш ефективним".

Робочий процес, який мені найбільше сподобався в оглядах коду, був такий:

1. Dev подає патч у списку розсилки / онлайн-інструменті.
2. Кожен, кому потрібно дбати, дивиться на пластир, пропонує вдосконалення.
3. Dev повертається до №1
4. Якщо поліпшення не потрібне, люди кажуть: "Гарна робота, будь ласка, дотримуйтесь". <- ПОЗИТИВНИЙ ЗВ'ЯЗОК. Весь код, який приймається, хороший. Чим менше людей повинні сказати вам змінити речі, тим краще ви робите.
5. Dev здійснює перехід до наступного пункту.

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

Перевагами такого підходу є:

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

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

Я не можу придумати час, коли я коли-небудь бачив код в рецензії, який би змусив мене зайти "О, це здорово". Я можу лише припустити, що якби я зіткнувся з таким кодом, він потрапив би в табір Cool-Yet-nepriceptable.

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

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

Залиште задній простір в паб.

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

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

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

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

Якщо у вас немає коментарів, ви можете вважати, що ви зробили хорошу роботу.

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

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

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

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

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