Да все из-за кадровых проблем. Всегда все из-за них. А кадровые проблемы бывают двух типов: кадров мало и кадры фигня. Причем одно другому не мешает.
1) Кадров мало. Часто некому в принципе хоть как-то формализовать все приобретенные компетенции по продукту и каждая новая фича бьет этим по лбу. На моей опыте все эти шесть "ролей" часто ложатся на плечи разраба, то есть меня. Дальше - или с коллегами повезло и они обучаемые, или "ну ее нафиг работу твою", потому что проблемы будут расти до состояния "невывозимо".
2) Кадры фигня. То есть никто не хочет в кросс-функциональность эту вашу: на выходе дизайнера картинка без описания сценариев, на вход у разраба принимается только детализированная задача и никакого аналитического выхода он не дает, на выходе у ПО (на которого навесили функции и СА и БА и ПМ и фонарь на лоб повесили, чтобы он еще на трех проектах по ночам светил) невразумительная двухстрочная лабуда вместо постановки задачи по случайному адресу. Если с наймом в этом варианте проблем нет - такая команда будет пожирать самого ответственного из нанятых ей в "усиление", любого СА и БА или даже разраба который не только задачки в жире умеет двигать, а еще и головой подумать когда надо.
Я вот всячески всегда и всем советую не парить себе голову формализмами, а искать людей с которыми работать приятно. Что по ту что по эту сторону переговорного стола на собесе. Но это и у меня не всегда получается что по ту что по эту ¯\_(ツ)_/¯
Спасибо что повторили мои слова оперируя своими терминами.
Собственно так и выглядит "смена майндсета". Мы используем разные формулировки, сказав по сути одно и то же. Смысл не пострадал. Набор орг-мероприятий и непосредственно рабочих задач необходимых для выполнения работы при внедрении принципов аджайл так же никуда не девается.
Работать все будут абсолютно так же. А вот утренняя разминка под другую музыку.
Это не методики и практики это "методология". То бишь подход к выработке конечных методик. Предлагается принять некоторые постулаты которыми вы будете руководствоваться при построении вашего рабочего процесса. Так же есть некоторый набор ритуалов которые в теории помогут вам в этом процессе. Заметьте, по технологическим процессам у всех аджайл-коучей или скрам-мастеров нет ровно никакой конкретики. Они и не должны обладать технической экспертизой. Управленческой экспертизой они так же не обладают. Это ритуальные услуги в широком смысле. А церковь не государство. Поэтому если у вас есть смутное чувство что вы поели "не шоколада", когда читаете аджайл-манифесты и их производные, то оно вас не подводит.
Ад какой. В 19 и 23 вообще не так было. Хотя и стеки у нас немного разные. Я до десяти приглашений на техсобес не добираюсь без 2-3 офферов, впрочем у меня и история другая - мобилки, внешние железки и любовь к экзотике по части предметной области (финтехи и чистый диджитал скукота) - а тут чаще просто не найти достаточно адекватного персонажа. По полгода собесим 2-3 раза в неделю.
1) Ну так вы по приглашениям на собес конверсию озвучили? Или это я не глазами прочитал? Чисто по ним не может быть 10%. Разве что вы по грейдам скакали слишком спешно, или в другой стек/специальность прыгали. И то через эйчар фильтр такое как правило легко проходит, если они сами решение принимают, а не команду дергают на каждое резюме.
2) Удивительно. Когда ищешь сеньора надо хоть как-то понять что это он. А это возможность самостоятельно затащить полный цикл. Как это еще проверить? Не по задачкам на линкед лист же. Этому и макаку научить можно.
По ощущениям все-таки больше порно-кастинг напоминает. Идешь на свидание, а тебе вжух и четырехчасовую техническую секцию. Или две по три. И ты такой "блин, а я думал мы тут кофе попьем и поболтаем". А тебе уже устраивают трипл брейн пенетрейшон без прелюдии и лубриканта.
Ну и не могу не отметить два момента:
Из того что вы посчитали свою личную статистику никак не следует что конверсия любого отклика будет 10%. В среднем у человека хоть с каким-то релевантным опытом и открытым резюме она выше 100%. Потому что мгновенно наваливается почтой того что ты и не увидел в вакансиях.
Оба представленных варианта записи в резюме неверные. Второй слишком длинный. В описании обязанностей и достижений важен, во-первых, вклад - сам/в команде/во главе команды, во-вторых, полнота цикла - с нуля/на поддержке/вытащил из легаси. Остальное, если очень хочется, можно проговорить на вводной к техсекции: "да этот космический корабль я сам сделал, могу показать какие проводки я использовал".
Теперь начнется интересное. Вы по сути "всякого" ещё не видели. Семь лет жалкий трейлер на фоне пенсии в 65. Я как раз третий раз стек менял лет через 8.
Хотя в целом подход с мапками еще полезен чтобы объектики не плодить, один фиг курсоры это своеобразные мапы и параметризация самих sql-запросов без них не обходится. Так зачем нам лишний класс который все равно не уйдет выше дата-слоя.
Ну таки-да, это не ОРМ. ОРМ решает в первую голову задачу объектного мапинга (да даже банально называется Объектно-Реляционным Маппингом) и только по желанию инкапсуляцию SQL-диалектов в свой DSL. Это DSL over SQL. То есть специфический тулинг, как я понимаю, для задач автора. Например, навскидку, шаблонизированного стейт-менеджмента для выборки/солоедита из набора полей/формы замапленной на филдсет.
А вы стрелочку поверните. В какой из вышеперечисленных категорий сорокадвухлетний айтишник с ускоренных курсов учителей/хирургов/пилотирования будет не левым? :) Вам вообще сама идея этих ускоренных курсов не кажется бредовой? Читали бы вы внимательно - поняли бы что никто не охает и в спортлото не пишет. Сегодня оно так. Завтра по-другому. Кто-то бегает туда-сюда за длинным рублем, кто-то работает свою работу и ей доволен. Я вообще за все хорошее и мимо всего плохого. Так что бесполезно на меня повышать буквы.
Выводы на спорных тезисах всегда спорны. Тем не менее есть один тезис с которым я согласен: да действительно индустрия настолько популяризовалась что в ней появилась масса "левых" людей.
"Левых" читай как "профнепригодных" по той или иной причине, не обязательно по причине неумения отличить гитлаб флоу от гитхаб флоу, или отличать логарифмы от квадратов. А, скажем, занимающихся резюме-драйвен девелопмент. Почему так - ниже будет.
Тезис этот затронул не только соискателя, но и работодателя. То есть не только многие люди которые программируют не умеют программировать правильно, но и многие люди решающие кадровые вопросы не умеют их решать правильно.
Порог входа в команду ориентированный на отсев по формальному признаку ничем не лучше на выходе чем творчество чат гпт. То есть настоящую задачу он не решает. Тут звучал вопрос "зачем напрягаться". Ну вот затем. Настоящая задача команды разработки это разработка и поддержка продукта. На этапе поддержки продукта рано или поздно возникает точка Ж (стоимость поддержки > стоимости переделывания), которую желательно отодвинуть как можно дальше. Связанная с ней кадровая "настоящая задача" состоит в том чтобы поддерживать команду способную отодвигать точку Ж вперед по оси времени. Этот момент нельзя убрать. Можно только отсрочить.
Состав команды всегда не константа, а поток. Состояние продукта это не константа, а поток. Если представить себе что из текущего значения потока команды мы можем сделать некоторое преобразование и применить его к текущему состоянию продукта, то результатом будет следующее состояние продукта. И эти эмиты идут постоянно. Какие бы методики и методологии вы не использовали все это надо или поздно приводит к деградации.
Если простыми словами - команда которая ищет не человека который ей подходит для работы над проектом, а ищет того который умеет проходить много секций тех-скринингов обрящет человека который умеет проходить много секций тех-скринингов. Это не коррелирует напрямую с его полезностью продукту и остальной команде в данный момент. То есть может и повезти с полезностью. А может и нет. Как в анекдоте про блондинку и динозавра.
И это не последствия февраля 22-го. Это было раньше и повсеместно и будет дальше и повсеместно - недопонимание методик техногигантов, которые буквально забрасывали любой проект деньгами и "универсальными" инженерами, то есть людьми отбираемыми по принципу наличия у них общей академической подготовки в области компухтер саенс, не вдаваясь в подробности продуктов, ведь если что его всегда можно похоронить, часть людей уволить, а формальных топ-перформеров закинуть в другой (они ж универсальные).
Вот такая вот хурма. Но вы знаете что? Я работаю в индустрии с 2002-го года, когда мне мои же одногруппники из универа говорили что "это не нормальная работа" и "ты упрешься в потолок по бабкам". И ни на что ее не променяю, потому что мне нравится и процесс и результат моего труда. Даже если она вернется в "то" состояние. Чего, я уверен, не будет. Слишком мы привыкли к автоматизации всего и вся в жизни. И рано или поздно, я уверен, наступит спад популярности курсов и установится баланс. Очень хочется надеяться что за счет того что подрастет доход в других, подчас более социально значимых профессиях.
Ага. 1) "Большое" это какое? Сотня экранов - это сотня экранов, под ними может быть не так много домена в облачных решениях. Три оси измерения: объем кода, соотношение объема домен/ui и количество людей показывают сложность проекта (если честно - моя личная метрика). Растет домен/объем или объем/люди - сложность растет. При этом, понятное дело, что прибавлению людей нелинейно работает. То есть вы доводите объем/чел до расслабленного 10-15К строк на человека как в тиньке, но у вас общий объем так же как там два ляма - тут чисто инфраструктурной ереси будет с лям. Уже просто потому что у вас так много людей и надо много бойлерплейта чтобы они друг другу не мешались. Но и 300К на 2-3 человека при толстом домене это офигеть как сложно, я делал. Так что тут закономерный вопрос - насколько большое и почему именно оно такое. Экраны это эмоциональная метрика, имхо.
2) Логика ui-слоя утаптывается в bloc(mvi)|mvvm(cubit)|mvp|mvc(mvc морально устарел уже потому что связность у него выше прочих, mvp, впрочем, тоже, хотя жить и с ним можно). Вы точно уверены что mvc в его классическом понимании где все завязаны на всех без модификаций это нормально по солиду? И логика ui-слоя - она логика отображения стейта. Стейт формируется отдомена.
3) Если взять во внимание клин (я беру, он хороший). Стейт вьюшек композится из массы доменных стейтов как раз в "логике ui" то есть в контроллерах, презентерах, вьюмоделах, блоках. В этом архитектурном плане нет домена. Вообще. Фича-модули построенные на стейт-менеджмент паттернах - ок, но это, по сути, подходит под очень простое фронтенд-приложение и не более. Объем тут вторичен, бьется и параллелится оно легко на любом подходе, коммона там мизер, в основном сессия+ui-кит.
4) Собственно фича-модули. Часто (хотя не всегда, в виде исключения) есть доменные сущности типа той же сессии юзера, или сложносочиненных взаимозависимых репозиториев с синхронизацией замудренной в зависимости от авнономности аппа, и это делает дерево модулей сложным в обслуживании. Если оно не таково, то коммон-штуки дублируются не только прим большом количестве людей которые не знают что уже есть имплементации, но и даже в одно жало. Потому что проще копипаст, чем думать как слабосвязно прокинуть, я такое поддерживал, это боль. Вот это почему? Большое значит бьем, вы уверены что оно из большого не станет именно сложным?
Имхо разница между анемичной и толстой моделью в глазах смотрящего :)
Если мы вынесли логику в некие условные сервисы, юзкейсы и прочее (манипулирующие само собой только доменными же интерфейсами и ентитями ) - они частью домена быть не перестают. Ну или самой моделью в широком смысле этого слова. Так что анемичная модель это такой Гомер Симпсон с защипами на спине. Мне, кстати, с ней удобнее - выстроить иерархию сервисных классов манипулирующих дата-ентити, зацепив их на интерфейсы друг друга. Тогда у нас не нарушается буковка S из нашего любимого SOLID и у нас не возникает необходимости лезть в один класс дважды - за изменением формата данных и протоколом их обработки в бизнес-процессе.
Именно поэтому споры и ненависть про алгоритмы. Именно поэтому сеньор ~3 года это очень смешно. Именно поэтому побеседовать сеньора не умеет 99% собеседующих. На реальной задаче сеньора на ту же оптимизацию ложится не столько параметр ее мат. эффективности, сколько параметры сроков, кадров и пресловутое бизнес-велью.
И да. 99% соискателей сеньорской должности не умеют в построение апи. Этому литкод, хакерранк и олимпиады не учат.
Дык а чего концептуально нового вы ждете от текстового редактора с большим количеством свистоперделок? С течением времени их все больше, они все тяжелее и интегрируют в себя все больше разного барахла. Если писать на c++, то наверное прям всю пользу какой-нить тяжелой idea и не увидишь, даже если это поставляется под названием clion. Слышал много всякого про то что с джава/котлин инструментарием в ней же это несравнимо. Но под jvm или kmp c градлом как бы лучше ничего и нет.
Все дело ж еще может быть именно в том что c++ такой. К примеру недавно пришлось на нем написать немного, писался кусок в vscode из-за того что идея у меня community и я не мог все делать в одной среде и таки это действительно не слишком прям сильно отличающийся от старого опыт писания с чистого листа. С рефакторингом, думаю, он бы был уже значительно лучше. И вряд ли что-то кардинально сдвинется хоть когда-то. Но я бы проснулся в холодном поту если бы мне пришлось пользоваться чем-то типа старых терминальных редакторов на моих jvm-проектах нынешнего масштаба (то есть по дефолту я такое только в страшном сне себе могу представить).
А так да, спасибо, поностальгировал на синие экранчики. Писали в институте и игры и вирусы на турбопаскале и сложные, неполигональные рендер-движки на турбо цпп.
Да все из-за кадровых проблем. Всегда все из-за них. А кадровые проблемы бывают двух типов: кадров мало и кадры фигня. Причем одно другому не мешает.
1) Кадров мало. Часто некому в принципе хоть как-то формализовать все приобретенные компетенции по продукту и каждая новая фича бьет этим по лбу. На моей опыте все эти шесть "ролей" часто ложатся на плечи разраба, то есть меня. Дальше - или с коллегами повезло и они обучаемые, или "ну ее нафиг работу твою", потому что проблемы будут расти до состояния "невывозимо".
2) Кадры фигня. То есть никто не хочет в кросс-функциональность эту вашу: на выходе дизайнера картинка без описания сценариев, на вход у разраба принимается только детализированная задача и никакого аналитического выхода он не дает, на выходе у ПО (на которого навесили функции и СА и БА и ПМ и фонарь на лоб повесили, чтобы он еще на трех проектах по ночам светил) невразумительная двухстрочная лабуда вместо постановки задачи по случайному адресу. Если с наймом в этом варианте проблем нет - такая команда будет пожирать самого ответственного из нанятых ей в "усиление", любого СА и БА или даже разраба который не только задачки в жире умеет двигать, а еще и головой подумать когда надо.
Я вот всячески всегда и всем советую не парить себе голову формализмами, а искать людей с которыми работать приятно. Что по ту что по эту сторону переговорного стола на собесе. Но это и у меня не всегда получается что по ту что по эту ¯\_(ツ)_/¯
Спасибо что повторили мои слова оперируя своими терминами.
Собственно так и выглядит "смена майндсета". Мы используем разные формулировки, сказав по сути одно и то же. Смысл не пострадал. Набор орг-мероприятий и непосредственно рабочих задач необходимых для выполнения работы при внедрении принципов аджайл так же никуда не девается.
Работать все будут абсолютно так же. А вот утренняя разминка под другую музыку.
Это не методики и практики это "методология". То бишь подход к выработке конечных методик. Предлагается принять некоторые постулаты которыми вы будете руководствоваться при построении вашего рабочего процесса. Так же есть некоторый набор ритуалов которые в теории помогут вам в этом процессе. Заметьте, по технологическим процессам у всех аджайл-коучей или скрам-мастеров нет ровно никакой конкретики. Они и не должны обладать технической экспертизой. Управленческой экспертизой они так же не обладают. Это ритуальные услуги в широком смысле. А церковь не государство. Поэтому если у вас есть смутное чувство что вы поели "не шоколада", когда читаете аджайл-манифесты и их производные, то оно вас не подводит.
Ад какой. В 19 и 23 вообще не так было. Хотя и стеки у нас немного разные. Я до десяти приглашений на техсобес не добираюсь без 2-3 офферов, впрочем у меня и история другая - мобилки, внешние железки и любовь к экзотике по части предметной области (финтехи и чистый диджитал скукота) - а тут чаще просто не найти достаточно адекватного персонажа. По полгода собесим 2-3 раза в неделю.
Мне сложнее найти куда откликнуться.
1) Ну так вы по приглашениям на собес конверсию озвучили? Или это я не глазами прочитал? Чисто по ним не может быть 10%. Разве что вы по грейдам скакали слишком спешно, или в другой стек/специальность прыгали. И то через эйчар фильтр такое как правило легко проходит, если они сами решение принимают, а не команду дергают на каждое резюме.
2) Удивительно. Когда ищешь сеньора надо хоть как-то понять что это он. А это возможность самостоятельно затащить полный цикл. Как это еще проверить? Не по задачкам на линкед лист же. Этому и макаку научить можно.
По ощущениям все-таки больше порно-кастинг напоминает. Идешь на свидание, а тебе вжух и четырехчасовую техническую секцию. Или две по три. И ты такой "блин, а я думал мы тут кофе попьем и поболтаем". А тебе уже устраивают трипл брейн пенетрейшон без прелюдии и лубриканта.
Ну и не могу не отметить два момента:
Из того что вы посчитали свою личную статистику никак не следует что конверсия любого отклика будет 10%. В среднем у человека хоть с каким-то релевантным опытом и открытым резюме она выше 100%. Потому что мгновенно наваливается почтой того что ты и не увидел в вакансиях.
Оба представленных варианта записи в резюме неверные. Второй слишком длинный. В описании обязанностей и достижений важен, во-первых, вклад - сам/в команде/во главе команды, во-вторых, полнота цикла - с нуля/на поддержке/вытащил из легаси. Остальное, если очень хочется, можно проговорить на вводной к техсекции: "да этот космический корабль я сам сделал, могу показать какие проводки я использовал".
ПК гейминг с 80-х умирает.
Заскриньте пост чтобы еще через пять лет над собой поржать. И еще через пять. Открывайте раз в пять лет чтобы посмеяться, короче.
Теперь начнется интересное. Вы по сути "всякого" ещё не видели. Семь лет жалкий трейлер на фоне пенсии в 65. Я как раз третий раз стек менял лет через 8.
Хотя в целом подход с мапками еще полезен чтобы объектики не плодить, один фиг курсоры это своеобразные мапы и параметризация самих sql-запросов без них не обходится. Так зачем нам лишний класс который все равно не уйдет выше дата-слоя.
Ну таки-да, это не ОРМ. ОРМ решает в первую голову задачу объектного мапинга (да даже банально называется Объектно-Реляционным Маппингом) и только по желанию инкапсуляцию SQL-диалектов в свой DSL. Это DSL over SQL. То есть специфический тулинг, как я понимаю, для задач автора. Например, навскидку, шаблонизированного стейт-менеджмента для выборки/солоедита из набора полей/формы замапленной на филдсет.
А в чем проблема с lib gdx у котлина? Плюс для 2d есть korge.
Жарковато. Носите шляпу и пейте больше воды. А то все эти ведущие индустрии и нарративы они преходящи, а здоровье одно.
Нуууу, "в на... общество" хорошо попал, душевно, прям цепляет с эмоциональной стороны, но с другой стороны, а как там у вас погодка, а? :)
А вы стрелочку поверните. В какой из вышеперечисленных категорий сорокадвухлетний айтишник с ускоренных курсов учителей/хирургов/пилотирования будет не левым? :) Вам вообще сама идея этих ускоренных курсов не кажется бредовой? Читали бы вы внимательно - поняли бы что никто не охает и в спортлото не пишет. Сегодня оно так. Завтра по-другому. Кто-то бегает туда-сюда за длинным рублем, кто-то работает свою работу и ей доволен. Я вообще за все хорошее и мимо всего плохого. Так что бесполезно на меня повышать буквы.
Выводы на спорных тезисах всегда спорны. Тем не менее есть один тезис с которым я согласен: да действительно индустрия настолько популяризовалась что в ней появилась масса "левых" людей.
"Левых" читай как "профнепригодных" по той или иной причине, не обязательно по причине неумения отличить гитлаб флоу от гитхаб флоу, или отличать логарифмы от квадратов. А, скажем, занимающихся резюме-драйвен девелопмент. Почему так - ниже будет.
Тезис этот затронул не только соискателя, но и работодателя. То есть не только многие люди которые программируют не умеют программировать правильно, но и многие люди решающие кадровые вопросы не умеют их решать правильно.
Порог входа в команду ориентированный на отсев по формальному признаку ничем не лучше на выходе чем творчество чат гпт. То есть настоящую задачу он не решает. Тут звучал вопрос "зачем напрягаться". Ну вот затем. Настоящая задача команды разработки это разработка и поддержка продукта. На этапе поддержки продукта рано или поздно возникает точка Ж (стоимость поддержки > стоимости переделывания), которую желательно отодвинуть как можно дальше. Связанная с ней кадровая "настоящая задача" состоит в том чтобы поддерживать команду способную отодвигать точку Ж вперед по оси времени. Этот момент нельзя убрать. Можно только отсрочить.
Состав команды всегда не константа, а поток. Состояние продукта это не константа, а поток. Если представить себе что из текущего значения потока команды мы можем сделать некоторое преобразование и применить его к текущему состоянию продукта, то результатом будет следующее состояние продукта. И эти эмиты идут постоянно. Какие бы методики и методологии вы не использовали все это надо или поздно приводит к деградации.
Если простыми словами - команда которая ищет не человека который ей подходит для работы над проектом, а ищет того который умеет проходить много секций тех-скринингов обрящет человека который умеет проходить много секций тех-скринингов. Это не коррелирует напрямую с его полезностью продукту и остальной команде в данный момент. То есть может и повезти с полезностью. А может и нет. Как в анекдоте про блондинку и динозавра.
И это не последствия февраля 22-го. Это было раньше и повсеместно и будет дальше и повсеместно - недопонимание методик техногигантов, которые буквально забрасывали любой проект деньгами и "универсальными" инженерами, то есть людьми отбираемыми по принципу наличия у них общей академической подготовки в области компухтер саенс, не вдаваясь в подробности продуктов, ведь если что его всегда можно похоронить, часть людей уволить, а формальных топ-перформеров закинуть в другой (они ж универсальные).
Вот такая вот хурма. Но вы знаете что? Я работаю в индустрии с 2002-го года, когда мне мои же одногруппники из универа говорили что "это не нормальная работа" и "ты упрешься в потолок по бабкам". И ни на что ее не променяю, потому что мне нравится и процесс и результат моего труда. Даже если она вернется в "то" состояние. Чего, я уверен, не будет. Слишком мы привыкли к автоматизации всего и вся в жизни. И рано или поздно, я уверен, наступит спад популярности курсов и установится баланс. Очень хочется надеяться что за счет того что подрастет доход в других, подчас более социально значимых профессиях.
Ага.
1) "Большое" это какое? Сотня экранов - это сотня экранов, под ними может быть не так много домена в облачных решениях. Три оси измерения: объем кода, соотношение объема домен/ui и количество людей показывают сложность проекта (если честно - моя личная метрика). Растет домен/объем или объем/люди - сложность растет. При этом, понятное дело, что прибавлению людей нелинейно работает. То есть вы доводите объем/чел до расслабленного 10-15К строк на человека как в тиньке, но у вас общий объем так же как там два ляма - тут чисто инфраструктурной ереси будет с лям. Уже просто потому что у вас так много людей и надо много бойлерплейта чтобы они друг другу не мешались. Но и 300К на 2-3 человека при толстом домене это офигеть как сложно, я делал. Так что тут закономерный вопрос - насколько большое и почему именно оно такое. Экраны это эмоциональная метрика, имхо.
2) Логика ui-слоя утаптывается в bloc(mvi)|mvvm(cubit)|mvp|mvc(mvc морально устарел уже потому что связность у него выше прочих, mvp, впрочем, тоже, хотя жить и с ним можно). Вы точно уверены что mvc в его классическом понимании где все завязаны на всех без модификаций это нормально по солиду? И логика ui-слоя - она логика отображения стейта. Стейт формируется от домена.
3) Если взять во внимание клин (я беру, он хороший). Стейт вьюшек композится из массы доменных стейтов как раз в "логике ui" то есть в контроллерах, презентерах, вьюмоделах, блоках. В этом архитектурном плане нет домена. Вообще. Фича-модули построенные на стейт-менеджмент паттернах - ок, но это, по сути, подходит под очень простое фронтенд-приложение и не более. Объем тут вторичен, бьется и параллелится оно легко на любом подходе, коммона там мизер, в основном сессия+ui-кит.
4) Собственно фича-модули. Часто (хотя не всегда, в виде исключения) есть доменные сущности типа той же сессии юзера, или сложносочиненных взаимозависимых репозиториев с синхронизацией замудренной в зависимости от авнономности аппа, и это делает дерево модулей сложным в обслуживании. Если оно не таково, то коммон-штуки дублируются не только прим большом количестве людей которые не знают что уже есть имплементации, но и даже в одно жало. Потому что проще копипаст, чем думать как слабосвязно прокинуть, я такое поддерживал, это боль. Вот это почему? Большое значит бьем, вы уверены что оно из большого не станет именно сложным?
Имхо разница между анемичной и толстой моделью в глазах смотрящего :)
Если мы вынесли логику в некие условные сервисы, юзкейсы и прочее (манипулирующие само собой только доменными же интерфейсами и ентитями ) - они частью домена быть не перестают. Ну или самой моделью в широком смысле этого слова. Так что анемичная модель это такой Гомер Симпсон с защипами на спине. Мне, кстати, с ней удобнее - выстроить иерархию сервисных классов манипулирующих дата-ентити, зацепив их на интерфейсы друг друга. Тогда у нас не нарушается буковка S из нашего любимого SOLID и у нас не возникает необходимости лезть в один класс дважды - за изменением формата данных и протоколом их обработки в бизнес-процессе.
Проблема. Сеньор это уже не алгоритмы. Это уже
1. Спектр технологий.
2. Построение и сопровождение продукта с нуля.
3. Работа с людьми.
Именно поэтому споры и ненависть про алгоритмы. Именно поэтому сеньор ~3 года это очень смешно. Именно поэтому побеседовать сеньора не умеет 99% собеседующих. На реальной задаче сеньора на ту же оптимизацию ложится не столько параметр ее мат. эффективности, сколько параметры сроков, кадров и пресловутое бизнес-велью.
И да. 99% соискателей сеньорской должности не умеют в построение апи. Этому литкод, хакерранк и олимпиады не учат.
Дык а чего концептуально нового вы ждете от текстового редактора с большим количеством свистоперделок? С течением времени их все больше, они все тяжелее и интегрируют в себя все больше разного барахла. Если писать на c++, то наверное прям всю пользу какой-нить тяжелой idea и не увидишь, даже если это поставляется под названием clion. Слышал много всякого про то что с джава/котлин инструментарием в ней же это несравнимо. Но под jvm или kmp c градлом как бы лучше ничего и нет.
Все дело ж еще может быть именно в том что c++ такой. К примеру недавно пришлось на нем написать немного, писался кусок в vscode из-за того что идея у меня community и я не мог все делать в одной среде и таки это действительно не слишком прям сильно отличающийся от старого опыт писания с чистого листа. С рефакторингом, думаю, он бы был уже значительно лучше. И вряд ли что-то кардинально сдвинется хоть когда-то. Но я бы проснулся в холодном поту если бы мне пришлось пользоваться чем-то типа старых терминальных редакторов на моих jvm-проектах нынешнего масштаба (то есть по дефолту я такое только в страшном сне себе могу представить).
А так да, спасибо, поностальгировал на синие экранчики. Писали в институте и игры и вирусы на турбопаскале и сложные, неполигональные рендер-движки на турбо цпп.