За все время своей работы с Битрикс мне довелось поработать с очень большим количеством проектов, которые кто-то разрабатывал до меня. Тут и мелкие доработки, фикс различных багов и ошибки работы логики, редизайн сайта и глобальные изменения существующего функционала. И, как и любой другой разработчик, я терпеть не могу разгребать чужой мусор, костыли и «временные» заплатки, которые на деле помнят еще 8 редакцию продукта.
Здесь я постараюсь не акцентировать внимание на стандартных «worst practice» при программировании на PHP, типа наплевательского отношения к выборам имен переменных и функций, излишних запросов к БД в цикле, отсутствия проверок пользовательских данных в формах, игнорирование комментариев и тому подобного. Я попытаюсь коснуться именно моментов, свойственных разработке на Битриксе, которые в последствии позволят избежать негодования и проклятий в ваш адрес от программиста, которому выпало сопровождать ваш код. И да, нередко этим программистом будете оказываться вы сами через год, или более, когда уже совершенно забудете, зачем вы вставляли сюда тот или иной костыль.
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте» (с) Джон Ф. Вудс
Первое, и самое, на мой взгляд, важное — ради всего святого, используйте папку local. Это просто жизненно необходимо при использовании системы контроля версий – все, что вам нужно – добавить в исключения папку /bitrix/. Всё. Далее практически вся разработка ведется только в ней. Это заметно упрощает поиск нужных файлов и компонентов в последствии, помогает не засорять репозиторий лишними файлами, да и вообще – приводит дерево проекта в более опрятный, «человеческий» вид.
Не модифицируйте ядро. Даже если вы уверены, что оно не будет обновляться. Даже если так быстрее. Даже если вам лень. Забудьте эту мысль, как страшный сон. Если необходимо изменить логику работы стандартного компонента – перенесите его в новое пространство имен /local/components/modify/ и работайте с ним. То же самое касается модулей, гаджетов и activities бизнес-процессов.
Не засоряйте файл init.php. Объединяйте функции для работы с каким-то конкретным модулем или функционалом в класс, весь этот класс записывайте в отдельный файл, а в init.php просто подключайте эти файлы и прописывайте обработчики событий. Мне встречались файлы init.php по 500Kb, где в кашу были смешаны функции, определение констант, классы и инициализация обработчиков. Разумеется, когда приходилось разбираться в этих файлах, я сыпал проклятиями на своих предшественников.
Следующий пункт не касается случая разработки готовых решений для Marketplace, когда целью ставится сделать максимально настраиваемый функционал из публичной части для конечного потребителя. Если вы работаете над конкретным проектом, по конкретному ТЗ – не стоит пытаться сделать унифицированный шаблон для компонента на все случаи жизни. Лично я придерживаюсь философии – лучше несколько простых шаблонов, использующихся для разных целей, чем один универсальный, но в котором сам черт потом ногу сломит. Разумеется, в каждом конкретном случае нужно отталкиваться от того, что есть – техзадание, варианты реализации и тому подобное, но некоторые слишком рьяно используют «Бритву Оккама». Как пример приведу один проект лизинговой компании, который мне довелось править. Сам проект, конечно, был реализован ужасно, на настоящий ужас был в страницах раздела каталога услуг. У каждого из пяти разделов была собственная верстка, на которых отличалось как положение блоков на странице, так и в принципе наличие некоторых из них. И для всех пяти страниц использовался один шаблон с кучей if-else, дублированием вызовов компонентов, подключением стилей и скриптов, которые, к тому же, периодически конфликтовали друг с другом. Как итог – огромный файл, в котором разобраться «без поллитры» было смерти подобно. Хотя, казалось бы, что мешало сделать 5 разных шаблонов и не создавать трудностей на ровном месте?
Используйте API. Не изобретайте велосипеды там, где это не нужно. Юзайте документацию – весь продукт довольно хорошо описан, а так же каждую функцию можно посмотреть детально на bxapi.ru.
Избегайте прямых запросов к базе. Это частный случай предыдущего пункта – используйте API. Необдуманные, незащищенные запросы могут привести к порче, утере или даже к компрометации данных.
Не используйте компоненты с ЧПУ из корня сайта. Последствия, как правило, довольно печальны, так как ЧПУ использует файл обработчика адресов, попытка использовать его из корня легко ломает вам адресацию других компонентов, а так же 404 страницы. Ничего страшного не будет, если статьи у вас будут адресоваться относительно папки /articles/, а товары относительно /catalog/.
Подключайте css и js с помощью API. До сих пор повсеместно встречаю подключение скриптов и стилей с помощью тегов
Автор: разработчик 80-го уровня
