Сообщение Re: Комментарии Code Review от 06.02.2025 13:55
Изменено 11.02.2025 6:40 Pauel
Re: Комментарии Code Review
Здравствуйте, Буравчик, Вы писали:
Б>Какие комментарии в код-ревью вы считаете "по делу", а какие нет?
Б>Какими должны быть правильные комментарии к PR/MR/т.п.?
— грубые ошибки "в таком виде функцию нельзя покрыть юнит-тестами, а вот в таком — можно"
— баги
— секурити проблемы
— отхождение от принятого дизайна/архитектуры — вопросы "почему конфиг используется напрямую"
— где тесты "вот этой штуки"
— непонятные места — вопросы "а что это за константа"
до кучи — накидывать тикеты на те части, что требуют доработки. Это проще, чем переписываться неделями. В пр нужно просто указать, что создан тикет "исследовать, что будет в случае xxx при условии yyy"
стили, запятые, форматирование, линтинг — это всё мусор
много полезных вещей которые не нужно совать в ПР
— дизайн-архитектура, если это не просто какое то сиюминутное расхождение. Для этого лучше запланировать время на дизайн-ревью итд, заранее, до начала работ
— "херли ты пакеты публикуешь без тестов-билдов-доки" — это идти сразу к пм
— проверку каждой функции-строчки-итд — для этого есть другие подходы
Б>Какие комментарии в код-ревью вы считаете "по делу", а какие нет?
Б>Какими должны быть правильные комментарии к PR/MR/т.п.?
— грубые ошибки "в таком виде функцию нельзя покрыть юнит-тестами, а вот в таком — можно"
— баги
— секурити проблемы
— отхождение от принятого дизайна/архитектуры — вопросы "почему конфиг используется напрямую"
— где тесты "вот этой штуки"
— непонятные места — вопросы "а что это за константа"
до кучи — накидывать тикеты на те части, что требуют доработки. Это проще, чем переписываться неделями. В пр нужно просто указать, что создан тикет "исследовать, что будет в случае xxx при условии yyy"
стили, запятые, форматирование, линтинг — это всё мусор
много полезных вещей которые не нужно совать в ПР
— дизайн-архитектура, если это не просто какое то сиюминутное расхождение. Для этого лучше запланировать время на дизайн-ревью итд, заранее, до начала работ
— "херли ты пакеты публикуешь без тестов-билдов-доки" — это идти сразу к пм
— проверку каждой функции-строчки-итд — для этого есть другие подходы
Re: Комментарии Code Review
Здравствуйте, Буравчик, Вы писали:
Б>Какие комментарии в код-ревью вы считаете "по делу", а какие нет?
Б>Какими должны быть правильные комментарии к PR/MR/т.п.?
— грубые ошибки "в таком виде функцию нельзя покрыть юнит-тестами, а вот в таком — можно"
— баги
— секурити проблемы
— отхождение от принятого дизайна/архитектуры — вопросы "почему конфиг используется напрямую"
— где тесты "вот этой штуки"
— непонятные места — вопросы "а что это за константа"
до кучи — накидывать тикеты на те части, что требуют доработки. Это проще, чем переписываться неделями. В пр нужно просто указать, что создан тикет "исследовать, что будет в случае xxx при условии yyy"
стили, запятые, форматирование, линтинг — это всё мусор, решается автоматикой
много полезных вещей которые не нужно совать в ПР
— дизайн-архитектура, если это не просто какое то сиюминутное расхождение. Для этого лучше запланировать время на дизайн-ревью итд, заранее, до начала работ
— "херли ты пакеты публикуешь без тестов-билдов-доки" — это идти сразу к пм
— проверку каждой функции-строчки-итд — для этого есть другие подходы
Б>Какие комментарии в код-ревью вы считаете "по делу", а какие нет?
Б>Какими должны быть правильные комментарии к PR/MR/т.п.?
— грубые ошибки "в таком виде функцию нельзя покрыть юнит-тестами, а вот в таком — можно"
— баги
— секурити проблемы
— отхождение от принятого дизайна/архитектуры — вопросы "почему конфиг используется напрямую"
— где тесты "вот этой штуки"
— непонятные места — вопросы "а что это за константа"
до кучи — накидывать тикеты на те части, что требуют доработки. Это проще, чем переписываться неделями. В пр нужно просто указать, что создан тикет "исследовать, что будет в случае xxx при условии yyy"
стили, запятые, форматирование, линтинг — это всё мусор, решается автоматикой
много полезных вещей которые не нужно совать в ПР
— дизайн-архитектура, если это не просто какое то сиюминутное расхождение. Для этого лучше запланировать время на дизайн-ревью итд, заранее, до начала работ
— "херли ты пакеты публикуешь без тестов-билдов-доки" — это идти сразу к пм
— проверку каждой функции-строчки-итд — для этого есть другие подходы