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

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

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

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

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

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

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

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

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

ЯКЩО це допомагає, говоріть неупереджено, як ніби ви навіть не автор коду, який перевіряється. Код все-таки належить компанії або колективу, і команді доведеться його підтримувати. Вам просто трапився хлопець, який написав це, це не такий важливий фактор, як багато хто вважає.

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

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

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

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

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

На моєму досвіді я спостерігав різні типи відгуків під час огляду коду:

1. "Я чесно вважаю, що це неправильно / недостатньо оптимально, і ви повинні змінити це таким чином". Я зазвичай сприймаю подібні відгуки серйозно, і буду проти того, що запропоновано змінити, лише якщо я вважаю, що маю сильну позицію проти цього.
2. "Я вважаю ваше рішення нормальним. Розгляньте цю альтернативу, але ви вирішите, чи приймете ви зміну чи ні." Я теж дуже серйозно ставлюсь до такого типу відгуків: рецензент пропонує альтернативу, хоча вони не мають твердої думки, що їх рішення краще. У мене є можливість чогось навчитися, і я прийму зміну, якщо мені це більше подобається. В іншому випадку рецензент вважає це нормальним, якщо я зберігаю код за своїм смаком.
3. "Я зробив би це по-іншому, тому ви повинні змінити його, період", або навіть "О, я змінив ваш код, тому що ...", зміна не пропонується, вона вже була здійснена! Дано декілька швидких пояснень щодо зміни, з натяком на те, що часу для обговорення деталей не так багато, тому що ми повинні перейти до наступного завдання.
4. Рецензент пропонує невеликі зміни тривіального характеру, які не покращують код, а просто роблять його іншим. На запитання обговорити запропоновані зміни рецензент вступає в тривалі дискусії про тривіальні деталі, поки ви не відмовитеся від виснаження.

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

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

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

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

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

Говорити це - наш шлях, як уже зазначила більшість людей.

Якщо ви вже зробили це, можливо, навіть не один раз, одна корисна методика, яку ми використовуємо, - це якщо в якійсь області (іх) все ще виникають розбіжності - це сказати: «так, було б добре рефактор» -

Чи можемо ми поставити для цього окремий квиток?

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

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

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

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

Це не повинно призводити до зміни коду, не обговорюючи / розуміючи рішення кодерів під час розробки.

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

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

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

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

Схоже, ви ще не переглянули свій код :-)

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

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

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

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

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

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