Всем привет! Меня зовут Александр, я занимаюсь разработкой на PHP 8 лет, а проектированием инженерных систем и автоматизацией бизнес- и технологических процессов – уже больше 15 лет. За это время я наработал некоторое количество материалов и наблюдений как по архитектуре ПО, так и по написанию качественного кода, приобрел опыт менторства товарищей по команде, прошел под сотню техинтервью, получив десятки офферов. Успел поработать и в маленьких стартапах, и в крупнейших интернет-магазинах страны.

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

В ходе совместной работы мне довольно часто приходится объяснять товарищам по команде то, как стоит на практике понимать и реализовывать фундаментальные понятия, такие как, например, принципы ООП, энциклопедические определения которых, не знаю как сейчас, но раньше знал любой десятиклассник, внимательно слушавший учителя информатики.

С одного из таких принципов мне и хотелось бы начать. Инкапсуляция. Все слышали, да не все понимают.)) Из года в год я вижу одни и те же ошибки на код-ревью у самых разных разработчиков.

Часть 1 из 3. Продолжение ниже.

Изображение: Kandinsky по промпту "Инкапсуляция".

#ООП #инкапсуляция #интерфейс_класса

Инкапсуляция. Продолжение. Часть 2 из 3.

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

Давайте разберемся поподробнее, зайдя немного издалека. Что такое класс в ООП? Класс – это нечто, что объединяет (инкапсулирует за интерфейсом) поведение и данные. Данные – это поля класса, а поведение – его методы. Кроме полей и методов класса есть еще кое-что: области видимости. Публичные поля и методы класса образуют его интерфейс, за которым инкапсулированы (скрыты!) его приватные поля и методы. То есть, изменяя области видимости полей и методов класса, мы изменяем его интерфейс и одновременно изменяем то, что именно будет инкапсулировано (скрыто) за этим интерфейсом.

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

Инкапсуляция. Продолжение. Часть 3 из 3.

Второй совет, который я даю, состоит в том, чтобы представлять, что мы пишем не на интерпретируемом, а на компилируемом языке. Представьте, что ваш класс сразу после того, как вы закончите над ним работу, будет скомпилирован в некую библиотеку (DLL, например). Ваши коллеги и любой, кто будет работать с этим классом после вас, не смогут увидеть его код. То есть они не будут ничего знать о том, как работает ваш класс и что именно он делает. Все, что они будут видеть – это его интерфейс (за которым вы инкапсулировали все внутренности вашего класса). Когда вы начинаете мыслить подобным образом, вы начинаете более ответственно и внимательно относиться к интерфейсу вашего класса. Ведь интерфейс – это лицо, документация и «пульт с кнопками» вашего класса. Что увидят другие разработчики, глядя на ваш интерфейс? Поймут ли они, что делает ваш класс, для чего он предназначен? Смогут ли они с первой попытки воспользоваться вашим классом правильно, то есть так, как вы изначально задумали? Смогут ли они воспользоваться вашим классом неправильно, например, вызвав в самом начале какой-то метод, который должен вызываться только в середине? Задавая себе подобные вопросы, вы думаете об инкапсуляции (не только о ней, но и о ней тоже).

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

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

Собрав обратную связь после первого поста, решил взять паузу (удлиненную праздниками 🥂) на ее осмысление. Оказалось, что изначально задумывавшаяся направленность канала не слишком удачна. Точнее, тот материал, которым я планировал делиться, не слишком полезен, попадая как бы в середину. Более опытных ребят мне удивить, рассказав им что-то новое, практически нечем, а тех, кто мог бы еще много чему поучиться, не слишком занимают рассуждения о тонкостях красивого кода и хорошей архитектуры проекта, так как пристегнуть им эти рассуждения не к чему: волнуют более приземленные и насущные вопросы.

Поразмыслив над этим, я (не без внутреннего сопротивления) решил-таки, сместиться к более простым и повседневным аспектам разработки, интересным тем, кто находится вначале или в середине карьерного пути и хочет по этому самому пути сделать несколько новых шагов.

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

