Фрустрація з рецензування експертного коду

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

Щоб досягти цього, я представив своїй команді концепцію експертної оцінки. Два пальці вгору в github pull-прохання про злиття. Чудово - але не на мій погляд без гикавок.

Я часто бачу коментарі експертних оцінок від тих самих колег, як -

• Було б добре додати пробіл після <INSERT SOMETHING HERE>
• Небажана додаткова лінія між методами
• Повна зупинка повинна використовуватися в кінці коментарів у docblocks.

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

• Ви можете зменшити цикломатичну складність, ...
• Вийдіть рано та уникайте, якщо / ще
• Анотація запиту БД до сховища
• Ця логіка насправді тут не належить
• Не повторюйте себе - абстрактно та повторно використовуйте
• Що буде, якби Xбуло передано як аргумент методу Y?
• Де для цього є одиничний тест?

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

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

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

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

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

Переглядаючи код, я витрачаю, можливо, від 15 до 45 хвилин на 500 лок. Я не уявляю, як ці дрібні огляди займають більше 10 хвилин, якщо це глибина перегляду, яку вони виконують. Далі, на скільки значення має великий палець від неглибокого рецензента? Безумовно, це означає, що всі великі пальці не мають однакової ваги і потрібно пройти процедуру огляду за 2 проходи. Один великий палець для глибоких оглядів та другий великий палець для "полірування"?

Види оглядів

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

Типи рецензентів

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

Експертна оцінка - це співпраця, а не гра в теги

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

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

Поради

Наприкінці запитання ви написали:

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

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

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

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

Що робити після огляду

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

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

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

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

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

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

Ось практична відповідь:

Сценарій 1 : Ви старший член та хтось, хто може вирішити практику

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

Сценарій 2 : Ви не є тим, хто вирішує практику, або ви відносно молодший член команди

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

Проста відповідь, щоб запобігти "тривіальному" коментарям з перегляду коду, - це наполягати (заради ефективності), щоб рецензент повинен був їх виправити. Тож якщо рецензент виявить, що ви (жах!) Пропустили повну зупинку або неправильно написали коментар, вони повинні просто виправити це і рухатися далі.

На мій досвід, це означає, що:

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

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

Перегляньте процес огляду

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

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

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

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

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

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

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

• Незначні каламбури ("ви порівнюєте булеву з true, це трохи параноїдально ...", ...)
• Незначні порушення стилів ("керівництво стилем говорить X, те, що ви робили, знаходиться поза цим; я б робив Y або Z, залежно від того, яким шляхом ви хочете пройти")
• Кілька пропущених тестових випадків, які не важко написати

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

• Це були б такі речі, як "ні, насправді існує НАЙКРАЩИЙ кращий спосіб написання цього", "ви не обчислюєте те, що очікуєте, тому що ваш тестовий блок пропускає ці крайові випадки" та всі інші важкі проблеми.

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

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

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