Сайт как бизнес

Поисковое продвижение сайтов (SEO), создание сайтов в Минске (Беларусь).


Канал «СТАРТАП ТЕХНОЛОГИИ»: об ИТ-бизнесе, стартапах, инвестициях

Подпишись на рассылку блога об интернет-бизнесе:

CMS vs FRAMEWORK или прогибаем или прогибаемся под заказчика

пока нет комментариев

..Навеянно размышлениями о жизни…

Опробовав не одно CMS решение я задумался — какое же оно должно быть то..именно то, что доставляло бы радость при создании новых проектов. Будучи реалистом по жизни я не пытаюсь найти решение которое бы управлялось силой мысли, и могло бы построить то что хочет заказчик исключиельно словами «Трах-тибидох-тибидох…».

Все таки — какое оно — то решение которое подходило бы для всех Web проектов любой сложности, архитектуры и каскадности.. Я не любитель оперировать абстрактными понятиями типа «масштабируемо», «дружелюбно к пользователю», «изящно в архитектуре»..

На мой взгляд решение должно быть:

  1. Отталкиваться от желаний заказчика, т.е. заказчик задает условия для будущего web приложения, а не наоборот. Зачастую обращаясь к студиям мы слышим: «Наша CMS поистинне безгранична, но вот к сожалению то что вам надо — это вот совсем что то выходящее за рамки общепринятого в нашей галактике понимания, и это никто вам не сделает…»
  2. Быть относительно портабельным. Т.е. не привязанному к низкоуровневым функциям, классам, библиотекам, например к тому же PEAR (хотя многие настоятельно рекомендуют использовать его)
  3. Иметь бесконечное (да да, именно безконечное) множество степеней свободы данных — всевозможный связей таблиц, множеств таблиц, и т.д.
  4. Иметь возможность масштабироваться (в плане дополнения различного функционала)
  5. Быть высоко производительным, т.к. когда речь идет именно о Web — это играет не последнюю роль.

Исходя из всех перечисленных параметров можно рассмотреть следующие варианты решений:

  1. CMS — на рынке представленно огромное количество как платных так и бесплатных продуктов: Битрикс, Joomla, Drupal..
  2. Framework — тут явно рынок становится скуднее и на ум приходит Symphony
  3. Писать каждый раз под требования заказчика что то свое :)

CMS - оптимальны способ «срубить денег» и отдать заказчику вариант рабочий вариант сайта, но в дальнейшем вряд ли он будет приносить удовольствие, деньги.. Всего скорей он умрет через год-два, его заменит другая CMS которая уже будет больше навернута, выполнять текущие потребности но не более — в итоге замыкаемся в цикл: придумали-сделали-заплатил-придумали-сделали-заплатил. Тут можно много и долго спорить, но я за всю свою жизнь ниразу не видел решения уровня CMS которое подходило бы на все 100% к проектам любого типа.

Резюме: CMS — это решение для краткосрочных бесперспективных проектов. Сделал, получил денежку, забыл. О главной цели — нацеленность на удовлетворение клиента можно забыть напрочь.

Каждый раз новая разработка — довольно нестандартный подход, хотя отличается своей гибкостью. Однозначно заказчик останется доволен функционалом, т.к. сделать можно даже «с розовыми рюшечками», но такого вида работа хороша только студентам, у которых всегда дилема — вечерами пить пиво и рассказывать на однокласниках какую он сегодня «телку» видел или «состричь» деньжат завтра на пивас. Другими словами имея избыток времени на полную фазу разработки: анализ-проектирование-разработка-тестрование-сдача это оптимальный вариант. Но никак не подходящий для веб студий, т.к. при трудозатратах на простейший сайт в 300 человеко-часов можно наработать только на долг, равный внешнему долгу какого Гандураса или другой Африканской республики

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

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

Четко описывать модель данных приложения, должен уметь строить классы доступа к описанным данным, и иметь свой web интерфейс с вспомогательными функциями: авторизация, логи, бла-бла-бла.

Имея такой арсенал у себя в запасе вы сможите:

  • Подстроится под потребности заказчика, даже если у него будут неимоверно сложные процессы и связи данных, которые необходимо перенести в веб
  • Сэкономить кучу времени на написания системы управления этими данными
  • Построить гибкое приложение которое всегда можно будет с легкостью перестроить, дополнить, изменить

Как раз именно такое решение мы имеем у себя на вооружении. Речь идет о компилирущем фреймворке, в котором в виде XML структуры мы описываем модель данных и их взаимодействие. Далее компилируем описаную модель и на выходе получаем классы для работы с данными, сами данные и собственно web интерфейс для управления ими.

Теперь дело за малым — просто сделать Front-end для сайта, т.е. написать бизнес логику, натянуть шаблоны, протестировать, сдать и дальше за работу!

Резюме для заказчиков: не становитесь заложником навязываемой вам структуры данных. Почему ваш бизнес должен прогибаться под кого-то? Пускай кто то прогнется под вас!



Автор: Валерий Хвалев.

10 ноября, 2008 в 1:16 дп

Подпишись на обновления блога по e-mail или RSS!

Оставить мнение