Пару раз такой подход меня выручал. Это был больше библиотечный код с необходимостью расширения и интеграции функционала в довольно разношерстные микросервисы. Не всем нужно, никого не уговариваю :)
Он обычно и выносится. Когда в модуль, когда в отдельный репозиторий. Но поддержка со стороны модулей-потребителей никуда не денется. Отсюда и получаются дто с имплементацией интерфейсов.
Да, изменение промежуточного слоя контрактов потребует поддержки. Но иногда он дает выгоду, потому что бывает частая смена структуры дто, внутренние рефакторинги модулей и так далее. Если мы внутри отрефакторим модуль и поддержим контракты, другие модули ничего и не заметят. Если мы отрефакторим дто, другим модулям уже будет посложнее. Целесообразность использования зависит от многих вещей и в большинстве случаев избыточна, согласен.
У вас какое-то странное толкование dip. Там как раз и говорится про любую зависимость, а вы абстрагировали этот принцип только бизнес-логикой.
На практике мы можем извлечь выгоду от общения через интерфейсы вместо самих dto довольно просто. Потому что расположение dto может быть внутри модуля, и тогда при смене структуры или переносе этого dto в другой неймспейс нам придется адаптировать другие модули под новые реалии. Если же мы спрячем контракт под интерфейс вместо реализации и вынесем эти интерфейсы отдельно, зависимость между модулями ослабнет, т.к. они будут общаться через интерфейсы промежуточного слоя, и перенос реализации интерфейса в одном модуле никак не повлияет на другой модуль, использующий промежуточный контракт. Но тогда мы подпишемся на поддержку этого промежуточного слоя. На больших проектах помогает.
Так если полностью соблюдать инверсию зависимостей, то весь граничный контекст должен общаться посредством интерфейсов, а не реализации. И мы не можем передавать эту реализацию напрямую. Тут и получается, что dto имплементирует интерфейс если мы хотим передать его соблюдая dip. И на выходе получаем интерфейс, который имплементирует уже другая часть граничного контекста, что чаще всего является тем же dto.
Рационально ли это? Далеко не всегда. По солидному? Да. Усложняет код и поддержку? В разы.
У всех свой усредненный проект. У кого-то говнокод приносит немалые суммы и кормит большие команды разработки десятилетями, у кого-то даже первого пользователя за два года разработки нет, а код продолжает вылизываться сжигая деньги инвесторов.
Эти два примера я привел из реальных проектов над которыми работал.
Лично мое мнение, что dip хорош только когда архитектурно продуманы точки роста проекта. И это обычно не любой класс под интерфейсом, а те части, которые действительно могут замениться на другие реализации или адаптеры. Совсем избегать интерфейсов не советую никому, но и доводить до того, что каждая дто может в себя имплементировать под пяток интерфейсов тоже не стоит.
1) Помимо создания файлика (а в некоторых языках интерфейс не располагается в отдельном файле) есть еще регистрация этого интерфейса. Не все языки и контейнеры зависимостей поддерживают автовайринг. И часто изменения класса будет требовать изменения интерфейса, либо наоборот. За этим нужно постоянно следить. А если еще нет нормального компилятора или статического анализатора - пиши пропало и имей множество дебага, из-за того, что кто-то что-то не дописал или описал не так.
2) У интерфейсов есть преимущества и их пользу я не отрицал. Но далеко не все проекты требуют обмазывания интерфейсами со всех сторон по разным причинам. Есть mvp, есть ограничения языка и используемых библиотек, есть недостаток времени и давление со стороны менеджмента, есть внутрикомандные регламенты и т.д. и т.п.
Сеньер как раз побывал в разных ситуациях и не видит только черного и белого от использования того или иного подхода, и может сконфигурировать код в зависимости от внешних факторов для оптимальной доставки функционала, по пути решив, насколько его код будет углублен в академичную сторону.
На один и тот же вопрос джуниор и сеньер отвечают по разному.
Джуниор может вызубрить солид на википедии, а сеньер тебе расскажет примеры из практики этих букв, в том числе и примеры, когда следовало избегать слепого следования какой-либо буквы солида, и когда та же буква D в итоге незнамо как переусложнила код и поддержку из-за обилия интерфейсов, а подмены реализации этих интерфейсов в приложении так и не случилось ни разу.
Джуниор тебе напишет алгоритм бинарного поиска, а у сеньера есть пару случаев из практики, когда люди писали этот бинарный поиск, и его поддержка и последующее устранение заняло несколько недель возни с легасней, потому что изначально не использовали более подходящие для этого инструменты.
Джуниор расскажет про базовую авторизацию фреймворка, потому что недавно читал доку и знания освежил. Сеньер расскажет про опыт использования различных подходов к авторизации на этом фреймворке и расскажет про бандлы, которые лучше стороной обходить, если не хотите столкнуться с теми то и теми то проблемами.
В целом, когда я задаю подобные теоретические вопросы на собеседовании, всегда стараюсь по первичному ответу понять погруженность в конкретную тему, и копать дальше, если есть куда. Только так можно раскрыть опыт человека. И не ответ на некоторые вопросы не означает, что человек провалил собеседование, потому что оно состоит из нескольких теоретических частей, по которым ты в целом можешь понимать, на какой проект и роль можно определить человека, и какой у него технический кругозор, абмиции и т.д.
Да, есть некоторые очень душные вопросы и задачки, по которым пытаются понять, сможет ли человек сделать хоть что-то. Но в целом, вам задают эти вопросы, потому что на общих терминах в индустрии происходит общение внутри команды. И даже если вы сами пересобрали все паттерны проектирования и сами досмыслили базовые архитектурные принципы, вы будете очень долго доносить идею до команды. И в команде вам скорее всего ответят, что "да ты же предлагаешь такую-то аббревиатуру". Быстрая синхронизация с командой и общение на одном языке на самом деле нередко перевешивают харды человека.
Люди повышают себе зарплату путем смены работы. Компании об этом знают, но адекватно реагируют на это единицы. Продолжается такое десятилетиями. Значит, людей, которые могут себе позволить тратить огромные бюджеты на найм вместо удержания, такая ситуация устраивает.
Некоторые даже специально настроены на постоянную смену днк внутри компании, и считают эти обновления коллективов во благо, потому что таким образом перенимается опыт новых сотрудников с другими подходами из более крутых команд. Иногда такое действительно работает, и проект начинает жить новой жизнью. Иногда становится лишь хуже, потому что компания сама оказывается не готова к новым подходам, либо новые люди не оправдывают надежд.
Уход ключевых сотрудников всегда является достаточно серьезным уроном по командам, в которых они работают. Но и случается ситуация, что команда бизнесу особо не интересна. И бизнес пускает ее на самотек вместо жесткого устранения, постепенно переводя на поддержку. Это и выливается в сопротивление от всех отделов внутри компании для этой команды.
В общем, чаще всего не hr принимают эти решения, а кто-то повыше. И полную картину вряд ли донесут полностью до рядового сотрудника, который хочет повышения.
Код может быть идеальным и работать без багов, но бизнес может использовать фичу себе в убыток.
Или фичу могут тормозить вообще по независимым от разработчика различным причинам.
Или количество пофикшенных багов может говорить о том, что код изначально был плохо написан, и его целый год с гордостью залатывали, по пути плодя еще больше багов.
Или написанную документацию прочел один человек, а остальным она оказалась не нужна.
Или собеседования велись в отдел, который на этапе формирования, и прибыль будет приносить лишь спустя несколько лет.
Не стоит перекладывать ответственность бизнеса на реализаторов. Они не могут быть ответственны за результат и прибыль, потому что над ними, как правило, есть своя иерархия управленцев, которые уже и влияют на прибыль.
Как мне видится, оценивать работу разработчика можно по количеству оставленных артефактов и следованию процессам разработки в компании, но не по итоговому результату отдела. Потому что чем больше компания, тем меньше разработчик может на что-то влиять в ее процессах непосредственно.
Писал сопроводительные письма когда имел очень ограниченный список вакансий на выбор, чтобы они сыграли дополнительным бонусом при рассмотрении моей кандидатуры. Пару раз помогло, и люди были впечатлены изложением и подходом.
Позже, когда стал более уверен в своих силах, и список подходящих вакансий разросся, попробовал тоже присылать сопроводительное письмо. Столкнулся с тем, что в большинстве случаев люди даже с резюме ознакамливались лишь во время непосредственного диалога на собеседовании, а сопроводительное письмо отфильтровывал hr и не пускал дальше себя. Получалось, что люди задавали вопросы, ответы на которые были в сопроводительном письме, но прочитать его люди не стремились.
Остановился на отсутствии сопроводительного письма и довольно подробном описании резюме. Плюс готовности расширить информацию о себе, если резюме оказалось недостаточным. На данный момент думаю даже сократить резюме, но желания писать сопроводительное письмо не возникает совсем. Считаю что не стоит оно того.
Кому ли, как не профессиональному рекрутеру знать, что любая вакансия - это список пожеланий, и никогда не будет требовать 100% мэтча с ожиданиями? Потому и откликнулись в том числе люди с больших компаний, которые увидели большую цифру.
Ваши действия трактуются как "Сделать замануху, на которую клюнут совсем разные люди, и сделать выводы на основе откликов, что требования не совпали на 100%, по пути сказав, какие все кандидаты непутевые и читать не умеют". Хотя там у кандидатов и не было целью быть подходящими на 100% под вашу вакансию.
А вы точно уверены, что все откликнувшиеся являются профессиональными рекрутерами? Думаю как раз больше половины решили попытать удачу увидев большие цифры, не являясь на деле опытными профессионалами. Такова судьба вакансий с оплатой выше рынка - для них всегда первоначальный фильтр будет отсеивать большую часть резюме.
Ни в коем случае не оправдываю то, что все эйчары являются высоковквалифицированными людьми, но считаю эксперимент нерепрезентативным, и его выводы оскорбительными, а заголовок кликбейтным.
Да и сам метод проведения считаю с запашком. Размещать фейковые вакансии и требовать сопроводительные письма, не предлагая работу по факту, еще и ехидно хихикая над результатами. Вы бы еще тестовое задание дали на недельки 2.
А если не занимался? Тут и приходят на помощь доп. уведомления. И либо они вручную через чат вроде "посмотри плиз", либо через автоматизацию, которая на практике выигрывает человеческому фактору, что и показали метрики в посте.
Репозиторий не обязательно может являться проектом. Там может быть переиспользуемый библиотечный или инфраструктурный код. И чем дольше работаешь, тем чаще ты в тот или иной репо можешь добавить свои коммиты, чтобы задачку продвинуть связанную. Естественно, никто не говорит про овнерство 200 репозиториями. Но даже у одной команды может накопиться десяток репозиториев с поддержкой кода.
Можно, например, работать, выполняя свои непосредственные обязанности, в которые обычно не входит мониторинг всего и вся.
Не понимаю вашего сопротивления более удобной формы уведомлений в виде агрегации всего кода, который необходимо посмотреть.
У меня, например, открыт доступ к 200+ репозиториям, и если я буду заниматься мониторингом всего и вся, я только на него и буду тратить весь свой рабочий день даже вместо самого ревью. А так я каждый жень получаю уведомления от бота, который мне говорит "посмотри реквесты, порешай конфликты, зарезолвь треды где ты ответственен". Вместо выковыривания информации по крупицам я сразу получаю удобный инструмент для работы. И это в разы лучше, чем пинговать людей с разным графиком и подходом к работе на предмет ревью кода, плюс заниматься этим вручную.
Или сам процесс уведомлений неэффективен. Чем дольше человек в компании, тем больше он получает писем. И письма с ревью и прочими письмами в компании совсем не дают результата, т.к. разгребание почты и чатиков может занять очень много времени.
Ежедневное напоминание о задачах по ревью очень выручает, т.к. перед глазами всегда есть удобная сводка пулл-реквестов, по которым нужно что-нибудь сделать. При сильном загрузе на основе этой сводки можно даже букать время в календаре под процесс ревью, тогда он проходит в разы быстрее.
Так больше всего сами компании в этом и виноваты. Устраивают гонку в лояльность и промытие мозгов своими "семейными ценностями" с одной стороны, расформировывают отделы и увольняют пачками людей, перекидывая нагрузку на оставшихся сотрудников с другой. Т.е. ты должен быть как преданный сын, но мы можем сдать тебя в детдом и лишить бенефитов в любой момент. Когда встречаешься с таким диссонансом, перестаешь играть в подобные игры. Это здравый смысл, а не тихое увольнение.
Встречал людей, которым опаливали крылья, выплачивая 5% от обещанной премии под различными предлогами. Встречал закручивание гаек и оптимизацию расходов в виде урезания корпоративных плюшек уже на второй месяц работы. Встречал компании с полупремиальной зарплатой, которые при расставании забывали про премиальную часть.
В общем, мой опыт в российской разработке мне прямо диктует, что можно рассчитывать только на суммы, указанные в зарплате. Остальное, конечно, тоже можно брать в расчет, но не является ключевым фактором при выборе работодателя.
Очень рад ошибаться, если ваш опыт корпоративных плюшек более распространен в мире.
1) Выработали план, по которому принимаем соглашения на уровне стека
2) Выработали подход по плану. Назначался ведущий, который готовил и принимал последующие вопросы и пункты к обсуждению, согласовали формат обсуждений и оповещений об изменениях.
3) Раз в неделю собирались стеком и шли по плану.
4) В ходе обсуждений задавались конкретные вопросы и фиксировались результаты обсуждений в виде рекомендаций или обязательных правил. Фиксировались на странице вики в формате markdown, об изменениях оповещались участники процесса.
5) В параллеле с вопросами стека применили похожую схему к процессам в команде (git-flow, ревью, детализация, тестирование, практика релизов).
6) При дальнейших действиях в команде ее участник уже имел справочную информацию в виде документов, на которые можно опираться при принятии решений.
7) Попробовали нововведения в бою, настроили механизм отладки соглашений, запустили переодический пересмотр.
8) Автоматизировали лишь спустя какое-то время, и далеко не все. Потому что некоторые правила требовали достаточно весомых затрат на автоматизацию.
9) Запустили таким образом кросс-командные соглашения.
Это, конечно, все потребовало очень много времени на согласования и настройку продуктивной атмосферы для принятия решений, но в итоге получили прозрачные процессы. Если кратко резюмировать, то это дорого, и не везде применимо. Но стоит того.
Пару раз такой подход меня выручал. Это был больше библиотечный код с необходимостью расширения и интеграции функционала в довольно разношерстные микросервисы. Не всем нужно, никого не уговариваю :)
Перенести, переименовать, свойство со снейк-кейса на кемел по внутреннему регламенту отформатировать и т.д.
На самом деле, в ходе бурной работы над проектом могут быть самые непредсказуемые изменения, в том числе не всегда чистые и честные
Он обычно и выносится. Когда в модуль, когда в отдельный репозиторий. Но поддержка со стороны модулей-потребителей никуда не денется. Отсюда и получаются дто с имплементацией интерфейсов.
Да, изменение промежуточного слоя контрактов потребует поддержки. Но иногда он дает выгоду, потому что бывает частая смена структуры дто, внутренние рефакторинги модулей и так далее. Если мы внутри отрефакторим модуль и поддержим контракты, другие модули ничего и не заметят. Если мы отрефакторим дто, другим модулям уже будет посложнее. Целесообразность использования зависит от многих вещей и в большинстве случаев избыточна, согласен.
У вас какое-то странное толкование dip. Там как раз и говорится про любую зависимость, а вы абстрагировали этот принцип только бизнес-логикой.
На практике мы можем извлечь выгоду от общения через интерфейсы вместо самих dto довольно просто. Потому что расположение dto может быть внутри модуля, и тогда при смене структуры или переносе этого dto в другой неймспейс нам придется адаптировать другие модули под новые реалии. Если же мы спрячем контракт под интерфейс вместо реализации и вынесем эти интерфейсы отдельно, зависимость между модулями ослабнет, т.к. они будут общаться через интерфейсы промежуточного слоя, и перенос реализации интерфейса в одном модуле никак не повлияет на другой модуль, использующий промежуточный контракт. Но тогда мы подпишемся на поддержку этого промежуточного слоя. На больших проектах помогает.
Так если полностью соблюдать инверсию зависимостей, то весь граничный контекст должен общаться посредством интерфейсов, а не реализации. И мы не можем передавать эту реализацию напрямую. Тут и получается, что dto имплементирует интерфейс если мы хотим передать его соблюдая dip. И на выходе получаем интерфейс, который имплементирует уже другая часть граничного контекста, что чаще всего является тем же dto.
Рационально ли это? Далеко не всегда. По солидному? Да. Усложняет код и поддержку? В разы.
У всех свой усредненный проект. У кого-то говнокод приносит немалые суммы и кормит большие команды разработки десятилетями, у кого-то даже первого пользователя за два года разработки нет, а код продолжает вылизываться сжигая деньги инвесторов.
Эти два примера я привел из реальных проектов над которыми работал.
Лично мое мнение, что dip хорош только когда архитектурно продуманы точки роста проекта. И это обычно не любой класс под интерфейсом, а те части, которые действительно могут замениться на другие реализации или адаптеры. Совсем избегать интерфейсов не советую никому, но и доводить до того, что каждая дто может в себя имплементировать под пяток интерфейсов тоже не стоит.
1) Помимо создания файлика (а в некоторых языках интерфейс не располагается в отдельном файле) есть еще регистрация этого интерфейса. Не все языки и контейнеры зависимостей поддерживают автовайринг. И часто изменения класса будет требовать изменения интерфейса, либо наоборот. За этим нужно постоянно следить. А если еще нет нормального компилятора или статического анализатора - пиши пропало и имей множество дебага, из-за того, что кто-то что-то не дописал или описал не так.
2) У интерфейсов есть преимущества и их пользу я не отрицал. Но далеко не все проекты требуют обмазывания интерфейсами со всех сторон по разным причинам. Есть mvp, есть ограничения языка и используемых библиотек, есть недостаток времени и давление со стороны менеджмента, есть внутрикомандные регламенты и т.д. и т.п.
Сеньер как раз побывал в разных ситуациях и не видит только черного и белого от использования того или иного подхода, и может сконфигурировать код в зависимости от внешних факторов для оптимальной доставки функционала, по пути решив, насколько его код будет углублен в академичную сторону.
На один и тот же вопрос джуниор и сеньер отвечают по разному.
Джуниор может вызубрить солид на википедии, а сеньер тебе расскажет примеры из практики этих букв, в том числе и примеры, когда следовало избегать слепого следования какой-либо буквы солида, и когда та же буква D в итоге незнамо как переусложнила код и поддержку из-за обилия интерфейсов, а подмены реализации этих интерфейсов в приложении так и не случилось ни разу.
Джуниор тебе напишет алгоритм бинарного поиска, а у сеньера есть пару случаев из практики, когда люди писали этот бинарный поиск, и его поддержка и последующее устранение заняло несколько недель возни с легасней, потому что изначально не использовали более подходящие для этого инструменты.
Джуниор расскажет про базовую авторизацию фреймворка, потому что недавно читал доку и знания освежил. Сеньер расскажет про опыт использования различных подходов к авторизации на этом фреймворке и расскажет про бандлы, которые лучше стороной обходить, если не хотите столкнуться с теми то и теми то проблемами.
В целом, когда я задаю подобные теоретические вопросы на собеседовании, всегда стараюсь по первичному ответу понять погруженность в конкретную тему, и копать дальше, если есть куда. Только так можно раскрыть опыт человека. И не ответ на некоторые вопросы не означает, что человек провалил собеседование, потому что оно состоит из нескольких теоретических частей, по которым ты в целом можешь понимать, на какой проект и роль можно определить человека, и какой у него технический кругозор, абмиции и т.д.
Да, есть некоторые очень душные вопросы и задачки, по которым пытаются понять, сможет ли человек сделать хоть что-то. Но в целом, вам задают эти вопросы, потому что на общих терминах в индустрии происходит общение внутри команды. И даже если вы сами пересобрали все паттерны проектирования и сами досмыслили базовые архитектурные принципы, вы будете очень долго доносить идею до команды. И в команде вам скорее всего ответят, что "да ты же предлагаешь такую-то аббревиатуру". Быстрая синхронизация с командой и общение на одном языке на самом деле нередко перевешивают харды человека.
Люди повышают себе зарплату путем смены работы. Компании об этом знают, но адекватно реагируют на это единицы. Продолжается такое десятилетиями. Значит, людей, которые могут себе позволить тратить огромные бюджеты на найм вместо удержания, такая ситуация устраивает.
Некоторые даже специально настроены на постоянную смену днк внутри компании, и считают эти обновления коллективов во благо, потому что таким образом перенимается опыт новых сотрудников с другими подходами из более крутых команд. Иногда такое действительно работает, и проект начинает жить новой жизнью. Иногда становится лишь хуже, потому что компания сама оказывается не готова к новым подходам, либо новые люди не оправдывают надежд.
Уход ключевых сотрудников всегда является достаточно серьезным уроном по командам, в которых они работают. Но и случается ситуация, что команда бизнесу особо не интересна. И бизнес пускает ее на самотек вместо жесткого устранения, постепенно переводя на поддержку. Это и выливается в сопротивление от всех отделов внутри компании для этой команды.
В общем, чаще всего не hr принимают эти решения, а кто-то повыше. И полную картину вряд ли донесут полностью до рядового сотрудника, который хочет повышения.
Так эти метрики не влияют на прибыль компании.
Код может быть идеальным и работать без багов, но бизнес может использовать фичу себе в убыток.
Или фичу могут тормозить вообще по независимым от разработчика различным причинам.
Или количество пофикшенных багов может говорить о том, что код изначально был плохо написан, и его целый год с гордостью залатывали, по пути плодя еще больше багов.
Или написанную документацию прочел один человек, а остальным она оказалась не нужна.
Или собеседования велись в отдел, который на этапе формирования, и прибыль будет приносить лишь спустя несколько лет.
Не стоит перекладывать ответственность бизнеса на реализаторов. Они не могут быть ответственны за результат и прибыль, потому что над ними, как правило, есть своя иерархия управленцев, которые уже и влияют на прибыль.
Как мне видится, оценивать работу разработчика можно по количеству оставленных артефактов и следованию процессам разработки в компании, но не по итоговому результату отдела. Потому что чем больше компания, тем меньше разработчик может на что-то влиять в ее процессах непосредственно.
Писал сопроводительные письма когда имел очень ограниченный список вакансий на выбор, чтобы они сыграли дополнительным бонусом при рассмотрении моей кандидатуры. Пару раз помогло, и люди были впечатлены изложением и подходом.
Позже, когда стал более уверен в своих силах, и список подходящих вакансий разросся, попробовал тоже присылать сопроводительное письмо. Столкнулся с тем, что в большинстве случаев люди даже с резюме ознакамливались лишь во время непосредственного диалога на собеседовании, а сопроводительное письмо отфильтровывал hr и не пускал дальше себя. Получалось, что люди задавали вопросы, ответы на которые были в сопроводительном письме, но прочитать его люди не стремились.
Остановился на отсутствии сопроводительного письма и довольно подробном описании резюме. Плюс готовности расширить информацию о себе, если резюме оказалось недостаточным. На данный момент думаю даже сократить резюме, но желания писать сопроводительное письмо не возникает совсем. Считаю что не стоит оно того.
Кому ли, как не профессиональному рекрутеру знать, что любая вакансия - это список пожеланий, и никогда не будет требовать 100% мэтча с ожиданиями? Потому и откликнулись в том числе люди с больших компаний, которые увидели большую цифру.
Ваши действия трактуются как "Сделать замануху, на которую клюнут совсем разные люди, и сделать выводы на основе откликов, что требования не совпали на 100%, по пути сказав, какие все кандидаты непутевые и читать не умеют". Хотя там у кандидатов и не было целью быть подходящими на 100% под вашу вакансию.
А вы точно уверены, что все откликнувшиеся являются профессиональными рекрутерами? Думаю как раз больше половины решили попытать удачу увидев большие цифры, не являясь на деле опытными профессионалами. Такова судьба вакансий с оплатой выше рынка - для них всегда первоначальный фильтр будет отсеивать большую часть резюме.
Ни в коем случае не оправдываю то, что все эйчары являются высоковквалифицированными людьми, но считаю эксперимент нерепрезентативным, и его выводы оскорбительными, а заголовок кликбейтным.
Да и сам метод проведения считаю с запашком. Размещать фейковые вакансии и требовать сопроводительные письма, не предлагая работу по факту, еще и ехидно хихикая над результатами. Вы бы еще тестовое задание дали на недельки 2.
А если не занимался? Тут и приходят на помощь доп. уведомления. И либо они вручную через чат вроде "посмотри плиз", либо через автоматизацию, которая на практике выигрывает человеческому фактору, что и показали метрики в посте.
Репозиторий не обязательно может являться проектом. Там может быть переиспользуемый библиотечный или инфраструктурный код. И чем дольше работаешь, тем чаще ты в тот или иной репо можешь добавить свои коммиты, чтобы задачку продвинуть связанную. Естественно, никто не говорит про овнерство 200 репозиториями. Но даже у одной команды может накопиться десяток репозиториев с поддержкой кода.
Можно, например, работать, выполняя свои непосредственные обязанности, в которые обычно не входит мониторинг всего и вся.
Не понимаю вашего сопротивления более удобной формы уведомлений в виде агрегации всего кода, который необходимо посмотреть.
У меня, например, открыт доступ к 200+ репозиториям, и если я буду заниматься мониторингом всего и вся, я только на него и буду тратить весь свой рабочий день даже вместо самого ревью. А так я каждый жень получаю уведомления от бота, который мне говорит "посмотри реквесты, порешай конфликты, зарезолвь треды где ты ответственен". Вместо выковыривания информации по крупицам я сразу получаю удобный инструмент для работы. И это в разы лучше, чем пинговать людей с разным графиком и подходом к работе на предмет ревью кода, плюс заниматься этим вручную.
Или сам процесс уведомлений неэффективен. Чем дольше человек в компании, тем больше он получает писем. И письма с ревью и прочими письмами в компании совсем не дают результата, т.к. разгребание почты и чатиков может занять очень много времени.
Ежедневное напоминание о задачах по ревью очень выручает, т.к. перед глазами всегда есть удобная сводка пулл-реквестов, по которым нужно что-нибудь сделать. При сильном загрузе на основе этой сводки можно даже букать время в календаре под процесс ревью, тогда он проходит в разы быстрее.
Так больше всего сами компании в этом и виноваты. Устраивают гонку в лояльность и промытие мозгов своими "семейными ценностями" с одной стороны, расформировывают отделы и увольняют пачками людей, перекидывая нагрузку на оставшихся сотрудников с другой. Т.е. ты должен быть как преданный сын, но мы можем сдать тебя в детдом и лишить бенефитов в любой момент. Когда встречаешься с таким диссонансом, перестаешь играть в подобные игры. Это здравый смысл, а не тихое увольнение.
Разный опыт, разное отношение.
Встречал людей, которым опаливали крылья, выплачивая 5% от обещанной премии под различными предлогами. Встречал закручивание гаек и оптимизацию расходов в виде урезания корпоративных плюшек уже на второй месяц работы. Встречал компании с полупремиальной зарплатой, которые при расставании забывали про премиальную часть.
В общем, мой опыт в российской разработке мне прямо диктует, что можно рассчитывать только на суммы, указанные в зарплате. Остальное, конечно, тоже можно брать в расчет, но не является ключевым фактором при выборе работодателя.
Очень рад ошибаться, если ваш опыт корпоративных плюшек более распространен в мире.
Делали без ADR, более упрощенно:
1) Выработали план, по которому принимаем соглашения на уровне стека
2) Выработали подход по плану. Назначался ведущий, который готовил и принимал последующие вопросы и пункты к обсуждению, согласовали формат обсуждений и оповещений об изменениях.
3) Раз в неделю собирались стеком и шли по плану.
4) В ходе обсуждений задавались конкретные вопросы и фиксировались результаты обсуждений в виде рекомендаций или обязательных правил. Фиксировались на странице вики в формате markdown, об изменениях оповещались участники процесса.
5) В параллеле с вопросами стека применили похожую схему к процессам в команде (git-flow, ревью, детализация, тестирование, практика релизов).
6) При дальнейших действиях в команде ее участник уже имел справочную информацию в виде документов, на которые можно опираться при принятии решений.
7) Попробовали нововведения в бою, настроили механизм отладки соглашений, запустили переодический пересмотр.
8) Автоматизировали лишь спустя какое-то время, и далеко не все. Потому что некоторые правила требовали достаточно весомых затрат на автоматизацию.
9) Запустили таким образом кросс-командные соглашения.
Это, конечно, все потребовало очень много времени на согласования и настройку продуктивной атмосферы для принятия решений, но в итоге получили прозрачные процессы. Если кратко резюмировать, то это дорого, и не везде применимо. Но стоит того.