Що є корисним мисленням під час проведення офіційного перегляду коду

Нещодавно наша команда розпочала перевірку коду щодо кожної реєстрації.

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

Чи є докази, дослідження чи вказівки з добре відомих джерел, які підказують корисний підхід?

Пам’ятайте про загальні цілі: врешті-решт, важливим є лише робоче програмне забезпечення

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

Встановіть чітку область для свого огляду

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

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

• Не кидайте виклик за низьку ефективність, якщо не буде міри, яка показує, де проблема. Передчасна оптимізація - корінь усього зла ;-)

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

• вирішити відповідність встановленим стандартам кодування. Це найприємніша тема для обговорення як для рецензента, так і для рецензованого. Коли всі погодилися використовувати великі імена класів у вашій команді, і один хлопець має клас без, це питання смаку? Або ефективність та ризик роботи в команді?

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

Розвивати лідерство: людська сторона огляду

Як керівник команди, ви можете знайти тут можливість розвивати себе та свою команду поза формальністю контролю якості:

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

Скористайтеся іншими методами

Є кілька речей, яких можна уникнути в перегляді коду:

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

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

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

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

Тут суб’єктивний підхід. Об'єктивний підхід, IMO, дуже добре пояснений у цьому питанні .

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

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

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

Позиція з кодом розробника для косметичних змін призведе до демотивації розробника, але в абсолютних обставинах це потрібно зробити. Першоджерело має знайти баланс між наданням корисного перегляду коду та навчанням позбуватися незначних недоліків. https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-know/

Деякі речі, які слід пам’ятати:

1. Мова йде про психологію так само, як і про технології, тому жодного золотого правила тут немає.
2. Що стосується людей - це не лише знання, а й культура та положення в ієрархії.
3. Якщо це «довга» гра (стабільна і налагоджена компанія), добре інтегрована команда, де люди довіряють один одному, як правило, має більшу цінність, ніж код, що розглядається. Її не слід застосовувати для примушування речей, які не є абсолютно необхідними для продовження. Чорт у деталях ...
4. Якщо це "коротка" гра (побічний проект, НДДКР, багато фрілансерів у групі), витрати на КР часто долають переваги, що виникають внаслідок їх виконання. І ставлення повинно бути "просто змусити його"

Важливі лише дві речі.

1. Чи є автоматизовані тести на всі вимоги?
2. Вони всі проходять?

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

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

Чи вимоги хороші? Що в ідеалі ви повинні знати перед тим, як починати завдання, тобто продуктивність, безпека тощо

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