Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 177
Есть демо? Скиньте линк в личку
Используйте фреймворки. Это позволит вам сконцентрироваться на поставленных целях, не отвлекаясь на переделывание ненужного вам функционала.
Серебрянной пули в этом вопросе нет и, по видимому, не будет никогда.
Мне кажется, что все зависит от конкретной задачи:
1. CMS в случае, если не нужно множество специфичных функций, которые трудно реализуемы в ее рамках.
из плюсов — быстрота реализации, поддержка
из минусов — большая сложность тонкой кастомизации и настройки под конкретные задачи
2. Фреймворк + свой код как золотая середина
из плюсов — большая возможность кастомизации, уже готовое ядро (экономия времени), поддержка ядра
из минусов — большие трудо и время затраты по стравнению с вариантом выше
3. Полностью свой код в случае, если задача очень уникальна или не распространена (как правило это экстремальные нагрузки или количество данных с которыми работает проект)
Мне кажется, что все зависит от конкретной задачи:
1. CMS в случае, если не нужно множество специфичных функций, которые трудно реализуемы в ее рамках.
из плюсов — быстрота реализации, поддержка
из минусов — большая сложность тонкой кастомизации и настройки под конкретные задачи
2. Фреймворк + свой код как золотая середина
из плюсов — большая возможность кастомизации, уже готовое ядро (экономия времени), поддержка ядра
из минусов — большие трудо и время затраты по стравнению с вариантом выше
3. Полностью свой код в случае, если задача очень уникальна или не распространена (как правило это экстремальные нагрузки или количество данных с которыми работает проект)
использую второй вариант. минусы трудозатрат нивелируются тем, что за годы работы скапливаются горы готовых решений для типовых проектов.
Согласен — подобрать под себя фреймворк проще, чем CMS. Меньше ограничений, ничтожное количество переделок в самом фреймворке (которые чаще всего просто переносятся с предыдущего проекта заменой пары файлов). Скорость разработки возрастает в разы по сравнению с 3 вариантом, да и по сравнению с 1 вариантом при нестандартном проекте тоже может вырасти.
Чем фреймворк отличается от CMS (или движка)? Чтобы сделать простейший сайт на CMS, ее разворачиваешь за пару минут и вот тебе готовый базовый сайт.
А как это делается с использованием фреймворков? Правильно ли понимаю, что это уже готовые наборы функций и библиотек, из которых ты собираешь свой сайт? Т.е. в принципе мои коды в какой-то мере это даже больше не движок а именно мой самописный фреймворк?
Какой из них лучше использовать? В свое время попытался почитать про Zend, но было мало литературы на русском, а с английскими мануалами мое обучение еще в разы бы усложнилось и по срокам и по силам.
Не является ли сложность изучения фреймворка пропорциональной сложности доработки существующих движков? Ведь и там и там надо ковыряться, разбираться и изучать документацию?
А как это делается с использованием фреймворков? Правильно ли понимаю, что это уже готовые наборы функций и библиотек, из которых ты собираешь свой сайт? Т.е. в принципе мои коды в какой-то мере это даже больше не движок а именно мой самописный фреймворк?
Какой из них лучше использовать? В свое время попытался почитать про Zend, но было мало литературы на русском, а с английскими мануалами мое обучение еще в разы бы усложнилось и по срокам и по силам.
Не является ли сложность изучения фреймворка пропорциональной сложности доработки существующих движков? Ведь и там и там надо ковыряться, разбираться и изучать документацию?
Вы использовали jQuery в своих проектах?
Использую! Причем все больше и больше последнее время
Значит у вас есть опыт использования JavaScript фреймворка. В таком случае, можно представить, что представляют из себя PHP фреймворки.
Перечислю некоторые распространенные:
Yii framework, русскоязычное сообщество
Symfony2
Codeigniter
Kohana (форк Codeigniter), на русском
Конечно, для изучения все же желательно пустить в ход свое знание английского. Но для некоторых фреймворков есть множество информации и переведенная документация. Я привел известные мне ресурсы выше.
Сам нахожусь в начале пути изучения PHP фреймворков, хочется посмотреть на каждый и попробовать попрактиковаться.
Перечислю некоторые распространенные:
Yii framework, русскоязычное сообщество
Symfony2
Codeigniter
Kohana (форк Codeigniter), на русском
Конечно, для изучения все же желательно пустить в ход свое знание английского. Но для некоторых фреймворков есть множество информации и переведенная документация. Я привел известные мне ресурсы выше.
Сам нахожусь в начале пути изучения PHP фреймворков, хочется посмотреть на каждый и попробовать попрактиковаться.
Т.е. грубо говоря jQuery — это JavaScript фреймворк. Т.е. язык более высокого уровня.
Так же как jQuery по отношению к JS является фреймворком, так же, скажем Symphny по отношению к php является фреймворком??
Так же как jQuery по отношению к JS является фреймворком, так же, скажем Symphny по отношению к php является фреймворком??
Да, только не стоит путать Symfony и Symphony. Спутать можно с одной опенсорсной Symphony CMS и, на сколько мне известно, она не имеет отношения к фреймворкам.
Мое понимание фреймворков таково: сообщество опытных и серьезных программистов продумали многие часто возникающие в процессе создания сайтов задачи и предоставили удобные и крепкие инструменты для их решения. Эти инструменты достаточно безопасны, актуальны и не являются говнокодом. Их использование не ограничивает гибкости разработки, позволяет добиться её большей скорости.
Мое понимание фреймворков таково: сообщество опытных и серьезных программистов продумали многие часто возникающие в процессе создания сайтов задачи и предоставили удобные и крепкие инструменты для их решения. Эти инструменты достаточно безопасны, актуальны и не являются говнокодом. Их использование не ограничивает гибкости разработки, позволяет добиться её большей скорости.
Есть библиотеки и есть фреймворки. Под ваше понимание попадают оба понятия. Фреймворки это именно каркасы приложений, они, прежде всего, управляют потоком выполнения, инвертируют его с классического библиотечного подхода — не ваш код вызывает код библиотек, а код фреймворка вызывает ваш код.
Блин, надо браться за изучение какого-нибудь фреймворка. Теперь бы решить с чего начать. И желательно чтобы было развитое российское сообщенство с русскоязычной документацией.
Yii для начала, имхо, оптимален. Хотя сам предпочитаю symfony2.
а я бы посоветовал Kohana. Очень простая, на мой взгляд, для понимания.
Для ваших магазинов Yii в самый раз.
Я деля себя пока решил — как только мне потребуется фреймворк под PHP, значит время пришло, и пора изучать python и/или ruby. :)
PHP хорошо своей простотой.
PHP хорошо своей простотой.
С PHP-фреймворками не все так просто.
Неоднократно брался подобрать под себя фреймворк. Однако это довольно обширная область знаний, которая требует немалых затрат времени и усилий на освоение на дОлжном качестве, иначе не будет необходимого контроля над проектом. Когда ты программист-одиночка, то это может стать весьма нетривиальной задачей.
В результате я решил прекратить все эти метания, т.к. дело делать надо, а не метаться. К тому времени на голом PHP я программировал уже достаточно, чтобы собрать базовые грабли в непростом вопросе строительства веб-приложений.
До этого я много лет программировал бухгалтерские приложения на Clipper, а еще раньше это были поделки на Pascal 6.0 и 7.0, но это совершенно другая история.
Для меня одна из больных тем в фреймворках — это шаблонизация.
Не хочу порождать холиваров, это сугубо моё личное мнение, но лично я не выношу PHP-код замешанный внутри HTML. И, хотя, для PHP это изначальное и органичное поведение, у меня оно вызывает реакцию бурного отторжения. Достаточно давно я открыл для себя Smarty. Я искренне считаю, что он великолепен.
В своем «движе» я пошел путем полного разделения логики от представления. Т.е. контроллер и модель, буквально, ничего не знаю о представлении. Более того, легким движением руки ядро может переназначить обработчик представления, по необходимости.
Если в двух словах, то всю базовую работу делает ядро, тут я ничего нового не изобрел. А вот код контроллера-модели минимальный. Его задача — вернуть некий массив с параметрами — результатом своей работы.
Дальше, в зависимости от параметров, вызывается тот или иной обработчик выдачи. Одни и те же данные можно отдать хоть в шаблон, и это будет страница, хоть в конвертер JSON, и это будет уже, как правило, обработка AJAX-запроса.
В последней версии «движка» я пошел еще дальше. Текущий проект — богатое функционалом и гридами веб-приложение. Понадобился шаблонизиованный JS, во многом индивидуальный для каждой страницы.
Раньше я тупо вшивал это в
Файлы удобно лежат в логичной, продуманной и жесткой структуре, с жестким именованием (все равно неймспейсы к этому сейчас всех подводят уже). Все под рукой, все в ожидаемых и прогнозируемых местах.
ООП использую по минимуму, только там, где без него вовсе никак, либо в готовых библиотеках, тот же Smarty, например. Старая закалка в процедурном стиле сказывается, однако. Как я уже писал выше, надо делать дело, а процедурным инструментом я пользуюсь давно и владею, как мне кажется, неплохо, практически на уровне рефлексов. На ООП, к сожалению, рефлексов пока не выработалось.
Вот такая вот лирика.
Неоднократно брался подобрать под себя фреймворк. Однако это довольно обширная область знаний, которая требует немалых затрат времени и усилий на освоение на дОлжном качестве, иначе не будет необходимого контроля над проектом. Когда ты программист-одиночка, то это может стать весьма нетривиальной задачей.
В результате я решил прекратить все эти метания, т.к. дело делать надо, а не метаться. К тому времени на голом PHP я программировал уже достаточно, чтобы собрать базовые грабли в непростом вопросе строительства веб-приложений.
До этого я много лет программировал бухгалтерские приложения на Clipper, а еще раньше это были поделки на Pascal 6.0 и 7.0, но это совершенно другая история.
Для меня одна из больных тем в фреймворках — это шаблонизация.
Не хочу порождать холиваров, это сугубо моё личное мнение, но лично я не выношу PHP-код замешанный внутри HTML. И, хотя, для PHP это изначальное и органичное поведение, у меня оно вызывает реакцию бурного отторжения. Достаточно давно я открыл для себя Smarty. Я искренне считаю, что он великолепен.
В своем «движе» я пошел путем полного разделения логики от представления. Т.е. контроллер и модель, буквально, ничего не знаю о представлении. Более того, легким движением руки ядро может переназначить обработчик представления, по необходимости.
Если в двух словах, то всю базовую работу делает ядро, тут я ничего нового не изобрел. А вот код контроллера-модели минимальный. Его задача — вернуть некий массив с параметрами — результатом своей работы.
Дальше, в зависимости от параметров, вызывается тот или иной обработчик выдачи. Одни и те же данные можно отдать хоть в шаблон, и это будет страница, хоть в конвертер JSON, и это будет уже, как правило, обработка AJAX-запроса.
В последней версии «движка» я пошел еще дальше. Текущий проект — богатое функционалом и гридами веб-приложение. Понадобился шаблонизиованный JS, во многом индивидуальный для каждой страницы.
Раньше я тупо вшивал это в
<head>, либо выносил в публичный каталог /js/, но это оказалось неудобным. Потратив 10 минут времени я склонировал обработчик Smarty-шаблонов, пропатчил его, и теперь могу гибко обращаться к тому же адресу с одним дополнительным параметром, и страничка получит свой индивидуальный JS-код, отдельным файлом. Файлы удобно лежат в логичной, продуманной и жесткой структуре, с жестким именованием (все равно неймспейсы к этому сейчас всех подводят уже). Все под рукой, все в ожидаемых и прогнозируемых местах.
ООП использую по минимуму, только там, где без него вовсе никак, либо в готовых библиотеках, тот же Smarty, например. Старая закалка в процедурном стиле сказывается, однако. Как я уже писал выше, надо делать дело, а процедурным инструментом я пользуюсь давно и владею, как мне кажется, неплохо, практически на уровне рефлексов. На ООП, к сожалению, рефлексов пока не выработалось.
Вот такая вот лирика.
Был однажды опыт когда я решил сделать сайт с использованием шаблонизатора Smarty, т.к., честно признаться, страдаю тем, что мой код очень плохо отделен от представления. И в шаблонах часто можно встретить какой-нибудь php-цикл вывода менюешек, статей и пр.
Но понять всю красоту и удобство smarty я так и не смог. Может быть потому что у меня не было того, кто мог бы показать. Читал документацию и формы, сайт сделал, но намучился дай боже.
Но понять всю красоту и удобство smarty я так и не смог. Может быть потому что у меня не было того, кто мог бы показать. Читал документацию и формы, сайт сделал, но намучился дай боже.
Я вот хочу привести может немного дурацкий пример, но как мне кажется, показательный.
Допустим на сайте необходимо реализовать два вида заднего фона: ночной и дневной. В зависимости от текущего времени, скрипт определяет файл для бекграунда.
Сейчас у себя в кодах как я это реализую: пусть даже код отделен от шаблона, но как ни крути, когда скрипт определил время и выдал признак «день или ночь» и название файла, который нужно подставить в тег body, бекграундом, то в самом шаблоне же никуда уже не денешься от конструкции условия.
И хоть ты смарти используй, хоть чистый php куда деться от этой программистской условной конструкции (if), которая формирует фон сайта?
Или другой пример. Есть меню. Нужно подсветить активное в данный момент меню. Для этого снова нужно условие, которое определяет на какой странице в данный момент находимся и в зависимости от этого формирует стиль или класс конкретного пункта меню. А это опять конструкции сравнения, условный оператор и т.д. Без кода в шаблоне все-равно никуда не денешься!
Корзина покупок. Скрипт определи есть ли в корзине товар и выдал признак «есть/нет», а уже внутри шаблона условный оператор снова определяет какой стиль корзине подставить (картинку заполненной корзины или картинку пустой).
Есть сложнее примеры. Например выводим список товаров. Это уже код — оператор цикла в шаблоне. Между товарами какой-то разделитель, ну например обычная линия. После последнего товара линию выводить не нужно. Опять нужно писать код, который будет определять что товар последний и в зависимости от результата либо выводить, либо не выводить линию (знаю что некоторые такие моменты можно с помощью CSS3, но в данном случае этот пример просто очень показателен).
И таких нюансов много когда требуется большое вмешательство кода в шаблон. Или я что-то глобально не понимаю!
Допустим на сайте необходимо реализовать два вида заднего фона: ночной и дневной. В зависимости от текущего времени, скрипт определяет файл для бекграунда.
Сейчас у себя в кодах как я это реализую: пусть даже код отделен от шаблона, но как ни крути, когда скрипт определил время и выдал признак «день или ночь» и название файла, который нужно подставить в тег body, бекграундом, то в самом шаблоне же никуда уже не денешься от конструкции условия.
И хоть ты смарти используй, хоть чистый php куда деться от этой программистской условной конструкции (if), которая формирует фон сайта?
Или другой пример. Есть меню. Нужно подсветить активное в данный момент меню. Для этого снова нужно условие, которое определяет на какой странице в данный момент находимся и в зависимости от этого формирует стиль или класс конкретного пункта меню. А это опять конструкции сравнения, условный оператор и т.д. Без кода в шаблоне все-равно никуда не денешься!
Корзина покупок. Скрипт определи есть ли в корзине товар и выдал признак «есть/нет», а уже внутри шаблона условный оператор снова определяет какой стиль корзине подставить (картинку заполненной корзины или картинку пустой).
Есть сложнее примеры. Например выводим список товаров. Это уже код — оператор цикла в шаблоне. Между товарами какой-то разделитель, ну например обычная линия. После последнего товара линию выводить не нужно. Опять нужно писать код, который будет определять что товар последний и в зависимости от результата либо выводить, либо не выводить линию (знаю что некоторые такие моменты можно с помощью CSS3, но в данном случае этот пример просто очень показателен).
И таких нюансов много когда требуется большое вмешательство кода в шаблон. Или я что-то глобально не понимаю!
Весь трюк в Smarty не в том, чтобы уйти от PHP или, в более широком смысле, логики, в шаблонах, окончательно. От этого никуда не деться на самом деле. Но я, как разработчик, избавлен, от нечитаемого, лично для меня, PHP в шаблонах.
Так уж сложилось, что я, на уровне рефлексов, издавна, еще со времен Pascal, а потом и Clipper, привык к жестко структурированному коду. Смысл в этом был огромный, т.к. я писал бухгалтерские приложения, и количество кода, порой, доходило до 15 тысяч строк. Если в таком количестве кода не наводить дОлжный порядок, то развивать такой код становится затруднительно, даже если сам его писал от «А» до «Я». К слову сказать, несколько программ, написанных в 2004-2006 годах проработали без сбоев (кое-что и сегодня работает) вплоть до 2012 года, когда контора стала массово переходить на софт типа 1С.
И еще, PHP в шаблонах, не будучи структурированным, меня просто убивает. И да, я знаю, что многим другим программистам он там вполне комфортен. Я говорю только за себя.
Сам же Smarty компилирует шаблоны, превращая в самый обыкновенный PHP pазбавленный HTML/JS.
Т.е. Smarty — это дополнительный уровень абстракции. Таким образом имеется 2 уровня шаблонов. Первый — это абстракция, с которой я работаю как разработчик. Там прекрасно код Smarty отделен от остального HTML/JS, и позволяет гибко передавать данные и регулировать шаблонную логику, о которой контроллеру знать совершенно не обязательно. Smarty в шаблонах, на мой взгляд, куда как более читаем и лаконичен, органичен, я бы даже сказал. Второй уровень шаблонов — это фактический код, откомпилированный из первого, движком Smarty, и непосредственно исполняемый в системе.
И да, от условий и некоторой логики в шаблонах никуда не деться. Благо сейчас уже акценты бурно смещаются в сторону клиентской динамики, где море JS. Это совершенно отдельная песня. В моем случае, как я уже писал, где-то в этой ветке, индивидуальный JS так же шаблонизирован, что позволяет гибко вставлять куда надо управляющие конструкции. Получается своего рода мета-программирование, т.к. JS-код может гибко реагировать на некоторые условия, пришедшие как управляющий сигнал от контроллера.
Возвращаясь к логике в шаблонах — это другая логика, это логика шаблона. И к контроллеру она не имеет вообще никакого отношения. Поэтому, по моему глубочайшему убеждению, контроллеру совершенно не обязательно знать ту логику, которая касается исключительно шаблона.
Работал я недавно в связке с одним программистом, причем решения принимал я, в виду должностной инструкции и обязанностей, а он мне должен был помогать. Так вот, программист бурно не переносил вообще какую-либо логику в шаблонах, а, так же, инклюды, норовя вынести всю шаблонную логику в контроллер, там же подключая подшаблоны (порой с довольно сложной иерархией и зависимостями). В результате, открывая шаблон, я совершенно не мог понять, что там происходит. Откуда-то появились блоки с произвольным функционалом, никак не регламентированным самим шаблоном. В то же время код контроллера превратился в километры невнятных условий. Открывая такой контроллер я переставал понимать, чем он вообще занимается.
Например меню, которое касается только представления, генерилось у него в месте, совершенно никак логически не связанном с самим представлением, вплоть до вставки HTML-кусков в рамках контроллера. Это уже было слишком! Конечно эти безобразия я пресек на корню, по поводу чего было очень много стонов. Пресек категорически, т.к. время потраченное на поиски неочевидной логики и зависимостей я считаю напрасно потраченным.
Лично для меня Smarty куда как ближе к JavaScript, нежели к PHP, т.к. оба этих инструмента оперируют, как раз таки, в области представления. Говоря ближе, я подразумеваю именно область влияния.
Более того, вся иерархия подключаемых подшаблонов у меня лично регулируется из мастер-шаблона, что избавляет контроллер вообще от подобных, неуместных, на мой взгляд, забот. Т.е. контроллер у меня, как правило, предельно простой. Его задача — отработать бизнес-логику, отдать данные и управляющий сигнал. Что происходит дальше — его НЕ КАСАЕТСЯ!
Т.е. схема следующая:
1) Точка входа производит базовую инициализацию, типа названия приложения и ключевых констант, в основном это базовые пути, далее передает управление.
2) Ядро инициализирует приложение, гибко подключает, по необходимости, те или иные модули, в зависимости от настроек.
3) Роутер определяет какой контроллер должен отработать, после чего ядро вызывает его обернутым в функцию, таким образом контроллер изолирован от остального приложения, в том числе по части вывода на экран какого-либо мусора.
4) Контроллер, кроме прочего, возвращает параметр — конечный обработчик данных.
5) Далее ядро вызывает обработчик с данными, полученными от контроллера и общей конфигурацией приложения, в том числе со заданными всеми путями. И уже конечный результат формируется обработчиком.
*) А теперь представим, что контроллер сгенерил кучу HTML, в то время как он должен быть гибок и мочь сработать хоть в HTML, хоть в JSON, хоть куда еще…
В движок я зашил несколько библиотек, здорово облегчающих жизнь, например Smarty и DBSimple.
И да, тема скинов тоже замечательно регулируется тоже. Например на многих сайтах которые я делал на движке, на главной странице скин несколько отличается от оного на внутренних. Как Вы уже могли догадаться, контроллер вообще ничего об этом не знает. :)
Так уж сложилось, что я, на уровне рефлексов, издавна, еще со времен Pascal, а потом и Clipper, привык к жестко структурированному коду. Смысл в этом был огромный, т.к. я писал бухгалтерские приложения, и количество кода, порой, доходило до 15 тысяч строк. Если в таком количестве кода не наводить дОлжный порядок, то развивать такой код становится затруднительно, даже если сам его писал от «А» до «Я». К слову сказать, несколько программ, написанных в 2004-2006 годах проработали без сбоев (кое-что и сегодня работает) вплоть до 2012 года, когда контора стала массово переходить на софт типа 1С.
И еще, PHP в шаблонах, не будучи структурированным, меня просто убивает. И да, я знаю, что многим другим программистам он там вполне комфортен. Я говорю только за себя.
Сам же Smarty компилирует шаблоны, превращая в самый обыкновенный PHP pазбавленный HTML/JS.
Т.е. Smarty — это дополнительный уровень абстракции. Таким образом имеется 2 уровня шаблонов. Первый — это абстракция, с которой я работаю как разработчик. Там прекрасно код Smarty отделен от остального HTML/JS, и позволяет гибко передавать данные и регулировать шаблонную логику, о которой контроллеру знать совершенно не обязательно. Smarty в шаблонах, на мой взгляд, куда как более читаем и лаконичен, органичен, я бы даже сказал. Второй уровень шаблонов — это фактический код, откомпилированный из первого, движком Smarty, и непосредственно исполняемый в системе.
И да, от условий и некоторой логики в шаблонах никуда не деться. Благо сейчас уже акценты бурно смещаются в сторону клиентской динамики, где море JS. Это совершенно отдельная песня. В моем случае, как я уже писал, где-то в этой ветке, индивидуальный JS так же шаблонизирован, что позволяет гибко вставлять куда надо управляющие конструкции. Получается своего рода мета-программирование, т.к. JS-код может гибко реагировать на некоторые условия, пришедшие как управляющий сигнал от контроллера.
Возвращаясь к логике в шаблонах — это другая логика, это логика шаблона. И к контроллеру она не имеет вообще никакого отношения. Поэтому, по моему глубочайшему убеждению, контроллеру совершенно не обязательно знать ту логику, которая касается исключительно шаблона.
Работал я недавно в связке с одним программистом, причем решения принимал я, в виду должностной инструкции и обязанностей, а он мне должен был помогать. Так вот, программист бурно не переносил вообще какую-либо логику в шаблонах, а, так же, инклюды, норовя вынести всю шаблонную логику в контроллер, там же подключая подшаблоны (порой с довольно сложной иерархией и зависимостями). В результате, открывая шаблон, я совершенно не мог понять, что там происходит. Откуда-то появились блоки с произвольным функционалом, никак не регламентированным самим шаблоном. В то же время код контроллера превратился в километры невнятных условий. Открывая такой контроллер я переставал понимать, чем он вообще занимается.
Например меню, которое касается только представления, генерилось у него в месте, совершенно никак логически не связанном с самим представлением, вплоть до вставки HTML-кусков в рамках контроллера. Это уже было слишком! Конечно эти безобразия я пресек на корню, по поводу чего было очень много стонов. Пресек категорически, т.к. время потраченное на поиски неочевидной логики и зависимостей я считаю напрасно потраченным.
Лично для меня Smarty куда как ближе к JavaScript, нежели к PHP, т.к. оба этих инструмента оперируют, как раз таки, в области представления. Говоря ближе, я подразумеваю именно область влияния.
Более того, вся иерархия подключаемых подшаблонов у меня лично регулируется из мастер-шаблона, что избавляет контроллер вообще от подобных, неуместных, на мой взгляд, забот. Т.е. контроллер у меня, как правило, предельно простой. Его задача — отработать бизнес-логику, отдать данные и управляющий сигнал. Что происходит дальше — его НЕ КАСАЕТСЯ!
Т.е. схема следующая:
1) Точка входа производит базовую инициализацию, типа названия приложения и ключевых констант, в основном это базовые пути, далее передает управление.
2) Ядро инициализирует приложение, гибко подключает, по необходимости, те или иные модули, в зависимости от настроек.
3) Роутер определяет какой контроллер должен отработать, после чего ядро вызывает его обернутым в функцию, таким образом контроллер изолирован от остального приложения, в том числе по части вывода на экран какого-либо мусора.
4) Контроллер, кроме прочего, возвращает параметр — конечный обработчик данных.
5) Далее ядро вызывает обработчик с данными, полученными от контроллера и общей конфигурацией приложения, в том числе со заданными всеми путями. И уже конечный результат формируется обработчиком.
*) А теперь представим, что контроллер сгенерил кучу HTML, в то время как он должен быть гибок и мочь сработать хоть в HTML, хоть в JSON, хоть куда еще…
В движок я зашил несколько библиотек, здорово облегчающих жизнь, например Smarty и DBSimple.
И да, тема скинов тоже замечательно регулируется тоже. Например на многих сайтах которые я делал на движке, на главной странице скин несколько отличается от оного на внутренних. Как Вы уже могли догадаться, контроллер вообще ничего об этом не знает. :)
И еще, PHP в шаблонах, не будучи структурированным, меня просто убивает.
А что мешает его структурировать? Или я не понял, что вы имеете в виду под этим словом?
А что мешает его структурировать? Или я не понял, что вы имеете в виду под этим словом?
Основная претензия к PHP в шаблоне — что теги сливаются, приходится каждый раз прикладывать дополнительные усилия для разбора и распознавания.
вариант {$url_txt} гораздо более удобочитаем,
нежели <?=$url_txt?>
вариант {$url_txt} гораздо более удобочитаем,
нежели <?=$url_txt?>
PHP-цикл в коде PHP-шаблона — это нормально. Будете пользоваться шаблонизатором — напишите тот же цикл, но на языке шаблонизатора (берём «обычные» шаблонизаторы, в XSLT и ему подобных обходятся без них вроде). В шаблоне не должно быть бизнес-логики и логики приложения. Грубо говоря в нём должны быть только if/then/else, while/for/foreach и echo/print (как вариант <?= ?>).
Кстати, хороший холивар про шаблонизаторы вс PHP — много полезного можно узнать.
Основная причина по которой я начал использовать шаблонизаторы — они обеспечивают автоматическое экранирование, а так при использовании альтернативного синтаксиса в php разницы практически нет. Кроме той что до версии 3 Smarty, емнип, не поддерживал наследования шаблонов — тоже очень удобная штука.
Имхо, если веб-фреймворк не позволяет выбрать шаблонизатор на свой вкус, то это очень странный фреймворк… или просто сырой ещё.
Так вот jQuery это и есть фреймворк. Нитивный вариант на javascript document.getElementById('id') на фреймворке $('#id'), то есть проще, это уже готовая обвертка.
Теперь начинаю понимать. Только все-равно не понимаю как функции php можно еще обернуть. Ведь язык изначально был веб ориентирован.
Из набора функций делают класс а функции называются методами этого класса. Класы могут взаимодействовать друг с другом, наследоваться и т.д. Почитайте что такое ООП.
С ООП хорошо знаком. Все мои коды написаны исключительно с использованием ООП. Все хранится в виде классов. Хотя вот наследование мало использую
Притом что наследование — один из столпов ООП, Вы отказываетесь от него по каким-то причинам?
Объединение набора функций в класс в виде методов — это далеко не ООП.
Объединение набора функций в класс в виде методов — это далеко не ООП.
Да, видимо, мои классы — это ничто иное как просто объединение функций. Почему не использую наследование? Даже не знаю что на это ответить… Не столкнулся еще с такой надобностью. А точнее сказать, что скорее всего в силу может быть слабого понимания каких-то моментов просто не вижу где у меня это можно применить, хотя на самом деле может таких мест и много.
Поэтому может утверждение «хорошо знаком с ООП» и правда слишком сильно сказано…
Поэтому может утверждение «хорошо знаком с ООП» и правда слишком сильно сказано…
Без наследования невозможен объектно-ориентированный дизайн. Погуглите про SOLID-принципы в OOD — возможно это Вас сподвигнет более полно использовать объектно-ориентированный подход.
Спасибо за совет!
Как-то получается обходиться практически без него. А OCP как-то никогда не понимал до конца. Вот написал класс с парой методов, скажем, show и hide, понадобился ещё один, например, blink — что наследоваться от него? Почему просто не добавить метод? Существующим клиентам он не помешает, ответственность не добавится, да вообще, по-моему, ничего не изменится кроме того, что клиенты смогут более гибко управлять отображением.
ООП != ООП
Чтобы понимать, когда и зачем нужно наследование, надо понимать техники объектно-ориентированного проектирования, а не программирования.
Чтобы понимать, когда и зачем нужно наследование, надо понимать техники объектно-ориентированного проектирования, а не программирования.
Неправильно значит понимаете :) Оборачивание стандартных функций — не фреймворк. Разработка под фреймворком — это, прежде всего, оборачивание вашего кода в понятные фреймворку интерфейсы. То есть вы следуете архитектуре, принципам и практикам фреймворка при разработке своих компонентов, особо не заботясь об их взаимодействии. Фреймворк берёт на себя низкоуровневое взаимодействие типа создания объектов запроса, ответа и контроллера и доступа из последнего к первым.
jQuery, всё же, не полноценный фреймворк, имхо, это скорее библиотека.
Обычно фреймворк это чуть меньше, чем набор модулей. Фактически, это набор классов и функций, ускоряющих написание модулей + сообщество, которое создает и даже делится друг с другом готовыми модулями на основе фреймворка, т.е. готовые блоки тоже есть в огромном количестве.
Мне вот нравится, что используя фреймворк, можно забыть о массе рутинных действий, типа правильной обработки запросов к БД (хотя, всецело на него полагаться не стоит), работы с сессиями, правильного использования модели MVC и т.п. + поддерживать такой код проще, т.к. он уже структурирован по правилам фреймворка и любому, кто занком с фреймворком потом будет понятен (читай — получается меньше говнокода).
Мне вот нравится, что используя фреймворк, можно забыть о массе рутинных действий, типа правильной обработки запросов к БД (хотя, всецело на него полагаться не стоит), работы с сессиями, правильного использования модели MVC и т.п. + поддерживать такой код проще, т.к. он уже структурирован по правилам фреймворка и любому, кто занком с фреймворком потом будет понятен (читай — получается меньше говнокода).
Это чуть больше, чем инструмент, облегчающий написание модулей. Это инструмент облегчающий создание приложения в целом. Вернее даже, фреймворк — это, как правило, готовое, пускай и простейшее приложение, но подразумевающее очень широкие возможности кастомизации. Грубо говоря во фреймворке есть заглушки, хуки и прочая «магия» на все случаи жизни, чтобы изменить ответ на запрос GET /fakga/sgdsdfg/4545/fgdfh/57547?hksdhg=jhkf&ghsdlgh=112 c «hello word» на то, что есть в ТЗ в нескольких местах.
В ваших примерах непосредственно к веб-фреймворку относится, в лучшем случае, только MVC, остальное это модули и библиотеки по сути и средства их удобной интеграции. Собственно фреймворк и есть средство интеграции компонентов в приложение согласно его архитектуре, реализация интерфейсов между компонентами.
В ваших примерах непосредственно к веб-фреймворку относится, в лучшем случае, только MVC, остальное это модули и библиотеки по сути и средства их удобной интеграции. Собственно фреймворк и есть средство интеграции компонентов в приложение согласно его архитектуре, реализация интерфейсов между компонентами.
Все вот говорят «MVC», «MVC». Читал про MVC. Читал про паттерны и шаблоны. Даже пару книг прикупил. Тока щас начинаю их читать! Но нужен живой пример! Разбор живого примера. Я бы даже сказал сайта. Может простейшего, но передающего суть. Только так можно понять модель. А читать сотню статей про паттерны где абтрактно рассказыается про контроллеры, модели и пр. — это только общее представление дает.
И еще такой момент: получается что многие разработчики так или иначе создали свой движок или CMS (называйте как хотите) и работают с ним. Он легко кастомизируется, работает и неплохо написан. Ведь явно не мало есть таких. И неужели в сети не ходят такие вот наработки, которые можно взять, использовать для своих сайтов (как CMS) и дорабатывать самому? Т.е. вот у меня щас есть миллион мыслей как сделать свой движок (совершенствовать свой), но для этого нужно полгода или год. А зачем это делать, если эту задачу уже кто-то решил и не раз. Велосипед готов. Ну хотя бы база к нему.
И еще такой момент: получается что многие разработчики так или иначе создали свой движок или CMS (называйте как хотите) и работают с ним. Он легко кастомизируется, работает и неплохо написан. Ведь явно не мало есть таких. И неужели в сети не ходят такие вот наработки, которые можно взять, использовать для своих сайтов (как CMS) и дорабатывать самому? Т.е. вот у меня щас есть миллион мыслей как сделать свой движок (совершенствовать свой), но для этого нужно полгода или год. А зачем это делать, если эту задачу уже кто-то решил и не раз. Велосипед готов. Ну хотя бы база к нему.
И я именно не про какой-то известный движок типа джумлы или того же битрикса, а что-то проще. Но что можно взять как базу. Хотя бы как готовую модель и уже дальше ее корежить. Т.е. такая начальная наработка.
Ну так возьмите любой из фреймворков, там есть все что нужно — модули авторизации, разделения прав доступа, модули работы с БД, реализованная MVC (в виде FrontController + Command часто), есть роутинг, да и много чего еще.
И уже на нем делайте что хотите. Смысл писать свой фреймворк есть только тогда, когда тебя что-то действительно не устраивает в существующих фреймворках (либо есть какие-то гениальные супер-идеи, которые еще никто и нигде не реализовывал).
Это как раз и будет база, кирпичи, бетонные балки и перекрытия, из которых Вы будете проектировать конечный продукт.
И уже на нем делайте что хотите. Смысл писать свой фреймворк есть только тогда, когда тебя что-то действительно не устраивает в существующих фреймворках (либо есть какие-то гениальные супер-идеи, которые еще никто и нигде не реализовывал).
Это как раз и будет база, кирпичи, бетонные балки и перекрытия, из которых Вы будете проектировать конечный продукт.
А как это делается с использованием фреймворков? Правильно ли понимаю, что это уже готовые наборы функций и библиотек, из которых ты собираешь свой сайт?
Скорее это готовая «инфрструктура» проекта.
так вот про MVC. Фреймверк уже представляет из себя готовую структуру, архитектуру? Или из имеющихся функций и классов нужно самому ее создавать.
Минус мне, но никак не могу понять суть фреймверков принипиально. Какая-то тонкая грань отделяет меня от понимания…
Минус мне, но никак не могу понять суть фреймверков принипиально. Какая-то тонкая грань отделяет меня от понимания…
У современных все есть. Вам, как правило, достаточно развернуть фреймворк, написать в командной строке что-то типа «symfony generate:app frontend && symfony generate:module fontend main» (ну или создать файлы ручками) и получить рабочее приложение (в т.ч. структуру файлов и папок), которое, правда, не будет делать ровным счетом ничего пока вы не заполните сгенерированные файлы своим кодом.
Нужно создать модель, вьюшку (шаблон) и контроллер. Как правило есть средства автогенерации заготовок для них.
Пример простейшего фреймворка:
Если из приложения в приложение вы перетаскиваете этот файл, не изменяя его, а изменяете только routes.php и создаёте свои main.php, about.php и т. п., то это фреймворк.
Пример простейшего фреймворка:
//index.php
require_once 'routes.php';
require $routes[$_GET['page'];
Если из приложения в приложение вы перетаскиваете этот файл, не изменяя его, а изменяете только routes.php и создаёте свои main.php, about.php и т. п., то это фреймворк.
Я начал с symfony. Как оказалось намного позже — выбор был очень даже правильный. Доки и философия зенда и рядом не лежали.
Просто есть такая штука… Симфони задает стандарт. И даже в доках на нем делается очень большой акцент. И если придерживатся рекомендаций (стандарта) у Вас просто не может получится что-то неправильно. Соответственно, в Вашем коде разберется любой кто работал с фреймворком на должном уровне.
Кстати, это же касается рельс и почти так же верно по отношению к джанге.
Просто есть такая штука… Симфони задает стандарт. И даже в доках на нем делается очень большой акцент. И если придерживатся рекомендаций (стандарта) у Вас просто не может получится что-то неправильно. Соответственно, в Вашем коде разберется любой кто работал с фреймворком на должном уровне.
Кстати, это же касается рельс и почти так же верно по отношению к джанге.
Можете попробовать yii, kohana, lavarel, получите всю ту же свободу, но будете уже думать о бизнес логике, да и ваш код уже будет легче читать другому программисту.
Если сравнивать очень грубо, то в CMS уже обычно заданы сущности (объекты, термины и т. п.) предметной области, а во фреймворках нет. Если брать простейшую «страничную» CMS, то в ней, как правило, реализованы такие сущности как «страница», «иерархическое меню». Во фреймворках этого обычно нет, там работаешь уровнем ниже — есть http-запрос и есть http-ответ, который ты формируешь используя инфраструктуру фреймворка. Класс «страница» или «меню» нужно сформировать самому(или воспользоваться готовыми модулями).
>Т.е. в принципе мои коды в какой-то мере это даже больше не движок а именно мой самописный фреймворк?
Вероятно, скорее фреймворк, если при создании нового проекта вы сначала копируете базу, а потом свой код в неё внедряете, меня реализации методов, классов, функций, инклудов, а не, грубо говоря, начинаете писать index.php вызывая из него свои методы, функции, инклуды (поток выполнения общего и кастомизированного кода главное отличие фреймворка от библиотеки).
>Т.е. в принципе мои коды в какой-то мере это даже больше не движок а именно мой самописный фреймворк?
Вероятно, скорее фреймворк, если при создании нового проекта вы сначала копируете базу, а потом свой код в неё внедряете, меня реализации методов, классов, функций, инклудов, а не, грубо говоря, начинаете писать index.php вызывая из него свои методы, функции, инклуды (поток выполнения общего и кастомизированного кода главное отличие фреймворка от библиотеки).
Да, да именно так!
На самом деле в современных фреймворках очень часто есть намного больше чем просто Request-Response, если, конечно, не брать в расчет микро-фреймворки типа Silex (хотя даже у него тот же dependency injection есть) ;)
Ну да, современные фреймворки уже давно не только каркасы приложений, обеспечивающий единый (по умолчанию) поток выполнения для всех запросов, но и куча библиотек для типичных задач, как примитивных типа хелперов, так и чуть ли не превосходящие по сложности и объёму кода всё остальное типа ORM.
Фреймворки — это только коды или еще и, например, готовые каркасы таблиц баз данных? Или может наборы каких-то требований или правил к таблицам?
Вообще говоря только коды, в том числе зачастую коды генерации БД на основе моделей, либо моделей на основе БД. Бывают некоторые умолчания типа имя таблицы должно быть множественным числом от имени класса модели (User -> users), но они, как правило, легко перекрываются.
Нет там каркасов. Как правило просто описываем по какому-то шаблону структуру таблиц, а фреймворк сам создает бд и абстрактные модели/формы (некоторые фреймворки исплюзуют свои ORM (зенд например), другие сторонние разрабоки(в симфони используется doctrine)). А некоторые и простой CRUD для таблицы сгенерят автоматом…
Фреймворки бывают разные. Какие то это просто набор библиотек, какие то — нечто большее. В среднем фреймворк обычно предоставляет базовый архитектурный каркас(рабочая модель mvc и т.д.) и много различных хелперов.
Насчет того какой попробовать. Есть Zend, который пожалуй самый популярный, но он монструозен и очень тяжел, как для изучения так и в плане нагрузки на сервер. Есть Symfony 2, который тоже весьма тяжел, но не так как Zend, весьма достойный фреймворк на на мой взгляд он реализует чересчур много лишнего.
Есть Codeinteger и Kohana(форк последнего) — хорошие легкие фреймворки.
И есть Yii — один из самых молодых фреймворков и мой личный фаворит. Очень удобный и красивый в плане архитектуры.
Конечно есть еще вагон фреймворков, но все описывать подробно это не на одну статью.
Насчет того какой попробовать. Есть Zend, который пожалуй самый популярный, но он монструозен и очень тяжел, как для изучения так и в плане нагрузки на сервер. Есть Symfony 2, который тоже весьма тяжел, но не так как Zend, весьма достойный фреймворк на на мой взгляд он реализует чересчур много лишнего.
Есть Codeinteger и Kohana(форк последнего) — хорошие легкие фреймворки.
И есть Yii — один из самых молодых фреймворков и мой личный фаворит. Очень удобный и красивый в плане архитектуры.
Конечно есть еще вагон фреймворков, но все описывать подробно это не на одну статью.
Есть ещё четвёртый вариант — движок на базе популярного фреймворка. Такие легко кастомизировать и расширять, а плюсом ко второму варианту идёт то, что при тех же возможностях кастомизации уже готово не только ядро, но и наиболее популярные фичи в конкретной области, будь то e-commerce, новостной портал или соц.сеть. Для каждой области будет отдельный движок на одном фреймворке.
Я бы убрал поддержку из плюсов.
Особенно, если имеется в виду поддержка клиентов, а не кода.
Т.е. разработчики CMS или фреймворка заниматься моими клиентами скорее всего не будут.
Особенно, если имеется в виду поддержка клиентов, а не кода.
Т.е. разработчики CMS или фреймворка заниматься моими клиентами скорее всего не будут.
Добавлю пункт:
4. Полностью свой код, даже если задача не уникальна, но если сайт должен стать «конкурентным преимуществом» фирмы перед другими такими же магазинами, сделанными на типовых движках. Именно как у автора этой заметки — когда «стиль работы» сайта совпадает со стилем работы менеджеров, когда можно учесть любые нюансы, то общая эффективность значительно повышается.
Готовые магазинные скрипты или магазины и CMS хороши, но всегда найдётся пунктик, из-за которого приходится «плеваться» и переписывать этот кусок или уговаривать разработчиков на изменение или развитие этого функционала. И это стоит стольких нервов, времени или денег, что почти всегда проще самому с нуля всё написать. А если уж когда-то что-то подобное делал, то тем более — допилить свою старую разработку всегда проще, чем чужую. Вот только система получается зависимой от одного программиста… Но «независимости» тут и не бывает — зависимость от фирмы-поставщика CMS может стать не меньшей проблемой. У них тоже и программисты меняются, и нередко и вовсе с рынка вылетают. А выбирать CMS не по функционалу, а по прикидке «кто наиболее вероятный лидер рынка в ближайшие 5 лет» (и поэтому не пропадёт и может быть будет учитывать наши пожелания по доработкам) — тоже как-то неправильно…
В общем, в такой простой задаче как «онлайн-магазин» я голосую за самописные магазины.
4. Полностью свой код, даже если задача не уникальна, но если сайт должен стать «конкурентным преимуществом» фирмы перед другими такими же магазинами, сделанными на типовых движках. Именно как у автора этой заметки — когда «стиль работы» сайта совпадает со стилем работы менеджеров, когда можно учесть любые нюансы, то общая эффективность значительно повышается.
Готовые магазинные скрипты или магазины и CMS хороши, но всегда найдётся пунктик, из-за которого приходится «плеваться» и переписывать этот кусок или уговаривать разработчиков на изменение или развитие этого функционала. И это стоит стольких нервов, времени или денег, что почти всегда проще самому с нуля всё написать. А если уж когда-то что-то подобное делал, то тем более — допилить свою старую разработку всегда проще, чем чужую. Вот только система получается зависимой от одного программиста… Но «независимости» тут и не бывает — зависимость от фирмы-поставщика CMS может стать не меньшей проблемой. У них тоже и программисты меняются, и нередко и вовсе с рынка вылетают. А выбирать CMS не по функционалу, а по прикидке «кто наиболее вероятный лидер рынка в ближайшие 5 лет» (и поэтому не пропадёт и может быть будет учитывать наши пожелания по доработкам) — тоже как-то неправильно…
В общем, в такой простой задаче как «онлайн-магазин» я голосую за самописные магазины.
Имхо если есть необходимость создавать гибкий и нестандартный функционал, но при этом есть вероятность того, что сайт в дальнейшем будет поддерживать какой-то другой человек — разрабатывайте на основе какого-то популярного фреймворка. Проблем с поддержкой у более-менее хорошего программиста не будет. При всём уважении к 1С, Битрикс — это то ещё чудовище, на его фоне, конечно, вариант «сделать самому» пересиливает любые доводы.
Я скажу за себя. Мне проще поддерживать свой движок, чем переходить на готовую CMS. Тут вопрос не столько в том, что какие-то фичи невозможно сделать — я думаю, что многие CMS позволяют программистам использовать возможности низкого уровня. Вопрос в том, что мне уже лень разбираться и изучать новые CMS, технологии, языки, framework и т.д… Лень и еще возраст, из-за которого мозг не может усваивать информацию также быстро, как в 20-25 лет.
мы с вами, вероятно, очень разные люди. Мне наоборот стало лень допиливать свое. Изучать новое и участвовать для меня стало комфортнее. Мне сейчас удобнее хорошо разбираться в кирпичах и знать как их укладывать (конечно разбираясь в технологии обжига, раствора и умея корректировать технологию в зависимости от условий применения).
По факту, фрейворка или цмс сейчас в одиночку не построишь если месседж не гениальный, и все равно не в одиночку, а на свой jquery или ror, у меня например мозгов\времени\желания не хватило.
Извиняюсь, не мог не прокомментировать.
мне тоже за 20-25 )))) Скорее немного дальше ))))))
По факту, фрейворка или цмс сейчас в одиночку не построишь если месседж не гениальный, и все равно не в одиночку, а на свой jquery или ror, у меня например мозгов\времени\желания не хватило.
Извиняюсь, не мог не прокомментировать.
мне тоже за 20-25 )))) Скорее немного дальше ))))))
Я как-будто про себя сейчас этот текст прочитал. Тоже перед каждым проектом мучаюсь — взять что-то готовое за основу или делать самостоятельно. И тоже понимаю, что в хорошо оттестированных и обкатанных сотнями установок системах намного меньше проблем и работа значительно упростится. Но в конечном итоге, на мой взгляд, все сводится к вопросу стабильности функционала, который закладывается в самом начале.
Если честно, именно магазинов у меня за спиной — всего один. И именно для него я взял готовую систему. Могу сказать, что я потратил на доработку под потребности клиента столько же времени, сколько потребовалось бы для реализации функционала с чистого листа. Т.е. конкретно в этом случае, клиенту не были нужны 60% функций движка, но нужно было столько же того, чего в нем не реализовано.
При этом, глядя на коды движка я, с одной стороны, видел, что там заложена сложная архитектура и реализованы многие полезные для расширения вещи, а с другой стороны, там полно говнокода, нет комментариев в коде, а структура вызова функций явно написана не с учетом человеческой логики. При этом, в форумах преимущественно сидит народ, который готов сделать за деньги, но не готов делиться опытом с коллегами.
И возвращаясь к стабильности функционала — когда через месяц после запуска проекта клиент просит сделать голосование, это нормально, но потом появляются именные анкеты для постоянных клиентов, раздел для фотоконкурса среди посетителей, раздел публикации проекции сферического коня в ваккууме на поверхность Марса и т.п. Вот тут, имхо, затраты на доработку своего движка могут быть в разы ниже, чем стороннего. Опять таки, все действительно зависит от ресурсов, но если с самого начала есть помощники, то сложность будущей поддержки уже сократится вдвое, если хотя бы два разных человека будут работать над кодом. В такой ситуации ты вынужден писать больше комментариев, делать более читабельный код и больше думать над тем, чтобы за него не было стыдно… Ну а если добавить процедуры тестирования, то вообще может выйти красота.
Я тешу себя мыслью о том, что многие известные системы тоже начинались как чей-то штучный проект, когда человеку надоело делать заново каждый раз одно и то же…
Если честно, именно магазинов у меня за спиной — всего один. И именно для него я взял готовую систему. Могу сказать, что я потратил на доработку под потребности клиента столько же времени, сколько потребовалось бы для реализации функционала с чистого листа. Т.е. конкретно в этом случае, клиенту не были нужны 60% функций движка, но нужно было столько же того, чего в нем не реализовано.
При этом, глядя на коды движка я, с одной стороны, видел, что там заложена сложная архитектура и реализованы многие полезные для расширения вещи, а с другой стороны, там полно говнокода, нет комментариев в коде, а структура вызова функций явно написана не с учетом человеческой логики. При этом, в форумах преимущественно сидит народ, который готов сделать за деньги, но не готов делиться опытом с коллегами.
И возвращаясь к стабильности функционала — когда через месяц после запуска проекта клиент просит сделать голосование, это нормально, но потом появляются именные анкеты для постоянных клиентов, раздел для фотоконкурса среди посетителей, раздел публикации проекции сферического коня в ваккууме на поверхность Марса и т.п. Вот тут, имхо, затраты на доработку своего движка могут быть в разы ниже, чем стороннего. Опять таки, все действительно зависит от ресурсов, но если с самого начала есть помощники, то сложность будущей поддержки уже сократится вдвое, если хотя бы два разных человека будут работать над кодом. В такой ситуации ты вынужден писать больше комментариев, делать более читабельный код и больше думать над тем, чтобы за него не было стыдно… Ну а если добавить процедуры тестирования, то вообще может выйти красота.
Я тешу себя мыслью о том, что многие известные системы тоже начинались как чей-то штучный проект, когда человеку надоело делать заново каждый раз одно и то же…
<blockquote< Могу сказать, что я потратил на доработку под потребности клиента столько же времени, сколько потребовалось бы для реализации функционала с чистого листа.
Программисты склонны занижать оценку по времени. Не грызите себя, вы все сделали правильно ;)
Программисты склонны занижать оценку по времени. Не грызите себя, вы все сделали правильно ;)
Вот тут, имхо, затраты на доработку своего движка могут быть в разы ниже, чем стороннего.
А могут и не быть. Выигрывает тот движок, в котором лучше реализована модульность. Тот, в котором меньше связанность (loose coupling). Выбирайте движок с умом и не попадете в ситуацию, когда «проще написать самому, чем дорабатывать этого монстра».
многие известные системы тоже начинались как чей-то штучный проект, когда человеку надоело делать заново каждый раз одно и то же…
Так оно и есть, афаик. Грубо говоря общий код двух и более проектов (или относительно независимых подпроектов одного большого) выделяются в общую базу хотя бы для облегчения сопровождения. Простой DRY :)
Так оно и есть, афаик. Грубо говоря общий код двух и более проектов (или относительно независимых подпроектов одного большого) выделяются в общую базу хотя бы для облегчения сопровождения. Простой DRY :)
Я сделал свой движок, всем так понравился, что теперь продаю его
Ну не стесняйтесь, линк в студию!
Визуально очень даже неплохо. По сравнению с битриксом сразу возникает ощющение, что логика в интерфейсе вынесена из практики.
Сколько времени пришлось потратить на первую версию? Сколько людей его разрабатывают и сапортят? В связи с интерфейсом как то сразу вспомнился Tango Desktop Project. Это он, или мне кажется?
Сколько времени пришлось потратить на первую версию? Сколько людей его разрабатывают и сапортят? В связи с интерфейсом как то сразу вспомнился Tango Desktop Project. Это он, или мне кажется?
Спасибо за комплимент. По времени не могу определенно сказать, за много лет плавно выросло из примитивного редактора сайта в движок магазина, хотя два раза переписывалось с нуля. Разработчик один, а сапортят обычно партнеры-студии, я не продаю напрямую клиентам. с Tango Desktop Project к сожалению не знаком.
Кстати, к какого типа лицензии в итоге пришли? (поглядел просто в q&a). Товарных знак, движок как-то регистрировались? По сути получается b2b схема в которой порой приходится озаботиться бумажкой подтверждающей авторское право на продаваемое ПО. Хотя если работать со знакомыми студиями вопрос этот не возникает и я так понимаю, что как раз этот вариант сейчас и есть?
Поражает скорость работы, а фреймворк используется?
Нет, там всё слишком просто чтобы тянуть за собой фреймворк
Фреймворки обычно вносят свой оверхед, путь небольшой, но вносят. А PHP в некотором смысле сам как фреймворк, так что нужно его использовать по полной, что pixxxel и сделал. Но вообще там есть еще куда выжимать. Как я посмотрю на демке типичное время генерации ~40 мс. Я для одной не завершенной еще разработки магазина получают типичное время в ~10 мс, но есть страницы которые и за 3 мс генерятся. Собственно, это одна из причин за вариант написания своего.
40мс — это просто хорошо, некоторые выдают до 0,3 с без нагрузки…
я добился формирование стр. за 7 мс
я добился формирование стр. за 7 мс
Если у вас уже есть свой движок для магазина, то просто поставьте его в один ряд с Ubercart, VirtueMart, Bitrix, Magento, etc. Этот ряд называется — «движки, проверенные опытом реальной работы».
В другой ряд поставьте Zend Framework, Yii, Django, RoR, да хоть ChicagoBoss. Этот ряд назовем «разработкой с нуля».
Вы же совершаете громадную ошибку, перенося свой движок во второй ряд. Если движку несколько лет и несколько рабочих инсталляций с разной конфигурацией, то это уже можно считать своим продуктом, своей IP.
Проблема №1. Выбор движка под новый проект. Тут все, как всегда — делим требования из ТЗ на возможности движка и вычитаем известностью этого движка программистам. Результаты сортируем по возрастанию ;)
Проблема №2. «Что делать, если кому-то еще придется работать». Напишите документацию. Ведите dev-blog.
В другой ряд поставьте Zend Framework, Yii, Django, RoR, да хоть ChicagoBoss. Этот ряд назовем «разработкой с нуля».
Вы же совершаете громадную ошибку, перенося свой движок во второй ряд. Если движку несколько лет и несколько рабочих инсталляций с разной конфигурацией, то это уже можно считать своим продуктом, своей IP.
Проблема №1. Выбор движка под новый проект. Тут все, как всегда — делим требования из ТЗ на возможности движка и вычитаем известностью этого движка программистам. Результаты сортируем по возрастанию ;)
Проблема №2. «Что делать, если кому-то еще придется работать». Напишите документацию. Ведите dev-blog.
Это всё равно что велосипеду покупать авиаангар для хранения. Лихо вы замахнулись.
«Разработка с нуля» это далеко не «Zend Framework, Yii, Django, RoR, да хоть ChicagoBoss» — это полноценные продукты. Просто это продукты для разработчиков приложений. CMS, «движки» — это продукты для веб-мастеров прежде всего. Разная ЦА.
Я просто не вижу смысла в разработке «с абсолютного нуля» в 2012 году, когда на рынке столько хороших фреймворков.
Один из смыслов: если программист не знает ни одного из них, и если нет у него старшего товарища поблизости, то выбор фреймворка плюс изучение его (потом на первом проекте убеждение в неверном выборе, потом изучение второго и т.д.) займёт намного больше времени, чем написание своего с нуля по мере освоения PHP и целевой задачи. Ну а потом, со временем, со знанием дела, можно будет повыбирать и из готовых. Это как сначала научиться нормально ходить на своих двоих, и только потом (через несколько лет) осваивать автомобиль.
«КАК он будет разбираться с тем, что я сделал???» — для этого в программистах ценят «умение разбираться в чужом коде» а так же эту строку можно встретить во многих вакансиях )
А вот что касается фреймворк или готовое решение, здесь и у меня дилема. Написать свою админку и взять ядром фреймворк или юзать готовую систему. На фреймворке будет в пару сотен раз быстрее чем другие коммерческие/свободные CMS/CMF так как там не будет лишнего, а написать самому себе пару модулей типа новостных лент, будет не сложно. Сейчас все эти системы сделаны так, что бы сайты делали те кто не умеет программировать. Натыкал модулй, вызвал их в нужных местах ХТМЛ и готово.
Я две недели назад для опыта выбрал MODX для общего развития и как вариант для своих работ. Большую часть времени я потратил на ознакомление с системой в сайте с текстовых страниц и фотогоалерей мне пришлось переписать кусок кода GalleryAlbums расширения Gallery так как не работает в связке с getPage. Другими словами не могу сделать пагинацию для списка галерей, что привело меня в ужас при том что сама система как говорят «очень гибкая».
З.Ы. Надеюсь мой ответ был исчерпывающий и поможет вам в выборе.
А вот что касается фреймворк или готовое решение, здесь и у меня дилема. Написать свою админку и взять ядром фреймворк или юзать готовую систему. На фреймворке будет в пару сотен раз быстрее чем другие коммерческие/свободные CMS/CMF так как там не будет лишнего, а написать самому себе пару модулей типа новостных лент, будет не сложно. Сейчас все эти системы сделаны так, что бы сайты делали те кто не умеет программировать. Натыкал модулй, вызвал их в нужных местах ХТМЛ и готово.
Я две недели назад для опыта выбрал MODX для общего развития и как вариант для своих работ. Большую часть времени я потратил на ознакомление с системой в сайте с текстовых страниц и фотогоалерей мне пришлось переписать кусок кода GalleryAlbums расширения Gallery так как не работает в связке с getPage. Другими словами не могу сделать пагинацию для списка галерей, что привело меня в ужас при том что сама система как говорят «очень гибкая».
З.Ы. Надеюсь мой ответ был исчерпывающий и поможет вам в выборе.
Практика показывает, что редко какой сайт на базе CMS/CMF обходится без дорабатывания напильником программной части. Ну разве что, когда нужен сайт именно с тем функционалом, который предлагает CMS. Например, если хочется standalone-блог, то есть CMS-ки, заточенные именно под блоги. Но попользовавшись системой, человек всё равно приходит к выводу, что без какой-то доработки не обойтись. И тут либо кого-то нанимать, либо сидеть и самому разбираться.
Согласен, пилить можно, вот только там где это нужно. Как по мне так фотогалерея это не прерогатива. Дело в том что там есть целая куча ненужной фигни, а то что по сути нужно — нету.
В настройка безопасности доступа более 120 чекбоксов и это настройка группы а есть ещё другие настройки. Можно создать правил для целой армии модераторов, да вот вопрос, зачем их столько? Зато банального пагинатора для перечня альбомов нет. Я об этом, что ненужных вещей много а то что нужно мало. А это много, хорошо грузит систему, а пользуется этим человек так 2 из 10 000 что далеко не целевая аудитория. Так что это все «гибко» да не в ту сторону.
В настройка безопасности доступа более 120 чекбоксов и это настройка группы а есть ещё другие настройки. Можно создать правил для целой армии модераторов, да вот вопрос, зачем их столько? Зато банального пагинатора для перечня альбомов нет. Я об этом, что ненужных вещей много а то что нужно мало. А это много, хорошо грузит систему, а пользуется этим человек так 2 из 10 000 что далеко не целевая аудитория. Так что это все «гибко» да не в ту сторону.
Одна из причин выбора своего движка в том, что он заточен под свои нужды и под свою ЦА.
Точить чужой движок под свои нужды и свою ЦА — это плодить те же самые тонны своего кода.
Чужой движок — это потеря контроля над его разработкой. Новая версия — и привет — проверяй как тонна твоих изменений с ней совместима.
Более того, Ваше восхищение чужими движками магазинов несколько подозрительно. Код там конечно иногда красивый, но во многом не менее кривой чем среднеобычный велосипед хорошего программиста. Т.к. эти движки обычно пишут обычные программисты на обычных зарплатах, плюс они еще и меняются от времени ко времени.
Так что наше мнение — работайте над своим движком, проводите иногда рефакторинг, всё.
p.s.: если хотите, посмотрите magento. Малознакомый в росии, но неплохой движок, на голову выше многих советских коммерческих решений.
Точить чужой движок под свои нужды и свою ЦА — это плодить те же самые тонны своего кода.
Чужой движок — это потеря контроля над его разработкой. Новая версия — и привет — проверяй как тонна твоих изменений с ней совместима.
Более того, Ваше восхищение чужими движками магазинов несколько подозрительно. Код там конечно иногда красивый, но во многом не менее кривой чем среднеобычный велосипед хорошего программиста. Т.к. эти движки обычно пишут обычные программисты на обычных зарплатах, плюс они еще и меняются от времени ко времени.
Так что наше мнение — работайте над своим движком, проводите иногда рефакторинг, всё.
p.s.: если хотите, посмотрите magento. Малознакомый в росии, но неплохой движок, на голову выше многих советских коммерческих решений.
P.S. Неплохо, но, имхо, пример того, как в одни язык (PHP) тащат подход из другого (Java). В результате вкатка в сам концепт, в сам уровень абстракции, увеличивается. Цена сапорта такой установки повышается. И такая вроде не сложная задача как «каталог в 250 кпозиций» по заверенью разработчиков возможна только в интерпрайзной редакции, цена которой что-то около 400 круб/год. В таких условия вопрос, а нужно ли пилить свое уже не возникает. Нужно, ибо выходит значительно дешевле и более кастомизированно.
>пример того, как в одни язык (PHP) тащат подход из другого (Java)
это сплошь и рядом, и тяжело объяснить некоторым товарищам что, что для Java хорошо, для РНР может быть плохо :)
это сплошь и рядом, и тяжело объяснить некоторым товарищам что, что для Java хорошо, для РНР может быть плохо :)
Ну явно Java-виский подходя в контексте PHP движка я видел только в Magento. Возможно технически это не очень оправдано, зато наверняка близко разному западному энтерпрайзу, а как ни крути вектор продаж движка направлен именно туда.
Этот подход пришел в Magento из Zend Framework. А уж Zend, будучи разработчиком PHP задает некий ориентир.
Спасибо, рассмешили.
Вы таки вообще не видели изнутри либо зф, либо же маженту.
Вы таки вообще не видели изнутри либо зф, либо же маженту.
Видел и то, и другое.
тогда покажите мне подход «Мы наплодим вам никому не нужных сущностей потому что мы шарим ООП» у зенда.
www.ruilog.com/blog/view/b6f0e42cf705.html — вот это меня убило ;)
Вот вам еще пример подхода — Symfony2. Хотя, наверно, это неправильно сравнивать ее изящество и простое нагромождение абстрактных сущностей в Magento.
Маджента польностью бесплатна, если использовать ее на своем хостинге. Уже делал 2 магазина на ней и, помимо достаточно сложной кастомизации дизайна и функций, она ооочень тяжело ворочается. Простой шаред хостинг для нее не подходит в принципе, а впска нужна не из самых слабых.
Угу. Бесплатная. В Magento Community Edition. А я говорю про Magento Enterprise Edition.
Насколько я там вижу, отличие от Community Edition только в наличии поддержки от разработчиков.
Для одного магазина потребовался каталог в 250 кпозиций (в дальнейшем возможно наращивание до миллиона). Возник вопрос движка. Один из вариантов был Magento. Соответственно разработчикам был задан вопрос о возможности потянуть такой объем данных. Был получен ответ, что под указанные требования под ходит только Enterprise Edition. Я думаю, что разработчикам как-то виднее что может их детище.
я не видел красивого кода в чужих движках…
все работает криво и медленно, например,
дерево категорий вытягивается отдельным запросом на каждой подкатегории (в итоге формирование стр выходит 30-300 запросов),
если это все можно вытянуть одним запросом и затем уже построить дерево средствами РНР.
поиск — однозначно прикручиваем свой сфинкс, притом тюним нудно и долго, так чтоб искал не только по названию, но и отсеивал по характеристикам, или на запрос webcamera выдавал только вэбкамеры, а не тянул за собой 100500 ноутбуков с вэбкамерами
и таких моментов сотни…
все работает криво и медленно, например,
дерево категорий вытягивается отдельным запросом на каждой подкатегории (в итоге формирование стр выходит 30-300 запросов),
если это все можно вытянуть одним запросом и затем уже построить дерево средствами РНР.
поиск — однозначно прикручиваем свой сфинкс, притом тюним нудно и долго, так чтоб искал не только по названию, но и отсеивал по характеристикам, или на запрос webcamera выдавал только вэбкамеры, а не тянул за собой 100500 ноутбуков с вэбкамерами
и таких моментов сотни…
Не согласен с автором. Однако я проголосовал «за» топик, т.к. очень интересно послушать аргументированные чужие мнения, не совпадающие с моим. Жаль что многие не голосуют по этому принципу.
В большинстве случаев лучше использовать свое.
Самопис всегда затачивается под конкретные задачи и не растекается на тысячи абстрактных классов и т.п.
Проблему поддержки кода частично можно решить грамотным документированием.
Самопис всегда затачивается под конкретные задачи и не растекается на тысячи абстрактных классов и т.п.
Проблему поддержки кода частично можно решить грамотным документированием.
теперь немного по теме, есть свои плюсы и минусы:
если хотим что-то стандартное — берем готовое (OpenCart OsCommerce и им подобные) и натягиваем дизайн.
если хотим нагрузки, свой динамический дизайн (c AJAX подгрузкой), особенный поиск по характеристивам товаров, то должны быть готовы в переписывании тонны говнокода.
если хотим что-то стандартное — берем готовое (OpenCart OsCommerce и им подобные) и натягиваем дизайн.
если хотим нагрузки, свой динамический дизайн (c AJAX подгрузкой), особенный поиск по характеристивам товаров, то должны быть готовы в переписывании тонны говнокода.
Не растекается ровно до того времени когда вы поймете что вам его использовать еще не раз и не два :)
Разрабатывали мы как-то мегашоп, за основу взяли OpenCart
там такой говнгокод — пришлось более чем на 50% переписывать функционала админки,
а вторые 50% просто не использовались, так как товары загружались с сайтов партнеров.
— фронтэнд переписали на все 100%
— не оптимизирован под нагрузки совершенно
— нельзя использовать одни и теже классы для фронтэнда и бэкенда, вообще они разделены физически
В других движках с ООП еще хуже дела.
там такой говнгокод — пришлось более чем на 50% переписывать функционала админки,
а вторые 50% просто не использовались, так как товары загружались с сайтов партнеров.
— фронтэнд переписали на все 100%
— не оптимизирован под нагрузки совершенно
— нельзя использовать одни и теже классы для фронтэнда и бэкенда, вообще они разделены физически
В других движках с ООП еще хуже дела.
Подойду с точки зрения- клиента, менеджера проекта. Что нам необходимо, когда мы заказываем у вас интернет-магазин:
1) чтобы все работало
2) чтобы было просто для «девочек»
3) чтобы мы были уверенны в том, что если вы убежите- любой другой специалист все нам сделает.
4) чтобы конкуренты нас не задавили с технической точки зрения(безопасность)
5) чтобы мы могли доделывать фичи и модернизировать
Это с точки зрения самого клиента. Но тут же есть пузомерки хозяина:
1) «А мой сайт сделан на базе Битрикса и вот я какой крутой итд»
С точки зрения возможного гемора, экстренных ситуаций и перевода стрелок ( это я не я такой, а CMS глючная- напишу им- пусть сидят разбираются) — я бы посоветовал платные версии CMS.
P.s. У самого проект на Farpost.CMS
1) чтобы все работало
2) чтобы было просто для «девочек»
3) чтобы мы были уверенны в том, что если вы убежите- любой другой специалист все нам сделает.
4) чтобы конкуренты нас не задавили с технической точки зрения(безопасность)
5) чтобы мы могли доделывать фичи и модернизировать
Это с точки зрения самого клиента. Но тут же есть пузомерки хозяина:
1) «А мой сайт сделан на базе Битрикса и вот я какой крутой итд»
С точки зрения возможного гемора, экстренных ситуаций и перевода стрелок ( это я не я такой, а CMS глючная- напишу им- пусть сидят разбираются) — я бы посоветовал платные версии CMS.
P.s. У самого проект на Farpost.CMS
Плюсы к своему движку:
Когда пишешь на чужом движке/фреймворке — пишешь уже не на языке программирования, (пхп перл питон) а на языке движка/фреймворка, его терминами, абстракциями и тд.
Если нужно сделать что-то «этакое», а чужой движок изучен на уровне «здесь написал так — там появилась еще одна галочка», и как альтернатива — есть свой до строчки понятный движок — я бы выбрал свой.
И ситуация номер 2: Вдруг откуда не возьмись — поведение движка не соответствует ожиданиям. Глюк. Если это свой движок — отладка предельно прозрачна. А если чужой, да еще и время поджимает — стискиваем зубы, лезем в хитросплетения чужого движка. Он написан изящно: комментарии, модули, всё по отдельности понятно, но вместе — тяжело: очень много лишних обвязок, которые могут пригодиться… в общем сложнее исправлять неполадки.
Но свой движок обязательно писать простыми и понятными блоками, комментариями и прочими рекомендациями для хорошего кода. Пусть его никто кроме вас не увидит, но чем черт не шутит.
Минусы своего движка:
Все-таки очень плохо замыкаться в своемвелосипедном заводике коде. Изучая чужие движки/фреймворки обязательно узнаешь новые приемы. Они красивые, удобные и современные.
Когда пишешь на чужом движке/фреймворке — пишешь уже не на языке программирования, (пхп перл питон) а на языке движка/фреймворка, его терминами, абстракциями и тд.
Если нужно сделать что-то «этакое», а чужой движок изучен на уровне «здесь написал так — там появилась еще одна галочка», и как альтернатива — есть свой до строчки понятный движок — я бы выбрал свой.
И ситуация номер 2: Вдруг откуда не возьмись — поведение движка не соответствует ожиданиям. Глюк. Если это свой движок — отладка предельно прозрачна. А если чужой, да еще и время поджимает — стискиваем зубы, лезем в хитросплетения чужого движка. Он написан изящно: комментарии, модули, всё по отдельности понятно, но вместе — тяжело: очень много лишних обвязок, которые могут пригодиться… в общем сложнее исправлять неполадки.
Но свой движок обязательно писать простыми и понятными блоками, комментариями и прочими рекомендациями для хорошего кода. Пусть его никто кроме вас не увидит, но чем черт не шутит.
Минусы своего движка:
Все-таки очень плохо замыкаться в своем
а что плохого в говнокоде? главное, суметь его продать (как Битрикс), а дальше можно хорошо жить с саппорта.
С первых строк подумал «Ба, да я это уже где-то читал». И не ошибся: habrahabr.ru/post/144729/
С первых же строк автор начинает себя нахваливать. И не перестаёт до самого конца.
С первых же строк автор начинает себя нахваливать. И не перестаёт до самого конца.
Блин, но вот опять пишут что я себя нахваливаю! Если вы про работающие магазины и хорошие доходы — это лишь вступление, необходимое, чтобы понять контекст статьи!
А про предыдущую статью — вы правы! Раскусили меня! Можно сказать из одной серии. Но ведь люди то вон как включаются в беседу. Тема и та и та близка для многих. И мне польза, я вижу огромное кол-во полезных комментарий.
А про предыдущую статью — вы правы! Раскусили меня! Можно сказать из одной серии. Но ведь люди то вон как включаются в беседу. Тема и та и та близка для многих. И мне польза, я вижу огромное кол-во полезных комментарий.
Вы пропустили один вариант: например для ror это spree — скелет, обладающий основным функционалом, который можно относительно безболезненно обвешивать своим функционалом. На мой взгляд — это довольно удобно, кода у тебя из коробки есть основные функции, остальной специфичный для ресурса функционал добавляешь сам. К сожалению я не знаю как обстоят дела на других платформах.
На худой конец абстрагироваться от детских ошибок фреймворком.
Все, можете минусовать за ror ))))
На худой конец абстрагироваться от детских ошибок фреймворком.
Все, можете минусовать за ror ))))
Я этот вопрос решил для себя раз и навсегда следующим образом. Сначала перешел с open source cms (Wordpress, Drupal) на framework Ruby on Rails. На котором многое писалось с нуля. Со временем появилось много своих наработок — модель пользователей, страницы, товары, теги и прочее. И сейчас я все свои наработки оформляю ввиде engines (вроде плагинов, но как отдельные приложения), которые можно подключить к любому проекту одной строчкой кода и сэкономить себе в будущем массу времени.
Ну, CMS или в данном случае движек магазина — это
+ готовые реализации часто используемых фич
+ комьюнити с готовыми плагинами для чуть менее используемых фич и зачастую бесплатный хелпдеск на гугле
— чужой код — потемки и мусорка
— локализация, кастомизация и прочая
Если бы речь шла не об магазинах, я бы посоветовал потратиь время и разобраться как работает один-два-три самых популярных и поддерживаемых движков. Это время должно окупиться в будующем использованием чужих модулей и общего фреймворка. Но для магазинов все не так — там собственные наработки важнее и их тупо больше, потому время вложенное в изучение чужого кода может не окупиться.
У меня с магазинами так и не сложилось. В смысле я не знаю хорошего. Поскольку я пишу для буржуев то обычный выбор — Magento, но оно все переООПешное. Любое действие обычно — сделал по быстрому, потом переделал как надо. Фактически стандартные предположения о сроках первым делом надо умножать на два.
для русского рынка это вообще — отказать, потому что реалии другие и выбор модулей тут никакой, поддержка нужный платежных систем чуть больше чем никакая и даже с хостингом будут проблемы.
Я бы, имея свои рабочие наработки, стал бы думать в сторону их улучшения. Подумать, отрефакторить, провести аудит безопастности, уменьшить связность, ввести дополнительные модули. А там глядишь и новый супер движек появиться :)
+ готовые реализации часто используемых фич
+ комьюнити с готовыми плагинами для чуть менее используемых фич и зачастую бесплатный хелпдеск на гугле
— чужой код — потемки и мусорка
— локализация, кастомизация и прочая
Если бы речь шла не об магазинах, я бы посоветовал потратиь время и разобраться как работает один-два-три самых популярных и поддерживаемых движков. Это время должно окупиться в будующем использованием чужих модулей и общего фреймворка. Но для магазинов все не так — там собственные наработки важнее и их тупо больше, потому время вложенное в изучение чужого кода может не окупиться.
У меня с магазинами так и не сложилось. В смысле я не знаю хорошего. Поскольку я пишу для буржуев то обычный выбор — Magento, но оно все переООПешное. Любое действие обычно — сделал по быстрому, потом переделал как надо. Фактически стандартные предположения о сроках первым делом надо умножать на два.
для русского рынка это вообще — отказать, потому что реалии другие и выбор модулей тут никакой, поддержка нужный платежных систем чуть больше чем никакая и даже с хостингом будут проблемы.
Я бы, имея свои рабочие наработки, стал бы думать в сторону их улучшения. Подумать, отрефакторить, провести аудит безопастности, уменьшить связность, ввести дополнительные модули. А там глядишь и новый супер движек появиться :)
Про мадженту на российском рынке поддержу полностью. Сама она сложная, входной порог высокий, стоимость тех или иных работ для большинства российских заказчиков просто пугающая.
Аудит безопасности. Каким образом его проводить, когда ты сам не являешься спецом в этом вопросе. Конечно, общие знания какие-то есть (XSS, SQL-инъекции и т.д.), и даже есть функции для борьбы с этими гадами. Вопросом занимался, интересовался, реализовывал. Но все равно знаю, что тема гораздо обширнее, чем мои знания в этой области, поэтому подозреваю, что дыр много. И найти их я сам не могу. Возникает резонный вопрос: кто может? Искать продвинутого программиста или хакера, какого-нибудь, который может поломать и потестить сайт на данный предмет и представить отчет (не за бесплатно конечно)? Или может есть сервисы какие? Спецы, кто этим специально занимается?
Только своя система.
Столько нюансов, что для их реализации надо в чужой системе разбираться не хуже её создателей. А смысл?
Половина их функционала мне не нужна, а половина нужного мне функционала у них отсутствует.
И надо писать свои «плагины», а на деле — просто заплатки. И при каждом обновлении по новой проверять, а не поломалось ли где чего…
Нет уж.
Грамотно построенная система, нацеленная на расширение — ничуть не хуже любой другой, всё-таки не боги горшки обжигают.
Столько нюансов, что для их реализации надо в чужой системе разбираться не хуже её создателей. А смысл?
Половина их функционала мне не нужна, а половина нужного мне функционала у них отсутствует.
И надо писать свои «плагины», а на деле — просто заплатки. И при каждом обновлении по новой проверять, а не поломалось ли где чего…
Нет уж.
Грамотно построенная система, нацеленная на расширение — ничуть не хуже любой другой, всё-таки не боги горшки обжигают.
один в один мой случай, собрат по счастью/несчастью (нужное подчеркнуть)
весь говнокод свой (на базе CI), уже почти 4 года тьфу-тьфу (разумеется дорабатывается по причине веяний времени, но не более).
и серьезных перевешивающих минусов (на данном этапе и в ближайшем ощутимом будущем) не вижу.
а вот плюсы (как Вы правильно упомянули невозможность многих специфических вещей на стандартных движках) очевидны. Я даже половины тех вещей, что есть сейчас в админке, нигде не встречал (ну кроме базовой простой неприменимой в жизни «в-лоб-реализации». А допиливать кем-то когда-то написанные плагины для какого-нибудь друпала, к примеру… да ну ей богу, мне есть куда потратить время =)
весь говнокод свой (на базе CI), уже почти 4 года тьфу-тьфу (разумеется дорабатывается по причине веяний времени, но не более).
и серьезных перевешивающих минусов (на данном этапе и в ближайшем ощутимом будущем) не вижу.
а вот плюсы (как Вы правильно упомянули невозможность многих специфических вещей на стандартных движках) очевидны. Я даже половины тех вещей, что есть сейчас в админке, нигде не встречал (ну кроме базовой простой неприменимой в жизни «в-лоб-реализации». А допиливать кем-то когда-то написанные плагины для какого-нибудь друпала, к примеру… да ну ей богу, мне есть куда потратить время =)
Я настоятельно автору рекомендую пройти по этой ссылке shopcms.ru/
Установить этот движек и посмотреть «что внутри». Особенно admin.php
Я уверен что ваша самооценка вырастит просто в разы и больше вопросов «писать или не писать» у вас не возникнет :-)
Установить этот движек и посмотреть «что внутри». Особенно admin.php
Я уверен что ваша самооценка вырастит просто в разы и больше вопросов «писать или не писать» у вас не возникнет :-)
На этот вопрос по разному отвечают разработчики и менеджеры. Разработчику во многих случаях лучше писать свой код. Менеджеру во всех случаях лучше, чтобы код был сторонний. Автор правильно указал, что самое главное — это поддержка кода, которая в большинстве случаев делается не разработчиком. Поэтому, если автор является только разработчиком и ему не дано четких указаний — писать свой или использовать сторонний — то лучше писать свой, насколько я понимаю, так для разработчика в данном конкретном случае удобнее. А о поддержке другими можно не заботиться: это головная боль менеджеров и их проблемы, что они приняли решение, которое не позволит им поддерживать продукт в будущем не разрабочтками.
PS: Я был и на месте разработчика, и на месте менеджера. В первом случае всегда писал свое, во втором — всегда требовал, чтобы было стороннее
PS: Я был и на месте разработчика, и на месте менеджера. В первом случае всегда писал свое, во втором — всегда требовал, чтобы было стороннее
А если скажем так: есть надежда стать в своей фирме не просто разработчиком, а руководителем отдела IT и брать на работу других разработчиков. Как быть тогда? Ведь придется их либо натаскивать на свой движок и тем самым создавать и им и себе большие проблемы. И, кстати, компрометировать себя, показывать свои коды. Либо же придется заставлять их писать новый магазин (ны).
Разработчик, надеющийся стать руководителем IT отдела, должен рассуждать как менеджер
Коды можно скрыть от глаз разработчиков. Это заморочка, но можно. Нужно принимать от работников фрагментированный и документированный код. А какой-нибудь главный программист будет собирать все это в кучу. Работники будут знать, что вы им не хотите показывать исходники, и что весь упавший на них рабочий геморрой
— тоже из-за этого. Они скорее всего уйдут или попросят больше оплату.
Так в том то и проблема, что корявые исходные коды могут стать не проблемой другого человека, который будет ими в дальнейшем заниматься, а МОЕЙ, в случае если этот человек будет нанят мной для продолжения моего дела. Это наверное больше всего и гложит!
1. Начальник всегда прав
2. Если не прав, смотри п. 1
Лично я, как автор «не очень красивого» кода, не боюсь, что его потом кто то увидит — а если увидит и укажет на ошибки — так даже лучше, нет предела совершенству. Если стыдно за код — то всегда можно отговорится «это было давно и не правда», и сказать «предложи, как лучше».
Но это уже наверное личное дело каждого.
2. Если не прав, смотри п. 1
Лично я, как автор «не очень красивого» кода, не боюсь, что его потом кто то увидит — а если увидит и укажет на ошибки — так даже лучше, нет предела совершенству. Если стыдно за код — то всегда можно отговорится «это было давно и не правда», и сказать «предложи, как лучше».
Но это уже наверное личное дело каждого.
Я тоже за самописные решения и использую только свою CMS. А уже к своей системе прикручиваю что угодно, независимо от того на фреймворке оно написано или просто куском кода.
Разработку этой CMS, фирма заказчика спонсировала в течение 3-х месяцев по 1000$/мес. (кто-то спрашивал про цены), с условием что в перспективе не будет проблем с наращиванием функционала сайта(ов), а так же, что всеми сайтами они смогут управлять из одной админки. Я лишь упомянул об авторском праве. Заказчика это совершенно не интересовало.
Сделал прототип.
90% CMS получилось классическим велосипедом, но в данной ситуации вопрос о нецелесообразности разработки даже не стоял — в поисковиках о кроссдоменных CMS сложно найти внятную информацию.
Ощутив удобство управления несколькими сайтами из одной админки, я решил создать еще более проработанную версию CMS и вылить в сеть.
Те, кому нужно ежедневно обновлять пару десятков сайтов/сателлитов, будут рады инструменту для работы сразу с сетью. Это не заходить на 20 адресов админок, не вводить 20 раз пару логин/пароль,…, а просто добавить все 20 статей на 20 сайтов одной формой.
Тот же самый выбор станет позже уже перед другим человеком. Он может:
1. использовать мое готовое
2. или создать свой велосипед
3. или допилить известную CMS
И если его выбором будет создание своего такого же велосипеда, то он скорее всего имеет в рукаве пару козырей, например в виде уникальных фич или коммерческой жилки.
Некоторые велосипеды писать можно, а некоторые поздно писать уже с десяток лет. Написать форум может каждый второй вебмастер. Но каждый первый установит бесплатный движок, и скажет форум «готово».
Новичкам, я бы не рекомендовал вообще писать коды форумов, блогов и множества подобной ерунды. Даже в целях обучения. А прежде чем начать программировать, придумать интересную и сложную задачу. Желательно чтобы ее никто не решал. Тогда однажды вы поймете что работаете над перспективным проектом и улыбнетесь, а не взгрустнете от того, что тот форум который вы писали на самом деле нахер никому не нужен.
Разработку этой CMS, фирма заказчика спонсировала в течение 3-х месяцев по 1000$/мес. (кто-то спрашивал про цены), с условием что в перспективе не будет проблем с наращиванием функционала сайта(ов), а так же, что всеми сайтами они смогут управлять из одной админки. Я лишь упомянул об авторском праве. Заказчика это совершенно не интересовало.
Сделал прототип.
90% CMS получилось классическим велосипедом, но в данной ситуации вопрос о нецелесообразности разработки даже не стоял — в поисковиках о кроссдоменных CMS сложно найти внятную информацию.
Ощутив удобство управления несколькими сайтами из одной админки, я решил создать еще более проработанную версию CMS и вылить в сеть.
Те, кому нужно ежедневно обновлять пару десятков сайтов/сателлитов, будут рады инструменту для работы сразу с сетью. Это не заходить на 20 адресов админок, не вводить 20 раз пару логин/пароль,…, а просто добавить все 20 статей на 20 сайтов одной формой.
Тот же самый выбор станет позже уже перед другим человеком. Он может:
1. использовать мое готовое
2. или создать свой велосипед
3. или допилить известную CMS
И если его выбором будет создание своего такого же велосипеда, то он скорее всего имеет в рукаве пару козырей, например в виде уникальных фич или коммерческой жилки.
Некоторые велосипеды писать можно, а некоторые поздно писать уже с десяток лет. Написать форум может каждый второй вебмастер. Но каждый первый установит бесплатный движок, и скажет форум «готово».
Новичкам, я бы не рекомендовал вообще писать коды форумов, блогов и множества подобной ерунды. Даже в целях обучения. А прежде чем начать программировать, придумать интересную и сложную задачу. Желательно чтобы ее никто не решал. Тогда однажды вы поймете что работаете над перспективным проектом и улыбнетесь, а не взгрустнете от того, что тот форум который вы писали на самом деле нахер никому не нужен.
Пользуюсь своей цмс — скорость генерации в 0.03 сек.
Надежность, безопасность, скорость — за все отвечаете Вы. Использовать ли фреймворки?
Если Вы пишете плохой код, то да.
Надежность, безопасность, скорость — за все отвечаете Вы. Использовать ли фреймворки?
Если Вы пишете плохой код, то да.
Железо на сервере, нагрузка в конкретный момент времени, число и сложность запросов к БД, и сам код, определяют скорость генерации ответа, поэтому она совсем не показатель.
Я имел ввиду, что сравнивая свою цмс и фреймворк у Вас 1 усредненное железо.
При установке на него цмс и допиленного фрейворка — собственная цмс уделяет любое решение по производительности. Конечно с учетом ровных рук.
А сложность запросов и код — есть результат ровных или кривых рук.
При установке на него цмс и допиленного фрейворка — собственная цмс уделяет любое решение по производительности. Конечно с учетом ровных рук.
А сложность запросов и код — есть результат ровных или кривых рук.
Хотите более-менее адекватный тест — пройдите проверку а-ля Yii.
Нагуглите их тест, описание и цифры, и сравните.
По сути, там тестируется Hello, World, который проверяет скорость запуска, сложность ядра и другие показатели, не обращая внимания на сложность самого кода контроллеров/моделей и сложности SQL-запросов.
Хотя 0.03 — неплохо (если разумеется, кеширование всё отключено, иначе — нехорошо).
Нагуглите их тест, описание и цифры, и сравните.
По сути, там тестируется Hello, World, который проверяет скорость запуска, сложность ядра и другие показатели, не обращая внимания на сложность самого кода контроллеров/моделей и сложности SQL-запросов.
Хотя 0.03 — неплохо (если разумеется, кеширование всё отключено, иначе — нехорошо).
Всё верно, кроме фразы «Использовать ли фреймворки? Если Вы пишете плохой код, то да.»
Гитхаб написан на фреймворке, и твиттер тоже, и групон.
Гитхаб написан на фреймворке, и твиттер тоже, и групон.
Знакомая ситуация. Выхода вижу 2:
1. Если пишутся какие то уникальные рекламные акции и другие маркетинговые финты ушами то лучше эту логику привязывать к инет магазу другими скриптами а не делать ее внутри магаза. Один из лучших что я видел это amember. Насколько я понял написан русскими программерами но ориентирован на запад (и там офигенно популярен)
2. Выбрал я сам. У меня исторически сложился стиль работы «нафига делать то что уже есть и часто бесплатно». То есть пошел по пути cms и плагинов/модулей. Со временем стал понимать что у каждой cms — своя специализация и под разные хотелки заказчиков надо либо ту либо другую юзать. Весь этот зоопарк в голове держать — эт сума сойти можно. Начал тестить фреймворки — все круто но трудозатраты на простые вещи возросли. В итоге пришел к некоему балансу: простые вещи (аля визитки) это Wordpress, сложные/нестандартные вещи asp.net. Почему не php? Ответ прост: на пыхапэ есть куча бесплатного и замечательного но как только начинаешь это пытаться подпилить или объединить — автоматом огребаешь кучу гемора и это системная проблема. В win платформе это тоже встречается но реже. и трудозатраты на привинчивание одной вин-штуки к другой — на порядки меньше. Например был один извращенный эксперимент: к asp сайту привязывал функции onenote и visio (из msoffice 2010) — трудозатрат — 1 вечер. Да разработка дороже — но плюшек в виде личной производительности — заметно выше.
1. Если пишутся какие то уникальные рекламные акции и другие маркетинговые финты ушами то лучше эту логику привязывать к инет магазу другими скриптами а не делать ее внутри магаза. Один из лучших что я видел это amember. Насколько я понял написан русскими программерами но ориентирован на запад (и там офигенно популярен)
2. Выбрал я сам. У меня исторически сложился стиль работы «нафига делать то что уже есть и часто бесплатно». То есть пошел по пути cms и плагинов/модулей. Со временем стал понимать что у каждой cms — своя специализация и под разные хотелки заказчиков надо либо ту либо другую юзать. Весь этот зоопарк в голове держать — эт сума сойти можно. Начал тестить фреймворки — все круто но трудозатраты на простые вещи возросли. В итоге пришел к некоему балансу: простые вещи (аля визитки) это Wordpress, сложные/нестандартные вещи asp.net. Почему не php? Ответ прост: на пыхапэ есть куча бесплатного и замечательного но как только начинаешь это пытаться подпилить или объединить — автоматом огребаешь кучу гемора и это системная проблема. В win платформе это тоже встречается но реже. и трудозатраты на привинчивание одной вин-штуки к другой — на порядки меньше. Например был один извращенный эксперимент: к asp сайту привязывал функции onenote и visio (из msoffice 2010) — трудозатрат — 1 вечер. Да разработка дороже — но плюшек в виде личной производительности — заметно выше.
Господа, надо мыслить логически, и не основываться на предположениях, говоря о теоретической куче наработок для фреймворка или сайта-за-один-вечер на CMS.
Вот мы как сделали — проанализировали ряд сделанных проектов, и просмотрели таблицу соотношения стоимость/срок создания. Получилась составляющая рублей-в-день. По ней отсортировали.
Она различалась от 20000 до 1800 для всех сайтов на самописном фреймворке.
В самом низу оказались два проекта на bitrix и Joomla.
Joomla 500.
Bitrix 250.
Вот и всё, проверить гораздо проще, нежели предположить. Это что касается сроков.
А теперь отсебятина.
Опытный программист может написать свою CMS/Фреймворк. Там будет всё — красивый код, поддержка UTF-8, и так далее. Далее можно посоветовать этому программисту глянуть в код существующих CMS, либо их модулей (в случае Joomla, например). И тогда мучительные вопросы выбора отпадут сами собой.
Это что касается качества.
Далее (если это действительно важный вопрос) попросите маркетолога оценить риски при использовании CMS. В разных случаях они будут разными, в случае bitrix их целый ворох — выкидывание с хостинга, отсутствие поиска по каталогу, пессимизация поисковикам за долгое время ответа, переплата за доработки, проблемы с интеграцией с 1С и так далее. Их можно перевести в рубли — будет много.
Это что касается денег.
Вот мы как сделали — проанализировали ряд сделанных проектов, и просмотрели таблицу соотношения стоимость/срок создания. Получилась составляющая рублей-в-день. По ней отсортировали.
Она различалась от 20000 до 1800 для всех сайтов на самописном фреймворке.
В самом низу оказались два проекта на bitrix и Joomla.
Joomla 500.
Bitrix 250.
Вот и всё, проверить гораздо проще, нежели предположить. Это что касается сроков.
А теперь отсебятина.
Опытный программист может написать свою CMS/Фреймворк. Там будет всё — красивый код, поддержка UTF-8, и так далее. Далее можно посоветовать этому программисту глянуть в код существующих CMS, либо их модулей (в случае Joomla, например). И тогда мучительные вопросы выбора отпадут сами собой.
Это что касается качества.
Далее (если это действительно важный вопрос) попросите маркетолога оценить риски при использовании CMS. В разных случаях они будут разными, в случае bitrix их целый ворох — выкидывание с хостинга, отсутствие поиска по каталогу, пессимизация поисковикам за долгое время ответа, переплата за доработки, проблемы с интеграцией с 1С и так далее. Их можно перевести в рубли — будет много.
Это что касается денег.
>> КАК он будет разбираться с тем, что я сделал??? Ведь самый большой косяк всех самописных движков, на мой взгляд, что постороннему человеку в нем нереально разобраться.
1. После написания первого движка всё-таки изучить и начать применять подходы к проектированию архитектуры и предметной области (доменной модели).
2. Документация. Хотя бы на уровне: описание пользовательской задачи — описание её технического решения. Т.е. ответ на вопросы: «Что делает пользователь?» «Что его может ожидать?» «Почему выбрано такое решение?»
3. Полное покрытие юнит тестами предметной области (domain model) и интеграционные тесты для инфраструктуры (выборки\вставки из БД и запросы к веб-сервисам). Это минимум.Но это поможет понять что делает тот или иной модуль. На себе испытал ускорение внесение изменений в ХХХ раз. Без тестов больше не пишем.
4. Использовать шаблоны проектирования. Если сменщик будет грамотный, то он узнает правильно примененный шаблон. А если джуниор или говнокодер, считающий себя синьором, то ему ни легче ни тяжелее будет от красивой архитектуры.
5. Соблюдения правил написания хорошего кода всей командой и постоянный текущий рефакторинг и рефакторинг устоявшихся за 2-3 неделю частей. Я, например, только под дулом пистолета буду пользоваться методом, который больше 10-15 строк. Потому что я смогу только догадаться, что он на самом деле делает или может делать. Как он работает или должен работать знает только Бог и автор. Соответственно, могу накосячить сам того не ведая. Можно, конечно, этого не делать. Так многие и начинают. Но потом переписывают заново. Стоимость выше. Клиент уходит, говоря, что я не буду платить за новую фичу столько, сколько отдал за целый сайт, хотя раньше, «год назад», он говорил обратное: «Давайте поскорее запустим магазин, а там видно будет и мне вообще не нужен ваш этот рефакторинг».
Про всё вышеописанное следует прочесть по книге и попробовать применить не менее 3 раз(3х проектов или модулей). Статей и тем более форумных дискуссий\мнений не достаточно. Первые 1-2 попытки только шишек набить помогут, 3я уже принять решение позволит. Но делать нужно в точности по книгам сперва, потом отклонения уже свои внедрять. Иначе получиться как всегда «фигня этот ваш… Мы все сделали, а оно не работает как мы хотели».
1. После написания первого движка всё-таки изучить и начать применять подходы к проектированию архитектуры и предметной области (доменной модели).
2. Документация. Хотя бы на уровне: описание пользовательской задачи — описание её технического решения. Т.е. ответ на вопросы: «Что делает пользователь?» «Что его может ожидать?» «Почему выбрано такое решение?»
3. Полное покрытие юнит тестами предметной области (domain model) и интеграционные тесты для инфраструктуры (выборки\вставки из БД и запросы к веб-сервисам). Это минимум.Но это поможет понять что делает тот или иной модуль. На себе испытал ускорение внесение изменений в ХХХ раз. Без тестов больше не пишем.
4. Использовать шаблоны проектирования. Если сменщик будет грамотный, то он узнает правильно примененный шаблон. А если джуниор или говнокодер, считающий себя синьором, то ему ни легче ни тяжелее будет от красивой архитектуры.
5. Соблюдения правил написания хорошего кода всей командой и постоянный текущий рефакторинг и рефакторинг устоявшихся за 2-3 неделю частей. Я, например, только под дулом пистолета буду пользоваться методом, который больше 10-15 строк. Потому что я смогу только догадаться, что он на самом деле делает или может делать. Как он работает или должен работать знает только Бог и автор. Соответственно, могу накосячить сам того не ведая. Можно, конечно, этого не делать. Так многие и начинают. Но потом переписывают заново. Стоимость выше. Клиент уходит, говоря, что я не буду платить за новую фичу столько, сколько отдал за целый сайт, хотя раньше, «год назад», он говорил обратное: «Давайте поскорее запустим магазин, а там видно будет и мне вообще не нужен ваш этот рефакторинг».
Про всё вышеописанное следует прочесть по книге и попробовать применить не менее 3 раз(3х проектов или модулей). Статей и тем более форумных дискуссий\мнений не достаточно. Первые 1-2 попытки только шишек набить помогут, 3я уже принять решение позволит. Но делать нужно в точности по книгам сперва, потом отклонения уже свои внедрять. Иначе получиться как всегда «фигня этот ваш… Мы все сделали, а оно не работает как мы хотели».
Спасибо за тему. Она многим близка.
К сказанному уважаемыми хабраюзерами я бы добавил только одно, но на мой взгляд важное утверждение:
«Если вы получаете удовольствие от работы над своим движком — работайте над ним».
Я, как и вы, постоянно в состоянии выбора — писать свое или искать готовое.
Столько вокруг движков, фрейморков, библиотек, столько интересного, что хотелось бы когда-нибудь изучить и применять.
Я почти всегда выбираю писать своё. Я тоже работаю преимущественно один и могу себе это позволить.
Вспоминая такие моменты, я отчетливо понимаю — выбрал «написать самому», потому что мне это интересно, я получаю от этого удовольствие.
Я оставляю движки и фреймворки тем, кто без них еще или уже не может. Тем, кто получает за это деньги.
К сказанному уважаемыми хабраюзерами я бы добавил только одно, но на мой взгляд важное утверждение:
«Если вы получаете удовольствие от работы над своим движком — работайте над ним».
Я, как и вы, постоянно в состоянии выбора — писать свое или искать готовое.
Столько вокруг движков, фрейморков, библиотек, столько интересного, что хотелось бы когда-нибудь изучить и применять.
Я почти всегда выбираю писать своё. Я тоже работаю преимущественно один и могу себе это позволить.
Вспоминая такие моменты, я отчетливо понимаю — выбрал «написать самому», потому что мне это интересно, я получаю от этого удовольствие.
Я оставляю движки и фреймворки тем, кто без них еще или уже не может. Тем, кто получает за это деньги.
Кстати, каждый может провести эксперимент: перечислите свои любимые 10 онлайновых магазинов и проверьте, сколько из них работают на «типовых всем известных движках без изобретения велосипедов». Едва ли наберется хотя бы 2-3. Скорее всего даже ни одного из 10. Так что…
Дилемму «брать готовое» или «писать своё» можно изложить и так: «быть как все и не париться» или «попробовать сделать лучше».
Дилемму «брать готовое» или «писать своё» можно изложить и так: «быть как все и не париться» или «попробовать сделать лучше».
Рано или поздно, по разным причинам, в любом проекте меняется разработчик. Вы когда-нибудь слышали (а скорее всего и произносили) такую фразу: «здесь нужно все снести нафиг и переделать заново!!»? Программисты НЕНАВИДЯТ и ленятся разбираться в чужом коде! Даже если есть документация и движок написан по всем законам проектирования. А если будет разбираться, то возьмет за это с клиента сумму, сопоставимую с переносом на другой движок. В итоге, вместо развития проекта клиент вынужден вкладываться второй раз в его разработку. Я лично видела не один десяток таких рыдающих клиентов, твердо намеренных перейти на коробку.
И второе — вы говорите, что при обновлении коробочного движка часто слетают кастомы. Это неверно! Качественные коробочные продукты спроектированы таким образом, что кастомы, разработанные по документации разработчика, пишутся в отдельно отведенный для этого файл/директорию и не затрагиваются при обновлении системы.
Кстати — а самописный движок вы вообще обновляете?
И второе — вы говорите, что при обновлении коробочного движка часто слетают кастомы. Это неверно! Качественные коробочные продукты спроектированы таким образом, что кастомы, разработанные по документации разработчика, пишутся в отдельно отведенный для этого файл/директорию и не затрагиваются при обновлении системы.
Кстати — а самописный движок вы вообще обновляете?
«Программисты НЕНАВИДЯТ и ленятся разбираться в чужом коде! „
Ну зачем же так жестко? Мне чужой код, написанный согласно этого стандарта, так же легко читать как и свой. А вот смотрю (к примеру) код битрикса — и говорю, я вам сделаю 30% скидку, но надо переписать.
Ну зачем же так жестко? Мне чужой код, написанный согласно этого стандарта, так же легко читать как и свой. А вот смотрю (к примеру) код битрикса — и говорю, я вам сделаю 30% скидку, но надо переписать.
В обоих моих самописных движках были случаи, когда обновлялось ВСЁ, в т.ч. структура хранения данных. Кастомы были на месте. Да, у движка есть система обновлений, и да, ничего не слетает, и да, можно переопределить всё, включая куски ядра, которые будут обновляться впоследствии.
Также были случаи, когда слетали кастомы битрикса, шопскрипта, джумлы, некоторые случаи были смешные.
Именно поэтому переходим к первому Вашему предложению — программисты ненавидят разбираться в коде на битриксе и подобных ерундовинах, и суммы, потраченные на CMS всегда выше (да, мы делали измерения).
И наконец, однажды сам лез в код на чужой велосипедной админке, которая была сделана на фреймворке Codeigniter, которого я тогда не знал. Надо было сделать карту сайта + поиск по всем разделам, а их много, размазаны по сайту и по таблицам.
Итог — 6 строк кода, и работает. Да, я НЕНАВИЖУ разбираться в коде на нынешних популярных CMS, потому что результат меня поражает. Да, я ЛЮБЛЮ ковыряться в чужом качественном коде велосипедных CMS, потому что можно делать гибкие фичи за пару строк — а ведь именно из-за возможности видеть результат, сделанный своими руками после пары строк я и стал программистом.
Например, возьмём некий «чужой код» получения списка 10 новостей.
Это всё, действительно всё.
А теперь посмотрим на код битрикса
И это — не получение. Это кусок связанного монолита «шаблон + код системы», в который вшиты наглухо параметры IBLOCK_TYPE и другие. Я уже молчу, что такой код пишут не ручками (хотя и такие извращенцы бывают), а вставляют через GUI.
Также были случаи, когда слетали кастомы битрикса, шопскрипта, джумлы, некоторые случаи были смешные.
Именно поэтому переходим к первому Вашему предложению — программисты ненавидят разбираться в коде на битриксе и подобных ерундовинах, и суммы, потраченные на CMS всегда выше (да, мы делали измерения).
И наконец, однажды сам лез в код на чужой велосипедной админке, которая была сделана на фреймворке Codeigniter, которого я тогда не знал. Надо было сделать карту сайта + поиск по всем разделам, а их много, размазаны по сайту и по таблицам.
Итог — 6 строк кода, и работает. Да, я НЕНАВИЖУ разбираться в коде на нынешних популярных CMS, потому что результат меня поражает. Да, я ЛЮБЛЮ ковыряться в чужом качественном коде велосипедных CMS, потому что можно делать гибкие фичи за пару строк — а ведь именно из-за возможности видеть результат, сделанный своими руками после пары строк я и стал программистом.
Например, возьмём некий «чужой код» получения списка 10 новостей.
$news = d()->News->limit(10);
Это всё, действительно всё.
А теперь посмотрим на код битрикса
<?$APPLICATION->IncludeComponent("bitrix:news.detail","",Array(
"DISPLAY_DATE" => "Y",
"AJAX_MODE" => "Y",
"IBLOCK_TYPE" => "news",
"IBLOCK_ID" => "3",
/* .... */
)
);?>
И это — не получение. Это кусок связанного монолита «шаблон + код системы», в который вшиты наглухо параметры IBLOCK_TYPE и другие. Я уже молчу, что такой код пишут не ручками (хотя и такие извращенцы бывают), а вставляют через GUI.
тоже посещают подобные мысли, только проекты начинаю не очень часто, восновном все большие. Но вот как подумаешь, для того чтобы сделать привычную вещь X нужно потратить времени в 5 раз больше чем обчно, а сроки поджимают, так понимаешь, что пока все таки свое. Хотя сегодня поразбирался с симфони2, и очень понравилось, особенно наличие кучи бандлов на все случаи жизни. Для себя вижу такой выход — пока в фоне изучать и пробовать различные заковыристые вещи в новом фреймворке, когда уровень владениям им станет хоть более-менее приличным, попробовать сделать реальный проект
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Извечный вопрос: CMS или свой движок