Все верно, в данном посте инструмент SQL, знающий его человек сможет построить такую механику, не знающий — нет. Как определить знающего — задать некоторые вопросы выше.
Вы можете попытаться объяснить, что и под задпчу можнл учить, но практика подсказывает, что задача отдается тем, кто знает, а не тем, кто готов знать (и тратить чужие деньги).
Ну и выше перечисленные знания можно уже причислить к фундаменту, более того — считаю эти вопросы очень поверхностными и знать нужно куда глубже.
Кстати вчера задавали похожий вопрос на Тостере, мое объяснение «покороче» вашего вышло в силу специфики формата, так что в целом посту вашему плюс, разъяснять нужно это дело: toster.ru/q/641030#answer_1406923
везде обсуждается КАК сделать, но практически нигде – ЗАЧЕМ
Мне казалось, что DI паттерн всегда объясняется со словом ЗАЧЕМ, всегда рядом есть такие аргументы как тестирование и принципы DIP (Dependency Inversion Principe) и OCP (Open/Closed Principe) из SOLID. Так как благодаря инверсии зависимостей мы можем использовать полиморфизм (тем самым облегчая подмену зависимости снаружи, чем и обеспечиваем оба принципа SOLID).
К сожалению, на момент написания статьи PhpStorm этого не умеет.
К сожалению на момент написания этой статьи PhpStorm это умеет. Да-да перевод, все дела, но дата у статьи на Хабре сегодняшняя, а в статье аж 11 упоминаний про бесполезность Шторма
Для джуниора тоже хороши, тк могут дать разработчику дополнительную ценность, дополнительное value в работе и в глазах коллег/бизнеса. Всегда стараюсь прощупать — какую ценность представляю и что могу сделать. На позапрошлой работе благодаря этому выторговал 3 раза повышение зп (хотя смотрю назад — все копейки), на прошлой тоже получилось нащупать, но спустя месяца 4 только… Я далеко не сеньор и не тимлид, да и мидл начинающий
Большие проекты — командные проекты с валом задач, с фрилансерами просто очень туго работать в этом плане: банда разбойников (пусть даже каждый и достойный головорез) сыпется, когда на тебя идет организованный строй проблем, но сюда добавляется риск «смыться» у каждого, потому что — потому что фрилансеры они.
И это крайне не стабильно, более того системы бывают на столько сложные, что фрилансер не будет сидеть и изучать проект с 2 недели.
Кроме того есть минусы с обратной стороны — менеджеру сложно работать с фрилансерами, тк если работник может послушать/ПОДслушать контекст и сэкономить время на объяснении, подглядеть, пообщаться, то на удалении — для этой сессии нужно выделять четкое кол-во времени и сил. При условии, что он может срулить (сори, это практика), проект сложный и еще усложнить на уровне процесоов работы — не простительно для ряда проектов. При чем тут фрилансер? Да потому что вкуснейшие и технологичные проекты работают так, достойно платят и еще сильно подходят кандидатам.
Думаю, что не будете отрицать — поиск достойного исполнителя тоже сложноватый, плюс кодом на лево и направо торговать — так себе идейка, пусть и решаема. Это ж как будет выглядеть HR при работе с фрилансерами? (речь про большой командный проект).
А понял, вы интеграционное делаете тестирование. Тогда наверное ваши подходы подходят.
Если юнит-делать. Например так: В репозитории сделать метод add(). В оригинальной репе флаш будет, в имитации — просто добавление в приватный массив. Тогда ваш сервис будет тестить я без зависимостей и легко.
Или так: мокать репу, и мокать ее методы, а сохранение тестировать уже в интеграционном тесте, как сказали ниже.
Правда в вашем случае может вообще отпасть его надобность, а слову суффикс Service сам на это намекает, что логику бы определить по конкретнее.
Так solid как раз и помогает большим проектам, тк если это не так, то разгребание и понимание кода, а также его тестирование, превращается в боль
Очень забавно читать про непринятие DI в контексте java разработки :)
Свой продукт у таргетолога — грамотный таргетинг :)
Юнит-тесты и бд не укладываются в моей голове :) Может все же интеграционные?
Скоро плявится ресурс с более чуткими и конкретными данными и оптом :) С деанонимизацией вме скоро станет возможным
Вы можете попытаться объяснить, что и под задпчу можнл учить, но практика подсказывает, что задача отдается тем, кто знает, а не тем, кто готов знать (и тратить чужие деньги).
Ну и выше перечисленные знания можно уже причислить к фундаменту, более того — считаю эти вопросы очень поверхностными и знать нужно куда глубже.
Раз в США расстреливали, то ок? Можно и у нас?
Не плохая у них вилка, оффер одним из лучших был
deletedtoster.ru/q/641030#answer_1406923
Мне казалось, что DI паттерн всегда объясняется со словом ЗАЧЕМ, всегда рядом есть такие аргументы как тестирование и принципы DIP (Dependency Inversion Principe) и OCP (Open/Closed Principe) из SOLID. Так как благодаря инверсии зависимостей мы можем использовать полиморфизм (тем самым облегчая подмену зависимости снаружи, чем и обеспечиваем оба принципа SOLID).
сейчас проверил — ничего не светит
тогда приношу извинения m0rtis, мой комментарий не верный
К сожалению на момент написания этой статьи PhpStorm это умеет. Да-да перевод, все дела, но дата у статьи на Хабре сегодняшняя, а в статье аж 11 упоминаний про бесполезность Шторма
И это крайне не стабильно, более того системы бывают на столько сложные, что фрилансер не будет сидеть и изучать проект с 2 недели.
Кроме того есть минусы с обратной стороны — менеджеру сложно работать с фрилансерами, тк если работник может послушать/ПОДслушать контекст и сэкономить время на объяснении, подглядеть, пообщаться, то на удалении — для этой сессии нужно выделять четкое кол-во времени и сил. При условии, что он может срулить (сори, это практика), проект сложный и еще усложнить на уровне процесоов работы — не простительно для ряда проектов. При чем тут фрилансер? Да потому что вкуснейшие и технологичные проекты работают так, достойно платят и еще сильно подходят кандидатам.
Думаю, что не будете отрицать — поиск достойного исполнителя тоже сложноватый, плюс кодом на лево и направо торговать — так себе идейка, пусть и решаема. Это ж как будет выглядеть HR при работе с фрилансерами? (речь про большой командный проект).
Если юнит-делать. Например так: В репозитории сделать метод add(). В оригинальной репе флаш будет, в имитации — просто добавление в приватный массив. Тогда ваш сервис будет тестить я без зависимостей и легко.
Или так: мокать репу, и мокать ее методы, а сохранение тестировать уже в интеграционном тесте, как сказали ниже.
Правда в вашем случае может вообще отпасть его надобность, а слову суффикс Service сам на это намекает, что логику бы определить по конкретнее.