Як вирішити незгоду в огляді коду щодо малоймовірного кращого випадку?

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

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

Я надам приклад:

Я витратив день на написання тестових випадків на зміну алгоритму пошуку переходу, який я створив. Він запропонував мені розглянути незрозумілу справу, що навряд чи трапиться - насправді я не впевнений, що це навіть можливо. Код, який я зробив, вже працює у всіх наших оригінальних тестових випадках та деяких нових, які я знайшов. Код, який я зробив, вже проходить наші 300+ моделювання, які виконуються щоночі. Однак для вирішення цього незрозумілого випадку знадобилося б 13 годин, які можна було б витратити на спробу поліпшити робочі характеристики. Зрозуміло, що попередній алгоритм, який ми використовували до цього часу, також не обробляв цей неясний випадок, і не один раз, у створених звітах 40k, чи колись це було. Ми стартап і нам потрібно розробити продукт.

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

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

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

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

Відсутність неперевіреної поведінки в коді може бути дуже важливою. Якщо фрагмент коду виконується, наприклад, 50 разів на секунду, шанс на мільйон трапляється приблизно кожні 5,5 годин виконання. (У вашому випадку шанси здаються меншими.)

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

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

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

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

Коли розроблявся Ariane 4 , значення з бічних акселерометрів масштабувались, щоб вони вміщувались у 16-бітове ціле число, і тому що максимально можливий вихід акселерометрів при масштабуванні ніколи не може перевищувати 32767 і мінімум ніколи не може опускатися нижче - 32768 "не було необхідності в режимі перевірки дальності". Загалом, всі вхідні дані повинні бути перевірені діапазоном перед будь-яким перетворенням, але в цьому випадку це намагатиметься зафіксувати неможливий кут.

Через кілька років розроблявся Ariane 5 , і код для масштабування бічних акселерометрів був повторно використаний з мінімальними випробуваннями, оскільки це було «доведено у використанні». На жаль, велика ракета могла очікувати більших бічних прискорень, тому акселерометри були модернізовані і могли б отримати більші 64-бітні плаваючі значення.

Ці великі значення "загорнуті" в код конверсії, не пам'ятайте про перевірку діапазону, і результати першого запуску в 1996 році були непогані. Це коштувало компанії мільйонів і спричинило велику перерву в програмі.

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

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

Уточнення

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оскільки ви, здається, там є новим, ви можете зробити лише одне - проконсультуватися з керівником команди (або керівником проекту). 13 годин - ділове рішення; для деяких фірм / команд дуже багато; для деяких нічого. Це ще не ваше рішення.

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

Що стосується оглядів коду взагалі, розслабтеся. Мати завдання, яке повертається вам один-два рази, - цілком нормально.

Одне, я не думаю, що я бачив звернене в натурі, хоча це було якось вихованим у відповіді @SteveBarnes:

Які наслідки невдачі?

У деяких полях помилка - це помилка на веб-сторінці. Сині екрани ПК та перезавантаження.

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

У цих крайнощах існує світ різниці.

Незалежно від того, чи варто 13 годин на покриття "невдачі", не залежить від вас. Це має залежати від керівництва та власників. Вони повинні мати відчуття для більшої картини.

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

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

Може поговорити з людиною, яка відповідає за пріоритетність роботи? У запуску може бути CTO або власник продукту. Він міг би допомогти з’ясувати, чи потрібна ця додаткова робота та чому. Також ви можете викликати свої турботи під час щоденних резервів (якщо у вас є).

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

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

Дійте, як Коламбо .

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

Я думаю, що це також пов'язано з методом Сократа .

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

У вашому випадку у вас є дві ідеї, але вони мають принципово ту саму мету: зробити код кращим.

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

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

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

Коли ви ставите під сумнів свої припущення та свої висновки, ви копаєте, розкриєте упередження та врешті-решт з’ясуєте, який правильний хід дій.

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

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

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

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

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

Перегляд коду має кілька цілей. Одне, про що ви, очевидно, знаєте: « Чи підходить цей код за призначенням? » Іншими словами, чи він функціонально правильний; чи адекватно перевірено; чи належним чином коментуються неочевидні частини; чи відповідає це конвенціям проекту?

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

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

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

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

