Як відхилити огляд коду, який ви вважаєте непотрібним?

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

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

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

Попросіть тестовий випадок, який не вдається без зміни, яка вдається зі зміною.

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

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

Рецензенти повинні бути об'єктивними.

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

Розглянемо командний підхід.

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

Відхилення - це природна частина процесу перегляду коду.

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

Відповідальність скорочує обидва напрямки.

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

Робіть замітки.

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

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

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

Ви викличете деяку недоброзичливість із закріплювачем, тож переконайтеся, що проблема стоїть (тобто, чи не усунення шкоди завдає шкоди?)

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

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

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

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

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

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

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

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

Проблемним кодом було:

int d[16];

int SATD (void)
{
   int satd = 0, dd, k;
   for (dd=d[k=0]; k<16; dd=d[++k]) {
     satd += (dd < 0 ? -dd : dd);
   }
   return satd;
 }

Під час останньої ітерації d[++k] => d[++15] => d[16]доступний. Оскільки зазвичай наступним елементом була легальна пам’ять (з точки зору підключення до моделі пам'яті C), навіть тривіальні компілятори не створювали жодного виконуваного файлу із дивним поведінкою. Єдиним способом написання тестового випадку було пошук платформи з точно такою ж моделлю пам'яті, що і C (ймовірно, VM).

Однак видно попередню передачу gcc 4.8, яка d[++k]виконується в кожному циклі. Тому в k < 16іншому випадку доступ був би незаконним, і законність програми, що подається компілятору, є частиною договору. Тож умова циклу завжди відповідає дійсності припущень, тому це нескінченна петля. Це може здатися дивним, але це була абсолютно юридична оптимізація - випромінювання system("dd if=/dev/zero of=/dev/sda"); system("format c:")також було б правильною заміною циклу. Є більш тонкі способи вибору прояву поведінки. Наприклад, під час лекції про транзакційну пам'ять я пам’ятаю, що ведучий кілька разів намагався отримати неправильне значення, коли 2 нитки збільшували одне і те ж значення.

Однак C / C ++, на відміну від деяких мов, є стандартизованим, щоб такий спір можна було вести з посиланням на об'єктивне джерело:

• Якщо ви думаєте, що це не проблема, спробуйте довести це за допомогою стандарту C / C ++ (тобто, це призводить до визначеного значення та поведінки)
• Якщо він вважає, що це проблема, попросіть його довести це, використовуючи стандарт C / C ++ (тобто це призводить до невизначеного значення або поведінки)

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

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

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

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

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