ищу инструмент для code review \ code audit

ты описываешь gerrit, но ты им не пользуйся — тот еще кусок говна

Ревьюят обычно изменения при пулл-реквесте. Для всего остального нужно просто написать тесты.

То, что ты хочешь, не имеет и капли смысла, ибо качество ревью ни один инструмент гарантировать не может.

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

это твоя личная картина мира

Так работает любая профессиональная разработка, маня, не надо тут.

качество ревью, о чем ты вообще

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

мои ситуации требуют того инструмента, что я написал

Земля пухом твоим проектам.

хотя бы два человека подтвердило

Подтверждать таким образом мердж-реквесты не вариант? Вроде самая популярная практика, и в мастер код не попадает до проверки.

Либо можно прикрутить сбоку любой сервис для ревью, например upsource, но уже вручную отслеживать что код неправильный код не попал куда не надо.

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

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

ТС хочет не инструмент ревью ПРов, а трекер аудита кода (вне ПРов).

Из того, что можно сказать сейчас - из коробки точно такое будет не скоро, если вообще: https://gitlab.com/gitlab-org/gitlab/-/issues/15470

Вот здесь есть описание костыля, который позволяет добиться похожего поведения на механизме стандартных ПРов: https://astrofrog.github.io/blog/2013/04/10/how-to-conduct-a-full-code-review-on-github/

ТС, если найдешь что-то, отпишись, интересно.

Вообще, вряд ли что-то супер-общее найдешь. Основная задача аудита обычно - безопасность, и глазами никто не смотрит, есть куча софта (https://owasp.org/www-community/Source_Code_Analysis_Tools). Его запускают автоматом, и уже на основе его отчетов продолжают работать. То же самое и для качества кода в целом.

Можешь сделать так: у тебя задача - чтобы убедились, что код написано «хорошо». «Хорошо» - это набор каких-то метрик (соответствие стилю, требования по безопасности, требования по производительность и т.д.). Прикручиваешь к репозиторию набор средств для этого (трекинг качества кода, трекинг уязвимостей и т.д.), прогоняешь на мастере. На основе отчетов создаешь миллион issues в трекере, ассайнишь их на кого попало. Потом по каждой из них открывается ПР, его уже ревьювят, таким образом, ты решаешь свою первоначальную проблему. Потом включаешь это не на мастере, а на отдельных ПРах, таким образом получая гарантию того, что хуже, чем есть, не станет.

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

А почему самим фактом принятия пулл-реквеста целиком не считать, что все причастные его уже посмотрели и подтвердили своё «хорошо»?

ТС хочет не инструмент ревью ПРов, а трекер аудита кода

Спасибо, Кэп.

То, что ты хочешь, не имеет и капли смысла, ибо качество ревью ни один инструмент гарантировать не может

Твоё капитанство утверждения не отменяет.

У него же цель провести аудит того, что есть, а не того, что предлагают.

Спасибо, Кэп.

пожалуйста, школьник из 2015-го

качество ревью ни один инструмент гарантировать не может

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

Т.е. есть некий написанный проект и тебе нужно что его еще просмотрели?

код написан без ошибок

Не сработает, говорю как кодер c 10+ годами опыта, конечно можно всякие WTF понаписать и даже можно что-то найти вопиющее, но основная масса ошибок останется.

Упомянутый здесь gerrit про другое, это ревью нового кода. Через него можно сделать так, что новый код должен пройти ревью минимум двух разработчиков прежде чем будет отправлен в ветку.

Но даже с gerrit смотреть на код через веб интерфейс мало, нужно выгружать изменения и смотреть прямо в IDE с навигацией по коду. Это нужно чтоб проанализировать работу, а не навязывать свои стилистические предпочтения (для последнего лучше годятся статические анализаторы).

Это надо чтобы хотя бы два человека подтвердило

Можно организационно решить. Пуская ревьюверы в каждом файле исходников, в главном комменте, отмечают свое ревью, например: @ReviewedBy Harvey_Weinstein 27/05/2020 потом сможешь загребать и отчет сделать (я так понял, ради этого все и делается).

форсить качество ревью

Тебе пацаны из соседней палаты рассказали?

По-моему, для этого достаточно «то, что есть» снова превратить в «то, что предлагают» к пересмотру.

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