Блокова модель розробки на CMS Vi-Site 5.0

13 Квітня 2020

1. Передісторія

До недавнього часу ми розробляли сайти за стандартною схемою, назвемо її – «шаблонна модель розробки».

Сайт розбивався на шаблони, припустимо: головна сторінка, контакти, розділ новин, окрема новина, якась контентна сторінка і так далі, а кількість таких шаблонів могла сягати сотні великих проєктів. Потім оцінювали кожен шаблон, верстку та програмування, і так само розробляли їх, верстали та програмували кожен шаблон окремо.

У командній роботі це виглядало приблизно так.

Верстальник Інокентій верстає головну сторінку, верстальник Гавриїл верстає сторінку контакти, і так далі. Після верстки програміст Опанас програмує головну сторінку, а програміст Женаїда бере на роботу сторінку контактів. І так шаблончик до шаблончика, і виходив сайт.

2. Проблема

Все було класно, але якщо подивитися на шаблони уважніше, то можна помітити, що багато блоків у цих шаблонів повторюються, а змінюється тільки контент в них. Шапку та футер сайту не беремо до уваги, адже вони майже завжди однакові на всіх шаблонах сторінок.

Шаблон #1

Шаблон #2

Як бачимо, це різні шаблони, але блоки банер, хлібні крихти, заголовок h2 однакові, а змінюється лише контент.

Розробляючи за шаблонним методом верстальники Інокентій та Гавриїл робили б одне й те саме, або їм доводилося б якось домовлятися між собою, щоб не виконувати подвійну роботу. Така сама проблема була і у програмістів.

Бували випадки коли все вже зверстано і запрограмовано, а клієнт раптом захотів поміняти блоки місцями або вирішив на одній сторінці сайту більше не використовувати верхній банер.

Зазвичай наша реакція така: "Блін, ми вже всі запрограмували і дизайн був раніше затверджений!". У результаті доводилося створювати новий шаблон, де були реалізовані всі побажання клієнта. А що робити якщо таких буде з десяток чи сотня?

У результаті дедлайни переносяться, клієнт не задоволений, що ми не встигаємо вчасно здати сайт і доводиться переробляти по кілька разів один і той же шаблон.

3. Вирішення проблеми

На допомогу прийшла «блочна модель розробки». Ми вже пробували її впроваджувати раніше на деяких сайтах і зачатки були зроблені 1-2 роки тому, але зараз з появою нової версії CMS «Vi- Site 5.0» і з урахуванням нюансів, які були з цією моделлю розробки на минулих проєктах, ми змогли зробити нове та близьке до ідеалу рішення. Але, ясна річ, що ідеалу не існує, і ця модель поступово доопрацьовуватиметься і розвиватиметься.

4. У чому суть нового рішення?

Ми перестали розробляти шаблони, а тепер розробляємо лише блоки.

У CMS замість 50-70 різних шаблонів, які клієнт може застосовувати для відображення сторінок, тепер існує лише один шаблон для вибору, ми його назвали «універсальний шаблон». Його можна застосувати до будь-якої сторінки на сайті та наповнити доступними блоками. При цьому можна змінювати порядок відображення та контент блоків так, як забажає клієнт, і не прив'язуватись до початкового дизайну.

Наприклад, для сторінок вище в CMS шаблон виглядатиме приблизно так.

Блочна модель розробки

Кожен блок має перегляд, в якому видно, як він виглядатиме на сторінці сайту. Всі блоки згруповані за типами для спрощення пошуку за ними.

5. Що це дає?

Переваги для клієнта:

  • Можливість наповнювати сторінки сайту блоками та контентом так, як він захоче сам, без втручання верстальника та програміста.
  • Економія часу, адже не потрібно розробляти новий шаблон, а потрібно лише з доступних блоків скласти сторінку, як з конструктора.
  • Економія грошей, такий підхід дозволяє знизити час людино-годин на розробку сайту у 2-3 рази! Як? Поясню нижче.
  • Менше багів, виключаються ситуації коли правлять код в одному місці, а зламалося щось у зовсім іншому. Оскільки кожен блок живе своїм життям, і він ніяк не пов'язаний з іншими блоками.
  • Додаткова перевага в новій CMS Vi-Site – редагування контенту можливе прямо на фронті сайту, якщо адміністратор при цьому авторизований у CMS.

Переваги для верстальника:

  • Тепер не потрібно верстати шаблони, а потрібно верстати лише блоки з яких складаються шаблони.
  • Над проєктом одночасно можуть працювати багато верстальників, не заважаючи один одному.
  • Завдання можна розділяти на дрібніші та виконувати їх швидше.

Переваги для програміста:

  • Програмісти отримують завдання на програмування блоку, а не запрограмувати весь шаблон, а це спрощує розробку.
  • Принципи DRY (не повторюватись) та SRP (принцип єдиної відповідальності) працюють на повну силу, код не дублюється і кожен блок незалежний. За функціонал кожного блоку відповідає окремий клас, який нічого не знає про інші блоки, і редагуючи код у класі одного блоку, неможливо щось зламати в іншому блоці.
  • Принципи MVC. Рекомендую використовувати «товсту модель та тонкий контролер», ось як виглядає контролер нашого універсального шаблону.

Контролер тонкий

Мені здається, що це найтонший контролер у світі програмування, який тільки можна придумати.

Переваги для тестувальника

Тестувати такий код набагато простіше. На кожен блок пишеться функціональний тест, при цьому тест дуже простий і в сукупності вони покриють функціонал всього сайту, що спростить розробку і рефакторинг коду.

6. Що маємо в результаті?

  • Розробка сайту спрощується в рази.
  • Клієнт має можливість конструювати сторінки сайту на свій смак без звернення до нас.
  • Супровід та доопрацювання таких сайтів спрощується.
  • Багів у десятки разів менше через те, що кожен блок покритий тестом.
  • Рефакторити код можна без остраху щось зламати.
  • Менеджерам проєкту легше ставити завдання. Не потрібно розробляти весь шаблон, потрібно розробити лише нові блоки для "універсального шаблону".
  • Всі щасливі та задоволені! :)

Статтю підготував: Артур Щаблевський

Сподобалася стаття ? - Поділіться посиланням ::