Портал Belkin-labs»PHP классы»Статья
welcome!

Что и почему мне не нравится в готовых движках интернет-магазинов

Я уже несколько лет занимаюсь услугами в области создания и поддержки сайтов. Конечно, интернет магазинов. Работаю обычно непосредственно с руководством. С директорами или их заместителями. И вот, что я заметил.

Рано или поздно у клиента возникает настойчивое желание изменить существующий сайт. Причем часто есть желание изменить либо очень сильно, либо вообще концептуально!

Неадекватные трудозатраты программиста, поддерживающего работу сайта на чужом движке

Почему же возникает это желание? А потому, что так или иначе существующий движок, система управления контентом, поступает от производителя с уже готовым дизайном. Под этот дизайн в движке заточено буквально все! В первую очередь концепция. Способ авторизации, система безопасности, строение каталога, админка, страницы, система человеко-удобных урлов (хотя я для себя эту гугловскую идею не приемлю в принципе, но клиентам об этом не говорю)! И вот клиент, работая на движке "из коробки", рано или поздно замечает, что даже изменив, на сколько позволяет движок, дизайн сайта, этот сайт все равно по своим основным концепциям и функциям точь-в-точь похож на тысячи других, сделанных на том же самом движке. А это совсем не комильфо, особенно если фирма не только продает, но и представляет интересы поставщика в России или в отдельном городе, да еще и эксклюзивно! И вот тут, казалось бы, должен произойти праздник на моей улице, ибо натянуть новый и совсем непохожий дизайн на чужой движок - задача крайне объемная и поэтому высокооплачиваемая! Но именно поэтому я не считаю это событие праздником. Дело в том, что для такой работы надо досконально знать движок. Буквально не хуже производителей. А это банально требует кучу времени и напряжения всех физических и умственных сил. И часто сидя и разбираясь в тоннах чужих программ, проклянешь все на свете и десять раз дашь себе обещание никогда и ни за что с такой работой больше не связываться. Так, натягивание нового и сложного дизайна на CS-CART задача сравнимая, кажется, с написанием нового движка!

Не! Ну реально,
разбираясь со сложным движком, приходит ощущение, что ты сам этот движок создал, но в реальности движки создаются целыми бригадами! Понимаете юмор ситуации? Целая бригада делает продукт в течение нескольких месяцев, а программист разбирается в нем совершенно один, по исходным кодам (из-за отсутствия должной документации) и "через тернии", пробираясь сквозь ошибки и шероховатости программистов из этой бригады! Такое ощущение, что программист на поддержке должен быть если и не гением, то работать в разы больше других! Это бывает обидно и всегда хочется, чтобы кто-то за это заплатил. Таким лицом чаще всего выступает клиент.

Реализация новых сложных функций или концептуальное изменение движка скорее всего вполне возможно, но экстремально невыгодно клиенту

А если клиент хочет изменить способ регистрации клиента? Например, он желает иметь "заказ в один клик", а движок этого не позволяет на концептуальном уровне? Приходится клиента расстраивать. Конечно, я не говорю о том, что что-то невозможно в принципе. Напротив, я всегда повторяю, что могу сделать абсолютно все, что угодно, при времени, стремящемся к бесконечности, но большие сроки клиентов обычно не устраивают и в итоге получается, что стоимость изменения функциональности готового движка делает эти изменения абсолютно невыгодными, что плохо сказывается на бизнесе, ибо директор - он на то и директор, чтобы генерировать идеи и заставлять персонал эти идеи воплощать в жизнь, а движки убивают эту возможность творчества для руководства фирмы, превращая процесс руководства из творчества в рутину. По своему богатому опыту я знаю, чем это кончается для фирмы и персонала...

Так почему же клиенты выбирают движки?

Спрашивал ли я директоров, с которыми, кстати, у меня всегда отличные отношения, почему они выбирают движки? Да спрашивал. И знаете, какой у них у всех довод? Всего один, и заключается он в следующем. Я покупаю движок, и сайт сразу начинает работать. Более того, управляется с ним одна девочка, которая имеет среднюю зарплату и абсолютно ничего не понимает в программировании.

