Поиск по сайту

У меня давно в голове назревала идея создать некое руководство с лучшими практиками и примерами того, как нужно и как не нужно делать при разработке шаблонов. Никакой саморекламы тут не будет, я адекватно воспринимаю критику и никогда не считал свои шаблоны (особенно первый – кто знает, тот поймет ) эталонными с точки зрения разработчика, так что аргументированная критика только приветствуется. Многие разработчики и фрилансеры называют лучшим шаблоном – default и в целом негативно относятся к коллегам-«шаблонописателям», на то есть немало причин, которые мы тут и обсудим. Для удобства восприятия информации дальнейшее изложение будет структурировано по пунктам, от более общих понятий к более частным. 1. Не воруйте чужие решения Как ни странно, даже среди известных разработчиков шаблонов были случаи воровства чужих решений: от заимствования целых модулей (например, фильтров) до более скрытого использования чужого кода, причем порой без понимания его сути. Думаю, всем очевидно, что это – плохо, причем плохо не только с моральной или этической точки зрения, но и с точки зрения атмосферы в самом сообществе в целом (а еще про вас напишет Yoda). Одно дело, когда код шифруется от пиратов, но когда разработчику приходится скрывать свой код от коллег, т.к. он понимает, что его могут просто украсть – это никоим образом не способствует ни сплочению сообщества, ни доверию к разработчикам в целом. 2. Не шифруйте все подряд Очевидный совет, который относится и к разработчикам модулей. Да, я знаю, что есть пираты (мне ли не знать этого?), с которыми вы так боретесь, но зачем кубить все? Каким образом стороннему разработчику потом разбираться в вашем коде? Каким образом пользователю внести свои индивидуальные доработки, если у вас закодированы и модель, и контроллер? А может быть в зашифрованном коде скрываются не только авторские решения, но и позаимствованные у коллег? 3. Не бойтесь пиратов По моему опыту те пользователи шаблонов, что стабильно используют взломанные версии с вареза, никогда ничего у вас не купят, это просто не их путь. По этой же причине малоэффективно тратить время и силы на пуленепробиваемую антипиратскую защиту шаблона – если даже у вас получится сделать что-то подобное и шаблон чудом не будет взломан, то этот факт вовсе не заставит сотню пользователей вареза пойти к вам его покупать, им гораздо проще взять любой другой пиратский шаблон, чем тратить деньги на ваш. Идея в том, что пользователь вареза изначально не настроен на покупку в принципе. Тот небольшой процент, которым кровь из носу нужен именно ваш шаблон (к примеру, нечистоплотные вебмастера, которым заказчик говорит «хочу») в случае отсутствия этого шаблона на варезе будут изо всех сил отговаривать заказчика от его выбора, поскольку это их хлеб. А абсолютно уникальных шаблонов уже просто не существует, в отличии от некоторых узкоспециализированных модулей. Также не стоит забывать о том, что есть определенная категория пользователей, которые любят тестировать дополнения с вареза, а уже потом их покупают, поэтому если у вас не предполагается тестовой версии шаблона – это еще одна причина не бояться пиратов, а воспринимать их как один из своеобразных рекламных каналов. 4. Не демпингуйте Если ваш шаблон плохо покупают – причина вовсе не обязательно связана с его ценой. Если ваши конкуренты продают похожие шаблоны за 3000, а вы выложите свой за 1000 – вы не получите в 3 раза больше покупателей, а получите покупателей в 3 раза более жадных и вредных. 5. Следите за чистотой кода Еще один очевидный совет, которым многие пренебрегают – все мы знаем, какое «удовольствие» разбирать чужой код. Порой читабельность кода не особо вырастает даже когда он не зашифрован, причем речь не только о коде как таковом, но и о верстке, скриптах и стилях. Если в самом опенкарте полностью избежать спагетти-кода (и не создать проблем с совместимостью) не получится при всем желании, то это вовсе не значит, что стоит пускаться во все тяжкие и запихивать $this->config->get в tpl-файлы (знаю-знаю, у меня в 1-м шаблоне именно так все и сделано и мне до сих пор стыдно) или делать множественные sql-запросы в контроллерах. Если вы не знаете, что и как сделать правильно – установите на локалку девственно чистый опенкарт и изучайте его структуру и его файлы, он сам по себе как документация (которой нет). 6. Забудьте о «разработке через страдания» Если вы хотите сделать толковый шаблон, то забудьте о принципе «Разработка через страдания», который звучит так: сначала сделай, чтобы было, затем — чтобы было красиво, затем — чтобы было быстро. Он совершенно неприменим к шаблонам. У вас все должно быть по возможности быстро, красиво и продумано до мелочей с самой первой версии, поскольку иначе ваш продукт просто не заметят и не оценят покупатели, а потом будет уже поздно. Даже если у вас горят все сроки по возврату кредита/ипотеки и вся надежда только на скорейший релиз шаблона – не выпускайте сырой «неупакованный» продукт, вы этим сделаете только хуже! Наполнение вашего демо не должно быть основано на стандартных унылых товарах и баннерах OpenCart, презентация шаблона не должна быть написана в последний вечер на коленке в ворде, а в самом шаблоне должны быть продуманы даже такие мелочи, как склонения числительных в таймере акций (никаких «Осталось: 13 дн 11 час 18 мин», вы шаблон делаете для живых людей, у которых в русском языке есть склонения, а не для роботов). На форуме представлена масса интересных и полезных дополнений, которые никогда не станут популярными по той простой причине, что их авторы – в первую очередь программисты, они не думают про упаковку своего продукта и считают простыню голого текста в описании дополнения презентацией. Они не думают о том, чтобы тратить время на «вылизывание» своего продукта и продумывание всех мелочей. Выражение «pixel-perfect» воспринимаются ими как что-то ужасно долгое и ненужное, но это совершенно не так, по крайней мере в случае с шаблонами – дьявол часто кроется именно в деталях. Если у вас однотипные элементы имеют разную высоту, абзацы выравниваются с произвольными отступами, а иконка в круглой рамке выводится не по центру, а смещена вниз – уделите этому свое время. Разумеется, все должно быть в меру, а лучшее – враг хорошего, поэтому маниакальным перфекционизмом заниматься тоже не стоит, важнейший навык в этом плане – найти золотую середину между скоростью и качеством работы. 7. Не превращайте шаблон в сборку Изначально задачи шаблонов заключались в обеспечении привлекательной «внешности» магазина, а функциональность обеспечивалась модулями. Но со временем началась своеобразная инфляция возможностей шаблонов, каждый новый старался превзойти предшественника по количеству настроек и модулей, входящих в комплект. Сейчас все знают, что получилось в итоге – монструозные сборки (это уже не шаблоны) со встроенными фильтрами, блогами, упрощенными оформлениями заказов, десятком плагинов фотогалерей и сотней комплектного модульного барахла, большую часть которого пользователь никогда не будет включать. Я прекрасно понимаю шаблонописателей, которые пошли по этому пути, да и сам не без греха, хоть и старался не перегружать шаблон лишней функциональностью. Почему же так произошло? Да потому что сложно «продать» средненький шаблончик, когда через дорогу продается такой же, но с фильтром и тележкой модулей в комплекте. Правильный ли это путь? Конечно нет, поскольку понятие шаблона смешивается с понятием сборки, от чего страдают абсолютно все: Пользователи получают неповоротливые громоздкие решения все-в-одном, чрезмерно сложные в целом и слабые по своим отдельным компонентам, в сравнении со специализированными модулями (смеха ради посмотрите возможности комплектного фильтра, входящего в состав какого-нибудь популярного шаблона, и модуля ocFilter), а постоянное наращивание таких решений у конкурентов вызывает у пользователя ложное предположение, что это нормальная практика – когда в шаблон впихивается модуль фильтра-блога-кешировщика и прочие несвязанные вещи Разработчики модулей теряют потенциальных клиентов, поскольку пользователю шаблона порой легче мучиться со встроенным в шаблон решением, чем искать нормальную отдельную альтернативу, которую к тому же придется адаптировать под шаблон Разработчики шаблонов вместо работы над внешним видом шаблона вынуждены постоянно наращивать его функциональность, стараясь угнаться за конкурентами, что доходит до абсурда и встраивания низкокачественных (а порой и вовсе чужих) решений, лишь бы не отстать в этой гонке 8. Не будьте эгоистом – ваш шаблон не единственный в мире Очень часто сталкиваюсь с ситуациями, когда пользователи решают сменить свой супер-шаблон на какой-то новый и их ждут любезно расставленные авторами грабли уже на моменте простого переключения в настройках на default, потому что заботливый разработчик и мысли не допускает, что его прекрасный супер-шаблон кто-либо когда-либо может захотеть сменить. Самая распространенная ситуация – когда многочисленная орава комплектных модулей супер-шаблона имеет файлы шаблонов исключительно для каталога самого супер-шаблона и не имеют своих адаптированных версий (или хотя бы копий!) для каталога дефолтного шаблона. В итоге при переключении на default все страницы магазина, где использовались модули супер-шаблона, перестают открываться, ведь опенкарт просто физически не может найти файлы шаблонов этих модулей. Несчастному пользователю придется вручную выискивать и отключать все модули супер-шаблона лишь для того, чтобы хотя бы вернутся к исходному состоянию системы со стандартным шаблоном. Вторая по распространенности ситуация – когда разработчику лень описать в документации процесс установки по шагам и все сводится к копированию всех файлов на хостинг (а модификаторов в /system) – уже догадались, что происходит при смене шаблона, когда пользователь понятия не имеет, что ему еще нужно по FTP ковыряться в системном каталоге и вручную удалять оттуда все модификаторы старого шаблона? И зачем в опенкарте сделан раздел Модификаторы с возможностью установки/удаления из админки? И напоследок уже довольно редкий сценарий – разработчик просто перезаписывает файлы шаблона default (и хорошо если только файлы шаблона, а не контроллеры или библиотеки). Думаю, объяснять последствия таких действий нет смысла, тут проще обрадовать пользователя, все сжечь и ставить движок с нуля. 9. Думайте о совместимости с другими дополнениями Бывает так, что у разработчика очень чешутся руки и он решает отказаться от устаревшего барахла, используемого опенкартом – убирает jquery, вырезает bootstrap или обновляет его с версии 3 на 4.5, убирает font awesome и т.д. Это все прекрасно и похвально, когда вы занимаетесь своим собственным магазином или выполняете работу для одного постоянного клиента и предупреждаете его о возможных рисках. Но если вы хотите сделать продукт, которым будете пользоваться не только вы и ваши друзья, подумайте на мгновение о том, с чем столкнется ваш пользователь при попытке установить какой-нибудь самый безобидный модуль, в котором используется сетка bootstrap (а это по определению абсолютно все модули, где идет вывод товаров), иконки font awesome (аналогично), а операции с DOM осуществляются через jquery. Конечно, можно следовать трендам и делать костыли для поддержки других дополнений (к примеру, убрать bootstrap и спустя пару десятков недовольных пользователей сделать опцию в админке «Подключить Bootstrap» – гениально же?), но не проще ли следовать стандартам? Поверьте, рядовому пользователю плевать на то, современный ли вы используете фреймворк и все ли у вас сверстано на флексах или на таблицах, ему важно, чтобы все работало как положено и сайт не разваливался при попытке поставить сторонний модуль. А сделать говно можно как на Bootstrap и jQuery, так и на каком-нибудь Foundation с ваниальным js или нодой. Это все лишь инструменты в руках разработчика, только вот успешность проекта зависит не от инструментов, а от навыков, с которыми эти инструменты используются. 10. Учите матчасть Один из последних пунктов по порядку, но не по важности – уделяйте внимание теории, причем я пишу не только про техническую составляющую, рассмотренную в п.5. Если вы делаете шаблон, то я бы очень советовал почитать Стива Круга, Филипа Котлера и других специалистов. Конечно, вы можете все делать и «по подобию» других шаблонов, ничего не понимая в дизайне, юзабилити и маркетинге, вдохновляясь на themeforest или на всяких дизайнерских CSSWinner и CSSDesignAwards, но есть один нюанс. Если проводить аналогии, то похожим образом на китайских ноунейм-фабриках делают дешевые велосипеды с тяжелой стальной рамой, неправильной геометрией, посадкой и «одноразовыми» компонентами. При этом со стороны их изделия действительно выглядят как велосипеды (ну а что там такого, два колеса, рама и руль), но если присмотреться поближе или проехаться на них, имея опыт эксплуатации нормальных моделей – все станет очевидно. Недаром есть термин BSO (Bike-Shaped Object, объект в форме велосипеда), которым и нарекают подобные продукты. Так и с шаблонами – если вы взялись их делать, стоит ли слепо копировать дизайн Юлмарта/Розетки в десятый раз? Почитайте пару книжек, поймите ошибки существующих решений и сделайте лучше! 11. Избегайте обращений к своему серверу Ваши пользователи не должны быть заложниками работоспособности вашего сервера лицензий. Любая зависимость ваших дополнений от вашего сервера – не просто неудобство и лишние тормоза (даже в относительно свежих шаблонах встречается ситуация с постоянным обращением к стороннему серверу для проверки лицензии), а и потенциально опасная уязвимость. Конечно, разработчик может возразить, что он – профессионал, доступ к его серверу есть только у него, а сам сервер невероятно надежен и полностью защищен. Пока петух не клюнет, все так говорят, к примеру, один печально известный «эксперт по php и OpenCart» @addist, пока из-за обращений к его серверу у пользователей не начались массовые проблемы с доступностью магазинов, а в его модулях не нашли критическую уязвимость. Или одна печально известная веб-студия N***** у которой модули по окончанию срока действия лицензии в определенных ситуациях просто «вешали» сайты клиентов. Не все разработчики понимают, что это не просто неудачные реализации и недоработки – это огромные убытки для работающего магазина, которые могут не только лишить владельца какой-то прибыли, но и привести даже к закрытию всего бизнеса, поэтому таких практик нужно избегать любой ценой. 12. Полная документация сэкономит время как вам, так и пользователям Думаю, тут и так все понятно из заголовка. Кто-то возразит, что пользователи – лентяи, поэтому документацию не читают, я с этим полностью согласен, но есть очень важный нюанс. Рано или поздно в общении с пользователями вы поймете, что чаще всего задаются одни и те же типовые вопросы, поэтому если вы их опишете в документации, то в будущем не будете тратить время, отвечая в -надцатый раз на вопрос о перекраске кнопок, а сможете дать ссылку на конкретный пункт в вашей документации. Это же касается любой из функций шаблона, поскольку при наличии даже базовой документации она со временем (при вашем участии, естественно) разрастется до такого состояния, когда будет отвечать на подавляющее большинство вопросов (или хотя бы задавать направление пользователям для самостоятельного поиска ответов). Если вы цените свое время, то сами к этом прийдете, но лучше это сделать раньше, а освободившееся время потратить на что-то более продуктивное. 13. Ведите лог разработки и обновлений Помимо очевидных удобств в плане повышения рабочей дисциплины и понимания изменений кода со временем, этот пункт имеет и другой важный и полезный эффект. Конечно, вы сможете показать своей маме/детям/внукам историю своей работы и эволюцию своего шаблона, но, как ни странно, вам это может пригодится в общении и с менее близкими людьми. Причем речь идет не только о хейтерах, но и об администрации площадки, где вы собираетесь выкладывать шаблон. Речь пойдет о плагиате и способах обоснованно избежать обвинений в нем. Причем я пишу не о плагиате, например, с многострадальной Розетки, удивительное сходство с которой можно без проблем увидеть даже в самых новых шаблонах. Я имею в виду другой плагиат – когда элементы более нового шаблона напоминают элементы другого, более старого шаблона. Пример из личного опыта – я уже третий год разрабатываю новый шаблон (назовем его A), в котором, среди прочих нововведений, используются градиентные кнопки, на карточке товара есть плавающий блок покупки, а на демо – фото айфонов. И вот неделю назад один разработчик выпускает свой новый шаблон B, в котором используются – угадали? – градиентные кнопки, на карточке товара есть плавающий блок покупки, а на демо фото айфонов в том числе Конечно, если через несколько месяцев будет релиз моего шаблона A, то некоторые персонажи могут усмотреть в этом плагиат с шаблона В другого разработчика. Но я веду историю разработки и в ней есть железные доказательства того, что, к примеру, градиенты на кнопках в моем новом шаблоне A были уже весной 2021-го года, когда шаблона В, естественно, еще не существовало и увидеть его будущий дизайн я физически никак не мог. Так вот, чтобы всего этого избежать и быть готовым в случае чего доказать свою правоту и авторство – у вас должна быть история разработки, в которой не только будет видно эволюцию шаблона, дизайн-макеты и прочее, но в ней также должны быть четкие (и независимые от вас) временные отметки по всем важным этапам разработки. В самом примитивном виде – снимок вашего тестового сервера из WebArchive или даже какие-нибудь скриншоты, пересланные в Telegram – такие данные не подделаешь, потому что там видно оригинальные даты, поэтому чем больше у вас таких данных – тем сильнее ваша позиция.