Привет! 👋 Меня зовут Всеволод.

Коротко: 18 лет в разработке, из них последние 5+ — Director of Engineering в PHILIPP PLEIN. Да, та самая fashion-компания с черепами. Нет, я не выбираю ткани — я отвечаю за то, чтобы всё цифровое работало.

Под «всё цифровое» я имею в виду: 5 e-commerce платформ, 22+ интеграций с маркетплейсами, ERP, и команда из 9 человек, которую я собрал с нуля. До этого был CTO в IT-консалтинге — аутстафф, e-commerce, финтех. Начинал, как многие, с PHP в 2007-м.

Почему завёл канал? Потому что происходит сразу несколько вещей, про которые хочется думать вслух:

🔸 Перехожу на Go после 15+ лет на PHP. Заканчиваю курс в Яндекс Практикуме, начинаю тащить Go в рабочие проекты. Ощущения — как заново учиться водить после автомата на механике.

🔸 Полез в инфобез — тестирование веб-приложений, OSINT, готовлюсь к первым CTF. Оказывается, ломать то, что сам строишь — отдельный вид удовольствия.

🔸 Строю инженерные процессы в компании, где IT — это не продукт, а поддержка бизнеса. Со всеми вытекающими.

О чём буду писать ✏️

— PHP -> Go: что удивляет, что бесит, что реально работает лучше
— Инженерное управление за пределами big tech — без agile-коучей и бесконечных бюджетов
— Безопасность веб-приложений на практике, а не в теории
— Честные заметки из повседневной работы: грабли, находки, выводы

Я не эксперт-на-сцене. Я человек, который каждый день решает задачи и попутно разбирается в новом. Если вам интересно наблюдать за этим процессом — подписывайтесь, будет полезно 🙌

Что меня удивило в Go после 18 лет на PHP

Ну что, первый технический пост. Как писал в интро — заканчиваю курс по Go в Яндекс Практикуме и уже пробую его в боевых проектах. После 18 лет на PHP ощущения... специфические. Делюсь тем, что реально зацепило 👇

Обработка ошибок — никаких try/catch

Функция возвращает ошибку, и ты обязан разобраться с ней прямо здесь. Не "где-то наверху в catch", не "потом". Сейчас.

file, err := os.Open("config.yaml")
if err != nil {
    return fmt.Errorf("failed to open config: %w", err)
}

Первую неделю это раздражает — код разбухает, if err != nil преследует во сне. Потом замечаешь: в проде перестают всплывать те самые "а откуда это прилетело?" ошибки. Стоит того.

Стандартная библиотека

HTTP-сервер, JSON, крипто, тесты — всё из коробки. На PHP я бы сначала полчаса ковырял composer.json и подключал пакетов десять, прежде чем написать первую строчку логики.

Деплой — один бинарник

Без PHP-FPM, без Nginx, без composer install на сервере. Собрал, скопировал, запустил. Кто танцевал с конфигами на пяти e-commerce площадках — тот поймёт, какое это облегчение.

Горутины вместо "один запрос — один процесс"

Конкурентность встроена в язык, а не прикручена расширением. Это не просто фича — это другой способ думать об архитектуре.

Типизация без компромиссов

PHP годами добавлял type hints. В Go типы — не пожелание, а требование. Компилятор ловит то, что раньше ловили юнит-тесты (если они были).

Go не лучше PHP — они про разное. Но после 18 лет в одной экосистеме полезно увидеть знакомые задачи с другой стороны. Буду делиться процессом — подписывайтесь, если тема близка 🤔

В прошлых двух постах я рассказал, кто я и зачем полез из PHP в Go. Сегодня — про безопасность. Не абстрактную, а ту, с которой сталкиваюсь каждый день в e-commerce.

Я управляю пятью онлайн-магазинами, у нас 22+ интеграции с маркетплейсами, платежки через Adyen, YooMoney, крипту и банковские переводы, ERP-системы. Это значит — PII клиентов, API-ключи, платежные данные. И я видел, как это всё ломается.

Мой чеклист для веб-разработчика — из боевого опыта:

1. Секреты не в коде. Видел API-ключи маркетплейсов прямо в репозитории. Используйте vault или хотя бы .env + .gitignore. Серьёзно.

2. Security-заголовки. Content-Security-Policy, X-Frame-Options, Strict-Transport-Security — проверьте прямо сейчас. Половина проектов, которые я видел, отдают голый ответ без единого заголовка.

3. Валидация на сервере. Фронтовая валидация — это UX, не безопасность. Платежные колбэки от Adyen надо верифицировать, а не просто парсить.

4. Логирование без PII. Однажды нашёл в логах полные данные карт. Логируйте действия, не данные клиентов.

5. Зависимости. composer audit, govulncheck — запускайте в CI. Уязвимая библиотека — это открытая дверь.

6. Rate limiting. Без него ваш API для авторизации — подарок для брутфорса.

Всё это — не rocket science, а базовая гигиена. Но именно на базе чаще всего и спотыкаются.

Хороший старт для углубления — OWASP Top 10 (owasp.org/www-project-top-ten/).

А какой пункт из списка вы последний раз проверяли у себя в проекте? Делитесь в комментариях 💬