Стоит ли писать свой php-фреймворк с целью улучшения знаний в области ООП и изучения шаблона MVC?

В общем-то в заголовке поста все сказано :)

Чем обусловлен вопрос?

С детства интересуюсь программированием (вернее сначала это была простая HTML страничка с фото с бананами, картинками прямо в тексте, которые сбивали весь формат и т.д. :)). Сейчас изучаю HTML, CSS, JS (а с ним и jQuery), PHP (да и вообще много чего еще, но перечислил только технологии, связанные с вопросом). В данном вопросе речь пойдет о PHP. Я считаю, что знаю я его на некотором уровне — чуть выше плинтуса. Конечно же это относительный показатель, но по-крайней мере, теперь, читая вопросы на stackoverflow.com на эти темы, некоторые из них вызывают у меня улыбку (а если тема вопроса непонимание как сравнить 2 значения переменных и подписано в CodeIgniter или Zend Framework, то ржач), а не мои вопросы вызывают улыбку у кого-то.

Есть несколько проектов созданных мной (вернее это серия сайтов, со схожей тематикой, схожей целевой аудиторией) — это не огромные порталы, а простые сайты, с небольшой посещаемостью (опять же — очень целевая аудитория), но задачу они свою выполняют. Сайты созданы с использованием чистого PHP. Движок написан с нуля (не фреймворк, не CMS) мной.

Сейчас приходится поддерживать эти проекты и часто сталкиваюсь с тем, что все как-то не очень удобно. Речь о том, что все обработки, SQL-запросы, выводы на экран, логика — все в одной куче. Хотелось бы разделить это все как-то. Тут подходим к сути.

Как раз для этого и были созданы фреймворки — для того, чтобы облегчить жизнь программисту (встроенные функции, модули, плагины фреймворка) + для того, чтобы отделить вывод на экран от логики и от работы с базой данных. Правильно? Правильно.

Я считаю, что для того, чтобы что-то понимать нужно самому это сделать, а потом еще и научить кого-то тому, что ты сам понял. Я подумываю о том, чтобы создать самому что-то подобное (нет, никто не собирается спорить с Zend или Yii, боже упаси): во-первых, для изучения подхода MVC; во-вторых, расширить знания в области ООП; в-третьих, получить какой-то опыт. Создать такой фреймворк и, например, написать на нем портфолио (ведь пора бы уже).

Вот и вопрос: стоит ли создавать свой велосипед или "просто" "тупо" взять какое-то готовое решение и разбираться с ним?

Хочу услышать ваше мнение и, может быть, ваши зубодробительные истории из детства с HTML страничками :)

P.S.: надеюсь, не уснули, пока читали :)
P.P.S.: постарался преподнести вопрос не "чисто холиварным"
  • Вопрос задан
  • 6297 просмотров
Пригласить эксперта
Ответы на вопрос 5
@romeo7
Читая Ваш вопрос,вспомнил себя 5-ей летней давности:) На тот момент мой бэкграунд состоял из дюжины сайтов на различных CMS и одного стартапа,который ясное дело не взлетел. Я к тому моменту долго вынашивал план по реабилитации одного замороженного проекта (спортивный портал),который разрабатывал со своими товарищами ещё в студенческие годы. Изначально задачи написать свой движок не было,но... всё началось с разработки шаблонизатора с синтаксисом а-ля CMS MODx. Много читал о том,что данная реализация выделяется на фоне остальных конкурентов,по сути являясь визитной карточкой последней. На поверку оказалось, что это всего навсего синтаксическая абстракция над Smarty,со всеми вытекающими по производительности. К примеру,моя реализация имеет альтернативную поддержку нативного php-шаблонизатора
<?=$this->getSnippet('List', $params)?>
для тех, кто терпеть не может синтаксические абстракции (Smarty, Twing, Fenom и иже с ними.) из-за их низкой производительности и иным религиозным соображениям.
Шло время, кодовая база росла. От паттерна Singleton до DI (Dependency Injection), к Service Locator-у. Много чего выпилено в угоду существующих решений. За последние 2 года,не без помощи Composer,стало в разы больше готовых решений,причём несколько на реализацию конкретно задачи. К примеру,из последнего - был заменён собственный файловый менеджер (манипуляция с файловой системой) на библиотеку Flysystem, ибо последняя помимо всего прочего, умеет "бегать" в облака. Круто же ;) Единственное,в моей реализации была возможность поиска по regexp-паттерну,пришлось писать абстракцию.

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

Вот сходу антипример. Достаточно популярная библиотека для валидации данных Respect Validation. Требовалось реализовать интернационализацию сообщений, не было возможности вывести иерархию выброшенных во время валидации ошибок одним большим массивом,а также хотелось вернуть,к примеру,только первую ошибку (first) или последнюю (last). Пришлось форкнуть,ибо абстрагироваться попросту невозможно.

