Dave

А мы то откуда знаем, с начальством разговаривай. Вообще непонятно почему сюда жаловаться полез, а не к руководителю.

з.ы. Скажут тут что нет, руководству скажешь что не будешь делать контент т.к. в интернете кто-то сказал что тебе не нужно этим заниматься?

Напомню всем, что сейчас банки сливают всю инфу в налоговую и любой налоговик может посмотреть историю ваших транзакций за любой период.

Тостер в текущем состоянии - это, в первую очередь, развлекательный ресурс типа баша, только не с цитатами, а со смешными вопросами.
С нормальным stackowerflow ЦА практически не пересекается, а русский не нужен - все вменяемые специалисты сидят на английском.

Обычное тестовое задание. Выполняйте и не ленитесь.

MVC не серебрянная пуля. Фреймворк не обязан реализовывать MVC.

Фреймворк это набор набор базовых компонентов, для избавления от написания в сотый раз одного и того же кода. Вы можете использовать любой фреймворк, или не пользоваться ими совсем. Главное не переборщите с ними. А то многие нынешние программисты, не могут и обычную авторизацию без любимого фреймворка реализовать.

Создай CV на brainstorage и hh и жди приглашений на собеседования.

Вы не правильно себя позиционируете. Дело в том, что для "великого и могучег" чаще всего в этих странах специалистов валом. А с учетом последних событий такие потребности скорее всего еще больше сократятся.

А вот конкурировать местными спецами по знаниям в других языках вы не можете. Так что я бы советывал делать упор на иностранный язык (Английский, французский) и параллельно искать работу на местных биржах, а не в специализированных "только для русских". На таких сайтах чаще всего имеется кидалово. Самое безобидное - неудобный договор, с отчислением части денег за посредничество и (как потом может оказаться) несколько далекой от первоначальной темы обсуждения.

Та же самая проблема. Удаление учётной записи на Хабре сделано, в прямом смысле, через жопу.

Что значит аналоги MVC? Есть модификации MVC типа MVVM или MVP (по сути, примерно то же), есть 3-tier архитектура (но вряд ли вы захотите ее делать на PHP).

Я осваивал MVC на примере CakePHP (хотя сам фреймворк мне не нравится, он тупой, но как учебный пример годится). Просто прочтите прилагаемый к нему мануал, где приведен пример, как сделать блог с использованием подхода MVC.

Паттерны вам пока не нужны. Все паттерны описаны в какой-то книге Мартина Фаулера (вот список: martinfowler.com/eaaCatalog/, там есть перевод на русский, но он плохой ), но, чтобы их понять, надо сначала иметь определенный опыт написания кода и разбора чужого кода. Если его у вас нет, для вас эти паттерны будут чем-то чужеродным и непонятным (много умных слов, а зачем это нужно, если можно по-простому написать).

Если вас (вдруг) интересуют паттерны, чтобы писать более аккуратный, качественный, профессиональный и поддерживаемый код, тут лучше руководствоваться общепризнанными принципами:

— DRY (не повторяйся) — не должно быть повторяющихся кусков в коде длинее нескольких строк, не должно быть генерации кода путем копипасты и правки, какие-то данные (к примеру, список стран) должны храниться только в 1 месте, а не в нескольких. Следование этому принципу улучшает архитектуру кода, упрощает поддержку.

— KISS (делай как можно проще) — выбирай самый простой способ реализации, если есть несколько вариантов, и если это не грозит проблемами в будущем.

— не ориентируйся и не используй фичи из PHP4. Он умер.

— не полагайся только на HTML5/CSS3. Еще не у всех есть айпады с маками, и живы ИЕ8, ИЕ7 и ИЕ6.

— пиши свой код, так, как будто после тебя его будет поддерживать псих-маньяк, который знает, где ты живешь. То есть, не пиши такие вещи, которые трудно/невозможно понять другому человеку. Думай о том, кто будет читать твой код. Изредка в сложных местах ставь комментарии. Не раскидывай логику выполнения действия по 10 файлам. Не делай файлы больше 500-1000 строк.

— давай правильные названия классам, функциям, константам и переменным. Не используй транслит ($chisloPokupatelei). Не знаешь английский — вооружись Яндекс.Словарями/Гуглотранслейтом. Выбери и следуй стандарту кодирования (рекомендую Zend Coding Standard).

— код на функциях можно легко превратить в ООП-код путем превращения функций в статические методы и объединения в классы.

если бы вы были заказчик и пришли к нам с этим и чемоданом денег, то всё равно были бы посланы.

составь грамотное. подробное тз и разработчики сами потянутся. попроси у тестировщика протестировать карандашь и ты поймёшь насколько у тебя сыра идея, а ведь даже хорошие игры гибли из-за мелких недочётов и отсутствия баланса.