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

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

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

Відповідь тут - спілкуватися.

1. Повідомте технічну / командну ведучу про проблему
2. Поговоріть із QA про можливий вплив
3. Повідомте керівництву проекту (хто знаходиться за вами), що може виникнути проблема, яка спричинить затримку випуску, і ви повернетесь з ними якнайшвидше (за лічені хвилини або години)
4. Оцініть, чи є ця проблема пробкою для випуску

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

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

Швидше за все, керівництво не порадує пробкового шоу в кінці гри, але не захоче, щоб його випустили у виробництво.

Спілкуйтеся та нехай керівництво телефонує.

Не просто повідомляйте про проблему, задокументуйте її

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

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

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

Визначте ризик та вплив

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

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

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

Коли ваш наступний реліз?

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

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

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

Кінцевий термін завтра, але ви опинитесь у такій ситуації:

керівник проекту стоїть через плече і тисне на вас, нарешті, скласти збірку

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

Представіть цей сценарій тому, хто веде цю справу.

• Визначте, які типи проблем слід подати.
• Визначте варіанти.
• Хто приймає рішення
• Коли все це слід вирішити? Ймовірно, це буде відносно дати випуску.

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

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

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

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

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

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

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

Ось кілька порад для усунення проблеми:

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