Совет: Иногда сталкиваешься с тем, что не все возможности какой-либо библиотеки задокументированы,даже если она достаточно популярна и имеет свой красивый "твиттеробутстраповый" сайт. Загляните в unit-тесты,возможно,откроете для себя что-то новое;)

Если всё же надумаете писать свой фреймворк,то опирайтесь на существующие решения. Выберите для себя один-два популярных фреймворка и изучите,как реализован в них тот или иной функционал,хотя бы визуально,благо документации навалом. Начните с модели MVC. Посмотрите как реализованы actions,а именно доступ к ним,фильтрация на входе и выходе в action. Я,к примеру,не сторонник реализации псевдо-аннотаций,как в Symfony,ибо в PHP поддержки нативных аннотаций пока нет,а всё остальное - это жалкое подобие через медленные Reflections,даже если всё это кэшируется. Вот и автор АОП парадигмы для PHP всё это понимает, но всё равно продолжает разрабатывать свой проект Go!. Реализация конечно интересная,но я обойдусь событийной моделью (Observer или PubSub).
Взгляните как устроен роутинг, ибо это основополагающая для реализации SOAP и REST. К примеру,моё решение испытало влияние Lavarel Routing по части использования групп. Нынче в силу распространённости мобильных платформ всё чаще используется REST не только на основе url-а,но и на основе кастомных заголовков (X-<имя прагмы>).
Обратите внимания на то,как осуществляется обработка ошибок/exceptions. К примеру,Yii давно ругают на то,что нет возможности верной идентификации того или иного исключения. Лучше для каждой отдельной задачи (к примеру, FileManager) свой класс Exception,который наследуется от базового:
class Exception extends BaseException
{
    const FILE_EXISTS = 'File exists: {path}';

    public function __construct(
        $level = self::ERROR,
        $msg = null,
        array $dataReplace = null,
        \Exception $handler = null
    ) {
        return parent::__construct($level, $msg, $dataReplace, $handler);
    }
}

Тогда в базовом классе BaseException можно легко реализовать логирование (к примеру, воспользоваться Monolog) и красивую визуальную выдачу в режиме дебага (к примеру, Whoops).
Желательно сразу избавить себя от привычки делать "жирные" контроллеры/actions. В этом может Вам помочь различные реализации валидации,фильтрации данных,а также задания дефолтовых значение на уровне модели. Обратите внимание на метод rules. Тогда в Вашем контроллере будет лишь метод отправки уже обработанных данных на вьюху.
Что касается ORM и DBAL (синонимы: DAO и Query Builder), то в этом случае уж точно не стоит изобретать свой "велосипед". Написать по возможности единый интерфейс для различных реляционных и нереляционных решений (СУБД, Систем полнотекстового поиска/индексаторов (Sphinx, Elasticsearch)) - более чем нетривиальная задача. Я в своём фреймворке взял за основу AR (ORM) и Query Builder Yii2. Да,в Yii отсутствует модульность,а потому всё достаточно зависимо друг от друга,но если захотеть, то можно.
Чувствуете этот момент. Вы препарируете почти готовое (прим. Yii2 еще в состоянии беты),одно из самых выдающихся на текущий момент решений и тем самым разбираетесь во всех тонкостях, попутно проявляете активность в исправлении ошибок.
Научитесь писать unit тесты. Множество ошибок всплывут на поверхности,да и сон Ваш тогда будет более крепким.
Вы наверно могли для себя заметить на том же stackoverflow или иных ресурсах, задаются достаточно тривиальные вопросы по фреймворкам. Вот и сейчас пока пишу Вам этот большущий ответ,в разделе "Похожие вопросы" красуется такой вопрос "Как реализовать правильно авторизацию с сессиями ... Отсутствует элементарная дисциплина к самостоятельности. И я даже догадываюсь почему так. Фреймворков стало больше,фреймворки стали лучше. Programmer Frendly,а не страшный зверь для избранных,как было когда-то. Правда,некоторые и по сей день недружелюбно скалятся;) Так или иначе,если есть желание задать вопрос из серии каким образом в JQuery сравнить две переменные,то стоит задуматься,а надо ли тебе всё это.
Не в коем случае не нужно уверять себя в том,что Ваш инструмент взлетит. Он не уникален,и в конечном счёте скорее всего будет состоять из множества готовых библиотек (прим. в моём случае 60 против 40% вендорного кода. Если учитывать значимость,то в этом случае, уже счёт будет не в мою пользу). К сожалению, не могу найти ссылку на англоязычную статью, где автор сетует на полный отказ от фреймворков в пользу packagist. Даже если в уникальности вашего решения нет сомнения,это ничего Вам не гарантирует. Необходимо грамотное продвижение - множество статей на тематические ресурсах,а также участие в конференциях. К примеру, PHPDaemon хоть и стартовал первым, но пока вчистую проигрывает ReactPHP, а всего-навсего необходимо было уделить внимание написанию документации. Автор PHPDaemon, Василий Зорин,как-то на вопрос чем отчается его проект от React,указал на то,что последний использует его идеи. Конечно печально за нашего соотечественника,но его проект попахивает откровенным эгоизмом.
Делайте Ваш инструмент прежде всего для себя,и возможно,когда-нибудь он станет интересен кому-то ещё. Так или иначе,Вы получите бесценный опыт. Главное,постараться довести это дело до конца. Отличительной чертой нашей ремесленной профессии является терпение. Вот Вам и проверка этого замечательного человеческого качества:) Кстати,чтобы интерес не угас,стоит свои наработки применять,если не в продакшене,то хотя бы небольшой проект для экспериментов.
Заметил за собой,что пока занимался разработкой инструмента,гораздо больше получил опыта,чем на предыдущих двух работах. Но это субъективно. Можно с самого начала устроится в такое место,где замечательный отзывчивый коллектив и не менее интересные проекты/стартап, а не "натяни шаблон на Wordpress". Считаю,что пусть CMS-сника - это путь в никуда, и Кипелов здесь не причём:) Чем раньше, тем раньше;)
Мне, как и sWinDos тоже забавно смотреть на свои исходники годичной давности:)) Вам знакомо такое понятие,как "Тезаурус"? В трактовке теории информации,это экспоненциальный рост знаний/опыта до какого-то предела, после которого, эффективность полученных знаний/опыта заметно падает. Получается этакая кривая Гаусса или что-то вроде жизненного цикла знаний/опыта в отдельно взятой предметной области.

