Як поводитися з TODO у запиті на виклик?

Коли я переглядаю зміни в запиті на витяг, я іноді натрапляю на коментар із приміткою "TODO", яка може бути там з різних причин, в нашому випадку в основному через:

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

Знаючи, що вони TODOвзагалі залишаються в кодовій базі протягом усього часу роботи кодової бази, як я повинен реагувати на них у запиті на виклик? Як я можу ввічливо просити цього уникнути, або якщо це дійсно виправдано, як я можу переконатися, що автор PR піде за ним пізніше в майбутньому?

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

• Запишіть це в вашому DoD , що TODO, FIXMEабо подібні мітки слід уникати.
• Використовуйте інструмент аналізу статичного коду, такий як SonarQube, щоб автоматично позначити збірку нестабільною.
• Тимчасово дозвольте їм, якщо і лише якщо у вашому трекері випуску є відповідний квиток. Тоді може виглядати кодTODO [ID-123] Description ...

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

Особисто я вважаю, що TODOs часом буває розумним, але не слід їх використовувати надмірно. Взято з "Чистого коду Роберта К. Мартіна : Підручник з гнучкої майстерності програмного забезпечення" (стор. 59):

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

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

Я часто використовую TODO або FIXME як спосіб нагадати про себе, що мені потрібно чи хотілося повернутися, щоб вирішити проблему.

Наприклад, я можу зателефонувати add (a, b) і додати TODO для рефакторації методу add. Я не хочу зараз працювати над методом add, але хочу повернутися до нього.

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

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

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

Справедливо кажучи, я також переконуюсь, що кожен проект має час вбирання коду. Так, можна бути готовим до запуску 15-го, але робили код прибирання з 15-го по 30-й. (здається дивним, але якщо ви коли-небудь керували продуктом, ви знаєте, що якщо ви спробуєте перед початком запуску завдань із низькою видимістю, вам ніколи не дозволять потрапити до них. Щось ще отримає пріоритет.)

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

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

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

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

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

Правило будинку №1 - Усі зобов’язання щодо майстра повинні бути готові до тестування, оскільки майстер будується щодня після будь-яких реєстрацій. Ці зобов'язання також повинні включати будь-які необхідні додаткові тести.

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

Правило будинку №2 - Вся інформація щодо відкритих питань зберігається в трекері випусків. Все це. Нотатки, писанки, зачіпки, що завгодно.

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

Правило будинку №3 - вся інформація щодо завдань, що очікують на виконання проекту, належить до черги пріоритетів (або будь-якої назви вашої системи для цього).

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

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

Правило будинку №4 - пропозиції містяться у вікні ідеї (чи будь-що інше).

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

Правило будинку №5 - TODOкоментарі у вихідному коді заборонені. ПЕРІОД.

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