12 причини да не използвате собственоръчно написан CMS на сайта
Най-често самонаписаните системи възникват като "нашият отговор на Chamberlain" - в противоречие със съществуващата CMS. И 99% от разработчиците на уебсайтове страдат от тази „болест“ - в някакъв момент, в пристъп на инфантилен максимализъм, програмист, прекарал много десетки часове, „прегръщайки“ кода на всяка система, възкликва: „Колко дълго! Колко може да се занимавате с тази помия?! Знам как да се справя по-добре!“ и малко по малко "Знам!" се превръща в твърда увереност "Мога!" и сега, виждате ли, ред след ред започва да се появява гръбнакът на ново въображение.
Всеки обаче е добре наясно какво и къде е асфалтиран съответният път и следователно всяка, дори и най-красивата идея, с грешен подход към нейното изпълнение, може да се превърне в проблеми за всички нейни потребители.
По-долу ще разгледаме недостатъците, с които е натоварена почти всяка самостоятелно написана система и причините, поради които трябва да се въздържате от използването й.
В допълнение, на пазара има безплатни самостоятелно написани системи, разработени от отделни ентусиасти. Понятието „написана от самите CMS“ означава масов продукт. В тази статия не се разглеждат уникални разработки, предназначени за решаване на "еднократни" нестандартни задачи.
1. Твърдо обвързване с един разработчик
Представете си кола, която е проектирана така, че да може да се зарежда само с един вид гориво, което се продава от една бензиностанция в града. В същото време се разбира, че тази бензиностанция е 100% монопол.
2. Одит на сигурността
Основата на всяка система не е красив дизайн или удобна функционалност, а сигурност. Съгласете се, никой не се нуждае от CMS, дори и да е окачен с всякакви "къдрици", но които могат да бъдат хакнатистудент първа година на KPI. Одитът на сигурността на сайта включва подробна проверка на софтуера на сайта за уязвими елементи. Като част от одита се извършва цялостен анализ на системите и подсистемите на обекта.
3. Ниско разпространение на системата
Почти всички, дори и най-заклетите противници на Open Source, признават, че потребителският одит може до известна степен да замени професионалния одит на сигурността - хиляди програмисти и разработчици, които ежедневно модифицират системата, за да отговарят на нуждите на клиентите, рано или късно ще открият потенциалната заплаха, която може да съществува в системата, и ще я добавят към инструмента за проследяване на грешки за последваща корекция от официалния екип за разработка или дори повече - те просто ще изпратят готово решение сами.
4. Разработване на системна архитектура
Предвид факта, че разработването на архитектурата на системата е от пряко и фундаментално значение за функционирането на системата като цяло, този въпрос е един от най-важните при стартиране на разработката. И цялата по-нататъшна съдба на развитието на системата зависи от това колко добре е проведено проучването.
Проектирането на системна архитектура включва разделяне на системата на най-големите компоненти и вземане на дизайнерски решения, които, веднъж взети, са трудни за промяна.
според Wikipedia
Като се има предвид, че клиентът обикновено не е в състояние да оцени правилността на архитектурата на системата поради естествената липса на познания в тази област, естествено този въпрос остава на съвестта на разработчика. Но както в случая със сигурността, маниаците са изключително редки и следователно въпросът за изграждането на архитектурата на самонаписана система най-често се разкрива според метода - „няма нужда да преоткривате колелото“.Разработчикът взема за основа архитектурата на една от вече съществуващите популярни системи, прави няколко редакции (но абсолютно не е фактът, че те са необходими и полезни) и казва: „вижте, новата ми архитектура е революционна!
5. Качество на кода
Нивото на кода на самонаписаните системи първоначално е равно на нивото на техния разработчик, но тъй като това е „изпълнение на един актьор“, само самият разработчик може действително да оцени това ниво. За потребителите това може да бъде изпълнено с факта, че ако в началния етап на разработка - с минимум функции - системата изглежда по-бърза от съществуващия аналог, тогава в бъдеще може да се превърне в същите проблеми - претоварване, грешки, несъответствие със стандартните изисквания за хостинг и др. В резултат на това се оказва, че потребителят се е променил добре, само ако беше шило за сапун.
6. За програмисти за програмисти
Нека си припомним защо Windows, въпреки всичките си проблеми и грешки, все още заема водеща позиция сред операционните системи, използвани от потребителите? Всъщност по проста причина – лесно се научава и не изисква специфични познания.
Често чувам от много потребители - "административната част на Joomla е трудна за мен, но не искам да я разбирам." И по същество в него няма нищо необичайно - неговият интерфейс е само малко по-различен от обичайните "дървовидни" интерфейси. Но за мнозина това вече се превръща в проблем.
7. Липса на пълна потребителска документация
Документацията е ахилесовата пета на всеки софтуер. От всички CMS, с които съм се сблъсквал в моята практика, само максимум пет процента от системите имаха подходящи ръководства за потребителя.
8. Няма API
Защо Twitter изведнъж стана такъвпопулярен? Защо от известно време Yandex.Maps могат да бъдат намерени почти навсякъде? Отговорът е прост - пълноправен API, който позволява на програмистите да разработват приложения на трети страни въз основа на него.
Интерфейс за програмиране на приложения (понякога интерфейс за програмиране на приложения) (англ. Application Programming Interface, API [hey-pi-ay]) е набор от готови класове, функции, структури и константи, предоставени от приложение (библиотека, услуга) за използването му във външни софтуерни продукти.
според Wikipedia
9. Проблем с вратичка
За разработчиците на популярни системи с отворен код или патентовани системи е неизгодно да оставят всякакви „задни врати“ поради простата причина, че в системата с отворен код те ще бъдат бързо намерени от потребителската общност, а в платената CMS със затворен код - чрез одит. Освен това, ако въпросът за вратичките се повдигне поне няколко пъти във връзка със система от всякакъв вид лицензиране и се дадат доказателства за тяхното съществуване, тогава популярността и печалбата могат да се сбогуват веднъж завинаги.
В случай на самостоятелно написана CMS няма такива гаранции, тъй като няма нито потребителски одит, нито специализиран такъв. И ниското разпространение на системата ще направи доста лесно да се скрие наличието на вратичка, ако нейният разработчик е разумен и внимателен. Но само за потребителя на такава система това не вещае нищо добро.
10. Липса на професионална общност и поддръжка
Популярните CMS с отворен код са добри за техните отворени общности, където можете бързо да намерите отговора на повечето типични задачи. Поддръжката за собствени системи за контрол винаги се предоставя от бюрото за помощ и бюрото за помощ. И към кого да се обърна в случай на използване на самостоятелно написана система?
11.Липса на поддръжка от специалисти на трети страни (безплатни и платени)
12. Липса на професионални тестери
Много хора смятат, че тестването е доста проста работа. Изглежда, добре, какво има - седнах, преминах през функциите на системата, написах грешки и го дадох на програмиста за корекция. На практика обаче всичко далеч не е толкова просто. Няма да се спирам подробно на методите за тестване, тези, които се интересуват, могат да прочетат отделна статия в Wikipedia, която доста пълно разкрива общите понятия за професионално тестване на софтуер.
13. Няма ясен вектор за осигуряване на приходи или скрит вектор (за безплатна CMS)
Изводи
Въз основа на всички горепосочени причини винаги препоръчвам на клиентите да се въздържат от закупуване или използване на собствено написана CMS, тъй като няма нито един наистина положителен момент в използването им и те могат да причинят много главоболия.
От моя личен опит ще кажа, че няколко пъти вече съм срещал самостоятелно написана CMS с такава архитектура, че в един случай прехвърлянето на сайт към нова система струва на клиента 20% повече от цената на предишната разработка (без да се вземат предвид разходите за нов сайт), а в други прехвърлянето трябваше да се извърши почти ръчно, тъй като беше просто непрактично да се създаде система за импортиране.
Глеб Шапачников — Уеб администратор.