Понятно, что это зависит от уровня разработчика и bus фактора
Проблемы управления проектом — это ответственность менеджера проекта. Нисколько не головная боль ведущего программиста в этом проекте.
Если уж такая ситуация возникла, то надо уходить, давая бизнесу возможность согласовать с вам контракт на поддержку за оверпрайс. Где бизнес будет искать средства на этот оверпрайс? Проблемы бизнеса. Возможно, за счет того менеджера, который такую ситуацию допустил.
Те, у кого первый разговор с начальством — это разговор об увольнении с оффером на руках, обычно инициативны ровно настолько, что единственная значимая для них мотивация — это размер кеша. И купить такого человека ещё на полгодика не сверхсложная задача.
С чего бы это инфантильность? Вообще-то, многим неудобно идти и просить прибавку, это определённый стресс…
Инициатива о повышении ЗП должна исходить от начальства, а не от сотрудника.
Это и есть проявление инфантилизма. Взрослый человек, считающий, что ему что-то должны. И обосновывающий это тем, что самому попой двигать стрессово.
Такие работники, как раз, хороши. Инициативы от них немного, получают чуть ниже рынка — хорошие рабочие лошадки. Главное, чтобы процессы были выстроены так, чтобы они были хорошо взаимозаменяемы, а не каждый пилил свой кусок.
Придёт такой с оффером — можно ему накинуть чуть выше рынка и запустить процедуру расширения штата, которые через полгода-год обратно свернётся.
Лояльность к компании — это сказка для самых маленьких. Случись в компании изменения, требующие переформатировать ту её часть, где вы обитаете, и вас не спасут ни хорошие отношения с вашим руководителем, ни сама позиция руководителя направления. Вас просто подвинут, переставять, сократят. Как повезет. Как договорились те, кто эти изменения в компании инициировал.
А вот отношения внутри коллектива, команды — это другое. Но если они нормальные, то обычно они "некорпоративные", и судьба бывших коллег воспринимается как возможные карьерные пути, без привязки к конкретной компании.
До контроффера и оффера должны были быть разговоры с руководителем о проблемах и пожеланиях. Тогда контроффер будет ясен сразу: неожиданно вытащенные плюшки для вас, о которых вы не подозревали, будут смотреться нелепо.
С другой стороны оффер с вашей стороны может быть сигналом вашему руководству провести те изменения, которые вы давно запрашивали.
Но если сотрудник инфантилен настолько, что его первый и единственный разговор с начальством — это оффер, то контроффер с разумными цифрами — нормальный способ потянуть время. Такой сотрудник — максимум, хорошая рабочая лошадка для проекта, но с близким к нулю потенциалом роста.
Более того, с началом полноценного внедрения в PHP ко(нтр)вариативности для параметров и возвращаемых значений, что-то вообще не приходит в голову ни один пример, где static в качестве тайп-хинта хоть что-то добавляет.
Дать возможность перепроектировать на новые рельсы команде, которая с ними не знакома, — это авантюра подороже будет, чем нанять новую команду, знакомую с этими рельсами.
Если же в компании налажена система по техническому росту своих сотрудников, то тогда вопрос: а как там оказался легаси проект, который не находится в процессе миграции на новый стек?
Потому что он будет понимать откуда ноги растут.
Есть ровно противоположный опыт. Бест-практики возрастом более 10 лет, которые уже рассматриваются как анти-паттерны. И очень интересные нестандартные архитектурные решения (зарекомендовавшие себя костыли с предыдущего места работы).
Любая отсебятина сотрудника в проекте уменьшает автобусный фактор. И требует инициализации процесса по шерингу знаний об этой отсебятине.
Вы так говорите, как будто изучить легаси 5-ки пхп это нечто сравнимое с изучением явы после бейсика.
Я говорю об обратной ситуации. Что если вам будет суждено провести следующие лет 5 в легаси проекте, то цена ваших технических навыков по завершению этого проекта будет рынком проигнорирована.
Я говорю, что есть бизнес, который кладет на развитие своих сотрудников. И такой бизнес, если что-то пойдет не так, в первую очередь поменяет команду исполнителей. Ты пилишь систему четвертый год и постоянно жалуешься, что под текущие нагрузки она не проектировалась. А потом наблюдаешь, как твой проект постепенно загибается, а рядом набрали новую команду с современными компетенция… И правильно сделали, потому что у твоей команды есть понимание, что старое не тянет, но опыта с новым нет. И за эти четыре года у вас не было времени его получать.
Специалист, работающий с современными технология, по опыту, довольно быстро адаптируется в легаси-проекте. Но если надо идти заниматься исключительно легаси проектом, то надо просить конский оверпрайс. Чтобы хоть как-то компенсировать потерю своей привлекательности на рынке за время, проведенное в таком проекте.
Я говорю, что IT в таких компаниях — не приоритет.
Обычная менеджерская задачка. Есть проект, который нужно развивать. Есть спецы, которые его развивают. При этом проект должен соответствовать современным реалиям, а те, кто его делают — это само собой разумеющееся. «Бизнесу нет выгоды в регулярном обновлении стека». И если вначале, когда проект начинался, были набраны специалисты совренного на тот момент уровня владения технологиями, то через пять лет остались только те, кому всё равно на собственное развитие. Потому что компания кладёт на развитие тех, кто развивает её продукт.
Придёт такой специалист собеседоваться. 15 лет опыта, последние 10 лет поддерживал и развивал проект на PHP 5.3. О современных технологиях только слышал или чуть-чуть щупал на пет-проектах. Опыт использования современных фреймфорков — увы, мимо. И целый набор эксклюзивных архитектурных идей и практик, принятых на его прошлом месте работы, которые никак не соотносятся с текущими бест-практиками. Хочет сеньером. Но увы, ничего кроме позиции джуниора ему не предложить. И то, сомнительный кандидат, так как где-то несколько лет назад окончательно положил на саморазвитие. Студент без опыта поинтереснее будет. Это такой крайний вариант.
То же самое и с менеджерами проектов. Есть те, кому команда неинтересна. Вкладываться в то, чтобы она росла вместе с проектом, — нет, не слышал, выхлопа для бинеса в этом нет. Мы их выучим, а они уйдут ещё. Получаем через 3-4 года неинтересный рынку соискателей стек технологий (сложность найти за рыночную цену), огромную текучку, и пару старожилов, потеря которых равносильна смерти проекта.
Но если IT — не приоритет, то и так сойдёт. Проекты живут в стадии операционной поддержки, баг фикса, и по фиче раз в пол года. Идеальное место для «пенсии». Главное, продать себя в такую компанию подороже.
Опытным путем показано, что в компаниях, в которых используются древние технологии, IT стоит далеко не на первом месте. И те, кто хочет развиваться в IT, в таких компания не задерживаются, да и не идут туда.
"У вас в продакшене PHP 5.3? Спасибо, неинтересно".
Кроме зарплаты заметно выше рынка (в реальности не больше средней по рынку), такие конторы ничего IT-специалисту предложить не могут. Но огромный минус в остановке в развитии на время работы в такой компании, не стоит даже тех бонусов, которые могут там предложить.
Автор SomeService вполне мог завязать её на конкретную реализацию SomeHttpClient, чтобы декомпозировать функционал. Давать возможность подставлять (или, вообще, делать какие-то выводы об интерфейсе SomeHttpClient) другую реализацию в его планы не входило.
Вы же, в рамках решения задачи по логированию, накладываете на какую-то конкретную часть библиотеки дополнительное правило, что именно вот эта её часть ходит в сеть, и именно эту её часть надо декорировать. Т.е., смотрите на этот чёрный ящик (библиотеку), делаете выводы о его внутреннем устройстве, и завязываетесь на эти выводы.
Автор может в следующей минорной версии выпилить эту зависимость, поэтому что она была не под интерфейсом, а просто частью реализации.
Вот если бы он внедрил её интерфейсом, то он бы взял на себя обязательство, что его библиотека зависит от некого интерфейса, является его клиентом. И вы вправе использовать её с любой реализацией этого интерейса.
И да, далеко не всегда попадаются внешние библиотеки, где интересный нам функционал, который нам надо модифицировать, вынесен под интерфейс. И мы либо модифицируем такую библиотеку, делая её частью проекта, либо декорируем всю библиотеку целиком. И в подменяем её, а «полным ужасом» во всех местах добавляем необходимый функционал.
Вот вы и испытываете последствия этого архитектурного решения. Бизнес-сущности — это не что-то внутренее, что является ядром вашей программы, и то, чем она по сути является (если убрать сайд эффекты), а нечто, что вы получаете извне. Плюс со всем обвесом в виде логики получения и сохранения этой сущности обратно. Это database-centric подход, где таблицы базы данных — это и есть бизнес-сущности. Бизнес-логика сосредоточена на манипуляции и связях между таблицами. Постепенно мигруирует из кода приложения в саму базу данных в виде триггеров и процедур. И по мере усложнения модели данных, ОРМ начинает мешать, так как умеет, по сути, только мепить таблицу в объект, и немного связи (с минимальными оптимизациями). А взаимоотншения между таблицам в таком походе обычно сложнее, чем можем орм.
Если хотите в DDD, то нужно забыть о том, что бизнес-модель знает хоть что-то о том, как она хранится, и вообще, о том, что она где-то хранится. Только поля, и только бизнес-операции над ней. А рядом слой, который умеет сохранять эту модель в выбранное хранилици, и получать обратно. Будет ли при этом использоваться орм как слой абстракции для общения с базой, или нет — это дело реализаци этого слоя.
Репозиторий возвращает модельку орм. Моделька мепится сервисом в бизнес-сущность. Над бизнес-сущностью проводятся необходимые операции. Сервис мепит бизнес-сущность в модельку орм, которая сохраняется репозиторием.
Бизнес-сущность ничего не знает о том, как вы храните стейт. Есть служебный слой, который преобразует стейт-объекты в бизнес-сущности. ОРМ выполняет ту функцию, для которой была придумана: позволяет работать с таблицами базы данных как с нативными объектами языка.
принимающий в конструктор модель eloquent в репозитории
Так это же хорошо. Вы спокойно подставляете фикстуру и тестируете логику вашего объекта. Он же не зависит от содержимого внедряймой сущности… Это же логика над ней.
А если зависит, или, вообще, знает, что внутри внедряемого как зависимость, объекта, то тут, естественно, будут проблемы с тестированием, так как у вас нет в этом месте разделения на абстракции, и, следовательно, нужно тестировать все возможные взаимоотношения объектов, который взаимодействуют друг с другом напрямую.
Начальство за свое "ты должен" полатит монетой.
А какие у сотрудника взаимоотношения с компанией, помимо трудовых за заранее оговоренную монету, что компания тоже что-то должна сотруднику?
Ничего конкретного. Ок.
Примерно как на встречах 121, никогда ничего не требуют, вроде всё устраивает. А потом заявление об увольнении.
А по каким действиям в ваш адрес вы поймёте, что фирма к вам лояльна?
Проблемы управления проектом — это ответственность менеджера проекта. Нисколько не головная боль ведущего программиста в этом проекте.
Если уж такая ситуация возникла, то надо уходить, давая бизнесу возможность согласовать с вам контракт на поддержку за оверпрайс. Где бизнес будет искать средства на этот оверпрайс? Проблемы бизнеса. Возможно, за счет того менеджера, который такую ситуацию допустил.
Это и есть проявление инфантилизма. Взрослый человек, считающий, что ему что-то должны. И обосновывающий это тем, что самому попой двигать стрессово.
Такие работники, как раз, хороши. Инициативы от них немного, получают чуть ниже рынка — хорошие рабочие лошадки. Главное, чтобы процессы были выстроены так, чтобы они были хорошо взаимозаменяемы, а не каждый пилил свой кусок.
Придёт такой с оффером — можно ему накинуть чуть выше рынка и запустить процедуру расширения штата, которые через полгода-год обратно свернётся.
Лояльность к компании — это сказка для самых маленьких. Случись в компании изменения, требующие переформатировать ту её часть, где вы обитаете, и вас не спасут ни хорошие отношения с вашим руководителем, ни сама позиция руководителя направления. Вас просто подвинут, переставять, сократят. Как повезет. Как договорились те, кто эти изменения в компании инициировал.
А вот отношения внутри коллектива, команды — это другое. Но если они нормальные, то обычно они "некорпоративные", и судьба бывших коллег воспринимается как возможные карьерные пути, без привязки к конкретной компании.
До контроффера и оффера должны были быть разговоры с руководителем о проблемах и пожеланиях. Тогда контроффер будет ясен сразу: неожиданно вытащенные плюшки для вас, о которых вы не подозревали, будут смотреться нелепо.
С другой стороны оффер с вашей стороны может быть сигналом вашему руководству провести те изменения, которые вы давно запрашивали.
Но если сотрудник инфантилен настолько, что его первый и единственный разговор с начальством — это оффер, то контроффер с разумными цифрами — нормальный способ потянуть время. Такой сотрудник — максимум, хорошая рабочая лошадка для проекта, но с близким к нулю потенциалом роста.
Дать возможность перепроектировать на новые рельсы команде, которая с ними не знакома, — это авантюра подороже будет, чем нанять новую команду, знакомую с этими рельсами.
Если же в компании налажена система по техническому росту своих сотрудников, то тогда вопрос: а как там оказался легаси проект, который не находится в процессе миграции на новый стек?
Есть ровно противоположный опыт. Бест-практики возрастом более 10 лет, которые уже рассматриваются как анти-паттерны. И очень интересные нестандартные архитектурные решения (зарекомендовавшие себя костыли с предыдущего места работы).
Любая отсебятина сотрудника в проекте уменьшает автобусный фактор. И требует инициализации процесса по шерингу знаний об этой отсебятине.
Я говорю об обратной ситуации. Что если вам будет суждено провести следующие лет 5 в легаси проекте, то цена ваших технических навыков по завершению этого проекта будет рынком проигнорирована.
Немного не так.
Я говорю, что есть бизнес, который кладет на развитие своих сотрудников. И такой бизнес, если что-то пойдет не так, в первую очередь поменяет команду исполнителей. Ты пилишь систему четвертый год и постоянно жалуешься, что под текущие нагрузки она не проектировалась. А потом наблюдаешь, как твой проект постепенно загибается, а рядом набрали новую команду с современными компетенция… И правильно сделали, потому что у твоей команды есть понимание, что старое не тянет, но опыта с новым нет. И за эти четыре года у вас не было времени его получать.
Специалист, работающий с современными технология, по опыту, довольно быстро адаптируется в легаси-проекте. Но если надо идти заниматься исключительно легаси проектом, то надо просить конский оверпрайс. Чтобы хоть как-то компенсировать потерю своей привлекательности на рынке за время, проведенное в таком проекте.
Обычная менеджерская задачка. Есть проект, который нужно развивать. Есть спецы, которые его развивают. При этом проект должен соответствовать современным реалиям, а те, кто его делают — это само собой разумеющееся. «Бизнесу нет выгоды в регулярном обновлении стека». И если вначале, когда проект начинался, были набраны специалисты совренного на тот момент уровня владения технологиями, то через пять лет остались только те, кому всё равно на собственное развитие. Потому что компания кладёт на развитие тех, кто развивает её продукт.
Придёт такой специалист собеседоваться. 15 лет опыта, последние 10 лет поддерживал и развивал проект на PHP 5.3. О современных технологиях только слышал или чуть-чуть щупал на пет-проектах. Опыт использования современных фреймфорков — увы, мимо. И целый набор эксклюзивных архитектурных идей и практик, принятых на его прошлом месте работы, которые никак не соотносятся с текущими бест-практиками. Хочет сеньером. Но увы, ничего кроме позиции джуниора ему не предложить. И то, сомнительный кандидат, так как где-то несколько лет назад окончательно положил на саморазвитие. Студент без опыта поинтереснее будет. Это такой крайний вариант.
То же самое и с менеджерами проектов. Есть те, кому команда неинтересна. Вкладываться в то, чтобы она росла вместе с проектом, — нет, не слышал, выхлопа для бинеса в этом нет. Мы их выучим, а они уйдут ещё. Получаем через 3-4 года неинтересный рынку соискателей стек технологий (сложность найти за рыночную цену), огромную текучку, и пару старожилов, потеря которых равносильна смерти проекта.
Но если IT — не приоритет, то и так сойдёт. Проекты живут в стадии операционной поддержки, баг фикса, и по фиче раз в пол года. Идеальное место для «пенсии». Главное, продать себя в такую компанию подороже.
Опытным путем показано, что в компаниях, в которых используются древние технологии, IT стоит далеко не на первом месте. И те, кто хочет развиваться в IT, в таких компания не задерживаются, да и не идут туда.
"У вас в продакшене PHP 5.3? Спасибо, неинтересно".
Кроме зарплаты заметно выше рынка (в реальности не больше средней по рынку), такие конторы ничего IT-специалисту предложить не могут. Но огромный минус в остановке в развитии на время работы в такой компании, не стоит даже тех бонусов, которые могут там предложить.
Автор SomeService вполне мог завязать её на конкретную реализацию SomeHttpClient, чтобы декомпозировать функционал. Давать возможность подставлять (или, вообще, делать какие-то выводы об интерфейсе SomeHttpClient) другую реализацию в его планы не входило.
Вы же, в рамках решения задачи по логированию, накладываете на какую-то конкретную часть библиотеки дополнительное правило, что именно вот эта её часть ходит в сеть, и именно эту её часть надо декорировать. Т.е., смотрите на этот чёрный ящик (библиотеку), делаете выводы о его внутреннем устройстве, и завязываетесь на эти выводы.
Автор может в следующей минорной версии выпилить эту зависимость, поэтому что она была не под интерфейсом, а просто частью реализации.
Вот если бы он внедрил её интерфейсом, то он бы взял на себя обязательство, что его библиотека зависит от некого интерфейса, является его клиентом. И вы вправе использовать её с любой реализацией этого интерейса.
И да, далеко не всегда попадаются внешние библиотеки, где интересный нам функционал, который нам надо модифицировать, вынесен под интерфейс. И мы либо модифицируем такую библиотеку, делая её частью проекта, либо декорируем всю библиотеку целиком. И в подменяем её, а «полным ужасом» во всех местах добавляем необходимый функционал.
Вот вы и испытываете последствия этого архитектурного решения. Бизнес-сущности — это не что-то внутренее, что является ядром вашей программы, и то, чем она по сути является (если убрать сайд эффекты), а нечто, что вы получаете извне. Плюс со всем обвесом в виде логики получения и сохранения этой сущности обратно. Это database-centric подход, где таблицы базы данных — это и есть бизнес-сущности. Бизнес-логика сосредоточена на манипуляции и связях между таблицами. Постепенно мигруирует из кода приложения в саму базу данных в виде триггеров и процедур. И по мере усложнения модели данных, ОРМ начинает мешать, так как умеет, по сути, только мепить таблицу в объект, и немного связи (с минимальными оптимизациями). А взаимоотншения между таблицам в таком походе обычно сложнее, чем можем орм.
Если хотите в DDD, то нужно забыть о том, что бизнес-модель знает хоть что-то о том, как она хранится, и вообще, о том, что она где-то хранится. Только поля, и только бизнес-операции над ней. А рядом слой, который умеет сохранять эту модель в выбранное хранилици, и получать обратно. Будет ли при этом использоваться орм как слой абстракции для общения с базой, или нет — это дело реализаци этого слоя.
Бизнес-сущность ничего не знает о том, как вы храните стейт. Есть служебный слой, который преобразует стейт-объекты в бизнес-сущности. ОРМ выполняет ту функцию, для которой была придумана: позволяет работать с таблицами базы данных как с нативными объектами языка.
Так это же хорошо. Вы спокойно подставляете фикстуру и тестируете логику вашего объекта. Он же не зависит от содержимого внедряймой сущности… Это же логика над ней.
А если зависит, или, вообще, знает, что внутри внедряемого как зависимость, объекта, то тут, естественно, будут проблемы с тестированием, так как у вас нет в этом месте разделения на абстракции, и, следовательно, нужно тестировать все возможные взаимоотношения объектов, который взаимодействуют друг с другом напрямую.