x
 
Юрий
24 мая 2012

Здравствуйте!

Используете ли вы готовые ЦМС?
И как вы к ним относитесь, например, к Вордпрессу, Друпалу, Джумле?
И то же по фреймворкам — «Симфони» или что-то в этом духе?
Пользуетесь ли вы работой, которая уже была сделана кем-то, чтобы упростить жизнь?

Спасибо :-)



Юрий!

Бюро использует разные технологии, как самописные, так и промышленные. Это касается не только фреймворков, но и частей системы. Например, в качестве поискового движка в Советах используется Сфинкс, а в Дизайн-собаке — собственный, основанный на ПХП-морфи. К тому же, в работе с клиентами бюро постоянно сталкивается c разными системами. Уже успели поработать с Дотнетом, Битриксом, Йии и Гугл-вебтулкитом.

В любом деле важно полезное действие. Как правило, полезное действие выражается через бизнес-задачу. Если у вас есть хорошая рабочая идея, которую надо представить в интернете, то ЦМС может быть правильным решением. Модульная ЦМС с магазином готовых дизайнов избавит вас от необходимости программировать вообще. Это достаточно дешёвый способ выйти на рынок и начать зарабатывать на идее. Накопив первичный капитал, поразмыслите, действительно ли стоит писать систему под себя.

Другое дело — фреймворки. Они используются для создания интернет-проектов, когда программирование функционала является бизнес-задачей. Но, как это не удивительно, большинство фреймворков очень далеки от бизнес-задач. Они решают искусственные проблемы, созданные одними программистами для других программистов. Вместо того, чтобы описывать понятные вещи типа веб-страницы, обработчика пользовательского ввода или данных, они оперируют совершенно непонятными сущностями типа эктив рекодр, кэш, ОРМ, персистенс лейер, модель, вью, контроллер.

Мне, к примеру, непонятно, чем настолько плох Эс-кью-эль, чтобы оборачивать его в эктив рекорд. Проекты меняют СУБД не еженедельно, а при правильной архитектуре поправить запросы займёт не больше дня.

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

Тем не менее, в действительно большом проекте фреймворк может сэкономить недели разработки, а если в него легко интегрируется система автоматического тестирования, то и недели пусконаладки. Но если вы начнёте с малого, не используя сразу готовую систему, то раньше выпустите продукт. В процессе роста сможете развить вашу разработку, вырастив свой фреймворк из её внутренностей. Благо, все хорошие приёмы достаточно описаны в интернете. О самом важном из них я напишу.

Смотрите также совет об админках в ЦМС.

Я не побоюсь сказать, что Модель-вид-контроллер — просто «форсированный мем». Использование МВЦ не даёт гарантии хорошего кода. Главное в любой системе — архитектура. Можно написать проект на голом ПХП, Си++ или используя «Симфони». Важно, чтобы вся работа команды подчинялась каким-либо соглашениям. Без них вместо продукта получится неуправляемый монстр Франкенштейна.

Иногда без так называемого «говнокода» не обойтись. Чтобы избежать пагубного влияния, нужно локализовать места его обитания. Можно просто решить, где он допустим, а где нет. Я совершенно спокойно отношусь к говнокоду, который генерирует страницы, но нетерпим к нему в машинном отделении: модулях, которые отвечают за работоспособность системы в целом. Страница может измениться несколько раз за месяц, при этом никак не повлияв на остальные, и порой просто нет смысла вылизывть внутренности. Пустая трата времени.

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

Все ЦМС и фреймворки — просто инструменты. Выбор зависит от задачи, навыков команды и доступного времени на разработку.

Заметка Ильи Бирмана на английском про дизайн ПХП.

P. S.
Это был совет о разработке сайтов. Хотите узнать всё об умной вёрстке, правильных скриптах, грациозной деградации, трюках и работе технолога с дизайнером? Присылайте вопросы.

Поделиться
Отправить

Комментарии

Павел Карасев
24 мая 2012

После 10 лет в профессии я вывел для себя одно золотое правило: «Чем система проще, тем дешевле она обходится». Некоторые неопытные ребята просят уточнить. И я уточняю. Дешевле — во всём: в деньгах, во времени, в поддержке.

Серёжа Переверзев
24 мая 2012

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

У меня пока небольшой опыт, я только начинаю на реальных задачах чувствовать, зачем нужны те или иные шаблоны проектирования, и еще, пожалуй, не достиг того уровня, чтобы осознать, что они не нужны в принципе :) Лучшее — враг хорошего, это правда. Залезать в дебри абстракций просто так опасно — получаются неприменимые на практике, тяжеловесные, бесполезные продукты. Важно правильно выбрать актуальный для текущей задачи уровень расширяемости и не забывать вовремя рефакторить :) Однако упомянутые шаблоны не так уж бессмысленны: эктив рекорд, например, может позволить вообще забыть о том, что в проекте применяются какие-то там базы данных, и просто считать, что есть некий механизм, позволяющий хранить состояние объектов вне пределов текущего пользовательского запроса.

Про предназначение ПХП очень метко, кстати.

Евгений Волков
6 июня 2012

Хотелось бы добавить пару мыслей, чтобы читатели не принимали совет однобоко.

На мой взгляд, любому современному веб-разработчику необходимо владеть и понимать принципы пары-тройки ЦМС и столькими же фреймворками. Если вы веб-разработчик, но ещё не касались пальцами фреймворка, то надо идти и касаться, выносить полезное, отмечать вредное — расти и развиваться, в общем. Если вы ас в одной из ЦМС, то возьмите и поставьте любую другую популярную, всегда можно вытащить что-то полезное из новоизученного.

Для меня когда-то открытием стал фреймворк Руби-он-рейлс, сначала я его сторонился, потому что он (как и многие другие) отражает совершенно иной подход к разработке. Но зато он знакомит с принципами ведения хорошего кода, рефакторинга и прочего полезного, что в целом делает из вас лучшего разработчика. Лично мне этот фреймворк подарил довольно чёткое понимание, что такое код и как с ним надо обращаться, плюс представление неплохой архитектурной модели. Да, там и отдельный синтаксис роутинга, и эктив-рекорд, и МВЦ, но это всё должно быть знакомо лишь потому, что эти все продукты распространены на рынке и в любой момент может появиться необходимость их использовать.


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

EM или REM? 6 Можно ли достичь эффекта переливания без встраивания видео на сайт? 1




Недавно всплыло

1 1 7 Иногда я спрашиваю о скидке для тренировки и потому что не против шанса сэкономить 1