Совет: Запомните,Ваши проекты на github-е и контрибьюторская активность - это твёрдое, незыблемое портфолио. На собеседовании в большинстве компаний вы вправе выбрать свой сценарий поведения и темы для бесед.

P.S. Я специально не стал затрагивать моральную и финансовую сторону вопроса. Opensource или заработок? Вечные поиски свободного времени между семьёй,работой и отдыхом. Смотрю здесь уже кто-то отметился:) Если Вы ещё студент и не обременены чем-либо,то дерзайте. Вполне возможно уже по окончанию университета или даже раньше, Вы выйдите уверенным таким коренастым мидлом:) К слову,в первой организации, с которой я начал свой профессиональный путь проповедовали процедурное программирование,ибо ООП никем не понималось должным образом.
Ответ написан
svd71
@svd71
вы, видно, пока писали маоло думали.
1. Если ставить цель заработать на этом денег, то это довольно хреновое средство заработка: "шедевр" создать вряд ли получится, если кто то и рискнет использовать, кто будет поддерживать? Для конечного клиента, корому это все нужно для зарабатывания денег совсем не нужен интерес ковырять код или искать причину взлома. Он постарается найти специалистов и продук пропорционально сумме, которую он готов платить. Поэтому тогда уж лучше напрячь усилия в сторону какого-то конкретного продукта, который конкурентно проталкивают другие люди. Или же самому конкурентно проталкивать. Но на двух стульях сидеть обычно седалища не хватает.

2. Если все таки чтоб "понять, как она все таки вертится", то конечно неплохое решение. Но гораздо более доходным был бы точно так же ковыряться на каком либо oDEsk за деньги(пусть и не большие).

3. На одном языке (хотя php - это скриптовый язык) невозможно "расширить знания в области ООП". Нужно как минимум еще пару, торойку поковырять. Чтоб понимать достоинства и недостатки конструкций, различия и функциональность.
Ответ написан
Bandicoot
@Bandicoot
Backend Developer since 2015
Не стоит, лучше взять несколько популярных фреймворков и как следует их расковырять
Ответ написан
@sWinDos
Были такие же мысли лет 6 назад. И все-таки начал делать свой фреймворк работая с php всего около года на тот момент. До логического завершения дело не дошло, сделано было: работа с базой, обработка страниц, контроль доступа, что-то вроде медиатеки, пагинация и другие самые азы.
Сейчас посмотреть на свой код того времени без стыда и страха сложно, но в то время знания подтянулись прилично. Только времени у меня тогда было вагон.
Автор, если есть время на это, и его не жалко - то я бы посоветовал делать не то что бы фреймворк, а отдельные файлы-модули, для повседневных нужд. И со временем улучшать их.
Ответ написан
nazarpc
@nazarpc
Open Source enthusiast
Из своего опыта могу посоветовать поработать с чем-то готовым, и когда придет понимание, что и тут, и там что-то не устраивает, когда наберется достаточное количество аргументов в пользу написания своего - начинать писать, либо форкнуть существующий проект. Вы, наверное, сейчас не представляете себе на сколько это огромный кусок работы сделать фреймворк, который будет достаточно надежным, удобным, быстрым и расширяемым. Скорее всего это будет потеря большого количества времени. Если же вы сначала поработаете с готовым - будет понимание того, как проблемы решают другие, и появятся идеи как сделать лучше.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы