«Метод навідника» при роботі з пул реквестами

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

Хибна сліпота

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

У 2004 році був сформульований принцип «помилкової сліпоти», і цей термін об'єднує в собі декілька різноманітних феноменів нашого сприйняття. Зазвичай виділяють два види неправдивої сліпоти: сліпоту неуваги і сліпоту до змін. Сліпота неуваги (перцептивна сліпота) передбачає неготовність нашого мозку сприймати зміни, які ми не очікуємо побачити. Як горилу у ролику, яку вже охрестили «невидимої горилою» і навіть окремий сайт для неї зробили. Ще причиною називають неуважність, яка викликана необхідністю повністю сконцентрувати увагу. Очевидно, що ви цей феномен можете відчути, тільки якщо про нього не знаєте. І дійсно, при повторному експерименті з іншими футболістами і зовсім інший макакою ви її обов'язково помітите, так як очікуєте побачити її.

Сліпоту до змін теж можна помітити набагато простіше, є досить багато роликів в інтернеті на цю тему. Навіть National Geographic зняв передачу , присвячену цьому феномену. У звичайних умовах зміна спостережуваної картини миттєво звертає на себе увагу. Однак ми можемо не помічати зміни, якщо вони збігаються з коротким перериванням спостерігається картинки. Це може бути короткочасне моргання екрану, монтажний стик відео або коротка перешкода. В експериментах по сліпоті до змін виявилося , що майже 70% випробовуваних не помічали підміни головного діючої особи, а зміни менш істотних деталей залишалися проігнорованими майже в 100% випадків.

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

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

Підходи до код-рев'ю

Є два різних підходи. Звичайно, їх більше, але мова про нормальних підходах, а не перетворюють рев'ю в бюрократію з профанацією.

Перший — це відкрити пул реквест і прокрутити його зверху вниз (або в якомусь іншому розумному порядку), ретельно прочитавши його, щось виконавши в розумі, прочитавши тести і переконавшись, що вони перевіряють код. Потім взяти в ліву руку Фаулера, в праву — Макконнела та вказати на можливі косяки, погані імена, «тут виділіть клас», «заинлайните метод», «тут же N+1 у вас», «вистачить мокать тести», «це не REST», «ви забули авторизацію», «не треба писати власний метод, він в стандартній бібліотеці вже є» і всяке таке. Ну, або сказати «молодець». Загалом, побути сильно просунутим лінтером і аналізатором коду.

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

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

Метод навідника

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

Відповідальність, начебто, точно так само розподіляється, як і при класичному рев'ю пул реквеста, тільки в механіці парної роботи це не просто формальні правила, а природні умови роботи. Само собою, сучасні команди складаються суцільно з професіоналів, і вважається, що всі більш-менш рівні як прав, так і за інтелектуальним здібностям, тому кількість ролей «командир» і «виконавець» у кожного розробника має бути приблизно порівну. У результаті виявиться, що в половині випадків кожен розробник виступає виконавцем, а у другій — командиром. Знову ж таки, «виконавець» зовсім не означає, що тварюка він тремтяча і просто натискає на кнопочки, зовсім ні. Обговорення, аргументації та доводи повинні бути з обох сторін. Але остаточне рішення має бути за «командиром».

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

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

Висновки

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

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

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

  1. Дати ревьюверу необхідне почуття відповідальності за пул реквест.
  2. Показати виконавцю, що ревьювер — це не формальність чи бюрократія, а напарник, який допоможе уникнути помилок.
  3. Налагодити правильний, конструктивний діалог між цими двома.

Опубліковано: 27/05/19 @ 11:09
Розділ Різне

Рекомендуємо:

Висновок інтернет-магазину ортодонтичних товарів в топ 3
Go дайджест #8: нові фішки Go playground, що нас чекає в Go 1.13, належить мова його спільноти по-справжньому?
Новий стандарт Wi-Fi 6: можливості для розробників
Як ми створювали новинні заголовки російською мовою з допомогою Deep Learning
Чому я вибрала Project Management і не помилилася. Поради тим, хто роздумує