Decadal, К сожалению автору вопроса эта информация поможет лишь сформировать урывочное и вряд-ли верное представление о теме вопроса, и ложное ощущение что он что-то понял. Впрочем... Как и любая другая информация собранная по крупицам со всяких статей а интернете и сомнительных источников типа хабра и тостера.
Другое дело, что если бы dezzcore действительно хотел разобраться в вопросе приложил бы хоть немного усилий вместо того чтобы лезть на Тостер с глупыми вопросами
Decadal, мм. А как сущности связаны с таблицами с БД? Почему стоит их делать такими же?
Что если у меня две базы и в них они по разному хранятся? Что если в моделях на чтение и запись у меня по разному продукты выглядят?
И ещё, раз сущности зависят от базы, вы не ответили на изначальный вопрос - вот я нормализую базу мне title и description в одну таблицу ложить или несколько?
Проводя нормализацию таблиц, вы проектируете почти полностью подходящие для вас сущности.
Ммм. Вот есть у меня сущность продукт, как мне нормализация поможет понять, ProductTitle и ProductDescription я должен использовать, или запихнуть их в одну сущность Product?
Гляньте пару курсов по Ларавелю на laracasts и можно смело на собеседование )
Будет круто если вы вместо баззвордов почитаете Макконнелла или Боба Мартина, и хоть чуть чуть вникнете что такое качество программы и в чем оно выражается. Шансы попасть на место получше сильно повысятся, хотя это не быстро, я понял что нужно читать книги только когда начал работоть ( кроме книжки по PHP Котерова, которую давно освоил)
Вообще, я примерно с такими же навыками, только чутка подучив Laravel(прошел курс Laravel 5.4 from scratch и building For with Laravel and tdd) работу джуном прошлым летом нашел абсолютно без проблем, дело было в Москве
Decadal, Костыли?)
А писать MVC/*любой другой баззворд* не понимая что это такое не костыли?
Если вы считаете что гнаться за мифическим MVC(которым почти никто не интересуется дальше статей на хабре от школьников) важнее чем задумываться о качестве архитектуры и о том в чем оно измеряется - ок. Не мне вас переубеждать.
p.s. Я бы лично автору посоветовал задуматься лишь о том, как это сделать чтобы избежать каскадных изменений и смешивания в одном методе логики которую можно разделить, т.е. не выносить логику в одно место если она может меняться не вместе, не ложить её в разные места если она изменяется всегда вместе, и смотреть чтобы она не оказалась в том же месте, где просходит обработка запроса или связанная с этим логика, при необходимости выделять новые классы, и не задумываться о том к какому слою они относятся.
Разделение на слои нужно исключительно чтобы учитывать направление зависимостей. Без этого оно не имеет смысла.
Decadal, Сначала новички поначитаются всягой фигни на Хабре и тостере про MVC а потом вместо того чтобы думать о зависимостях и связности задают вопросы аля "где бы миграции впихнуть, в контроллер или модель?".
MVC не сообщает подробностей, что, где и что именно рендерит
А я считаю что сообщает, где будем правду искать?)
Decadal, 1. Какие проблемы решает MVC? Много людей это понимает, или просто делают единственное что умеют? Почему не MVVM?
2. По MVC вьюха сама себя отрисовывает и асинхронно кидает ивенты контроллеру, готовый преобразует их в синхронные вызовы модели, на изменения которой подписана вьюха, где вы в пхп такое видели, который по сути тупо на реквесты отвечает?)
cza10, Как будуте более уверены в своих силах, возьмитесь за какой-нибудь проектик для себя, выложите на гитхаб, развивайте. И направления для развития появятся, и резюме )
Многие советуют в чужие open source контрибьютить, но мне кажется вкатиться не так просто.
Я вот как пет проектик начал делать простенький интернет магазин, с упором на красивый код и архитектуру на бэкенде(я backend разработчик), чтобы подтянуть фронт начал пилить понемногу фронт для него в виде SPA на реакте
кажется, что в процессе работы все это крепче усваивается.
Первые месяцы-годик очень продуктивны, да, сейчас мне кажется что если надумаю менять работу с месяцок просто посижу дома занимаясь самообразованием как в студенчестве, т.к. накопилось очень много всего интересного.
А когда ещё не было опыта работы вообще не знал куда развиваться.
doppelgangerz, Объектно-ориентированный дизайн и ООП это разные вещи.
Наследование - вообще к ООП не относится, и его лучше избегать, но ладно )
Ответ на ваш вопрос я ниже описал
Отталкивайтесь от того, насколько вам важно хорошо выполнить это тестовое )
Проверяют то по хорошему программисты, они же дают фидбек. И получать фидбек от сильных программистов это круто.
Я обычно делаю ровно то что сказано оставляя,
скажем так, точки для расширения, т.е. красивую архитектуру не строю, но и в одну функцию не складываю.
Выкладывая на гитхаб, в readme обычно прописываю что бы улучшил на реальном продукте, и какие упрощения принял в тестовом, никто пока не жаловался (хотя я пару раз тестовое то делал).
А вообще, если не какая-то выдающаяся компания, и есть репозитории с вашим кодом в открытом доступе, можно рекрутеров с чистой совестью в них и отсылать