Нужна ли рефлексия? И если нужна, то где? Случалось несколько раз спорить на эту тему с теми, кто считает, что использование рефлексии усложняет проект и делает его менее читаемым для джунов и даже миддлов. Но, пардон, что тут усложнять? Если речь идет о необходимости изменить/прочитать значение приватного свойства, то делов на три строчки кода. Где это нужно? Чаще всего – при ручной гидрации. Где нужна ручная гидрация? В проектах, следующих DDD, у вас ее будет не меньше половины (а если у вас ее меньше, то скорее всего зря вы притащили в свой проект DDD 😈).

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

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

#рефлексия #гидрация

Продолжая тему предыдущего 👆 поста: еще один пример менее частого, но все же встречающегося простого и полезного использования рефлексии – это работа с кастомными атрибутами. Из моей личной практики и отношения к коду кастомные атрибуты наиболее уместны в слое контроллеров (а в доменном слое ИМО неуместны вообще никакие атрибуты, ибо нечего засорять метаданными тонюсенький слой бизнес-логики).

В частности, мне приходилось активно пользоваться атрибутами собственного производства при реализации ABAC (альтернативы RBAC) и при написании API шлюзов. И там и там очень удобно было размечать каждый эндпоинт собственными атрибутами, передавая через них аргументы в более глубокие слои приложения, вызывавшиеся симфонийским kernel.controller лисенером.

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

Получилось в этом посте спонтанно затронуть огромную и интересную тему ABAC. Дам ка я, пожалуй, ссылочку на статью, с которой в эту тему можно начать погружаться.

Ну а если (не дай Бог, но мало ли 🤷‍♂️) у кого-то вызвало замешательство упоминание kernel.controller, то вот вам ссылочка на доку по встроенным симфонийским событиям.

#атрибуты #рефлексия #контроллер

Быть или казаться?

Готовя следующий пост о том, нужно ли для успешного найма знать индексы БД, задумался. Тему успешного прохождения собеседований на вакансии до уровня Senior мне хотелось бы сделать одной из регулярно освещаемых в своем нарождающемся блоге. При этом я только сейчас осознал, как часто мне на самом деле приходилось встречаться с подходом «лишь бы пройти отбор» как в различных пабликах в сети, так и в живых коллегах.

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

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

Что ж, вопросы совести и морали оставлю за рамками этого поста, скажу лишь, что мой подход кардинально отличается. Для того, чтобы получить Level UP по карьере, нужно не пытаться «сдать экзамен» любой ценой, а просто оптимизировать процесс подготовки к собеседованиям, поняв, какие компетенции дают наибольшее влияние на принятие решения по вашей кандидатуре, и сосредоточившись на их прокачке, игнорируя все остальные навыки, которые тоже востребованы, но не оказывают большого влияния на ваши шансы успешно трудоустроиться.

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

#собеседования

Обязательно ли понимание индексов баз данных для карьерного роста разработчика?

Отвечу так: я дошел до позиций уровня senior без этого. Конечно, глядя из сегодняшнего дня на себя, первый раз получившего заветную лычку сеньора, я могу сказать, что я вообще ничего тогда не понимал ни то, что в БД, но и в написании кода. 😁

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

Однако цель этого поста не столько в том, чтобы обрадовать всех, кто, как и я, любит базы данных (да и вообще любые инфраструктурные компоненты) сильно меньше, чем написание кода, но и в том, чтобы порекомендовать вам источник, который содержит ответы на 90% вопросов, задаваемых по индексам во время техинтервью на позиции сеньора.

Вот такой видосик попался мне в свое время на глаза: https://www.youtube.com/watch?v=RUF3n_EIcy8

В нем автор очень доходчиво объясняет:

- общий принцип работы B-TREE индекса;

- как правильно строить составные индексы (об этом нередко спрашивают на собесах);

- что такое селективность и как она влияет на скорость работы индекса;

- как базово пользоваться EXPLAIN в MySQL.

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

#SQL_индексы #собеседования