Мой личный список вопросов работодателю (если не было освещено на собеседовании).
Чем я буду заниматься? Только узкими обязанностями или еще и смежными?
Какой стек на моём проекте? Есть ли легаси?
Что с тестированием
Есть ли CI/CD и девопс инженер?
Будет ли единый ПМ и четко заданный жизненный цикл таска?
Есть ли БА?
Системы мониторинга, сборщик логов?
Переработки бывают? Оплата?
Системы трекинга времени и руткиты на рабочем компе?
Отпуска: дробление отпуска, включены или нет выходные, за сколько нужно предупреждать, отказы
За что и как часто получаются премии? Кто определяет их размер?
Есть ли СБ? Какие требования у СБ?
Почему открыта вакансия? Если не новая, то куда ушел предыдущий разработчик?
Аналогично про гибкий график, карьерный рост. Что это значит и в чем выражается.
Ретроспектива.
Код ревью в компании: кто, как долго, что если пожар.
Именно в этом Laravel лучше PHP, в котором нет никаких шаблонов.
Вы серьезно? Вы думаете, после подобных фраз к вам придет хоть один человек на курс? Ну вот объективно оцените свой уровень и поймите, что это полный и беспросветный ужас.
Ничего сложного. docker-compose.yml класть в то место, где ты его будешь запускать. Он ищет в той папке, где ты вызвал команду docker-compose up -d. Идентификатор lesson1 появился из названия папки в которой запускается проект. То есть автор запускал проект в папке lesson1.
Не согласен. Тут вы тоже можете пойти и выбрать другой поисковик — гугл, яху, рамблер и другие. Поисковик правильно выводить, как аналогию магазина. Ибо это, если можно так назвать, маркетплейс ссылок.
Он будет корректным, если к вашей фразе дополнить, что при этом люди, в основном смотрят только первые 3-5 шоколадок на первой полке, а переход в подсобку осиливают единицы из миллионов.
Претензия не в том, что они не могут пиариться, а в том, что у них не те условия. Справедливо дать всем возможность использовать одинаковые инструменты, пусть и платно. То есть хочешь иметь такую привилегию — заплати Яндексу деньгу и получи свою возможность использовать этот функционал. Не хочешь платить — твое право, но Яндекс также не должен терять свой доход, ради которого он и занимает доминирующую позицию.
В корне с вами не согласен. Здесь должен был быть аргумент о скорости работы, но никак не о скорости установки. Развертка нового laravel приложения занимает минут 5, из которых 4 — скачивание пакетов из сети.
1) composer create-project laravel/laravel project_name
2) правка .env для подключения к базе
3) все.
Остальные действия ты делаешь так или иначе, когда работаешь с чистым php.
Правда я согласен с тем, что использование фреймворка для такой простой задачи — стрельба из пушки по воробьям.
Был дан очень грамотный комментарий. Если на ревью критично соблюдение стайлгайдов, сделайте жизнь разработчикам проще — добавьте гитовые пре-коммит хуки, которые будут проверять и исправлять стайлгайдовые ошибки. Вот и все решение. И себе время сэкономите и коллегам своим.
ИМХО.
Комментарии в коде часто недостаток, чем польза. Чаще всего они содержат //todo, либо //fixme, либо // это переменная. Если требуется комментарий, то надо подумать, а нельзя ли было написать лучше. Чаще всего, код документирует сам себя. Выбирай грамотные названия переменных. Комментарий ставится только тогда, когда без него никуда.
Даже если код вызывается редко это не отменяет необходимости сделать его оптимально.
Абстракции на уровне бизнес логики не менее важны, чем на уровне поддерживающего слоя.
UPD: Комментарии нужны для того, чтобы описать почему здесь сделано именно так, а не иначе, а не для ответа на вопрос что здесь происходит.
Здесь могу ответить только примерно так: вас привлекли, как профессионала для того, чтобы сделать свою работу. Также, как привлекают программистов, дизайнеров и так далее. Вы, как специалист в определенной области знаете ее гораздо лучше, чем все маркетологи и директора вместе взятые. Следовательно, и вопрос следует ставить так: либо вы доверяете и я делаю так, как считаю правильным с точки зрения знаний и опыта, а вы способствуете этому, либо мы делаем так, как сказали вы и получаем негатив от потребителей контента. При этом, естественно, за основу берется пожелание заказчика, то есть делать что-то абстрактное, естественно не нужно.
А вот за этот ответ — уважение. Признать ошибку это уже многое. И все же, на мой взгляд, необходимо доносить до маркетологов информацию о том, что подобные материалы можно публиковать на неспециализированных платформах, вроде Яндекс.Дзена, но никак не на ресурсе, посвященном IT, где львиная доля посетителей — разработчики различного уровня, желающие более качественного раскрытия материала. В общем-то говоря, выдает небольшую некомпетентность специалистов, не учитывающих целевую аудиторию.
P.S. Надеюсь, что второй материал из серии раскроет информацию подробнее.
Я выскажу свое, сугубо субъективное мнение. Проблема этого материала в том, что он состоит только из воды с вкраплением отдельно взятых и не особо связанных фактов. Вопрос в том, а что конкретно хотели таким материалом донести? То, что вы смогли слить две больших разрозненных системы в одну? Молодцы. Поработали, постарались. А поделиться архитектурой этих систем и рассказать в чем конкретно были сложности и какие были подводные камни?
У меня есть ощущение, что я прочитал отчет менеджера, который выпрашивает повышение зарплаты у директора. Много громких слов, абстрактные обозначения (значительно, сильно и другие подобные слова без особой конкретики было-стало), использование нагоняющих мистику фраз и подобное.
ИМХО. Статья несет два посыла: "придите к нам на конференцию, мы вас еще напоим водичкой" и "смотрите, какие мы крутые".
P. S. Прошу прощения за агрессивный тон комментария. Не претендую на истину в последней инстанции — личное мнение.
Меня больше смущает, что на стоимости в 1000 долларов за железо + администрирование, эти 3-4 раза дороже выйдут как раз 3-4 тысячи долларов. У бизнеса часто возникают серьезные вопросы в духе «А за что мы переплачиваем 2-3 тысячи вечнозеленых»? Не за надежность ли и возможность экстренно вертикально/горизонтально и быстро нарастить мощности? Не за сохранность ли данных и администрирование железок?
Такие минусы, как произошли у Яндекса заставляют задуматься о желании переехать туда. С их-то ценником, мне кажется, можно не допускать такое. Надеюсь, что они, реально, сделают выводы и такого не повторится.
P.S. Если потерялись данные — проблема не Яндекса, а бизнеса (читай, админа), который не настроил бэкапы, тут я не оправдываю. Хотя, конечно, хостинг доверие потерял и часть данных гарантированно вылетели в трубу — за это тоже нужно давать хорошую плюшку.
P.P.S. Если упал какой-то важный сервис по ошибке Яндекса, то, на мой взгляд, Яндекс должен возместить ущерб такого падения. И дать шоколадку сверху.
Поэтому хакатоны так любят студенты и безработные. Ну либо люди в отпуске, которым не особо есть чем заняться (а так тоже бывает). В основном, если есть желание участвовать, необходимо понимать, что это будет два бессонных (ну сон по 4 часа — максимум) дня непрерывного кодинга, причем вы не успеете все равно сделать идеальный продукт.
Хотите участвовать — берите неделю отгула / отпуска — один день до, два дня на хакатон, четыре дня на выспаться. И будет счастье. Если работа на неделе — нет, не выйдет.
Ах да. Важно. Не юзайте энергетики. Они блокируют на некоторое время нейромедиаторы, которые потом все равно дадут о себе знать. Шарахнет усталостью еще сильнее, чем раньше.
В тему. Есть шикарная (без шуток, очень хорошая) научная книга в тему сна от Мэтью Уолкера «Зачем мы спим». Подробная научная работа, покрывающая большУю часть исследований, существующих на сегодняшний день со ссылками на источники и further reading. Если хочется научной информации — туда. Несмотря на относительно легкий характер повествования, книга крайне нагружена информацией, в том числе, по нейрофизиологии — там есть, например, информация о работе нейромедиаторов и их влиянии на различные ощущения и желание спать.
На мой взгляд, статья в чистом виде вода. Из чего это можно понять: пол текста — клишированные обороты, вроде
Фундаментальная концепция приводит к появлению первых идей и к созданию первых моделей обработки данных.
Много красивого текста, но по факту никакой полезной информации.
В случае, если автору хотелось рассказать про архитектуру, следовало бы просто прочитать литературу на это счет. Из признанного и успешно работающего: Мартин (Чистая архитектура и чистый код), Вигерс (разработка требований к программному обеспечению), Басс (архитектура программного обеспечения на практике), O'Reilly.
Кроме того, можно было бы взять другие источники по разработке: прочитать про DDD и другие подходы к проектированию. Помимо этого, нужно знать о том, как проектируется MVP и чем прототип отличается от MVP.
Вот тут вы правы. PHP — интерпретируемый язык программирования, несмотря на opcache и ввод JIT в 8 ветке языка. Но если у PHP есть что-то вроде php -f index.php где он ругнется на неверный синтаксис и бросит (сразу) error, то для python мы это увидим когда непосредственно столкнемся, что может произойти далеко не сразу (знатоки питона, если это не правда — поправляйте). Однако, и правда, все это происходит в рантайме.
Это дело решается тестами, но, поверьте, тесты не всегда хорошие и не всегда имеют 100% покрытия.
Да, как бы странно это не было, я не считаю в данном случае Мартина правым в данной ситуации. Вернее, не согласен с тем, как этот материал повернут вами в контексте комментария, на который вы его отправили.
Смотрите. Кирилл говорит о том, что реализация на языке Python приводит к проблемам, которые будут найдены непосредственно в рантайме, что недопустимо. Что можно избежать в PHP использовав принципы того же Мартина — ISP + DI с использованием встроенных средств языка, а не внимательности разработчика. Кроме того, он апелирует к тому, что мы перестаем хардкодить и начинаем работать с абстракциями.
Суть комментария в том, что не важно, является ли ключевое слово вредным или нет: такое решение в языках есть и с ним мы живем. Если в Python реализовали множественное наследование через пень-колоду (к слову, сам автор в комментариях согласен с тем, что интерфейсы нужны), не дали нормального способа создавать абстрактные классы и методы, а в PHP это сделать реально, пусть и с использованием «вредного» interface (к слову, я не вижу дублирования кода в данном контексте, хотя если судить по Мартину оно здесь должно быть) — я выберу более безопасный, а как следствие, подходящий инструмент, который меня защитит от этого.
Кроме того. Мартин аппелирует к Eiffel, который решил проблему множественного наследования. Каким образом он это сделал? Мы можем указать, какие методы родительского класса мы наследуем. То есть потенциально доступна ситуация, когда родительский класс имеет какой-то метод, а дочерний — не имеет. Для меня такая ситуация является недопустимой и именно для этого принципиально и нужны интерфейсы. Это контракт, который гарантирует мне работу и ошибки компиляции.
P.S. Я не спорю с самой статьей и идеей. Если бы решилась проблема множественного наследования, принципиально у нас бы было всего два инструмента: класс и интерфейс, а абстрактный класс был бы не нужен, так как его функции перенял бы интерфейс. Ну или наоборот.
Вы видимо не захотели прочитать книгу «Паттерны проектирования» от банды четырех.
Там говорилось об одном важном пункте композиция вместо наследования.
Рекомендую почитать аргументацию, она развенчивает все мифы, указанные по вашей ссылке и дает понимание, когда использовать то или другое.
К тому же я хочу обратить ваше внимание на наличие частичного наследования в PHP, реализованного в виде трейтов.
P.S. Строка выше относится к тому, что оригинальная статья опирается на синтаксис языка Java, которая не позволяет использовать множественное наследование. Кроме того, рекомендую прочитать википедию по поводу множественного наследования и убедиться, что оно далеко не так «красиво», как его изображают в вашем материале.
В этом случае, согласитесь, данная уязвимость была бы в браузерах mozilla firefox и chrome, а также других браузеров на основе chromium, вроде Яндекс.Браузера и подобных, так как они отображают корректный url не превращая строку в punnycode.
Прошу вас, пообщайтесь с разработчиками. Данная проблема стоит, пусть и не очень остро, но url играет крайне важную роль, как для SEO, так и для специалистов по маркетингу. А вы заменяете его набором непонятных для пользователя символов.
Можете указать, конкретно какие требования безопасности будут нарушены, если перевести punnycode в нормальный понятный URL? Все браузеры это делают, оставляя punnycode только если присутствует комбинация символов из разных языков.
Русскоязычные домены — довольно частое требование бизнеса. У меня на поддержке есть четыре таких сайта.
Максимально точно выражено мое мнение, полностью поддерживаю. Но необходимо дополнить.
Использование репозитория просто как абстракции над хранилищем зачастую не имеет смысла в продуктах до определенного размера. Тут проблема в том, что любое изменение бизнес-условий в продукте чуть выше размером, чем домашняя CRUD страничка, вызовет мучительные боли чуть пониже спины, потому что эти изменения коснутся каждого файла проекта, где подобные операции используются.
К примеру, буквально вчера в большой лигаси-системе я зарелизил небольшой блок, который касался добавления нового типа сущности. Проблема в том, что этот тип сущности требовалось получить из внешнего источника, отличного от базы данных. Кроме того, его нужно было зарегистрировать во всех элементах сайта, где он может потенциально использоваться. Итого, мне пришлось изменить что-то в районе 80 файлов на стороне сервера, чтобы добавить тривиальную функцию. А это непаханое поле ошибок и потенциальных багов, которые необходимо еще отлавливать.
Используй разработчик паттерн репозиторий, да и в целом, поддерживай он исходники в более качественном состоянии, подмена кода была бы не такой страшной и менять пришлось бы не более 10-15 файлов.
То есть выбирая инструмент, а я пропагандирую отказ от AR в пользу более очевидного, но имеющего больший порог входа репозитория и сущности, как коллекции — объектного представления структуры данных, необходимо понимать и представлять не только то, что будет сейчас, но и загадывать на перспективу. Ибо, как сказал небезызвестный в узких кругах широких масс, некий М. Фраулер, чистая архитектура это такая архитектура, изменения в которую вносятся максимально просто.
Суть репозитория не только в том, чтобы было легко подменять источник получения данных, а в том, чтобы в принципе было удобно подменять логику работы с хранилищем. К примеру, у вас были в приложении новости, которые возвращались в десятке контроллеров. Приходит бизнес и просит вас добавить к этим постам параметр видимость. У вас несколько решений: если вы не использовали репозиторий, вы будете писать скоуп для модели, ползти в те места (если вы их помните, а в командной разработке это не факт), где это работать не должно, например, в админке, править это безобразие. В случае же с репозиторием, вы подменяете в одном из методов реализацию выборки добавлением этого скоупа, не добавляя ее в выборку для админки или сбрасываете ее.
Резюмируя. Если вы хотите сделать быстро, проверить гипотезы, не планируете вносить большие изменения от слова совсем — используйте Eloquent as is — это крутейший инструмент, значительно ускоряющий процесс разработки продукта. Но если вы делаете проект для заказчика, в условиях изменяющихся бизнес-требований, с учетом необходимости длительной поддержки сервиса, не поленитесь, пишите репозитории: они окупятся. И дело даже не в смене базы данных, а в целом, в простоте поддержки продукта на разных этапах его существования.
Мой личный список вопросов работодателю (если не было освещено на собеседовании).
Чем я буду заниматься? Только узкими обязанностями или еще и смежными?
Какой стек на моём проекте? Есть ли легаси?
Что с тестированием
Есть ли CI/CD и девопс инженер?
Будет ли единый ПМ и четко заданный жизненный цикл таска?
Есть ли БА?
Системы мониторинга, сборщик логов?
Переработки бывают? Оплата?
Системы трекинга времени и руткиты на рабочем компе?
Отпуска: дробление отпуска, включены или нет выходные, за сколько нужно предупреждать, отказы
За что и как часто получаются премии? Кто определяет их размер?
Есть ли СБ? Какие требования у СБ?
Почему открыта вакансия? Если не новая, то куда ушел предыдущий разработчик?
Аналогично про гибкий график, карьерный рост. Что это значит и в чем выражается.
Ретроспектива.
Код ревью в компании: кто, как долго, что если пожар.
Вы серьезно? Вы думаете, после подобных фраз к вам придет хоть один человек на курс? Ну вот объективно оцените свой уровень и поймите, что это полный и беспросветный ужас.
Ничего сложного. docker-compose.yml класть в то место, где ты его будешь запускать. Он ищет в той папке, где ты вызвал команду docker-compose up -d. Идентификатор lesson1 появился из названия папки в которой запускается проект. То есть автор запускал проект в папке lesson1.
Не согласен. Тут вы тоже можете пойти и выбрать другой поисковик — гугл, яху, рамблер и другие. Поисковик правильно выводить, как аналогию магазина. Ибо это, если можно так назвать, маркетплейс ссылок.
Он будет корректным, если к вашей фразе дополнить, что при этом люди, в основном смотрят только первые 3-5 шоколадок на первой полке, а переход в подсобку осиливают единицы из миллионов.
Претензия не в том, что они не могут пиариться, а в том, что у них не те условия. Справедливо дать всем возможность использовать одинаковые инструменты, пусть и платно. То есть хочешь иметь такую привилегию — заплати Яндексу деньгу и получи свою возможность использовать этот функционал. Не хочешь платить — твое право, но Яндекс также не должен терять свой доход, ради которого он и занимает доминирующую позицию.
В корне с вами не согласен. Здесь должен был быть аргумент о скорости работы, но никак не о скорости установки. Развертка нового laravel приложения занимает минут 5, из которых 4 — скачивание пакетов из сети.
1) composer create-project laravel/laravel project_name
2) правка .env для подключения к базе
3) все.
Остальные действия ты делаешь так или иначе, когда работаешь с чистым php.
Правда я согласен с тем, что использование фреймворка для такой простой задачи — стрельба из пушки по воробьям.
Был дан очень грамотный комментарий. Если на ревью критично соблюдение стайлгайдов, сделайте жизнь разработчикам проще — добавьте гитовые пре-коммит хуки, которые будут проверять и исправлять стайлгайдовые ошибки. Вот и все решение. И себе время сэкономите и коллегам своим.
ИМХО.
//todo, либо//fixme, либо// это переменная. Если требуется комментарий, то надо подумать, а нельзя ли было написать лучше. Чаще всего, код документирует сам себя. Выбирай грамотные названия переменных. Комментарий ставится только тогда, когда без него никуда.UPD: Комментарии нужны для того, чтобы описать почему здесь сделано именно так, а не иначе, а не для ответа на вопрос что здесь происходит.
P.S. Надеюсь, что второй материал из серии раскроет информацию подробнее.
Я выскажу свое, сугубо субъективное мнение. Проблема этого материала в том, что он состоит только из воды с вкраплением отдельно взятых и не особо связанных фактов. Вопрос в том, а что конкретно хотели таким материалом донести? То, что вы смогли слить две больших разрозненных системы в одну? Молодцы. Поработали, постарались. А поделиться архитектурой этих систем и рассказать в чем конкретно были сложности и какие были подводные камни?
У меня есть ощущение, что я прочитал отчет менеджера, который выпрашивает повышение зарплаты у директора. Много громких слов, абстрактные обозначения (значительно, сильно и другие подобные слова без особой конкретики было-стало), использование нагоняющих мистику фраз и подобное.
ИМХО. Статья несет два посыла: "придите к нам на конференцию, мы вас еще напоим водичкой" и "смотрите, какие мы крутые".
P. S. Прошу прощения за агрессивный тон комментария. Не претендую на истину в последней инстанции — личное мнение.
Такие минусы, как произошли у Яндекса заставляют задуматься о желании переехать туда. С их-то ценником, мне кажется, можно не допускать такое. Надеюсь, что они, реально, сделают выводы и такого не повторится.
P.S. Если потерялись данные — проблема не Яндекса, а бизнеса (читай, админа), который не настроил бэкапы, тут я не оправдываю. Хотя, конечно, хостинг доверие потерял и часть данных гарантированно вылетели в трубу — за это тоже нужно давать хорошую плюшку.
P.P.S. Если упал какой-то важный сервис по ошибке Яндекса, то, на мой взгляд, Яндекс должен возместить ущерб такого падения. И дать шоколадку сверху.
Хотите участвовать — берите неделю отгула / отпуска — один день до, два дня на хакатон, четыре дня на выспаться. И будет счастье. Если работа на неделе — нет, не выйдет.
Ах да. Важно. Не юзайте энергетики. Они блокируют на некоторое время нейромедиаторы, которые потом все равно дадут о себе знать. Шарахнет усталостью еще сильнее, чем раньше.
Много красивого текста, но по факту никакой полезной информации.
В случае, если автору хотелось рассказать про архитектуру, следовало бы просто прочитать литературу на это счет. Из признанного и успешно работающего: Мартин (Чистая архитектура и чистый код), Вигерс (разработка требований к программному обеспечению), Басс (архитектура программного обеспечения на практике), O'Reilly.
Кроме того, можно было бы взять другие источники по разработке: прочитать про DDD и другие подходы к проектированию. Помимо этого, нужно знать о том, как проектируется MVP и чем прототип отличается от MVP.
php -f index.phpгде он ругнется на неверный синтаксис и бросит (сразу) error, то для python мы это увидим когда непосредственно столкнемся, что может произойти далеко не сразу (знатоки питона, если это не правда — поправляйте). Однако, и правда, все это происходит в рантайме.Это дело решается тестами, но, поверьте, тесты не всегда хорошие и не всегда имеют 100% покрытия.
Смотрите. Кирилл говорит о том, что реализация на языке Python приводит к проблемам, которые будут найдены непосредственно в рантайме, что недопустимо. Что можно избежать в PHP использовав принципы того же Мартина — ISP + DI с использованием встроенных средств языка, а не внимательности разработчика. Кроме того, он апелирует к тому, что мы перестаем хардкодить и начинаем работать с абстракциями.
Суть комментария в том, что не важно, является ли ключевое слово вредным или нет: такое решение в языках есть и с ним мы живем. Если в Python реализовали множественное наследование через пень-колоду (к слову, сам автор в комментариях согласен с тем, что интерфейсы нужны), не дали нормального способа создавать абстрактные классы и методы, а в PHP это сделать реально, пусть и с использованием «вредного» interface (к слову, я не вижу дублирования кода в данном контексте, хотя если судить по Мартину оно здесь должно быть) — я выберу более безопасный, а как следствие, подходящий инструмент, который меня защитит от этого.
Кроме того. Мартин аппелирует к Eiffel, который решил проблему множественного наследования. Каким образом он это сделал? Мы можем указать, какие методы родительского класса мы наследуем. То есть потенциально доступна ситуация, когда родительский класс имеет какой-то метод, а дочерний — не имеет. Для меня такая ситуация является недопустимой и именно для этого принципиально и нужны интерфейсы. Это контракт, который гарантирует мне работу и ошибки компиляции.
P.S. Я не спорю с самой статьей и идеей. Если бы решилась проблема множественного наследования, принципиально у нас бы было всего два инструмента: класс и интерфейс, а абстрактный класс был бы не нужен, так как его функции перенял бы интерфейс. Ну или наоборот.
Там говорилось об одном важном пункте композиция вместо наследования.
Рекомендую почитать аргументацию, она развенчивает все мифы, указанные по вашей ссылке и дает понимание, когда использовать то или другое.
К тому же я хочу обратить ваше внимание на наличие частичного наследования в PHP, реализованного в виде трейтов.
P.S. Строка выше относится к тому, что оригинальная статья опирается на синтаксис языка Java, которая не позволяет использовать множественное наследование. Кроме того, рекомендую прочитать википедию по поводу множественного наследования и убедиться, что оно далеко не так «красиво», как его изображают в вашем материале.
Прошу вас, пообщайтесь с разработчиками. Данная проблема стоит, пусть и не очень остро, но url играет крайне важную роль, как для SEO, так и для специалистов по маркетингу. А вы заменяете его набором непонятных для пользователя символов.
Русскоязычные домены — довольно частое требование бизнеса. У меня на поддержке есть четыре таких сайта.
Использование репозитория просто как абстракции над хранилищем зачастую не имеет смысла в продуктах до определенного размера. Тут проблема в том, что любое изменение бизнес-условий в продукте чуть выше размером, чем домашняя CRUD страничка, вызовет мучительные боли чуть пониже спины, потому что эти изменения коснутся каждого файла проекта, где подобные операции используются.
К примеру, буквально вчера в большой лигаси-системе я зарелизил небольшой блок, который касался добавления нового типа сущности. Проблема в том, что этот тип сущности требовалось получить из внешнего источника, отличного от базы данных. Кроме того, его нужно было зарегистрировать во всех элементах сайта, где он может потенциально использоваться. Итого, мне пришлось изменить что-то в районе 80 файлов на стороне сервера, чтобы добавить тривиальную функцию. А это непаханое поле ошибок и потенциальных багов, которые необходимо еще отлавливать.
Используй разработчик паттерн репозиторий, да и в целом, поддерживай он исходники в более качественном состоянии, подмена кода была бы не такой страшной и менять пришлось бы не более 10-15 файлов.
То есть выбирая инструмент, а я пропагандирую отказ от AR в пользу более очевидного, но имеющего больший порог входа репозитория и сущности, как коллекции — объектного представления структуры данных, необходимо понимать и представлять не только то, что будет сейчас, но и загадывать на перспективу. Ибо, как сказал небезызвестный в узких кругах широких масс, некий М. Фраулер, чистая архитектура это такая архитектура, изменения в которую вносятся максимально просто.
Суть репозитория не только в том, чтобы было легко подменять источник получения данных, а в том, чтобы в принципе было удобно подменять логику работы с хранилищем. К примеру, у вас были в приложении новости, которые возвращались в десятке контроллеров. Приходит бизнес и просит вас добавить к этим постам параметр видимость. У вас несколько решений: если вы не использовали репозиторий, вы будете писать скоуп для модели, ползти в те места (если вы их помните, а в командной разработке это не факт), где это работать не должно, например, в админке, править это безобразие. В случае же с репозиторием, вы подменяете в одном из методов реализацию выборки добавлением этого скоупа, не добавляя ее в выборку для админки или сбрасываете ее.
Резюмируя. Если вы хотите сделать быстро, проверить гипотезы, не планируете вносить большие изменения от слова совсем — используйте Eloquent as is — это крутейший инструмент, значительно ускоряющий процесс разработки продукта. Но если вы делаете проект для заказчика, в условиях изменяющихся бизнес-требований, с учетом необходимости длительной поддержки сервиса, не поленитесь, пишите репозитории: они окупятся. И дело даже не в смене базы данных, а в целом, в простоте поддержки продукта на разных этапах его существования.