12 причин не використовувати самописні CMS на сайті
Найчастіше, самописні системи виникають як «наша відповідь Чемберлену» — на спис вже існуючим CMS. І на це «захворювання» страждають 99% розробників сайтів — у якийсь момент, у пориві інфантильного максималізму програміст, який багато десятків годин провів «в обіймку» з кодом будь-якої системи, вигукує — «Доколе! Скільки можна возитися з цим убожеством?! Я ж знаю як зробити краще! і помалу «я знаю!» перетворюється на тверду впевненість «я можу!» і ось уже, дивишся, рядок за рядком починає вимальовуватися кістяк нового дітища.
Проте всім добре відомо, чим і куди вимощена відповідна дорога і тому будь-яка, навіть найпрекрасніша ідея, при неправильному підході до її реалізації може обернутися проблемами для всіх її користувачів.
Нижче ми розглянемо ті мінуси, якими обтяжена практично кожна самописна система і причини яких варто утриматися від її використання.
Крім того, на ринку присутні і безкоштовні самописні системи, що розробляються одинаками-ентузіастами. Під поняттям «самописна CMS» мається на увазі масовий продукт. Унікальні розробки, призначені для вирішення «одноразових» нестандартних завдань, — у цій статті не розглядаються.
1. Жорстка прив'язка до одного розробника
Уявіть собі машину, яка розроблена таким чином, що може бути заправлена виключно одним видом палива, який продає одна-єдина заправка у місті. При цьому заправка є стовідсотковим монополістом.
2. Аудит безпеки
Основою будь-якої системи є не гарний дизайн чи зручний функціонал, а безпека. Погодьтеся, нікому не потрібна CMS, навіть обвішана всілякими «рюшиками», але яку може зламатистудент першого курсу КПІ Аудит безпеки сайтів включає детальну перевірку програмного забезпечення сайту на наявність уразливих елементів. В рамках аудиту проводиться комплексний аналіз систем та підсистем сайту.
3. Мала поширеність системи
Практично всі, навіть найзатятіші противники Open Source визнають, що аудит користувача може певною мірою замінити професійний аудит безпеки — тисячі програмістів і розробників, які щодня модифікують систему під потреби клієнтів, рано чи пізно знайдуть ту потенційну загрозу, яка може існувати в системі і додадуть її в багтрекер для подальшого виправлення офіційною командою розробників або навіть більше просто самі надішлють готове рішення.
4. Опрацювання системної архітектури
Враховуючи той факт, що опрацювання системної архітектури має безпосереднє і важливе значення для функціонування системи в цілому, це питання є одним із найважливіших при старті розробки. І від того, наскільки якісно було виконано опрацювання, залежить вся подальша доля розвитку системи.
Проектування системної архітектури передбачає поділ системи на найбільші складові частини та прийняття конструктивних рішень, які після їх прийняття важко піддаються зміні.
за матеріалами Вікіпедії
Враховуючи, що замовник зазвичай не здатний оцінити коректність архітектури системи через закономірну недостатність знань у цій галузі, це питання залишається на совісті розробника. Але як і у випадку з безпекою – вундеркінди зустрічаються вкрай рідко, а тому питання побудови архітектури самописної системи найчастіше розкривається за методикою – «не потрібно винаходити велосипед».Розробник бере за основу архітектуру однієї з популярних систем, що вже існують, вносить пару-трійку правок (але абсолютно не факт, що потрібних і корисних) і каже: «дивіться, моя нова архітектура революційна!».
5. Якість коду
Рівень коду самописних систем спочатку дорівнює рівню їхнього розробника, але оскільки це «вистава одного актора», оцінити цей рівень по суті може лише сам розробник. Для користувачів це може загрожувати тим, що якщо на початковій стадії розробки — при мінімумі функцій — система здаватиметься швидше за існуючий аналог, то надалі це може обернутися тими самими проблемами — перевантаженістю, помилками, невідповідністю стандартним вимогам хостингів тощо. У результаті вийде, що користувач поміняв добре, якщо тільки шило на мило.
6. Програмістам для програмістів
Давайте пригадаємо, чому Windows, за всієї своєї проблемності і помилковості, досі займає лідируючу позицію серед операційних систем, використовуваних користувачами? За простою, по суті, причиною вона проста для освоєння і не вимагає специфічних знань.
Від багатьох користувачів я часто чую — адміністративна частина Joomla для мене складна, а я не хочу розбиратися. А по суті, в ній немає нічого екстраординарного — її інтерфейс лише трохи відрізняється від звичних «деревоподібних» інтерфейсів. Але для багатьох вже це стає проблемою.
7. Відсутність повноцінної документації користувача
Документація – ахіллесова п'ята будь-якого програмного забезпечення. З усіх CMS, з якими я за свою практику мав справу, адекватні посібники користувача були лише максимум у п'яти відсотків систем.
8. Відсутність API
Чому Twitter відразу став настількипопулярний? Чому Yandex.Карти з деяких пір можна зустріти практично повсюдно? Відповідь проста - повноцінний API, який дозволяє програмістам розробляти на його основі сторонні програми.
Інтерфейс прикладного програмування (іноді інтерфейс програмування додатків) (англ. Application Programming Interface, API [ей-пі-ай]) — набір готових класів, функцій, структур та констант, що надаються додатком (бібліотекою, сервісом) для використання у зовнішніх програмних продуктах .
за матеріалами Вікіпедії
9. Проблема наявності лазівок
Розробникам популярних Open Source або проприетарних систем невигідно залишати будь-які «чорні ходи» з тієї простої причини, що в Open Souce системі вони будуть швидко знайдені спільнотою користувача, а в платних CMS із закритим кодом — аудитом. Крім того, якщо щодо системи будь-якого типу ліцензування хоча б кілька разів буде порушено питання лазівок і буде наведено докази їх наявності, то з популярністю та прибутком можна буде попрощатися раз і назавжди.
У разі самописної CMS — таких гарантій немає, оскільки немає ні аудиту користувача, ні спеціалізованого. А мала поширеність системи дозволить досить легко приховати наявність лазівки, якщо її розробник буде розумним та обережним. Але тільки для користувача такої системи це не обіцяє нічого хорошого.
10. Відсутність професійної спільноти та служби підтримки
Популярні Open Source CMS хороші своїми відкритими спільнотами, у яких можна швидко знайти відповідь більшість типових завдань. Підтримка пропрієтарних систем керування завжди забезпечується службою підтримки та help desk. А до кого звертатися у разі використання самописної системи?
11.Відсутність підтримки сторонніх фахівців (без- та платних)
12. Відсутність професійних тестувальників
Багато хто вважає, що тестування — досить проста справа. Здавалося б, ну чого там сів, пройшовся за функціями системи, виписав помилки і віддав програмісту на виправлення. Однак практично все далеко не так просто. Я не буду детально зупинятися на методиках тестування, які можуть почитати окрему статтю у Вікіпедії, яка досить повно розкриває загальні поняття та професійного тестування програмного забезпечення.
13. Відсутність чіткого вектора монетизації або прихованого вектора (для безкоштовних CMS)
Висновки
Виходячи з усіх вищеописаних причин, я завжди рекомендую замовникам утримуватися від придбання або використання самописних CMS, оскільки жодного дійсно позитивного моменту в їх застосуванні немає, а головного болю вони можуть доставити дуже багато.
Зі своєї особистої практики скажу, що вже кілька разів я стикався з самописними CMS з такою архітектурою, що перенесення сайту на нову систему в одному випадку коштувало замовнику на 20% більше, ніж вартість попередньої розробки (не враховуючи вартість нового сайту), а в інших — перенесення доводилося здійснювати практично вручну, оскільки створювати систему імпорту просто недоцільно.
Гліб Шапачников - Вебмайстер.