Могу даже видео ответ дать на вопрос "зачем" :) Отвечал не я. Так совпало, что в начале года прошла пара "php линчей" (код ревью). В т.ч. и Yii3 и отвечая на вопросы автор канала (Валентин Удальцов - думаю большой шанс, что кто погружен в php знает его. Он например в прошлом году конфу по php собрал) затронул и этот момент.
Так что вот ответ (с привязкой ко времени). на Вк и на youtube
Специально для задающих такой вопрос в доке статью написал :)
Если коротко. По работе естественно я использую готовые решения: битркис, ларавел и симфони. Но и на проектах где я лишь наемный разработчик и на своем проекте, который монетизирован: сроки, планы, какие то цели и все это диктуется во многом "что хотят пользователи еще вчера". А тут:
1. По фану - мне это интересно
2. Эксперименты. На пример: я примерно знал как работает автовайринг и контейнеры зависимости на их основе, но ни когда не делал да и делать может и не понадобиться, но интересно сделать самому, проникнуть какие проблемы возникают при этом и т.п. Что то из опробованного теперь применяю в рабочих проектах.
3. прокачать свои навыки.
Что значит "переписывание"?
Любая разработка ведется всегда с учетом своего опыта. И если приходилось работать с готовыми решениями на реальных проектах вполне естественно, что при создании своего аналога будешь принимать похожие решения из тех, что понравились и были удобны, и реализовывать "иначе", то, что показалось не удобным.
При этом в код лары, симфони и доктрины я ни разу не заглядывал, а вот в Битрикс много в ядре копался (но там как раз таки много не стандартного, и очень хорошо, что они стали двигаться в направлении более похожим на лару исимфони). Таким образом надо понимать: пользоваться той же ларой не значит знать ее код, т.ке. реализацию все равно надо придумывать.
О каком разочаровании речь? Если речь о моей CMS, так не было ни какого разочарования. Было разумное решение - освободить время на разработку более сложных частей, а не тратить на написание и поддержку велосипедов, которых есть на выбор и протестированных. Т.е. этот фреймворк тоже я на рабочих проектах даже не собираюсь использовать. У него совершенно другая цель. (Хотя тут есть вариант, что придется на одном проекте его внедрить, он по сути даже уже готов для той задачи, но там некоторые юридические/бюрократические процедуры нужно провести - совсем этим не хочется заниматься. Надеюсь не понадобится.) Поверь задач сложных и интересных выше крыши и без написания фреймоврков и они в большинстве своем именно из разряда "такого ни у кого нет".
В общем цель это просто попробовать то, что интересно. И потом на нем будет несколько небольших проектиков (один с монетизацией SaaS, и несколько чисто моих внутренних инструментов).
Пока нет. (Я б написал в отчетах, т.к. это пойдет отдельным модулем). На данный момент я пока только план разработки составил, (как показала практика: у меня мысль движется в направлении создания полноценного универсального веб фреймворка, а потому углубляюсь в задачи, которые обычному статейном сайту или форуму не нужны), пока планирую такой план.
На первом этапе будет сервис (оговорюсь: в понимании фреймворка) отвечающий за взаимодействие с любой БД (по сути "прокладка"), для нее сделаю по сути обертку над PDO, с удобным для дальнейшего расширения интерфейсом. ну и инструмент для миграций.
Далее пойду до реализации форума.
А потом уже вернусь к созданию билдера запросов и, возможно, ОРМ. Потому что задача сама по себе (если делать полноценно - что действительно интересно) достаточно объемная, т.к., для примера, нужна и поддержка разных диалектов SQL.
Т.е. в конечном итоге подразумевается наличие возможности работы с БД, без всяких квери билдеров и ОРМ, но все же через функционал фреймворка. (что полезно для проектов где важно максимальное быстродействие, да и поддержки какихто уникальных возможностей конкретной СУБД), квери билдер позволяющий работать с БД через построение запросов, но без необходимости знать какая БД подключена. Ну и ОРМ это уже другой уровень абстракции, пока не уверен.
В общем сел проектировать, посмотрел на различия диалектов нужных мне БД. И решил разбить на этапы. Все же задача сама по себе интересная и не хочется ее ваять на скорую руку.
Все гуд, наконец то присоединился, но хотелось бы, чтоб в видео не было перевирания моих мыслей (как ты сказал в первом видео). Я не говорил, что написать фреймворк это легко, и даже наоборот: хороший фреймворк это сложно. Моей мыслью было, что в том виде, как я увидел твой - это не сложно, т.к. он очень упрощенный. Еще раз попрошу: читай внимательнее, особенно если делаешь отсылки. Т.к. сейчас в первом видео информация о моих мыслях сильно искажена. Да и, как я понимаю, цели моей ты так и не понял. Я правильно понял, что думаешь, что моя цель "доказать"?
По поводу второго видео с генерацийей. Моделька явно не изучила твой фреймворк. Она просто тебе написала болванку. Попробуй SourceCraft возможно хватит подарочных стартовых нейрокредитов (там когда я подключился было 4000), возможно хватит. И поставь задачу первым этапом проанализировать фреймворк, а и далее точнее поставить задачу. Ты же, как я понял, даже не указал, что надо сделать это компонентом с использованием твоего фреймворка, или подходов используемых в твоем фреймворке. А так видно, что ИИ тебе сделал шаблон, но шаблон не в пониманиии твоего проекта, а просто заготовку для дальнейшей работы
Абстрагируясь от конкретики. У каждого своя оценка серьезности, крутости, масштабности. Формально это был портал. Не зависимо от того как я отношусь к коду автора, частично он даже судя по вебархиву был самоописом, и реализовать он мог точно. Т.е это даже не имея достоверных данных можно сказать уверенно.
Это я не сопора для, а справедливости ради.
