Как обработать TODO в запросе на включение?

Когда я просматриваю изменения в запросе на удаление, я иногда натыкаюсь на комментарий с пометкой «TODO», которая может быть там по разным причинам, в нашем случае в основном из-за:

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

Зная, что TODOобычно они остаются в кодовой базе в течение всего срока жизни кодовой базы, как мне реагировать на них в запросе на извлечение? Как я могу вежливо попросить избежать этого или, если это действительно оправдано, как я могу быть уверенным, что автор PR будет следить за этим позже в будущем?

Когда вы говорите, что они «обычно остаются в базе кодов в течение всего времени существования кода» в вашей команде / отделе / ​​организации, учтите следующее:

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

Как упомянуто в моем комментарии , последнее утверждение, вероятно, имеет смысл только в среде, в которой билеты не гниют (например, если вы придерживаетесь политики отсутствия ошибок ).

Лично я думаю TODO, что иногда это разумно, но не следует использовать их чрезмерно. Взято из книги Роберта С. Мартина «Чистый код: руководство по гибкому программному обеспечению» (стр. 59):

TODOЭто задания, которые, по мнению программиста, должны быть выполнены, но по какой-то причине не могут быть выполнены в данный момент. Это может быть напоминанием об удалении устаревшей функции или просьбой, чтобы кто-то еще посмотрел на проблему. Это может быть просьба кого-то придумать лучшее имя или напоминание о внесении изменения, которое зависит от запланированного события. Как бы то ни TODOбыло, это не повод оставлять плохой код в системе.

TODO сами по себе не зло. Я большой поклонник того, чтобы никогда не углубляться больше, чем в один слой, и всегда исправлять 1 проблему за билет трекера.

Я часто использую TODO или FIXME как способ напомнить себе, что я нуждался или хотел вернуться, чтобы исправить проблему.

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

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

Чтобы обойти проблему их невидимости или игнорирования, я использую скрипт, который перечисляет все строки TODO FIXME и DEGUG. И это добавляется к сообщению фиксации.

Трудно игнорировать 400-коммитное сообщение о фиксации, которое является всеми TODO. Таким образом, люди исправляют их, либо уже касаясь кода, о котором идет речь, либо создавая новые заявки и устраняя проблему самостоятельно.

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

Может случиться так, что есть пул-запросы, которые не идеальны. Прямо сейчас я делаю некоторую работу, которая может быть сделана «достаточно хорошо» в доступное время, но не идеально. Поэтому я отправляю запрос на извлечение, помещаю TODO с комментариями в правильные места в коде, и в то же время добавляю еще один запрос на изменение, чтобы изменить вещи с «достаточно хороших» на «совершенных».

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

Теперь ваш вопрос: «Как я могу вежливо попросить об этом, или, если это действительно оправдано, как я могу быть уверен, что автор PR будет следить за этим позже в будущем?» С тем, что я описываю, это кажется довольно глупым. Если у меня есть выбор между поздней отправкой и доставкой, что достаточно хорошо, то это не ваше решение. Вы можете спросить об этом своего менеджера по продукту, если хотите. И "убедитесь, что автор PR последует за этим"? Если у вас есть команда, то вы должны убедиться, что это зарегистрировано в ваших системах, и, надеюсь, ваша команда достаточно хорошо организована, чтобы зарегистрированные вещи не потерялись, и кто- то исправит это в конце концов, когда нет элементов с более высоким приоритетом. Помните, это командная работа.

Если ваш проект отслеживает ожидающие элементы в исходном коде с TODOкомментариями, то вы должны разрешить это.

Тот факт, что наличие TODOкомментария в запросе на получение доступа вызывает ошибку, следует сказать, что отслеживание ожидающих элементов в исходном коде - плохая идея. Вещи, как правило, теряются или игнорируются таким образом. Теперь, если вы говорите о вытягивающем запросе к «рабочей вилке», то ситуация другая. «Рабочая вилка» - это просто незавершенное производство. Но подобная вилка обычно не требует запроса на извлечение. Предлагаемые здесь «Внутренние правила» предназначены для запросов на извлечение для главной ветки.

Домашнее правило № 1 - Все коммиты мастера должны быть готовы к тестированию, так как мастер собирается ежедневно после любых проверок. Эти коммиты также должны включать любые дополнительные необходимые тесты.

Если TODOкомментарий присутствует потому, что код не завершен, или тесты не завершены, или код каким-либо образом не готов к тестированию, то этот код принадлежит локальному коммиту, а не запросу извлечения. Позвони мне, когда будет готово.

Домашнее Правило № 2 - Вся информация, касающаяся открытых вопросов, хранится в трекере. Все это. Заметки, каракули, догадки, что угодно.

Если TODOкомментарий относится к открытой проблеме и не является фактическим исправлением этой проблемы, то эта информация относится к системе отслеживания проблем. Таким образом, перед закрытием проблемы вся информация может быть просмотрена и проверена, если необходимо, чтобы убедиться, что проблема действительно решена.

Домашнее правило № 3 - Вся информация, касающаяся незавершенных задач проекта, находится в очереди с приоритетами (или какова бы ни была ваша система).

Для пояснения, незавершенная задача проекта - это то, что необходимо выполнить в проекте с установленным приоритетом, будь то дефект, который был обнаружен до того, как он сгенерировал заявку на выдачу, или выполнение определенного требования к дизайну или одно из необходимые компоненты этого требования.

Если здесь есть TODOкомментарий, говорящий о том, что новый код будет влиять на ожидающую задачу, или указывать на что-то еще в кодовой базе, на которую нужно обратить внимание, что было обнаружено при реализации нового кода, то эта информация принадлежит в очереди с приоритетами, либо на существующее задание или как новое.

Домашнее Правило № 4 - Предложения находятся в Ящике с Идеями (или как угодно).

Если TODOкомментарий предполагает изменение в дизайне или реализации программного обеспечения, то эта информация принадлежит блоку идеи проекта, или «vNext», или «Примечания к дизайну», или тому, что у вас есть для такого рода вещей.

House Rule # 5 - TODOкомментарии не допускаются в исходном коде. СРОК.

Если вы будете придерживаться этого правила, вам не придется беспокоиться о том, что кто-то что-то предпримет.