PHP и немного обо мне

Maffinca69

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

Если у вас есть какие-то дополнения, пожелания, замечания и все, что с этим связано вы можете написать мне в лс @maffinca69

Начнем.

Требование работодателей

В нашей компании новые сотрудники (все, но сейчас речь идет про backend) проходят 2 тестовых задания. Учитывая требования в них и личный опыт расскажу, что сейчас актуально.

Самый минимум требований:

ООП - это насколько уже стало нормой (кто бы что не говорил про то, что ООП усложняет код и делает его нечитабельным со временем), что у нас это не требуют, а просто считают как что-то обычное. Это как человек может разговаривать или дышать. Тут уже тоже самое, то есть вы априори должны это знать
PDO - как минимум. Будет хорошо, если вы с ним работали напрямую и понимаете как писать запросы. Экранирование будет тоже плюсом, но использование PDO даст вам несколько плюсов в вашу кандидатуру
Безопасность - базовый набор. SQL инъекции, CSRF, XSS и т.д. Иметь представление и уметь защищаться. Забегу вперед и скажу, что у нас в проектах даже Junior'ы не допускают таких ошибок (все коммиты проходят 1 или 2 merge request'a)
GIT - без него никуда. Знать про rebase, commit, push, merge request, fetch, stash и т.д. Без этих знаний даже на фоне всего остального вам откажут, ибо это такой же краеугольный камень, как и все остальное
IDE - да, звучит довольно странно, но вы должны владеть IDE (в нашем случае это php storm). На начальных этапах лучше только ей, а не каким-нибудь vs code, т.к вашему ментору или любому другому человеку будет легче вам помочь, если вы работаете в одной среде и у вас максимально схожее рабочее окружение. Поэтому знание хоткеев, фич и прочего очень важно
PHP. Куда же без него. Знать PHP 7.x, ибо ниже (лично мы) не используем. Зачастую это 7.1 или 7.2
Linux. Кто бы что не говорил про эту ос, но она почти всегда стоит на серверах. И т.к с 90% вероятностью сначала вы пойдете в небольшую компанию, где нет сисадминов. Поэтому вам придется самому с этим возиться. Поэтому минимум команд (скопировать, удалить, выставить права) вы должны знать, ибо почти сразу после прохождения стажировки вы с этим столкнетесь
Composer. Для фронтендеров это как NPM. Такой же менеджер пакетов
Ну и фреймворк. В компаниях очень редко пишут на чистом PHP, зачастую используются фреймворки - Symphony, Laravel, Yii2 (последний просто кал полный и те, кто на нем пишут - старперы из 90-ых)

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

Но технические знания далеко на самые важные. Не менее важный момент - Hard Skills. Ваше умение общаться, адаптироваться к коллективу и прочему. Порой общаться с менеджерами приходится весь день, при этом не написав ни единой строчки кода. Учитывайте это, когда будете искать работу. Ну и ответственность, без нее никуда.

Актуальные технологии и практики

За пол года работы я изучал просто гору всего (чего конечно же не будет в университете), что может пригодится в работе и что сделает меня лучше. не будем тянуть дешевую интригу, начнем

Лучшее практики кода:

Их можно встретить на каких-нибудь сайтах, но общие принципы такие:

Простота превыше всего. Важно помнить, что вы работаете не один, а с людьми, поэтому написание простого кода это очень хорошая практика. Для себя я выявил такую схему идеального кода - выполняет свои требования стабильно, максимально простой, не имеет уязвимостей, надежный. Если есть минут 10-15 времени, чтобы написать нормально, то лучше это сделать. Это упростит работу в будущем. Вообще, чем проще код и "нуднее" код, тем опытнее разработчик, который его написал. Это уже не мои слова, но с ними я согласен. Часто замечал, в том числе и на своем примере, что новички стараются сделать код сложнее, стараясь показать этим свои знания. Не надо, в компании есть люди, умнее и опытнее вас, не стоит усложнять ни себе, ни другим жизнь, написанием сложного кода, который нельзя будет потом ни то что поддерживать - читать
Не знаю как правильно описать этот пункт, но стараться придерживаться принципов SOLID, GRASP, KISS (про последний написано выше). Например: функция выполняет только что-то конкретное, как и класс и т.д. В идеале дополнительной логики быть не должно, но бывают ситуации, когда без нее никуда и сделать иначе просто невозможно. Оставляем. Все же лучше говнокод, чем вообще нерабочий код (но зависит от ситуации, конечно). Если что, в будущем через время вы можете сесть и переписать. В случае корпоративной разработки этот момент стоит согласовать с менеджером проекта или вашим ментором (тимлидом)

По идее все. Именно основных могу выделить только 2 пункта. Дальше будут нарабатываться уже только с опытом

Актуальные технологии