Зробивши вище багато загальних тверджень, як це стосується вашої конкретної ситуації? Я сподіваюся, що зараз очевидно, що моя порада - відповісти на огляд відкритими питаннями та домовитись про те, який підхід має найбільшу цінність. У вашому прикладі випадку, коли пропонується додатковий тест, то щось на кшталт "Так, ми можемо перевірити це; я вважаю, що для впровадження цього знадобиться <time> . Чи вважаєте ви, що користь того варта? А чи є ще щось, що ми може зробити, щоб гарантувати тест не потрібен? "

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

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

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

Кодекс ЗАВЖДИ може бути кращим.

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

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

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

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

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

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

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

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

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

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

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

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

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

Він запропонував мені розглянути незрозумілий випадок, який навряд чи станеться

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

Пропозиції для перевіряючих кодів для підвищення корисності для вашого коду для бізнесу (ви як ОП повинні запропонувати таку зміну):

• Позначте свої коментарі за типом. "Критично" / "Обов'язково" / "Необов'язково" / "Пропоновані покращення" / "Приємно мати" / "Я замислююся".

  Якщо це здається занадто CDO / анальним / складним, принаймні використовуйте 2 рівні: "Потрібно виправити, щоб пройти огляд і дозволити об'єднати свої зміни" / "Усі інші".

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

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

• Поставте квиток # як коментар до відповіді на предмет перегляду коду, якщо ваш процес дозволяє відповіді на коментарі, такі як огляди Fisheye або електронна пошта.

• Зверніться до рецензента і чітко запитайте, чи цей елемент типу "повинен виправити чи не буде об'єднаний / звільнений".

  • Якщо відповідь - «Так», але ви не погоджуєтесь, нехай особа, відповідальна за керівництво проектом (прем’єр-міністр, ваш менеджер тощо), приймає рішення - викладіть незгоду повністю і чесно. Йдеться не про те, хто з вас "правильний", а про те, що краще для проекту, тому робота прем'єр-міністра / менеджера.

Тепер розгляньте цей квиток як будь-який інший запит на розвиток.

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

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

Не слід ескалювати це керівництву.

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

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

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

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

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

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

Ось кілька тверджень, які можуть бути корисними для вас:

• Мене попросили зробити X, рецензент коду пропонує також робити Y, чи варто це робити чи слід перейти до більш важливих речей?
• Ви мені пропонуєте Y, щоб ви могли розібратися принаймні в одному тестовому випадку, який би сприйняв таку поведінку, щоб я міг це перевірити? Я вважаю, що код не буде називатися.
• Можливо, не варто спочатку розробити безпечний запас для виявлених випадків? Тож ми їх рано ловимо і виправляємо на ходу, щоб ми могли зосередитися на більш важливих речах.
• Гаразд, поки я впроваджую Y, ви можете бути настільки люб'язними, щоб написати для нього кілька тестових випадків, щоб ми це зробили раз і назавжди ?
• Мене просили зробити X, і я думаю, що я міг би зробити Y, якщо немає інших пріоритетів. Наступного разу, чому б ви не подали запит на функцію замість того, щоб ставити його як коментар до огляду мого коду ? Принаймні, ми можемо почути подальші думки інших членів команди щодо цієї функції перед її застосуванням (як правило, будь-який важливий матеріал повинен бути функцією і ним повинен займатися більше однієї людини; зазвичай перегляд коду повинен стосуватися перегляду коду та підходів до рішення; інше є виправлення помилок та функції).

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

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

Загалом намагайтеся уникати обох наступних дій:

• Ви не робите того, про що просили
• Ви змушуєте рецензента почуватися німим

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

Якщо під час перегляду коду щодо сфери застосування виникають незгоди:

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

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

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

1. Прийміть відгуки.
2. Перш ніж вносити будь-які зміни у свій код, спробуйте створити тест для кращого випадку та перевірте, чи зможете ви отримати тест (з підтвердженням того, що проблема існує). Якщо неможливо створити такий тестовий випадок і отримати помилку тесту, то, можливо, ви зможете зробити висновок, що кращий випадок насправді неможливий (хоча я б вагався зробити такий висновок).
3. Якщо ви можете отримати тестову помилку, застосуйте відповідну зміну коду, щоб пройти тест.

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

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

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

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

Є рецензенти кодів, яким потрібно виправдати власне існування, створивши непотрібну роботу для інших.

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

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