было бы круто! Каргокульты — наше все

Можно без инструментов )

да там даже специальная команда есть для осуждения.

кек

Странный вывод. Я ещё предлагаю git запретить, там видно кто автор строки - это побуждает к конфликтам, кек

Всё-таки какой-то профессионализм нужно развивать в индустрии

+
и все опенсорс проекты работают с пулл реквестами
и защиту бранчей не просто так придумали, даже человек с правами контрибьютора должен получить апрув от другого контрибьютора

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

я сомневаюсь, что серьёзный бизнес (== капитализация от 100 лям евро) готов нести все риски, чтобы сэкономить средства на "лишние" часы инженеров
пропустишь "норм" код в продакшен, и налетишь на хак, GDPR штраф или ещё что-то нехорошее и дорогое

На уровне два такая ошибка - $10
На уровне qa - $30
На уровне дев окружения - $500
На уровне стейдж - $1000
На проде - десятки, сотни, лямы.....

кстати я не против design review, и я адово топлю за ADR
это лучшее, что в принципе люди придумали для документирования кода и дизайна

ADR..
Двигатель audi a4b5 1.8 125 сил

При чем тут opensource проекты с внешними PRами? Там дофига причин иметь схему с PR, так как никакой другой защиты не предусмотреть и даже нельзя определить, кто именно принес PR.
Но внутри команды - совершенно другая обстановка и зачем переносить схему opensource на командную разработку - не понятно.

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

Ну, как я вижу, ты все еще даже не просмотрел слайды доклада.

Привет! :) А расскажи пожалуйста, чем именно не нравится ADR?

В стандартных кейсах внедрения (отдельный документ, формальная структура) он получается полностью бесполезным и не связанным с кодом. Если на продукт таких ADRок 10-15, то нет проблем. Если 100, то с ними уже сложно (невозможно) работать.
Ну и в таком подходе ADR становится мало отличим от meeting notes по любой арх.задаче.

если 100 то надо структурировать
и да, это meeting notes по сути, просто в гите и оформленные структурно

Спасибо :) я смотрю на ADR как на хороший коммент на стероидах - рассказываем зачем/почему понадобилось что-то сделать, какие были альтернативы если были - и как с этим дальше жить

То есть хорошо когда он маленький, а по связи с кодом - придумал такой фокус
В коде даём очень краткую выжимку к зачем/почему - по сути коммент, рядом указываем ссылку на ADR с номером

Итого из кода можно найти док в котором подробности решения, а из дока - места в коде где оно реализовано

Количество приближается к 50 за полгода

Ну а толку от них в гите? В Confluence оно полезнее.

А форматы они там разные вроде есть, MADR, и ещё какие-то

Ну я бы делал чуть иначе.
В коммите ссылка на задачу, а уже в design review ссылка на связанные ADR. Это удобнее и наблюдаемее.

конфлюенс безумно полезен, но он для всех вообще  и про всё
а ADR про код и продукт, и только про них

проект начали 3 месяца назад, пока ADR 21 штука