XDEBUG. Именно капсом. XDEBUG МАТЬ ТВОЮ. Без него никуда. Вы просто задолбаетесь дебажить проект сложнее Hello world'a var_dump'ами и console.log'ами. Потратить 2 часа на настройку и изучение сэкономит вам кучу времени в дальнейшем и даст пару бонусов вам в карман (опыт)
Gitlab CI/ GitHub Actions. Круто, если вы умеете настраивать деплой кода и разбираетесь в том, как это работает. У нас в компании активное движение по автодеплою начал я, когда спросил у моего тимлида как это сделать (мне было это очень интересно). Настроил и потом помог даже мидлу на его проекте с настройкой, а не так давно мы настроили деплой кода для всего фронтенд отдела (но этим занимался уже не я)
Laravel. Именно мы пишем на нем (хотя в последнее время из-за проекта я пишу на Yii2). Это божественный фреймворк, созданный людьми для людей. Красивая и понятная документация, дружное community, множество туториалов, понятная и чистая архитектура (не то что у Yii2, где проще сдохнуть, чем что-то понять). Он часто встречается в вакансиях на том же hh.ru. Так же можно выделить Symphony. Знание одного из этих фрейморков говорит о том, что вы знаете и имеете представлении об MVC, а знание и понимание MVC говорит о вас то, что вы сможете в короткие сроки выучить любой (ну почти) другой паттерн.
PHPUnit/Codeception. Написание тестов всегда хорошо и если вы их писали, то в 90% случаев вам либо дадут проект с ними, либо скажут написать, и вы будете просто лучше выглядеть на фоне других кандидатов. У нас тесты пишутся на каждый 2 проект. Бывают проекты без тестов, но таких осталось не так много и все они не особо крупные.
IDE. Будь то PhpStorm, WebStorm или тот жеVS Code. Знание IDE всегда плюс, а идеальное знание - еще больший плюс. Вы же не будете писать проекты в блокноте или том же Sublime Text? Да простят меня фанаты Sublime Text'а
Homestead/Docker. Они особенно часто используется на проектах. По началу вам вряд ли дадут настраивать тот же Docker, но развернуть у себя проект вы должны уметь. И тут мы подходим к следующему пункту статьи

Настройка локального окружения

Каюсь, Docker я так и не изучил. Не могу я понять всю эту систему образов и контейнеров пока, но вдоволь наигрался с Vagrant и Homestead, посему покажу, как настроить окружение на них.

Вводная часть

В общем все выглядит так - чтобы у разработчиков было максимально схожее окружение (чтобы не было такого, что, мол, у меня на пк все нормально, проблема у вас) используется что-то общее. Сервер! Да, именно он и поднимается на VirtualBox или на VMWare, ставится последний стабильный образ той же ubuntu и разворачивается проект (вместе с nginx и прочими вещами). Я поднимал только на VirtualBox, поэтому расскажу, как это делал я

Vagrant - конфигурационный файл, с помощью которого мы легко запустим все одной командой

VirtualBox - виртуальная машина. Будем симулировать сервер

Homestead - готовая сборка со всеми нужными плагинами и расширениями, php и т.д

Начинаем

Разворачивать для примера будем Laravel Homestead. Вот инструкция - https://laravel.com/docs/6.x/homestead

Для начала скачиваем и устанавливаем VirtualBox. На этом этапе проблем ни у кого не возникает, поэтому сразу перейдем к следующему шагу - настройке vagrant.

Просто установить эту сволочь уже задача и вот почему: для запуска вам нужен бокс, образ ОС. Который при хорошем раскладе качается часов 8 с падениями соединения. В плохом - 12 часов или вообще не качается, выкидывая ошибку. Решения я так и не нашел, мне просто повезло однажды и я скачал его за 12 минут. Вообще, где-то вроде лежали box'ы и были хаки для ubuntu и мак по типу экспериментов с wget и curl, но я особо не углублялся

Итак, прошло 12 часов и вы все таки смогли скачать бокс. Отлично! Клонируем Homestead:

git clone https://github.com/laravel/homestead.git

Клонируем в текущую директорию и переходим в нее

Далее в ней запускаем инициализацию (код из документации).

// Mac / Linux...
bash init.sh

// Windows...
init.bat

Затем я покажу свой конфиг рабочих проектов и что за что отвечает. В папке переименовываем Homestead.yml.exanple в Homestead.yml и открываем для редактирования

Черным замазаны домены и БД рабочих проектов

memory - кол-во оперативной памяти, которую вы можете выделить виртуалке. У меня 16гб озу, поэтому я решил выделить 4. По дефолту вроде 1

authorize/keys - ssh-ключи, которые нужны будут для ssh доступа к виртуалке после того, как она поднимется (вам же нужно будет как то редактировать nginx)

folders (map) - папка, где лежат другие папки с проектами. Схема папок примерно такая:

folders (to) - папка на сервере, где будут лежать проекты

На этх 2 пунктах остановлюсь подробнее - нельзя размещать все проекты в корне. То есть /home/vagant. Иначе при обновлении конфигурации и запуске vagrant reload --provision у вас будут проблемы с nginx, правами и прочим

