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

спасибо!

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

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

по пунктам:
- неэффективность код ревью и то что оно провоцирует непродуктивные споры - я писал выше про токсичные среды, фиксите среду и всё будет работать
- линтеры и статические анализаторы - разумеется, языки со строкой типизацией - да, только они
- автоматическое тестирование - конечно! только надо уметь готовить, а то городят разных хрупких конструкций из селениумов которые падают раз из трёх
- "не думать о качестве, думать о скорости" - ахах, бугаенко тот ещё авторитет
- дизайн/эксперт ревью - в нормальных командах это само собой происходит: взял задачу, что-то понял, но не всё, потом поговорил полчаса с лидом, понял всё и сделал
писать в issue tracker, ну такое - никто это потом не читает
и да, лид тебя может ткнуть в ADR где всё про это релевантное, или же попросить написать ADR как часть имплементации
- тех координатор - называться может по разному, но да, есть несомненная польза что один человек является финальным авторитетом, и он решает и с опсами и с девелоперами, как что должно делаться - и главное, объясняет почему
- ..on demand - и чем это отличается от code review? создавая pull request нормальные инженеры обычно пишут тезисно, что они поменяли и какие риски
- pair programming - очень полезно когда новый человек приходит и ему надо въехать, или же когда анализируем проблему
сложные куски кода писать вместе? ну может быть
- подбирать практики под команду, быть конструктивными и доверять - безусловно

1. Среду пофиксить не всегда возможно, дело не в ее токсичности, а в разных подходах и ценностях.
Ну и неэффективность Code Review только через среду не починить, это все равно очень дорого.
3. Ну, про автотестирование я может сделаю отдельный доклад, там все гораздо сложнее, чем "пирамида тестирвания и покрытие юнит-тестами"
4. Там в докладе много разных практик про линтеры и автоприемку. Название полностью противоречит содержанию.
5. Дизайн-ревью и эксперт-ревью - совсем разные практики. И нет, если нет экспертов и бюджета, то само по себе эксперт-ревью не работает.
При чем тут issue-tracker и ADR - вообще не понятно, ты о чем?
7. Отличается добровольностью и фокусировкой на сложности.  PR предполагает ревью всего кода, а не отдельной части.
8. Ну, у pair programming много использований, я выбрал релевантные теме доклада.

Спасибо👍 не понял про "если не захотелось принять ещё один ADR", это именно в смысле решения - а не какого то документа?
А если и захотелось, то что мешает просто обновить итоговый техдизайн - если решили не оформлять связанные решения в мини-документы, то решение фиксируется напрямую в техдизайне без выноса решения отдельной ссылкой на отдельный док?

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

Техдизайн - это про конкретную фичу.
АDR - про весь продукт.
Т.е. фича "сделать отчет по движению средств"
ADR "Почему выбрали Jasper Reports"

И тогда в техдизайне фичи будет что-то вроде:
1) Добавляем в такие-то сервисы такие-то вызовы
2) Рисуем отчет на джаспере (см. ADR)
3) Добавляем в процесс деплоя Jasper Reports Engine

наверное в каждом монастыре своё понимание сути ADR, и это может быть даже нормально
у нас ADR описывают например структуру URL или JWT token claims

Так это все равно про весь продукт, а не про конкретную фичу?

жизненный цикл соединения клиента
жизненный цикл stateful бизнес-сущности

и что значит "фича"? новое поле на форме? про такое не надо ADR, не

ADR - не надо. Тех.дизайн - надо.
Там же обычно "есть такой-то use case, нужно его реализовать". А как именно его реализовать (распилить по разным бизнес-сущностям, методам API и так далее) описывается тех.дизайном, там всегда есть что посмотреть.

Проверять же это на code review - неудобно и уже поздно.
А потом выясняется, что использование design review + expert review + qa review дает больше качества, чем code review на реквесте и делает его ненужным

ну вот как-то непонятно зачем это формализовать, выделять и писать в тикеты
всегда (== во всех командах за последние много лет) инженеры справлялись с техдизайном в формате устных обсуждений и pair, не programming, но смотрения в код, даже с удалёнкой вполне

а потом уже code review, как без него

правда нигде не было прям зелёных джунов, может в этом дело

Ну вот и получается фигово. Так как в устных обсуждениях оно все теряется, код после таких просмотров приходится переписывать и вообще тратить дофига ресурсов. Содержательный code review стоит очень много, не содержательный бесполезен.

И да, лучше всего design review работает с крепкими миддлами и выше.
Как раз для джунов его мало, но процесс обучения - не есть процесс разработки

И да, мой опыт говорит, что без design review инженеры начинают пороть лютую фигню - переусложенение, плохое понимание постановок, потерю архитектурного единства. Даже хорошие сеньоры и миддлы.