АБ
Как контролируете правильность данных после конвертации?
Size: a a a
2021 April 22
AS
Регрессионное тестирование на стейджах делаем
AS
Ну и в сентри все ошибки сразу падают, сложно что-то упустить 😀
O
С этим ещё помогают тесты, если мы сконвертили данные и ожидаем что что-то не изменилось или изменилось по новому, то тесты это покажут
Y
Ну это как раз тот вопрос: а надо ли вообще отслеживать «архитектурную нормальность»?
Если и правда надо, то я кидал сюда тестовый проект как это можно сделать. В С# и яве, такое есть
https://github.com/TNG/ArchUnit-Examples/tree/main/example-junit5/src/test/java/com/tngtech/archunit/exampletest/junit5
Если и правда надо, то я кидал сюда тестовый проект как это можно сделать. В С# и яве, такое есть
https://github.com/TNG/ArchUnit-Examples/tree/main/example-junit5/src/test/java/com/tngtech/archunit/exampletest/junit5
Y
Про что еще, там было так:
-Owasp scan - быстрая проверка
-SonarQube - стат анализ
-White hat nexus plugin for dependencies scan (не помню название) - лицензионная чистота и уязвимые зависимости
-ChekMarx - динамический анализ
Возможно еще что-то, но я уже и не вспомню
-Owasp scan - быстрая проверка
-SonarQube - стат анализ
-White hat nexus plugin for dependencies scan (не помню название) - лицензионная чистота и уязвимые зависимости
-ChekMarx - динамический анализ
Возможно еще что-то, но я уже и не вспомню
АБ
Это уже какие-то круги ада. Эти кто-то пользуется?
Наверное, если ты какой-то огромный энтерпрайз только…
Core review - это же не только контроль правильности, но и обучение и расшаривание знаний в команде. Контроль за джунами/начинающими мидлами/новыми членами команды
Наверное, если ты какой-то огромный энтерпрайз только…
Core review - это же не только контроль правильности, но и обучение и расшаривание знаний в команде. Контроль за джунами/начинающими мидлами/новыми членами команды
AR
Антон это я :)
Если говорить о postgresql то я делаю тулзы для отслеживания качества кода (sql) даже если у тебя orm (holistic.dev)
если не orm, то можно воспользоваться вот этим:
https://github.com/parsers-dev/sql-type-tracker
дает понять, что сломается еще до пуша
Если говорить о postgresql то я делаю тулзы для отслеживания качества кода (sql) даже если у тебя orm (holistic.dev)
если не orm, то можно воспользоваться вот этим:
https://github.com/parsers-dev/sql-type-tracker
дает понять, что сломается еще до пуша
Y
Аргумент в том, что скорее всего не нужно вам следить за качеством кода на этапе пулл реквеста. Можно и потом посмотреть. Код формально проходит - пусть его мержат, если что, в следующем коммите на след день поправите
АБ
не т. е. кто-то должен будет все равно посмотреть реквест постфактум
Y
Там уже возможны опции. Все зависит от ситуации. Могу расписать основные варианты, если интересно.
Пулл реквест плох тем, что его ревью завязано на людей, которые могут тупить, придираться и еще много чего
Пулл реквест плох тем, что его ревью завязано на людей, которые могут тупить, придираться и еще много чего
АБ
Интересно. Распиши
Y
Если так страшно упустить качество кода - то лучше утром смотреть дифф того, что в кодовой базе изменилось за день
Y
Давай тогда встречный вопрос задам:
Для чего вам фаза ревью?
Для чего вам фаза ревью?
MS
++
заодно отсеивает блок PR по причине "мне тут не нравится нейминг" и прочих мелочей
заодно отсеивает блок PR по причине "мне тут не нравится нейминг" и прочих мелочей
MS
если это важно - пожно постофиксом
MS
но это при условии что команда хорошая
если там джуны сидят, так не будет работать
если там джуны сидят, так не будет работать
MS
у нас еще если прогер считает что "где-то тут может быть важный проеб" может попроспть отревьюить до мержа
АБ
Для меня ревью кода - это:
- расшаривание знаний в команде
- соблюдение единого подхода к именованию классов/полей/переменных. Особенно в мире golang, где все так любят однобуквенный нечитаемый код
- валидация мыслей писателя и его подходов.
- валидация тестов и описания тесткейсов
- расшаривание знаний в команде
- соблюдение единого подхода к именованию классов/полей/переменных. Особенно в мире golang, где все так любят однобуквенный нечитаемый код
- валидация мыслей писателя и его подходов.
- валидация тестов и описания тесткейсов
Y
Сейчас быстрый ответ дам, потом дам другой:
1) сомнительно, потому что тогда либо все должны проревьюить все, либо...
2) это в большинстве кейсов решает sast, и минус споры о вкусовщине
3) дешевле ревьюить ненаписанный код, можно делать на фазе design review
4) аналогично пункту 3
1) сомнительно, потому что тогда либо все должны проревьюить все, либо...
2) это в большинстве кейсов решает sast, и минус споры о вкусовщине
3) дешевле ревьюить ненаписанный код, можно делать на фазе design review
4) аналогично пункту 3