Все-таки довольно сложно перестраиваться с режима удаленки на офис и обратно.
Как я считал в доковидные времена: в офисе работа кипит, другие форматы - экзотика. В командах можно эффективнее выстраивать коммуникацию. Необходимое жилье - это место для отдыха, желательно поближе к офису, в квадратах можно поужаться.
Как мое мнение поменялось с ковидом: коммуникации успешно заменяются онлайном, а у компаний, которые это не осилили и до ковида были так себе процессы. На удаленке работа кипит порой сильнее, чем в офисе. География команд изменилась на корню. Необходимое жилье - это как минимум плюс отдельная комната-офис, местоположение уже каждый выбирает исходя из своих предпочтений: инфраструктура мегаполиса или больше квадратов в регионах.
И попадая в ситуацию, когда переводили на удаленку, человек настроил свою жизнь под нее, а потом его обратно зазывают в офис, люди попадают не просто в смену рабочего режима, а смену своего стиля жизни. Потому и идет такое сопротивление к ней у сотрудников. Они могли потратить очень много денег и сильно изменить свою жизнь в некоторых аспектах, чтобы согласиться с удаленкой, а тут к ним приходят и говорят: вертайте обратно.
И в доковидные времена я тратил на работу с учетом добирательств в офис по 10-14 часов в некоторых случаях. Я стал меньше болеть, стало меньше раздражения из-за посторонних звуков, запахов, ремонтов и прочих прелестей опенспейсов. Потому для меня возврат в офис будет очень печальной картиной, как бы работодатели этого не хотели. Буду до последнего искать удаленку в случае необходимости. Надеюсь, жизнь не заставит вернуться в офисный формат.
Под стыком интересов в данном случае подразумеваются противоречия между целями участников команды.
Пм может хотеть сдать все в срок или отчитаться за огромный объем работ, плюя на отношение к этому команды.
Лид может иметь хорошего исполнителя и не поручать ему более сложных задач, потому что не хочет терять хороший темп разработки.
Разработчик может хотеть в серьезные рефакторинги или отклонения в более интересные смежные темы, превращая простые задачи в сложные со множеством изменений и отклонением сроков.
Тестировщик может находить кейсы под микроскопом, шанс выпадения которых 1 из миллиона и они не сильно влияют на общую работу системы, потому что ему нравится такое мировосприятие, и он мотивируется такими тест-кейсами.
Владелец бизнеса может вообще считать, что это все сделается за день работы, и продаст эту идею инвесторам, не посоветовавшись с командой.
Так или иначе, у всех свои цели, и когда начинается столкновение и их усреднение в целях настройки антивыгорания, нужно понимать, что это приведет скорее к дисбалансу отношения к работе у участников коллектива, чем к устранению выгораний. Да, возможны улучшения "в среднем по больнице", когда компания запрещает переработки или другие факторы, влияющие на перегорание на уровне всех отделов, но даже в таких случаях всегда найдутся люди, которые начнут перегорать даже больше, потому что, например, привыкли работать в другой атмосфере, и текущая для них становится губительной.
Потому считаю, что борьба с выгораниями - это зачастую самодисциплина и выработанные горьким опытом упражнения отстаивания личных границ внутри участников коллектива, а не борьба с трендом в рамках целой компании.
Так заметно проще копить ресурсы. Любые переработки или срывы этого графика просишь согласовывать заранее. И отказываешься, если тебя это не устраивает. На самом деле, ни разу ко мне за это не применяли санкции. Бывала пара угроз в стиле "у таких людей обычно замедленный рост в компании" от начальства, но ты сам решаешь, что тебе важно: сгореть дотла за месяц с возможным повышением или стабильная работа в долгую, когда важна длительность.
Обычно срочность эмоциональна, и на самом деле не так важна. Мы редко в it спасаем жизни людей напрямую. Бывало, во время субботних просьб поработать говорил, что не у компьютера, а компьютер в другом городе. И находили других людей, которые согласились поработать. По итогу ту срочную субботнюю работу других людей не могли протестировать спустя месяц. Это один из многих пример, когда "тушение пожаров" было не обязательным. Напоминание всепропальщикам про такие случаи их нередко отрезвляет, и они начинают уже не так резко реагировать на подобное. Если же не помогает - переадресовать проблему руководству вспропальщика, который нагнетает атмосферу.
2) Отключение уведомлений рабочих каналов мессенджеров во внерабочее время.
Даже не установка корпоративных мессенджеров на телефон. Избавляет от возможности резко прервать свое время восстановления, и отваживает от соблазна ворваться в какое-либо обсуждение.
Однажды перед сном получил сообщение в стиле 1-то-1 от лида, который решил проанализировать мое поведение, и вылил на меня гору претензий. Сон был отложен на часа 2, получен дикий стресс с непредвиденными day off в течение пары дней, лид был на эмоциях послан куда подальше и уволился в течение месяца после инцидента. Считаю, ситуацию можно было спасти запланированным 1-to-1 с адекватным разбором ситуации, когда эмоции поутихли. Всему свое время.
3) Сокращение встреч с коллегами во внерабочее время.
Бывало, слишком сильно пересекалось личное и рабочее. Когда вы становитесь друзьями и границы смешиваются. Это влияет на восполнение ресурсов, т.к. ты не сменяешь свою активность, и в любой момент может возникнуть обсуждение рабочей ситуации, которое потребует анализа, разборов и снова работы. А на работе такое неформальное общение часто приводит к сбоям в процессах, потому что ты уже не воспринимаешь коллег как коллег, и начинаются элементы кумовства в ту или иную сторону.
Я согласен, что иногда тимбилдинги необходимы. Но когда доходит до "давай по несколько раз в неделю собираться и обсуждать в том числе и работу" - уже перебор. Даже более раза в две недели, наверное, слишком.
Что касаемо самой атмосферы в компании, чаще всего она не налаживается в рамках одной команды, и внешние факторы перевешивают весь радостный настрой сделать для всех хорошую атмосферу. Даже если начинаются порывы в эту сторону, обычно идет столкновение о том, что всем не угодишь: кому-то нет возможности дать интересные задачи, где-то ФОТ компании порезали, где-то диаметральнопротивоположные мнения у коллег не дают играть в продуктивную и невыгорающую настройку коллектива, где-то пожары - это и есть работа команды, и без них ее расформируют к чертям и т.д. Чем больше коллектив, тем сложнее угодить всем, и выгорания чаще всего встречаются на стыке интересов коллег.
Там от hr ловушка в сторону "Ну вы же общались наверняка с другой командой, а команд у нас много, и может с этой срастется, и все будет иначе". И в больших компаниях это часто так. Бывает, в разрезе одной компании существует несколько миров.
Понятно. Сеанс психологии по комментариям. Ок, удачи вам.
К слову, я почти всегда проводил собеседования с кем-то. Это были, например, hr, тимлид другой команды, cto, начальник компании. И корректировал собеседования по обратной связи в том числе и напарников. И ни разу за много команд и опыта работы мне никто не сказал, что я кого-то валю или предвзято к кому-то отношусь на собеседовании. Видимо, вы лучше знаете.
Никогда не было настроя "завалить лоха" на собеседовании. Всегда задаю практически одни и те же вопросы. Копаю вглубь ответвлениями, но это скорее шанс получить доп. баллы в виде бонусной части, и эти ответвления подключаю только когда вижу, что человек хорошо ответил на первичный вопрос.
Я прекрасно знаю, что иногда у талантов довольно куцые резюме. Ни разу не отсеял человека по стилю оформления опыта. Говорю лишь о личной статистике. Чем обоснованы ваши предположения, что я ехидствую, да еще и самоутверждаюсь при проведении собеседования мне совсем не понятно.
Так в том-то и дело, что ко мне приходили резюме и в стандартном шаблонном виде, и настроенные на "достижения". И в стандартном шаблонном виде их было даже больше. С достигаторными резюме я нашел такую закономерность не потому что отношусь к этому плохо, а потому что имею опыт ответов от довольно разных кандидатов, и есть с чем сравнивать. И я сам с резюме без достигаторных шаблонов переодически получаю приглашения побеседовать, так что точно дело не в пробитии ATS.
По личному опыту проведенных собеседований, соискатели с расписанными достижениями по шаблону "сделал действие, что увеличило мировое господство компании в полтора раза" были одними из самых слабых по хард-скиллам.
И для меня чаще это ред-флаг. Видишь, что написана полная чушь, которую не измерить и не подтвердить, но кандидат будто впал в отчаяние и добавил эти выдуманные метрики, потому что на самом деле чувствует слабину в своем опыте.
Люди с дефолтным структурированным описанием опыта без прикрас из разряда "делал то-то то-то на таком стеке в такой-то команде" гораздо интереснее в общении.
На самом деле корректировка зп - самая малая из бед, если вы поручили обязанности сотруднику, с которыми он не справляется. Потому что основной вид ущерба от неквалифицированных сотрудников - это устранение ошибок от их низкой квалификации. И чем выше должность такого сотрудника, тем больше времени людей требуется для устранения этого ущерба, что измеряется десятками а то и сотнями иксов от суммы его повышения.
И для таких "не тянущих" всегда есть свои алгоритмы их отстранения от вредительства. Они далеко не в возвращении зп на предыдущий уровень.
Никто не против роста, когда он справедливо компенсируется. Чаще всего человек хочет роста для повышения компенсации, а не внутренней гармонии. Лишь когда все базовые потребности закрыты можно рассуждать о духовном. Иначе всегда материальное будет перевешивать. Так что считаю, что любое расширение обязанностей должно компенсироваться, вне зависимости от итогов этого расширения. Если этого не происходит - пахнет жареным и впаренным, нужно тщательно думать перед соглашением на такие условия.
Обычно эти внутренние мотивации конфликтуют с компенсацией за них.
Чаще в компаниях встречал подход из разряда "воу, ты круто справляешься, давай тебе еще горку полномочий выдадим, расширим твой круг обязанностей, научим тебя на трубе играть чтобы команду вдохновлял, но деньги это не важно же - зато смотри как ты вырастешь".
И приходишь ты на сеньера, получаешь быстро в подчинение команду в роли лида, а про деньги компания забывает. В итоге сидишь ты обмазанный этими доп. внутренними мотиваторами и выгоранием поглядывающим из-за плеча из-за перенагрузки, не знаешь куда потратить. А лидскую зп тебе обещают выдать через полгода-год на очередном перформанс-ревью, которое естественно шатко и ничего не гарантирует, т.к. у компаний часто нужно пояса потуже затянуть перед ними.
На данный момент наблюдаю, как начальство объявило очередные "awards", где самых-самых сотрудников награждают статуэткой и мерчем. Довольно забавно будет посмотреть, т.к. большинство победителей и номинантов из прошлогодней "awards" ушли из компании.
Говорить о спасибах следует когда остальные процессы работают приемлимо. Премирование, мотивация, планирование, например. Спасибо в данном случае лишь пудра на пончике. На спасибо велись бумеры, потому что их базовые потребности были закрыты.
В текущих реалиях самое вкусное спасибо - это деньги. А уж как их оформить и преподнести - дело десятое.
В 21-22 годах пользовался этой подпиской, когда контента было много и она сама себя окупала за покупки. За год пользования сервисами накопил чуть больше 6000 баллов, а потом перестал пользоваться из-за переезда.
По возвращению В 25ом году подключил опять из-за того, что были выгодные условия по накопительному счету для подписчиков. За 3 месяца подписки посмотрел один сериал на кинопоиске, получил 25% скидки за один заказ с наценкой в еде и какие-то невыгодные предложения по кешбекам.
Не стал продлевать бесплатный подсадочный период по истечению, так как по сравнению с 21-22 все подорожало, а выгоды от использования сервисов стал получать гораздо меньше. Самой экосистемой яндекса пользуюсь все реже, т.к. там борзометр накруток по ценам и комиссиям совсем зашкаливает уже.
Часто помещения начинают подстраиваться под роботов вместо их донастройки, потому что легче конфликтующее нечто поправить в помещении, чем дождаться толкового апдейта от производителя.
Сам стал шторы поднимать в квартире, т.к. умная ии-карта у себя внутри поняла, что они для нее непреодолимое препятствие, хотя более простая модель с лидаром легко доезжала до них и ее останавливало только столкновение со стеной.
Пару раз такой подход меня выручал. Это был больше библиотечный код с необходимостью расширения и интеграции функционала в довольно разношерстные микросервисы. Не всем нужно, никого не уговариваю :)
Он обычно и выносится. Когда в модуль, когда в отдельный репозиторий. Но поддержка со стороны модулей-потребителей никуда не денется. Отсюда и получаются дто с имплементацией интерфейсов.
Да, изменение промежуточного слоя контрактов потребует поддержки. Но иногда он дает выгоду, потому что бывает частая смена структуры дто, внутренние рефакторинги модулей и так далее. Если мы внутри отрефакторим модуль и поддержим контракты, другие модули ничего и не заметят. Если мы отрефакторим дто, другим модулям уже будет посложнее. Целесообразность использования зависит от многих вещей и в большинстве случаев избыточна, согласен.
У вас какое-то странное толкование dip. Там как раз и говорится про любую зависимость, а вы абстрагировали этот принцип только бизнес-логикой.
На практике мы можем извлечь выгоду от общения через интерфейсы вместо самих dto довольно просто. Потому что расположение dto может быть внутри модуля, и тогда при смене структуры или переносе этого dto в другой неймспейс нам придется адаптировать другие модули под новые реалии. Если же мы спрячем контракт под интерфейс вместо реализации и вынесем эти интерфейсы отдельно, зависимость между модулями ослабнет, т.к. они будут общаться через интерфейсы промежуточного слоя, и перенос реализации интерфейса в одном модуле никак не повлияет на другой модуль, использующий промежуточный контракт. Но тогда мы подпишемся на поддержку этого промежуточного слоя. На больших проектах помогает.
Так если полностью соблюдать инверсию зависимостей, то весь граничный контекст должен общаться посредством интерфейсов, а не реализации. И мы не можем передавать эту реализацию напрямую. Тут и получается, что dto имплементирует интерфейс если мы хотим передать его соблюдая dip. И на выходе получаем интерфейс, который имплементирует уже другая часть граничного контекста, что чаще всего является тем же dto.
Рационально ли это? Далеко не всегда. По солидному? Да. Усложняет код и поддержку? В разы.
Все-таки довольно сложно перестраиваться с режима удаленки на офис и обратно.
Как я считал в доковидные времена: в офисе работа кипит, другие форматы - экзотика. В командах можно эффективнее выстраивать коммуникацию. Необходимое жилье - это место для отдыха, желательно поближе к офису, в квадратах можно поужаться.
Как мое мнение поменялось с ковидом: коммуникации успешно заменяются онлайном, а у компаний, которые это не осилили и до ковида были так себе процессы. На удаленке работа кипит порой сильнее, чем в офисе. География команд изменилась на корню. Необходимое жилье - это как минимум плюс отдельная комната-офис, местоположение уже каждый выбирает исходя из своих предпочтений: инфраструктура мегаполиса или больше квадратов в регионах.
И попадая в ситуацию, когда переводили на удаленку, человек настроил свою жизнь под нее, а потом его обратно зазывают в офис, люди попадают не просто в смену рабочего режима, а смену своего стиля жизни. Потому и идет такое сопротивление к ней у сотрудников. Они могли потратить очень много денег и сильно изменить свою жизнь в некоторых аспектах, чтобы согласиться с удаленкой, а тут к ним приходят и говорят: вертайте обратно.
И в доковидные времена я тратил на работу с учетом добирательств в офис по 10-14 часов в некоторых случаях. Я стал меньше болеть, стало меньше раздражения из-за посторонних звуков, запахов, ремонтов и прочих прелестей опенспейсов. Потому для меня возврат в офис будет очень печальной картиной, как бы работодатели этого не хотели. Буду до последнего искать удаленку в случае необходимости. Надеюсь, жизнь не заставит вернуться в офисный формат.
Под стыком интересов в данном случае подразумеваются противоречия между целями участников команды.
Пм может хотеть сдать все в срок или отчитаться за огромный объем работ, плюя на отношение к этому команды.
Лид может иметь хорошего исполнителя и не поручать ему более сложных задач, потому что не хочет терять хороший темп разработки.
Разработчик может хотеть в серьезные рефакторинги или отклонения в более интересные смежные темы, превращая простые задачи в сложные со множеством изменений и отклонением сроков.
Тестировщик может находить кейсы под микроскопом, шанс выпадения которых 1 из миллиона и они не сильно влияют на общую работу системы, потому что ему нравится такое мировосприятие, и он мотивируется такими тест-кейсами.
Владелец бизнеса может вообще считать, что это все сделается за день работы, и продаст эту идею инвесторам, не посоветовавшись с командой.
Так или иначе, у всех свои цели, и когда начинается столкновение и их усреднение в целях настройки антивыгорания, нужно понимать, что это приведет скорее к дисбалансу отношения к работе у участников коллектива, чем к устранению выгораний. Да, возможны улучшения "в среднем по больнице", когда компания запрещает переработки или другие факторы, влияющие на перегорание на уровне всех отделов, но даже в таких случаях всегда найдутся люди, которые начнут перегорать даже больше, потому что, например, привыкли работать в другой атмосфере, и текущая для них становится губительной.
Потому считаю, что борьба с выгораниями - это зачастую самодисциплина и выработанные горьким опытом упражнения отстаивания личных границ внутри участников коллектива, а не борьба с трендом в рамках целой компании.
Приемы, которые я выработал для себя лично:
1) Работа в четком постоянном графике.
Так заметно проще копить ресурсы. Любые переработки или срывы этого графика просишь согласовывать заранее. И отказываешься, если тебя это не устраивает. На самом деле, ни разу ко мне за это не применяли санкции. Бывала пара угроз в стиле "у таких людей обычно замедленный рост в компании" от начальства, но ты сам решаешь, что тебе важно: сгореть дотла за месяц с возможным повышением или стабильная работа в долгую, когда важна длительность.
Обычно срочность эмоциональна, и на самом деле не так важна. Мы редко в it спасаем жизни людей напрямую. Бывало, во время субботних просьб поработать говорил, что не у компьютера, а компьютер в другом городе. И находили других людей, которые согласились поработать. По итогу ту срочную субботнюю работу других людей не могли протестировать спустя месяц. Это один из многих пример, когда "тушение пожаров" было не обязательным. Напоминание всепропальщикам про такие случаи их нередко отрезвляет, и они начинают уже не так резко реагировать на подобное. Если же не помогает - переадресовать проблему руководству вспропальщика, который нагнетает атмосферу.
2) Отключение уведомлений рабочих каналов мессенджеров во внерабочее время.
Даже не установка корпоративных мессенджеров на телефон. Избавляет от возможности резко прервать свое время восстановления, и отваживает от соблазна ворваться в какое-либо обсуждение.
Однажды перед сном получил сообщение в стиле 1-то-1 от лида, который решил проанализировать мое поведение, и вылил на меня гору претензий. Сон был отложен на часа 2, получен дикий стресс с непредвиденными day off в течение пары дней, лид был на эмоциях послан куда подальше и уволился в течение месяца после инцидента. Считаю, ситуацию можно было спасти запланированным 1-to-1 с адекватным разбором ситуации, когда эмоции поутихли. Всему свое время.
3) Сокращение встреч с коллегами во внерабочее время.
Бывало, слишком сильно пересекалось личное и рабочее. Когда вы становитесь друзьями и границы смешиваются. Это влияет на восполнение ресурсов, т.к. ты не сменяешь свою активность, и в любой момент может возникнуть обсуждение рабочей ситуации, которое потребует анализа, разборов и снова работы. А на работе такое неформальное общение часто приводит к сбоям в процессах, потому что ты уже не воспринимаешь коллег как коллег, и начинаются элементы кумовства в ту или иную сторону.
Я согласен, что иногда тимбилдинги необходимы. Но когда доходит до "давай по несколько раз в неделю собираться и обсуждать в том числе и работу" - уже перебор. Даже более раза в две недели, наверное, слишком.
Что касаемо самой атмосферы в компании, чаще всего она не налаживается в рамках одной команды, и внешние факторы перевешивают весь радостный настрой сделать для всех хорошую атмосферу. Даже если начинаются порывы в эту сторону, обычно идет столкновение о том, что всем не угодишь: кому-то нет возможности дать интересные задачи, где-то ФОТ компании порезали, где-то диаметральнопротивоположные мнения у коллег не дают играть в продуктивную и невыгорающую настройку коллектива, где-то пожары - это и есть работа команды, и без них ее расформируют к чертям и т.д. Чем больше коллектив, тем сложнее угодить всем, и выгорания чаще всего встречаются на стыке интересов коллег.
Там от hr ловушка в сторону "Ну вы же общались наверняка с другой командой, а команд у нас много, и может с этой срастется, и все будет иначе". И в больших компаниях это часто так. Бывает, в разрезе одной компании существует несколько миров.
Понятно. Сеанс психологии по комментариям. Ок, удачи вам.
К слову, я почти всегда проводил собеседования с кем-то. Это были, например, hr, тимлид другой команды, cto, начальник компании. И корректировал собеседования по обратной связи в том числе и напарников. И ни разу за много команд и опыта работы мне никто не сказал, что я кого-то валю или предвзято к кому-то отношусь на собеседовании. Видимо, вы лучше знаете.
Никогда не было настроя "завалить лоха" на собеседовании. Всегда задаю практически одни и те же вопросы. Копаю вглубь ответвлениями, но это скорее шанс получить доп. баллы в виде бонусной части, и эти ответвления подключаю только когда вижу, что человек хорошо ответил на первичный вопрос.
Я прекрасно знаю, что иногда у талантов довольно куцые резюме. Ни разу не отсеял человека по стилю оформления опыта. Говорю лишь о личной статистике. Чем обоснованы ваши предположения, что я ехидствую, да еще и самоутверждаюсь при проведении собеседования мне совсем не понятно.
Так в том-то и дело, что ко мне приходили резюме и в стандартном шаблонном виде, и настроенные на "достижения". И в стандартном шаблонном виде их было даже больше. С достигаторными резюме я нашел такую закономерность не потому что отношусь к этому плохо, а потому что имею опыт ответов от довольно разных кандидатов, и есть с чем сравнивать. И я сам с резюме без достигаторных шаблонов переодически получаю приглашения побеседовать, так что точно дело не в пробитии ATS.
По личному опыту проведенных собеседований, соискатели с расписанными достижениями по шаблону "сделал действие, что увеличило мировое господство компании в полтора раза" были одними из самых слабых по хард-скиллам.
И для меня чаще это ред-флаг. Видишь, что написана полная чушь, которую не измерить и не подтвердить, но кандидат будто впал в отчаяние и добавил эти выдуманные метрики, потому что на самом деле чувствует слабину в своем опыте.
Люди с дефолтным структурированным описанием опыта без прикрас из разряда "делал то-то то-то на таком стеке в такой-то команде" гораздо интереснее в общении.
На самом деле корректировка зп - самая малая из бед, если вы поручили обязанности сотруднику, с которыми он не справляется. Потому что основной вид ущерба от неквалифицированных сотрудников - это устранение ошибок от их низкой квалификации. И чем выше должность такого сотрудника, тем больше времени людей требуется для устранения этого ущерба, что измеряется десятками а то и сотнями иксов от суммы его повышения.
И для таких "не тянущих" всегда есть свои алгоритмы их отстранения от вредительства. Они далеко не в возвращении зп на предыдущий уровень.
Никто не против роста, когда он справедливо компенсируется. Чаще всего человек хочет роста для повышения компенсации, а не внутренней гармонии. Лишь когда все базовые потребности закрыты можно рассуждать о духовном. Иначе всегда материальное будет перевешивать. Так что считаю, что любое расширение обязанностей должно компенсироваться, вне зависимости от итогов этого расширения. Если этого не происходит - пахнет жареным и впаренным, нужно тщательно думать перед соглашением на такие условия.
Обычно эти внутренние мотивации конфликтуют с компенсацией за них.
Чаще в компаниях встречал подход из разряда "воу, ты круто справляешься, давай тебе еще горку полномочий выдадим, расширим твой круг обязанностей, научим тебя на трубе играть чтобы команду вдохновлял, но деньги это не важно же - зато смотри как ты вырастешь".
И приходишь ты на сеньера, получаешь быстро в подчинение команду в роли лида, а про деньги компания забывает. В итоге сидишь ты обмазанный этими доп. внутренними мотиваторами и выгоранием поглядывающим из-за плеча из-за перенагрузки, не знаешь куда потратить. А лидскую зп тебе обещают выдать через полгода-год на очередном перформанс-ревью, которое естественно шатко и ничего не гарантирует, т.к. у компаний часто нужно пояса потуже затянуть перед ними.
Так что нет - давайте лучше деньгами.
На данный момент наблюдаю, как начальство объявило очередные "awards", где самых-самых сотрудников награждают статуэткой и мерчем. Довольно забавно будет посмотреть, т.к. большинство победителей и номинантов из прошлогодней "awards" ушли из компании.
Говорить о спасибах следует когда остальные процессы работают приемлимо. Премирование, мотивация, планирование, например. Спасибо в данном случае лишь пудра на пончике. На спасибо велись бумеры, потому что их базовые потребности были закрыты.
В текущих реалиях самое вкусное спасибо - это деньги. А уж как их оформить и преподнести - дело десятое.
В 21-22 годах пользовался этой подпиской, когда контента было много и она сама себя окупала за покупки. За год пользования сервисами накопил чуть больше 6000 баллов, а потом перестал пользоваться из-за переезда.
По возвращению В 25ом году подключил опять из-за того, что были выгодные условия по накопительному счету для подписчиков. За 3 месяца подписки посмотрел один сериал на кинопоиске, получил 25% скидки за один заказ с наценкой в еде и какие-то невыгодные предложения по кешбекам.
Не стал продлевать бесплатный подсадочный период по истечению, так как по сравнению с 21-22 все подорожало, а выгоды от использования сервисов стал получать гораздо меньше. Самой экосистемой яндекса пользуюсь все реже, т.к. там борзометр накруток по ценам и комиссиям совсем зашкаливает уже.
Часто помещения начинают подстраиваться под роботов вместо их донастройки, потому что легче конфликтующее нечто поправить в помещении, чем дождаться толкового апдейта от производителя.
Сам стал шторы поднимать в квартире, т.к. умная ии-карта у себя внутри поняла, что они для нее непреодолимое препятствие, хотя более простая модель с лидаром легко доезжала до них и ее останавливало только столкновение со стеной.
Пару раз такой подход меня выручал. Это был больше библиотечный код с необходимостью расширения и интеграции функционала в довольно разношерстные микросервисы. Не всем нужно, никого не уговариваю :)
Перенести, переименовать, свойство со снейк-кейса на кемел по внутреннему регламенту отформатировать и т.д.
На самом деле, в ходе бурной работы над проектом могут быть самые непредсказуемые изменения, в том числе не всегда чистые и честные
Он обычно и выносится. Когда в модуль, когда в отдельный репозиторий. Но поддержка со стороны модулей-потребителей никуда не денется. Отсюда и получаются дто с имплементацией интерфейсов.
Да, изменение промежуточного слоя контрактов потребует поддержки. Но иногда он дает выгоду, потому что бывает частая смена структуры дто, внутренние рефакторинги модулей и так далее. Если мы внутри отрефакторим модуль и поддержим контракты, другие модули ничего и не заметят. Если мы отрефакторим дто, другим модулям уже будет посложнее. Целесообразность использования зависит от многих вещей и в большинстве случаев избыточна, согласен.
У вас какое-то странное толкование dip. Там как раз и говорится про любую зависимость, а вы абстрагировали этот принцип только бизнес-логикой.
На практике мы можем извлечь выгоду от общения через интерфейсы вместо самих dto довольно просто. Потому что расположение dto может быть внутри модуля, и тогда при смене структуры или переносе этого dto в другой неймспейс нам придется адаптировать другие модули под новые реалии. Если же мы спрячем контракт под интерфейс вместо реализации и вынесем эти интерфейсы отдельно, зависимость между модулями ослабнет, т.к. они будут общаться через интерфейсы промежуточного слоя, и перенос реализации интерфейса в одном модуле никак не повлияет на другой модуль, использующий промежуточный контракт. Но тогда мы подпишемся на поддержку этого промежуточного слоя. На больших проектах помогает.
Так если полностью соблюдать инверсию зависимостей, то весь граничный контекст должен общаться посредством интерфейсов, а не реализации. И мы не можем передавать эту реализацию напрямую. Тут и получается, что dto имплементирует интерфейс если мы хотим передать его соблюдая dip. И на выходе получаем интерфейс, который имплементирует уже другая часть граничного контекста, что чаще всего является тем же dto.
Рационально ли это? Далеко не всегда. По солидному? Да. Усложняет код и поддержку? В разы.