Що таке загальні процеси перегляду коду і що вважається поганим?

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

Процес здається справедливим, проте три людини, які роблять перевірку коду, не здаються справедливими. Я помічаю, що коли я ставлю свій код на огляд, я отримую десь 100-200 коментарів. Найбільше для мене одночасно було 300 коментарів. Звичайно, ви можете подумати, що це великі зміни, але це можуть бути і дуже невеликі зміни, як і менше ніж 50 рядків коду (що включає одиничні тести). Усі коментарі вважаються "повинні робити" і без аргументів.

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

Тож моє запитання, чи справедливо це? Або звичайні?

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

ІМХО - це справжнє питання, оскільки в цьому немає пріоритетів. Коли ви отримуєте 100-300 коментарів, там повинна бути деякі з них , які мають пріоритет А (реальні помилки), деякі з них Пріо B (швидше за все, приведуть до помилок пізніше) , а деякі з них Прио C (все інше). Скажіть своїм колегам, що ви готові поважати всі їхні бажання, але щоб зміни були ефективними, а ваш час обмежений, наполягайте на пріоритеті. Потім, почніть спочатку з виправлення коментаря, а коментар, і якщо у вас дійсно є час на більше, після цього, ви можете почати з B (якщо вам пощастить, ваш начальник зрозуміє, що виправити пріо B і C не так важливо, і дасть вам ще кілька важливих завдань замість того, щоб витрачати час).

Перегляд коду може бути суперечливим процесом.

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

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

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

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

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

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

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

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

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

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

• Перш за все, аналізатор статичного коду повинен використовуватися для виявлення більшості проблем до того, як відбудеться перевірка коду. Наприклад, запуск коду через Sonar, Lint або будь-який інший хороший аналізатор коду повинен допомогти вам позбутися більшості незначних проблем. Тим більше, що ваші рецензенти можуть визначати спеціальні профілі, щоб забезпечити все, починаючи від розміщення дужок, пробілів, коментарів, правильного іменування змінних та багато іншого ...
• По-друге, мені здається, що я добре працюю, якщо поділити коментарі на різні категорії. Наприклад, дві категорії, де одна група включає невеликі речі, які ви повинні взяти до відома і застосовувати в майбутньому. І друга група для тих коментарів, які потребують негайної модифікації вашого коду, що вимагатиме чергового зобов’язання та подальшого перегляду. Звичайно, кількість коментарів в останній групі має бути меншою.

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

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

² Припустимо, що хоча коментарі надмірні, в них є певна цінність

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

Однак це також залежить від "правил" процесу перегляду коду. У ВСЕГО є свої уявлення про те, як щось треба було зробити. Якщо ваш процес перегляду коду дозволяє коментарям мати форму "Ви повинні зробити це так, а не таким чином", ви, швидше за все, отримаєте багато коментарів навіть за відповідний код. Якщо ваш процес призначений для пошуку «дефектів», то кількість коментарів повинна бути значно меншою.

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

ОНОВЛЕННЯ: З урахуванням сказаного, деякий код є просто поганим, навіть якщо дефект є вільним. У такому випадку коментар до огляду повинен бути єдиним коментарем, який говорить щось подібне. "Цей код потрібно очистити. Будь ласка, відкладіть огляд, поки код не буде обговорено з [ваше ім'я тут]." У такому випадку подальший перегляд коду повинен припинитися, поки коментар не буде виправлений.

UPDATE2: @User: Чи обговорюєте ви свій код / ​​дизайн з одним із них, поки ви розробляєте його, щоб ви могли реалізувати те, що вони шукають, перш ніж дійти до того, як це зробити ваш шлях? Чи змінюєте ви щось про те, як ви розробляєте код на основі їх пропозицій чи продовжуєте думати, що ваш шлях добре? Ви щось дізнаєтесь з їхніх коментарів?

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

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

Деякі важливі відмінності в процесі перевірки нашої команди:

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

Для 50 LOC 300 коментарів здається трохи надмірними і - вау - 3 рецензенти на кожен запит на тягнення? Ваша компанія повинна мати багато ресурсів.

З мого досвіду щодо корисного перегляду коду, повинні бути деякі правила та / або вказівки:

• Пріоритетність коментарів
• Класифікація коментарів (помилка, стиль коду тощо)
• Узгоджена архітектура / дизайн, які слід виконати
• Узгоджений стиль коду

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

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

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

Це справді звучить для мене як проблема спілкування. Ви очікуєте, що ваш код недостатньо поганий, щоб заслужити 300 коментарів. Оглядачі, здається, вважають, що вам потрібно багато відгуків. Сперечаючись вперед і назад асинхронним способом, витрачається багато часу. Чорт, написання 300 коментарів - ДУМОВНА марна трата часу. Якщо це не всі дефекти, то, можливо, як новий член команди, ви ще не знаєте стилю команди. Це нормально і те, чого слід навчитися прискорювати весь колектив.

Моя пропозиція - заощадити час. Прискорити зворотній зв'язок. Я би:

• Робіть більше проміжних оглядів, щоб уникнути однієї і тієї самої помилки і не створювати один і той же коментар 50 разів
• Сядьте з рецензентом, коли вони переглядають ваш код, щоб ви могли поговорити про проблеми, коли вони з’являються, тим самим уникаючи документування 300 «проблем», які будуть вилучені під час наступного комітету
• Коли ви пишете код, попрацюйте з одним із цих "справжніх" розробників, щоб побачити, що вони роблять по-іншому

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