Ah
+ за линтер. Иначе код ревью превращается в инструмент гестапо. Вообще отношение к код ревью должно быть не как наказание, а как обучение и передача знаний
+
Size: a a a
2020 January 21
В
В принципе у нас есть соглашение о коде, соблюдение которое проверяется на ревью + ПР должен собрать апрувы двух коллег. Этого хватает, что бы херня в мастер не попало
не хватает, проверенно))
DU
Ну с дуру можно и лом сломать))
А чего не хватает?
А чего не хватает?
В
обычный человеческий фактор, невнимательность. поэтому не идет в мастер без потверждения от qa
В
qa проводим почти идентичном с боевым окружением + база - частичный дамп с лайва (без персональных данных)
AK
У на как правило так,
FeatureBranch должен быть проверен QA, а когда он дает аппрув, тогда уже Approve запрашивать можно и если в дали, тогда уже в мастер уходит
FeatureBranch должен быть проверен QA, а когда он дает аппрув, тогда уже Approve запрашивать можно и если в дали, тогда уже в мастер уходит
AK
Andrey Dottz
Всем привет, поделитесь опытом / методом, как снизить поток codereview на себя как на тимлида? Команда расширилась, все боятся навредить и без моего ревью не хотят деплоить. Схема текущая - все ревьюят всех, иерархии нет.
Статический анализатор, конвенция именования и код стайла + робот на проверку pull request’ов.
Дальше можешь только с apply/decline в request’ах жмакать.
Если анализатор не даёт ни одного варнинга, то уже 90% работы сделано.
Дальше можешь только с apply/decline в request’ах жмакать.
Если анализатор не даёт ни одного варнинга, то уже 90% работы сделано.
AD
Статический анализатор, конвенция именования и код стайла + робот на проверку pull request’ов.
Дальше можешь только с apply/decline в request’ах жмакать.
Если анализатор не даёт ни одного варнинга, то уже 90% работы сделано.
Дальше можешь только с apply/decline в request’ах жмакать.
Если анализатор не даёт ни одного варнинга, то уже 90% работы сделано.
Что за робот для реквестов? Пушер?
SR
А каким образом форсил? По идее отследить кто читал кто не читал не выйдет, спрашивать постоянно тоже не вариант.
Тут вопрос не в том чтобы следить. А в том, чтобы донести до людей зачем это нужно. Ну и я назначил ответственных по дням - тут не отвертишься, приходится смотреть. Зато потом у всех это вошло в привычку и сейчас каждый реквест смотрят 2-3 человека точно.
AK
Andrey Dottz
Что за робот для реквестов? Пушер?
При создании PR проверяет именование файлов и их положение.
Как минимум.
Как максимум может билдить, запускать и сценарии базовые гонять.
Как минимум.
Как максимум может билдить, запускать и сценарии базовые гонять.
SR
у нас с самого начала было правило что смотрим, комментируем, если все хорошо ставим апрувы. Х-апрувов - можно мерджить и отправлять на тестирование
Ну да, апрувы и у нас тоже есть, в гитлабе есть лайки. Если тебе 2 человека прокомментировало, то правишь и ждешь либо ещё комментариев, либо 2 лайка. Если стоят все лайки - можно мерджить.
SR
Статический анализатор, конвенция именования и код стайла + робот на проверку pull request’ов.
Дальше можешь только с apply/decline в request’ах жмакать.
Если анализатор не даёт ни одного варнинга, то уже 90% работы сделано.
Дальше можешь только с apply/decline в request’ах жмакать.
Если анализатор не даёт ни одного варнинга, то уже 90% работы сделано.
Статический анализатор на каком этапе включается?
AK
Статический анализатор на каком этапе включается?
По хорошему гоняется локально у каждого.
И общий при создании PR.
И общий при создании PR.
SR
По хорошему гоняется локально у каждого.
И общий при создании PR.
И общий при создании PR.
У вас это как-то автоматизировано? В том же CI, например. Или руками гоняете?
AK
У вас это как-то автоматизировано? В том же CI, например. Или руками гоняете?
Сервер свой слушает пуши с bitbucket и запускает сценарии.
Ну и имеет права чтобы некорректный PR сразу отклонить с причиной
Ну и имеет права чтобы некорректный PR сразу отклонить с причиной
SR
Сервер свой слушает пуши с bitbucket и запускает сценарии.
Ну и имеет права чтобы некорректный PR сразу отклонить с причиной
Ну и имеет права чтобы некорректный PR сразу отклонить с причиной
Прикольно, надо будет глянуть, спасибо
2020 January 22
Е
Статический анализатор, конвенция именования и код стайла + робот на проверку pull request’ов.
Дальше можешь только с apply/decline в request’ах жмакать.
Если анализатор не даёт ни одного варнинга, то уже 90% работы сделано.
Дальше можешь только с apply/decline в request’ах жмакать.
Если анализатор не даёт ни одного варнинга, то уже 90% работы сделано.
А как же проверка логики? Я когда делаю ревью, то сначала читаю задачу, а потом смотрю код, бывает, что что-то по логике не учтено или не совсем корректно сделано. Ещё у джунов иногда бывают проблемы с именованием методов, тоже на ревью стараюсь писать о таком.
AK
А как же проверка логики? Я когда делаю ревью, то сначала читаю задачу, а потом смотрю код, бывает, что что-то по логике не учтено или не совсем корректно сделано. Ещё у джунов иногда бывают проблемы с именованием методов, тоже на ревью стараюсь писать о таком.
TDD + % покрытие кода.
Если ещё и собирать аналитику по тому какие модули сколько ошибок выдают, то можно вывести корреляцию с % покрытия и кол-ом критических багов. Не занимался пока, но хочу.
Для проверки именования есть статический анализатор, который выдаёт warning на неправильное именование.
А при 10 таких warning’ах PR не принимается вообще. А в сообщении пишется причина.
Но вообще все правила именования встроены в IDE и она сама тебе скажет где не правильно.
Если ещё и собирать аналитику по тому какие модули сколько ошибок выдают, то можно вывести корреляцию с % покрытия и кол-ом критических багов. Не занимался пока, но хочу.
Для проверки именования есть статический анализатор, который выдаёт warning на неправильное именование.
А при 10 таких warning’ах PR не принимается вообще. А в сообщении пишется причина.
Но вообще все правила именования встроены в IDE и она сама тебе скажет где не правильно.
Е
TDD + % покрытие кода.
Если ещё и собирать аналитику по тому какие модули сколько ошибок выдают, то можно вывести корреляцию с % покрытия и кол-ом критических багов. Не занимался пока, но хочу.
Для проверки именования есть статический анализатор, который выдаёт warning на неправильное именование.
А при 10 таких warning’ах PR не принимается вообще. А в сообщении пишется причина.
Но вообще все правила именования встроены в IDE и она сама тебе скажет где не правильно.
Если ещё и собирать аналитику по тому какие модули сколько ошибок выдают, то можно вывести корреляцию с % покрытия и кол-ом критических багов. Не занимался пока, но хочу.
Для проверки именования есть статический анализатор, который выдаёт warning на неправильное именование.
А при 10 таких warning’ах PR не принимается вообще. А в сообщении пишется причина.
Но вообще все правила именования встроены в IDE и она сама тебе скажет где не правильно.
TDD круто! у нас нет пока, получается тесты проверяем вместе с основным кодом
DB
TDD + % покрытие кода.
Если ещё и собирать аналитику по тому какие модули сколько ошибок выдают, то можно вывести корреляцию с % покрытия и кол-ом критических багов. Не занимался пока, но хочу.
Для проверки именования есть статический анализатор, который выдаёт warning на неправильное именование.
А при 10 таких warning’ах PR не принимается вообще. А в сообщении пишется причина.
Но вообще все правила именования встроены в IDE и она сама тебе скажет где не правильно.
Если ещё и собирать аналитику по тому какие модули сколько ошибок выдают, то можно вывести корреляцию с % покрытия и кол-ом критических багов. Не занимался пока, но хочу.
Для проверки именования есть статический анализатор, который выдаёт warning на неправильное именование.
А при 10 таких warning’ах PR не принимается вообще. А в сообщении пишется причина.
Но вообще все правила именования встроены в IDE и она сама тебе скажет где не правильно.
А почему 10?