Що ви говорите в огляді коду, коли інша людина створила надто складне рішення? [зачинено]

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

У цій ситуації я запитую "чому це було зроблено таким чином?"

Відповідь - інша людина відчула, що робить це саме так.

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

Відповідь - ні.

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

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

Еквівалентний сценарій такий:
колега витрачає 8 годин рефакторингу коду вручну, що могло бути автоматично зроблено в Resharper за 10 секунд. Звичайно, я не вірю вручну рефакторингу, оскільки він сумнівної якості та не повністю перевірений.
Знову я отримав відповідь: "ну це вже зроблено".

Яка відповідна відповідь на таке ставлення?

Ментальність / ставлення

• Подавати приклад
• Нагадуйте приватно (один на один, поза оглядом коду)
• Заохочуйте менталітет Keep-it-simple серед членів команди

Керування командою

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

Рівень навичок

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

Управління проектами (ризиками)

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

Що ви говорите в огляді коду, коли інша людина створила надто складне рішення?

Ви кажете: «Ви побудували надто складне рішення».

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

Якщо вже пізно щось змінювати, чому ви робите перевірку коду?

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

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

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

Це не прийнятна відповідь:

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

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

І ...

... рішення не було повністю функціональним ...

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

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

Яка відповідна відповідь на таке ставлення?

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

Ви мали рацію, вони помилялися:

• порушений принцип ЯГНІ
• порушений принцип KISS
• чи повністю перевірено код? Якщо ні, то це не робиться

Яка відповідна відповідь на таке ставлення?

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

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

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

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

Слід зосередитись на першопричині проблеми:

1. Навчання програмістів зосереджується на збільшенні складності, що надається програмістам. Здатність до цього була перевірена школою. Таким чином, багато програмістів будуть думати, що якщо вони реалізують просте рішення, вони не виконали свою роботу правильно.
2. Якщо програміст дотримується тієї ж схеми, що він робив сотні разів, коли в університеті, це просто так, як думають програмісти - чим складніше складніше, тим самим краще.
3. Отже, щоб виправити це, вам потрібно буде суворо розмежовувати вимоги вашої компанії відносно складності порівняно з тим, що зазвичай вимагається в освіті програміста. Хороший план - це правило на кшталт "найвищий рівень складності повинен бути зарезервований лише для завдань, розроблених для вдосконалення ваших навичок - і його не слід використовувати у виробничому коді".
4. Для багатьох програмістів стане несподіванкою те, що їм не дозволяють робити свої найсумніші дизайни у ​​важливому виробничому кодовому середовищі. Просто зарезервуйте час для програмістів для експериментальних розробок, а потім збережіть всю складність у цій стороні огорожі.

(у огляді коду це вже пізно змінити)

Я не знаю нічого, що працює після написання коду.

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

Є ще один підхід, який працює з підрядниками - договори з фіксованою ціною. Чим простіше рішення, тим більше $$ програміст має зберегти.

Ви не можете виправити світ.

Ви навіть не можете виправити весь код у своєму проекті. Напевно, ви не можете зафіксувати практики розробки свого проекту, принаймні не цього місяця.

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

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

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

У проекті має бути стандартна політика, яка контролює доступні процедури перевірки якості та використовувані інструменти.

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

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

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

Ваш магазин повинен застосовувати деякі методики проектування.

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

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

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

Якщо сказати "це занадто складно", ви нікуди не потрапляєте.

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

Це, звичайно, залежить від того, коли завершиться перевірка коду. Якщо це частина процесу розробки, то ви можете отримати певну вигоду прямо зараз. Але якщо до ЧСД ставляться як до померлого, тоді вам краще вказати, що можна зробити краще в майбутньому. У вашому випадку (як уже говорили інші), вкажіть на YAGNI та KISS взагалі, а можливо, на деякі конкретні сфери, де ці принципи можуть бути застосовані.

Що означає надмірно складне? Ви зробите неоднозначну заяву, тоді у відповідь отримаєте неоднозначну / незадовільну відповідь. Те, що надто складно для однієї людини, ідеально для іншої.

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

Якщо ви бачите проблему (надмірно складну), то скажіть щось більш конкретне, як-от:

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

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

Іноді варто, як група, зосередитись на деяких принципах "Agile" - вони можуть допомогти групі чи окремому особі, які, здається, трохи не в курсі.

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

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

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

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

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

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

Одне слово: спритний

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

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

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

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

Ви повинні кодувати після видалення / скасування їх коду: "На жаль, ваш код пішов. Будь ласка, перепишіть його. Оскільки ви його вже написали, вам знадобиться менше двадцяти хвилин, щоб надати ТІЛЬКИ потрібний код специфікації.

"Наступний мій огляд - через 20 хвилин.

"Хороший день."

НЕ приймайте жодних аргументів!

Готово, ІМХО

Кріс