Три урока, которые я усвоил, будучи профессиональным веб-разработчиком

Непрерывная интеграция

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

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

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

#1 PHP благополучно вернулся

Или, в зависимости от ваших взглядов, вы можете считать, что с он по-прежнему великолепен. Такой ответ тоже принимается. Мне случалось сделать несколько простых динамических вебсайтов и кастомизировать WordPress-блоги с помощью РНР5 и я быстро заметил, что устаю от него. Такие языки как Python и Ruby казались более чувствительными и интересными в плане дизайна вебсайтов, чем старый добрый РНР. К счастью, это уже не так.

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

Сегодняшний РНР имеет сильную типизацию, отличную поддержку локальной разработки с Vagrant и Docker, более разумный синтаксис (больше никогда не пишите array()) и тысячи удобных фреймворков. Кстати о фреймворках: пользуйтесь ими. Серьезно. Фреймворки, подобные Laravel и Lumen, не только повышают безопасность вашего приложения, они также обеспечивают вам огромный массив помощников от абстракций баз данных, шаблонов аутентификации и до – это мое самое любимое – шаблонизаторов.

У вас по-прежнему будут забавные сравнения вроде:

echo 123 == '123lol' ? 'True' : 'False';
# Outputs True

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

Все достоинства фреймворков также касаются CMS-платформ, таких как WordPress. Например, Sage 9, грядущее крупное обновление популярной начальной темы WordPress, которая позволяет вам писать свою тему с использованием Webpack, шаблонов Blade и Bootstrap 4.

Остались в прошлом дни, когда вам приходилось редактировать ваши РНР-файлы локально, затем запускать FTP-клиент (например, FileZilla или WinSCP) для передачи вашего кода на удаленный сервер, а потом надеяться, что все будет работать. Мой собственный рабочий процесс с РНР состоит из установки РНР локально через менеджер пакетов Homebrew, настройки nginx, MariaDB, Redis и других зависимостей внутри их собственных контейнеров Docker, которые я объединил с помощью Docker Compose. С тем же успехом я мог бы установить все это в виртаулбоксе Vagrant, как Homestead или Scotch, или просто позволить им счастливо проживать в окружении macOS. Тем не менее это именно тот подход, который мне удобен, и он дает достаточно свободы, когда доходит до перемещения между ноутбуками.

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

#2 Не будь глупцом – конфигурируй свои инструменты

Это очень важная тема, которая часто ускользает из поля зрения. Настройка вашего окружения является (и должна быть!) чем-то большим, чем простое скачивание текстового редактора вроде Sublime Text и включения подсветки синтаксиса. Если вы пользователь Vim, то тема конфигурации редактора близка вам как никому другому.

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

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

Я, не отличаясь от многих других, перешел от выбора между Vim и Atom к Visual Studio Code, который уже дает мне встроенный терминал, дебаггинг, возможность запуска юнит-тестов, разумный статический анализ и инструменты рефракторинга кода с помощью расширений. Для некоторых более сложных задач я по-прежнему пользуюсь IntelliJ IDEA, у которого в данное время лучшая PHP-интеграция, но я планирую как можно быстрее начать использовать VS Code в качестве моего единственного редактора.

Несмотря на то, что Линус Торвальдс поливает грязью пользование отладчиками, я настоятельно рекомендую использовать один из них – Xdebug хорош для РНР. Без отладчика вы добавите дополнительную когнитивную нагрузку на свой мозг, пытаясь удержать в голове поток системы. Очень вероятно, что вы просто устанете и начнете перебирать все переменные и файлы пока не найдете жалкий метод, возвращающий 127 вместо false. С отладчиком вы видите все состояние приложения до контрольной точки, и можете оценивать выражения внутри этого состояния. Это не только бережет время, но и избавляет от ненужной усталости.

Последнее по порядку, но не по значению: если кому-то нравится Emacs, не пытайтесь со рвением религиозного фанатика заставить его использовать Vim или что-то другое. Вы при этом выглядите так, будто забыли мозги в прошлом столетии. Культура, касающаяся инструментов разработки, чрезвычайно богата, и у каждого есть пространство для выбора своего любимого снаряжения. Стали бы вы убеждать Гимли сменить его топор на лук перед лицом готовящейся к атаке орды Урук-хая? Я так не думаю.

#3 Непрерывная интеграция гарантирует спокойный сон

У нас, как у любой достойной компании, занимающейся программным обеспечением, обзоры кода это часть процесса разработки. Без стабильной CI (continuous integration) мы бы утонули в регрессии багов и нам бы пришлось приставать к нам коллегам на предмет тестировали ли они то или это и с каким покрытием.

В моем основном проекте мы настроили CI для первого запуска кода с помощью PHP Code Sniffer и PHP Mess Detector (которые являются прекрасными инструментами при правильной настройке), для запуска модульных тестов с покрытием и конечной проверкой, является ли покрытие 100%. Каждая предыдущая проверка с ненулевым кодом возврата остановит запуск и отправит уведомление разработчику. Покрытие меньше полного также остановит запуск. Если любая проверка проваливается мы не одобряем проверку кода. Временами это сложно, но это обеспечивает относительную краткость технических обязательств, приемлемый уровень качества кода и то, что новые свойства не сломают старые.

Непрерывная интеграция также очень легко настраивается в Travis и Gitlab с использованием пары блоков YAML. Если вы работаете над проектом с более чем несколькими разработчиками, использование CI очень полезно, если вообще не обязательно.

Заключение

В 2018 году я буду углублять эти навыки и расширять новыми. А что вы вынесли для себя из своего первого рабочего года?

***
Подписывайтесь на наш канал в Telegram!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

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

Прокрутить вверх