Советы начинающим PHP разработчикам

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

Достаточно исправить несколько мелких привычек, что бы команда по разработке сказала спасибо. Опуская лирику, начнём.

1). Тип входных параметров. Не забывайте про то, что PHP позволяет во входных параметрах указывать тип значения и тип выхода из метода. Встречал случаи, когда на вход метода принималось что-то вроде $customer, а под этим в проекте часто можно было встретить как id customer, так и наименование, и ссылку на него. И самое интересное, когда такое встречается в случаях, например:

И вот сиди думай, а что будет, если я сюда ФИО передам, а если объект? Особенно понимая, что для mysql, к примеру, часто в настройках указано неявное преобразование primary key. Как думаете, сколько команда разработчиков будет ловить ошибок или необъяснимое поведение программы? Итог, чем чаще уточнять тип передаваемой переменной, тем раньше можно определить потенциальную проблему или не желательное поведение программы.

А ещё бывает так, что в интерфейсе не указано явно типы входных и выходных параметров. Проходит время. Кто-то пытается реализовать метод из интерфейса и добавляет типы данных. И? Всё падает! И горе программист, дабы не усложнять себе работу – оставляет как есть!

Или ещё более «нервный» случай, дебажишь с десяток методов по цепочке и в самом конце оказывается, что тип переменной не тот. А ведь можно было это отфильтровать в самом начале. Итог, потрачено много нервов и времени на никому не нужные ошибки. Итоги в конце статьи.

2). Инкапсуляция – хороший защитник при большой команде и залог правильного использования в многопользовательском проекте. Часто встречается, что все методы объявлены public. При этом часть методов было написано специально узконаправленно для выполнения конкретного действия. Проходит несколько лет, и обнаруживается, что этим методом начали пользоваться все, кому не лень. И тут наступает ситуация, при которой нужно поправить этот уникальный метод. Попробуйте это провернуть, не поломав всю остальную программу. Вывод, если понимаете, что метод написан целенаправленно и сугубо для определённой ситуации, то сделав его приватным, вы защищаете его от необдуманного использования другими разработчиками, правда, не всегда.

3). Комментарии. Лучше потратить 5 минут для его написания, чем потом 20-ти разработчикам по 5 минут понимания логики. Бывает так, что название метода говорит само за себя, но не всегда. Часто, чтобы понять назначение одного метода, приходится разбираться во всей длинной цепочке. А вот если бы там был комментарий. Который описывает контекст использования – время на понимание логики сокращается в разы. Это же относится и к комментариям внутри метода. Конечно, избыток тоже не нужен. Есть способ определить, нужен он в конкретном месте или нет: если спустя время вы читаете свой код и «тупите», почему тут именно так, а не по-другому – нужен комментарий.

4). Разделить абзацами логические блоки. Вы пробовали читать большой текст, написанный одним абзацем? А почему разработчики должны это читать? Идея всё та же – чтение кода должно быть максимально простым и очевидным. Например, если в одном методе идёт математический расчёт, а затем вывод этого расчёта из метода или чего другое – отделите абзацем – это поможет сразу понять, где происходит вычисление, а где уже дальнейшее действие. Или другой пример: инициализация переменных и их использование. Казалось бы, фигня, нет – не фигня.

Надеюсь, теперь многие начнут относиться к своей работе с позиции «кто-то, а возможно и я сам здесь буду тупить, как же мне это облегчить?»

Подведём итог:

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

2. Указания типа входных и выходных параметров позволяет прогнозировать поведение программы на интуитивном уровне, а в добавок к написанным комментариям – даже не вчитываясь в логику реализации понимать, что произойдёт на входе и на выходе.

3. Комментарии сокращают время на вникание в логику. Время – деньги.

4. Логически выделенные абзацы кода, как и комментарии ускоряют и упрощают понимание кода.

На самом деле –это крайне простые истины, но как факт – далеко не везде используется.

Комментарии и критика принимаются, ведь цель – сделать программирование эффективнее.