Но тогда я резонно (на мой взгляд) спрашиваю, а какого ... делаю на фирме я, программист? Я же получаю зарплату и помогаю этой самой девочке поддерживать сайт, хоть и работаю удаленно! На это я почти всегда получаю следующий ответ: "Ты - это другое дело!" Я не понимаю, почему я - это другое дело, но с этого момента почти всегда закругляю беседу и говорю, что-нибудь типа: "Да-да! Я - это другое дело." И перевожу разговор на другую тему.

Тем не менее,
я готов согласиться, что готовый движок сокращает время первичного внедрения проекта. Но я стою на своем и говорю, что как только настает время изменения движка, мудрый руководитель всегда отложит движок в сторонку, как выполнивший свою функцию, и закажет сайт у отдельного программиста или у фирмы. Если руководитель думает об экономии, то конечно у программиста. Во-первых, это дешевле, во-вторых, легче договориться, в-третьих, безопаснее, если вовремя подстраховаться и поставить своего мальчика или девочку на контроль работ и перенимание опыта. Вы думаете, фирмы не рушатся и не пропадают? И движки не снимаются с поддержки и развития? К сожалению, и то и другое происходит.

Какие еще узкие места движков вижу лично я?

На своем сайте я ничем не связан, и могу высказаться напрямую. Так вот список вещей, которые я не понимаю, и которые объясняют, почему я в своей жизни ни разу еще не только не пользовался чужими движками, но и работу с чужими кодами воспринимаю как неприятную необходимость, но не удовольствие.

Я не понимаю, почему люди, создающие свои движки и системы управления контентом (CMS), так обожают создавать свои языки программирования. Действительно. Создается ощущение, что PHP создан не для них. и в этом мощнейшем языке не хватает возможностей для реализации их идей. Нужно обязательно создать свой, новый язык, обладающий своим синтаксисом, правилами, обработкой ошибок, компилятором и так далее. Причем язык этот создается на PHP и компилируется во что? Правильно! В PHP-же! То, что получилось в результате компиляции, уже обрабатывается интерпретирующими инструментами самого PHP и только затем в скрипте делается что-то полезное! Очевидно, такие выкрутасы не разгружают сервер, а наоборот нагружают его! В итоге синтаксис наслаивается на синтаксис, кэш наслаивается на кэш и в итоге мне надо изучать в 2 раза больше документации, а простейшая задача оптимизации времени загрузки страниц (для примера) превращается в нечто сравнимое с написанием своего движка!

Мне не нравится та небрежность в работе с MySQL, которой грешат даже крутые и дорогие движки! Видимо, сложилось впечатление, что взять сведенья из базы данных так же быстро, как обратиться к элементу массива! Очень редко в движках оптимизированы запросы к базе данных. Часто делаются до десятка лишних запросов там, где можно обойтись одним, но с использованием левых или правых JOIN-ов (не хотелось бы усложнять повествование техническими деталями). Я еще не видел движка, где использовались бы мультизапросы. Да даже массовый переход к прогрессивным обработчикам баз данных (mysqli) стал происходить не после того, как прекратилась поддержка старого доброго mysql, а только после того, как в последних версиях его использование стало вызывать предупреждение deprecated.

Совершенно очевидно! На готовом движке нельзя написать сайт, который бы обрабатывал 2 тысячи уникальных посетителей в сутки и располагался бы при этом на публичном хостинге за 1000 рублей в год! Мне не нравится тот факт, что сделав сайт на крутом покупном движке и вгрохав в этот сайт еще кучу денег, заказав и натянув на движок новый дизайн, мне, как владельцу этого сайта необходимо арендовать сервер вместе с администратором! Ну... буду справедлив. Часто можно заказать VPN и не заморачиваться на собственного администратора. Но VPN раз в 5, а то и в 6 дороже публичного хостинга! Опять же публичный хостинг требует прозрачной и очень сильной системы безопасности. Без нее сайт будет как проходной двор. В движках система безопасности стоит не на первом и, к сожалению, даже не на втором месте. Хорошо, если входит в десятку важнейших функций.

Лично мне в готовых движках с одной стороны не хватает контроля над сайтом, а с другой стороны мне приходится мириться с тем, что вложили в движок его создатели. Создатели движка - это программисты, а не владельцы магазинов! Напротив, у владельцев магазинов куда больше идей, чем у программистов! В итоге получается, что программисты вставляют в движок новые кнопочки и чекбоксы, которые позволяют включать и выключать некоторые функции, и большинство (порядка 80%) этих функций мне в сайте не нужны, но постоянно в нем присутствуют своеобразным балластом, утяжеляют его и своим присутствием крайне затрудняют обслуживание сайта.

