Привет, меня зовут Никита.
Я WordPress разработчик с 15-летним
стажем, четыре года из которых
работал в команде.
Предполагаю, что вы все
опытные разработчики,
работающие на Toptal, Upwork
или других платформах. Умеете создавать
сайты с нуля, разрабатывать
плагины и темы, исправлять ошибки,
оптимизировать и так далее. Будучи фрилансером,
вы можете работать как угодно,
никто не контролирует ваш код. Но если
вы решили перейти от фриланса
к командной работе.
Сначала
хочу поблагодарить мою жену
Викторию за поддержку. Буду рад
аплодисментам.
Хорошо.
Начнем.
Хочу поделиться с вами
дорожной картой, основанной на моем
опыте. Мне часто приходилось
чувствовать пробелы в знаниях,
особенно при работе с более опытными
командами.
В этом главный минус фриланса.
В интернете
множество источников знаний, руководств,
спецификаций,
курсов - бесплатных и
платных, коротких и длинных. Но
каждый курс обычно охватывает
лишь одну тему. Обещает
сделать из вас мастера "с нуля" и
выдает себя за "исчерпывающий" источник,
после которого вы будете знать
все необходимое о
разработке.
Это напоминает индийскую
притчу о слепых,
изучающих слона - они ощупывают
его хобот, уши и хвост, и каждый из них
и каждый думает, что слон похож
на змею, лист или веревку.
Кстати,
возможно, не случайно, что
слон - символ PHP.
Извините, еще раз моя жена. Обычный продвинутый
PHP-курс включает
базовый синтаксис, различные функции для работы с
датами, временем, строками, регулярными выражениями,
исключениями, базами данных,
почтой, шаблонами, сессиями.
Очень часто длина
курса не превышает 8-10 часов.
Это также напоминает другую книгу "Изучи
китайский за 7 дней". Однажды я взял один
курс на Udemy, что-то вроде
продвинутого PHP курса, который обещал
много. Он длился 6 часов и
включал только 9 минут
о PHP-фреймворках, 9 минут о паттернах
проектирования, 27 минут о SOAP и
REST протоколах.
Мне потребовался один вечер, чтобы пролистать его
и получил сертификат,
не узнав ничего нового
Как
Чеширский кот вел Эллиса в
сад, не давая прямых
ответов, я попробую сделать
почти то же самое. Я хочу подчеркнуть,
моя речь абстрактна. Я
не буду углубляться ни в одну из
тем. Вам придется много изучать
самостоятельно, но вы получите
неполный список предметов,
которые нужно изучить.
Если вы WordPress-разработчик
вы знаете, что эта CMS основана на PHP, поэтому
то, что вы должны знать -
это основной PHP, вы должны знать
последняя картинка - legacy код, вы должны отслеживать
изменения даже в небольших обновлениях.
Паттерны проектирования, архитектура
Model-View-Controller,
алгоритмы. Вы можете
проверить свои навыки на CodeWars
или LeetCode или подобных проектах.
Веб-технологии, HTML, CSS, конечно,
даже backend-разработчикам нужны,
поскольку WordPress представил Gutenberg,
без JavaScript и ReactJS
не обойтись.
Что касается WordPress,
то же самое для спецификаций. Вы
должны отслеживать изменения. Хорошо знать
developer.wordpress.com,
и WordPress Codex.
Как построены темы и плагины,
шаблоны и так далее. API, хуки, действия.
WP-CLI - консольный инструмент, нечасто
упоминаемый в курсах, но сегодня
он упоминался по крайней мере дважды, так что
он очень полезен. Помогает
установить
проект WordPress с нуля,
заполнить базу данных тестовыми
данными, создать скелеты тем и плагинов,
мигрировать, легко делать поиск
и замену. Gutenberg - новый
визуальный редактор, ну не новый, он существует
уже но многие фрилансеры все еще
работают со старым редактором
фрилансеров,
которые все еще работают со старым
редактором,
решая разные задачи с помощью мета-полей,
что не так удобно для
веб-мастеров. Также сторонние
плагины - очень важная часть. Вы
должны знать, какие плагины могут помочь
вам
WooCommerce - для магазинов
Polylang - для многоязычных сайтов,
что WooCommerce - хороший инструмент для
магазинов. Polylang и подобные
инструменты хороши для многоязычных сайтов.
Также я хотел бы упомянуть болгарский проект
Carbon Fields,
поддерживаемый компанией HTML Burger
со штаб-квартирой в Варне.
Компания
со штаб-квартирой в Варне.
MySQL -
вы должны очень хорошо знать
класс БД WordPress и его методы его
основные методы. Также вы должны знать,
как
защитить данные, как делать пользовательские
запросы.
Основы структуры таблиц,
где скрыты посты, мета-поля,
миграции, поиск и замена,
пример из работы: и так далее.
Я приведу один пример
из моей работы - мне приходилось
иметь дело с огромной базой данных,
может быть, 10 гигабайт. Мне пришлось
мигрировать ее в тестовые ветки.
И тогда я узнал, что мне не нужно
делать поиск и замену всей базы данных. Мне
нужно было внести некоторые изменения в таблицу
wp_options и некоторые другие места
без поиска и замены всей
базы данных. Этого было достаточно для тестирования.
Transients также не часто упоминаются, но
были упомянуты в первой
лекции. Много применений.
Одно из них - хранение
временных данных для экономии времени,
например, результатов API
запросов.
Когда вы работаете с каким-то
удаленным API, вы запрашиваете все время.
Это занимает много времени ждать,
пока он загрузится. Иногда
это платные данные, как в случае
Google BigQuery.
Системы контроля версий. Извините, у меня
здесь опечатка. Наиболее
распространенные - это git и Subversion.
Первый используется в большинстве
проектов, включая как
коммерческие, так и open source.
Subversion, вероятно, имеет своих
пользователей, но в основном если компания
поддерживает какой-то проект на WordPress
или тему, или это может быть тема или плагин
на WordPress.com, как Advanced Custom
Fields или Carbon Fields, которые я упоминал
ранее.
Git Flow или подобные рабочие
процессы обычно зависят от корпоративных
стандартов компании. То же самое для соглашений
о наименовании. Когда вы
фрилансер, строгие стандарты компании,
как вы называете коммиты. Используете ли
соло-разработчик работает
без проверки кода, если только
заказчик не разработчик, вы
должны их соблюдать.
Code review - также важная
часть. Когда вы соло-разработчик, никто
не проверяет ваш код, или может быть очень
часто, если заказчик - тоже разработчик.
Это помогает
проверить код, найти нехорошие решения или
опечатки,
ошибки или может быть
попытки цели: линтеры, тесты.
CI/CD - непрерывная интеграция,
загружает код через SFTP большая
тема. Но все компании
обычно или часы. Не критично
линтеры кода, прохождение
тестов,
посетителей или платящих
фрилансер,
вы можете загружать свой код через SFTP
протокол, сломать сайт на несколько
минут, может быть на час или больше,
на самом деле это не так критично, но когда
вы имеете дело с проектом с большим количеством
посетителей, виртуализация - оправдание,
которые платят деньги, вашей
компании не понравится, если вы сломаете
сервер какой-то пропущенной
точкой с запятой на 10
минут или на час. С этим
вы можете заказчику, он установит, если это
критично.
Виртуализация -
инструменты: Docker, VirtualBox -
Devilbox, Lando, Vagrant.
Когда
я имею дело с такими оправданиями, я
обычно говорю: "Хорошо, передайте
стандартов или вашего выбора в своем
дата-центре". Есть много
инструментов для этого - Docker, VirtualBox или
некоторые решения, как Devilbox, Lando,
Vagrant, и их тонны. Это
может зависеть от корпоративного
стандарта компании или на предыдущих версиях,
будет ошибка, проект сломается
отладка и профилирование
обновление PHP 8.4 ввело
новый синтаксис для инициализации
класса. Вы можете
с Xdebug, следить за APM. Если вы сделаете
то же самое на какой-то предыдущей
версии, у вас будет ошибка
и вы сломаете проект.
Отладка и профилирование. Обычно компания не заставляет
вас это делать. Но это
хорошая идея отлаживать
ваш код с помощью популярных инструментов, как Xdebug,
следить за APM, отслеживать,
где утечка ресурсов, какой запрос
занимает слишком много времени, что создает
время простоя и так далее. Инструменты тестирования.
Есть много видов тестов.
Есть много
паттернов тестирования и так
далее. Я не буду углубляться
или никогда. Сервисы как создадите
свои собственные тесты,
вы сэкономите время на
разработку. Вы сэкономите время ваших товарищей по команде,
QA.
И в результате вы станете
pet-проектам
как правило дорогая лицензия
или подписка
иногда требуется специальная
Periscope или BigQuery или Bright, используются
при переходе в команду
читаете описание работы
например, компания использует.
Обычно это дорогая лицензия или
не займет много времени.
5-10 страниц API последняя картинка - legacy код
обычно сервисы следуют.
RESTful API или GraphQL
не изобретают велосипед
на интервью можете сказать,
"не работал с Brightcove
но знаю Vimeo API
YouTube API. Не потеряюсь"
последняя картинка - legacy код.
типичная работа
разработчика в офисе
фрилансер может настаивать
на переписывании с нуля
в корпоративном проекте
никто не будет этим заниматься
legacy код - что-то
опубликованное годы назад
думаю, я не потеряюсь здесь.
многие разработчики ушли
из компании
пробелы в документации и коде
обычно говорят
"не чини, если не сломано"
зависит от компании
спасибо за время. Надеюсь
был полезен
готов ответить на вопросы
поддерживается пять или десять лет,
никто не будет с этим возиться, и
типичный legacy код - это что-то,
опубликованное годы назад, обновленное несколькими
командами. Многие из них перестали работать
и покинули компанию.
Есть пробелы в документации и в
коде, и обычно вам говорят:
"Не чини, если не сломано".
Это зависит от компании тоже.
Спасибо за ваше время. Надеюсь, я был
полезен
Готов ответить на вопросы.