Чи повинен рецензент в оглядах коду представляти рішення питань? [зачинено]

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

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

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

Отже, як рецензент, як добре сказати, "цей код хибний, тому що ..., зробіть це по-іншому" або вам потрібно придумати конкретне рішення?

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

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

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

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

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

Тож, як рецензент, добре сказати, що "цей код хибний, чи інакше це робити", чи потрібно придумати конкретне рішення?

Жоден з двох не є ідеальним ІМО. Найкраще це поговорити з автором та вирішити проблему спільно.

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

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

Ні. Якщо ви це робите, ви не рецензент, ви наступний кодер.

В оглядах коду, повинен рецензент ніколи уявити рішення проблем?

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

Коли рецензент повинен представити рішення питань?

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

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

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

Існують два типи поганих програмістів: ті, які не дотримуються стандартних практик, і ті, які «лише» дотримуються стандартних.

Коли я мав обмежений робочий контакт / надання кому-небудь відгуків, я б не сказав: "Це поганий дизайн". але щось на кшталт "Чи можете ви пояснити мені цей клас?" Ви можете виявити, що це хороше рішення, дев щиро зробив усе можливе, або навіть визнав, що це погане рішення, але це досить добре.

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

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

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

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

Моя думка стає більш сильною у напрямку надання коду у більшості випадків з кількох причин:

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

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

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

Я думаю, що ключовим для огляду коду є узгодження правил перед оглядом.

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

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

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

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

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

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

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

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

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

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