Рекомендации по написанию кода (Движка на PHP)

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

Движок сайта будет выполнять разные задачи, связанные с текстом, картинками, видео файлами и так далее. Для каждого вида данных удобно будет использовать отдельный файл, независимо в каком стиле вы пишите код, в процедурном или ООП. Допустим, вы пишите класс, который будет работать над картинками, в данном классе находятся методы, что будут загружать, обрезать, оптимизировать изображения, получать их размеры и так далее. Другой класс будет работать с текстом, проверять стоку на стоп слова, обрезание строки для краткого содержания и так далее. Третий класс будет полностью посвящен видео записям, например. Что это дает? Такой подход упрощает редактирование сценария. Например, вам необходимо изменить размер аватарок пользователей, аватар – это картинка, с картинками у нас работает такой-то класс, открываем файл с классом, что обрабатывает изображения и производим все необходимые изменения. То есть вы всегда будите знать, какой файл/класс надо редактировать, если появляется, какая-то задача. Теперь представьте, если такого порядка нет, все методы разбросаны в хаотичном порядке. Прошло полгода с момента написания движка и вот вам надо изменить аватарки, где, что находится, за полгода можно легко забыть, а на поиски нужного метода тратится драгоценное время. Если вам, например, для фотографий одного класса мало, то, разумеется, можно сделать несколько классов, допустим один класс будет – добавлять новое фото, редактировать его и удалять, второй класс будет резать, уменьшать, увеличивать и так далее. Оба файла с этими классами кладем в папку «photo». В общем складываем все по полочкам.

При больших объемах кода легко забыть, что, для чего служит, в свою очередь разработчик может запутаться в своем же коде и потерять уйму времени на то, чтобы разобраться. Чтобы не запутаться в своем же коде, оставляйте комментарии с описанием классов, методов, параметров, свойств и так далее. Не бойтесь писать большие комментарии, они на скорость выполнения сценария не играют, так как интерпретатор пропускает их мимо своих «ушей». Если вдруг вы забудете, для какой цели у вас, какой-то метод, то при помощи комментария над этим методом освежите свою память. Комментарии в коде – очень удобно. Я порой экспериментирую – закомментирую оригинальную строчку кода, а ниже напишу ей замену, затем сравниваю, что лучше работает, оригинал или новое, если оригинал, то его можно легко вернуть.

Порой необходимо внести изменения в какой-то метод. Эти изменения могут быть самыми незначительными, но из-за них может потребоваться править еще несколько файлов, так как работа кода одного метода зависит еще от нескольких, других методов. Очень неудобно подгонять несколько методов под один, а отредактировав другие, придется подгонять еще и еще… Чтобы не приходилось переписывать половину движка из-за одной – пары строк, необходимо изначально писать методы, чтобы они были независимы друг от друга.

PHP позволяет не ставить фигурные скобки, если, допустим, в условии используется всего одно действие, например:

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

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

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

Так же мне доводилось видеть, как разработчик, допустив ошибку, не исправляет ее, а подавляет ее (собака «@»). Так сказать прячет ошибку с глаз. Это в корне не правильное решение, ошибки надо исправлять и не допускать, но не как не подавлять. Плохой тон, к тому же ошибки в коде, могут значительно тормозить выполнение сценария. Если появляется ошибка, например, неопределенной переменной, то ее, возможно, исправить при помощи условия (можно использовать тернарный оператор). Проверяем, определена ли переменная, если нет, назначаем ей «null» (например) или, что-то другое, если определена, то работаем дальше. Все просто, при написании/редактировании кода, включайте отладчик и исправляйте ошибки, если таковые имеются. Так же пользуйтесь отладчиком во время редактирования кода.

Для того, чтобы всегда знать, какое значение может содержать конкретная переменная, давайте им наглядные имена. Например, если переменная может содержать только «true» или «false» и служит она исключительно для проверки – выполнять, какую-то операцию или нет, ее можно назвать примерно так «$isOperation». Вместо «Operation» можно вставить название операции или функции. Так вы всегда будите знать, для какой цели написана такая-то переменная и какое она может содержать значение, так как ее название описывает ее предназначение.

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

Одно из самых главных правил (принципов, законов, как вам угодно) любого разработчика – это «ни когда не доверять своим пользователям». Рано или поздно, ваш движок проверят на прочность, его попытаются взломать, возможно, конкуренты или простые школьники, которые, взламывая сайты, повышают свою самооценку. Вы должны быть к этому готовы всегда и предусмотреть все за ранение. Необходимо проверять все вводные данные, что идут от пользователей. Необходимо обезопасить свой движок от возможных инъекциях. В ближайшем будущем я напишу об этом отдельную статью.

При посещении сайта, для пользователя, порой, появляется необходимо обновить, какие-то данные, которые помещаются в один небольшой блок или даже строку. Например, это может быть уведомление о новом личном письме или о новом комментарии на написанную статью, ну или еще чего. Из-за этого не стоит обновлять страницу полностью, достаточно обновить только эту строчку при помощи технологии «AJAX». Загрузка данных при помощи AJAX выполняется гораздо быстрее, чем загрузка всей страницы, к тому же это избавит пользователя от постоянного обновления страницы.

Не пишите код на устаревшей версии PHP, например, зачем писать код под PHP 5 если уже давно есть PHP 7. PHP 5 еще поддерживается серверами и скорее всего поддерживаться будет еще долго, но все же время подойдет, когда оно уйдет в прошлое, так же подойдет время и для PHP 7, когда ей будет замена, но пока это последняя версия. Если ваш движок написан на PHP 5 или еще ниже, то рекомендую переписать его на актуальную версию, это не так сложно.
Будьте современны и не отставайте от релизов PHP!

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

На этом я, пожалуй, закончу. Еще раз хочу сказать, что мои советы не являются правилами или какими-то стандартами. Как вам писать код, решать только вам самим, я всего лишь предложил делать так, как, на мой взгляд, будет удобнее. Надеюсь, мой пост оказался вам полезен. Если вам есть, что добавить или остались, какие-то вопросы, пожалуйста, пишите комментарий, постараюсь помочь/ответить всем прокомментировавшим статью.
Спасибо за внимание!

Добавить комментарий

Войти с помощью: 

Ваш e-mail не будет опубликован. Обязательные поля помечены *