Так же ОЧЕНЬ ВАЖНО, чтобы имя пользователя windows или ubuntu было не на кириллице, то есть не "Иван", например, ибо так вряд ли вообще что-то запустится. Если у вас все же кириллица, то вариант - завести еще одну учетку для проектов и все делать в ней. На этом моменте я убил около 16 часов, пытаясь понять что не так

sites (map) - домен, по которому будет доступен сайт. Лучше выбирать .local или .test. В таких случаях хром не пошлет вас куда подальше

sites (to) - папка на сервере с index файлом в ней. Для laravel это public

databases - тут все просто. Все базы данных, которые будут использоваться в проектах. Логин/пароль стандартные - homestead/secret

Так же обратите внимание на слэши в пути к папкам и то, какие это - обратные. В Windows именно так, иначе конфигурация будет кривая и опять же - ничего не запустится. В оф.документации приведены примеры для mac/ubuntu

Когда все готово можно запустить

vagrant up

Или

vagrant reload --provision

Для обновления конфигурации

Так же не забудьте в host файл добавить записи для ваших доменов

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

"А как переносить файлы с локальном машины на виртуалку?"

Никак, когда вы меняете файл у себя локально он так же меняется на виртуалке. Мы ведь не зря прописывали folders секцию

Настройка Xdebug

На этом пункте я прокопался неделю, наверно, ибо в CLI версии нет xdebug, хотя сам модуль вроде как есть и он подключен. Нет, это не так. Его нужно ставить отдельно

Подключаемся по ssh (vagrant ssh)
Клонируем и переходим в папку

git clone git://github.com/xdebug/xdebug.git && cd xdebug

3. Запускаем конфигурацию

sudo ./configure --enable-xdebug

make

make install

4. Все произойдет автоматически и занимает около 1-2 минут. Следующий шаг - настроить php. В php.ini вписываем

Где remote_host - домен вашего тестового сайта, а zend_extension - путь, который вам дадут после конфигурации (3 пункт)

На всякий перезапустим nginx

sudo service nginx restart

5. Проверим, что оно работает

php -v

Работает. Теперь нужно настроить IDE и тут все упирается в то, где вы работаете. Покажу на примере PhpStorm

Настройка PhpStorm

Настройки -> Languages & Frameworks -> PHP. Тут выбираем CLI Interpreter. По умочланию его нет, поэтому тыкаем кнопку справа и добавляем

В первом поле указываем путь до Homestead.yml. Это один из первых шагов по развертке. У меня это:

В итоге должно быть примерно так:

А вот гарантия, что Xdebug установлен правильно

В меню получится так:

Далее заходим во вкладку Servers

Host - домен

Name - без разницы

После этого xdebug должен работать. Кликаем в верхнем правом углу PhpStorm:

Зеленая - прослушивается. Так же нужно поставить расширение для хрома, чтобы отлаживать.

https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc

Далее в хроме включаем его

И в коде на любую строчку ставим брейкпоинт и перезагружаем страницу

И видим в PhpStorm вывод:

На этом настройку локального окружения можно заканчивать

Что я узнал

Напоследок расскажу, что я интересного узнал за последнее время

Наконец-то почитал про Redis. Понял, как он работает, какие плюсы и минусы
Почитал про SPL. Для себя я выписал следующее:

Почитал документацию и статьи на хабре и медиуме. Возможно, проблема с производительностью была в пхп5 и в 7 версии все исправили, но все равно пока не видел примеров, которые бы использовали эту библиотеку и встроенные в нее классы для работы с объектами, очередями, стеками и т.д. В большинстве используют стандартные пхп функции для работы с массивами или встроенные возможности фреймворка для работы с очередями, ивентами и прочим (например Symphony/Laravel)

Использовать буду вряд ли, но зато теперь имею представление

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

4. Освоил Vue на базовом уровне (emit, кастомные компоненты, props). Разве что route пока не использовал в силу специфики своей должности (я все таки не фронтендер, хотя это и не отменяет того, что мне не надо это знать)

5. ElasticSearch. Крутая вещь для поиска и индексации больших данных, но пока нигде не использовал

6. Laravel cache. Изучил и попробовал. Оптимизировал 47 запросов до 24, а потом и до 14. Ускорил загрузку страницы с 2.2с до 800мс. Вот хорошая статья на хабре

https://m.habr.com/ru/post/463495/comments/

7. Прикоснулся к Laravel broadcasting. По идее та же реализация websocket'ов, нигде не пробовал, просто почитал и понял как работает.

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

Вообще, за последнее время на меня повлияли следующие слова моих коллег по работе, я их принял и стараюсь придерживаться:

Менеджер проектов:

Давайте разговаривать, все-таки не маленькие уже

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

Мой менеджер проекта:

Это не твоя игрушка, чтобы как-то играться с ней, это серьезный проект

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

Руководитель производства:

Это сломалось, в данный момент мне без разницы как оно сломалось. Мне важно, что оно заработало. Мы можем починить это с минимальными трудозатратами?

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

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

Мама, смотри какой дядя полицейский высокий. Я когда вырасту таким же стану!

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