Мне не понятен и не нравится тот факт, что при всей крутизне программисты многих движков не используют простейших функций языка PHP. Я имею ввиду объектно ориентированный подход. К чему это я о нем вспомнил? Это я вспомнил о проблеме обновления движка до новой версии в сочетании с его изменением на стороне клиента. Грандиозной бедой всех движков является тот факт, что после внесения в него изменений, нарушается его стандартная работа. Если движок изменен, после этого, обычно, его либо нельзя обновлять совсем, либо после обновления все изменения, сделанные программистом, затираются, переписываются стандартными кодами, и программисту необходимо все перенастраивать после каждого обновления. Чтобы как-то с этим справиться, программисты придумали хуки. А зачем? Ведь куда проще сделать некие базовые классы и стройную систему наследования. Нужно мне что-то поменять - я создаю класс наследник и меняю в нем то, что хочу. Либо добавляю. Зачем опять выдумывать функционал на функционал? Сайт от этого надежнее будет? Не думаю. По опыту наоборот! Эти хуки нарушают основополагающий принцип программирования "от простого к сложному", они нарушают структуру программы! Делают ее нечитаемой! Работа программиста часто превращается в поиск хука, который делает понятно что, но находится совершенно неизвестно где (в каком файле).

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

Что в итоге сделал бы я, если бы был директором магазина?

А в итоге я не уверен, что готовый движок - это лучшая идея для действительно приличного сайта. Опытный программист сделает заказной сайт и, может, хоть и потратит на него чуть больше времени на внедрение, но:

  • Сайт будет оптимизирован по времени загрузки до предела и сможет работать на публичном хостинге или на VPN! Минус расходы на хостинг и администратора.
  • Сайт будет обладать не просто системой безопасности, но системой с заказанными функциями, что очень важно для действительно серьезного сайта! Именно слабой безопасностью грешат готовые движки.
  • Сайт не будет нагружен миллионом ненужных функций и админка не будет изобиловать миллионом кнопок и чекбоксов, в котором не то, что девочка-менеджер, а и программист не сразу разберется. Минус усиленное изучение функций персоналом, который должен быть в теории низкооплачиваемым.
  • Быстрое внедрение на сайте новых функций. Полагаю, что программист, который сделал сайт, знает его наизусть и сможет сделать в нем изменения со скоростью света (мысли)! Причем, он будет доволен, а не раздражен, поскольку он делает сайт на своем инструменте, и, если видит в процессе работы ошибку, то исправляет и улучшает он свой движок, а не чужой, где ошибки появляются тоже со скоростью мысли, умноженной на количество программистов в бригаде.
  • Самое главное, если что-то случится с создателем сайта, руководству не нужно искать специалиста по движку! Достаточно взять просто квалифицированного программиста PHP. Согласитесь, найти программиста широкого профиля в разы легче и дешевле, чем специалиста, например, по CS-CART. А программисты, изучившие этот крутой движок, потратили на это изучение столько времени, сил и собственных средств, что не продадут свое время дешево! Говорю, поскольку сам его изучил.

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

Ну только мне, как руководителю фирмы, надо не ошибиться в выборе программиста. Я бы, как руководитель, отдал бы предпочтение программисту опытному, с большим стажем работы по профессии, человеку с высшим и лучше профильным образованием и со сложившимся и, лучше, уже задокументированным подходом и концепциями к созданию сайтов. Посмотрел бы, как человек общается. Если человек хорошо говорит, не запинается, не ЭЭЭкает и не МЭЭЭкает, значит у него высокий IQ (проверено). Необходимо, чтобы программист знал английский язык и мог читать документацию в подлиннике, и при этом знал бы наизусть название соответствующих сайтов. Поинтересовался бы, кто у человека отец и мать по профессии, то есть озаботился бы той средой, в которой человек получал основы воспитания. Это важно для того, чтобы оценить, на сколько человек силен морально и ответственен. На сколько склонен к обману и кидалову. Именно так я выбирал сотрудников в свой отдел, когда работал в серьезной компании IT-директором.

А что я сделаю, как программист?

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

Очевидно,
я должен соответствовать высокому уровню, который сам же себе и поставил несколькими абзацами выше.

Программист с 25-ти летним стажем
Дмитрий Белкин

Статья создана 15.12.2014