МОЙ ПЕРВЫЙ ЯЗЫК ПРОГРАММИРОВАНИЯ В КОММЕРЧЕСКОЙ РАЗРАБОТКЕ

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

Программирование я начал изучать с первого курса. За год изучения я уже знал на уверенном уровне С, С++ и немного Python. Как и все студенты, я мечтал попасть на стажировку в крупную IT компанию и получить свой первый опыт разработки. Однако меня (к сожалению или к счастью) не взяли ни в Яндекс, ни в Mail, ни в Авито, ни в Ozon. Оказалось, что знание С/С++ кроме Яндекса было мало кому интересно, а в Яндекс, к тому же, еще были очень высокие требования к знанию алгоритмов, которые на тот момент я особо глубоко не изучал. Так я впервые столкнулся с жестокой реальностью и понял, что изучение универсальных языков программирования совсем недостаточно для того, чтобы попасть на работу в IT.

В итоге моя мечта о работе в крупной BigTech компании была отложена, и так получилось, что я попал в небольшую IT компанию, которая специализировалась на разработке ERP систем для крупных российских компаний. В ней требовалось разрабатывать не на С/С++, не на Python и не на PHP… Моим первым коммерческим языком разработки стал… (барабанная дробь🥁) - ABAP！Да-да, многие из вас никогда даже не слышали о нем! ABAP — язык программирования специально разработанный для создания и поддержки приложений на платформе SAP.

Чтобы как-то кратко поведать о специфике этого языка и передать вам ощущениях от работы с ним, представьте 90-ые годы. Вы устроились программистом в компанию, вам дают маленький компьютер со стеклянным толстым монитором, вы запускаете IDE, которая выглядит как браузеры и сайты того времени на HTML 1.0. Вы открываете программу и видите: смесь SQL, C и Pascal. Комьюнити особого тут нет, в помощь вам 3-х томик по SAP и пару русскоязычных форумов… Куда я попал…?

У меня ушел месяц, чтобы погрузится в этот язык. После С++ он был чем-то очень примитивным и простым, но все же понятным. Итак, мне достается первая боевая задача, которая звучит как пофиксить какой-то небольшой баг в поле, где выводится не та циферка. Уф, здорово, я сейчас ворвусь в разработку! Моя первая таска - держись! Но не тут-то было… Следующие 3 дня я провел в отладке в монолитной программе, которую разрабатывали с 2007 года и столько разных людей и в разных компаниях, что, боже упаси, вам когда-то окунуться в такие дебри, legacy и монолит! Архитектура кода, паттерны, документация?! Нее, тут только хардкор в мире ABAP-а: только монолиты, только спагетти-код, только огромные SELECT-ы и VIEW на 400+ полей… За пару дней я пережил невероятные чувства разочарования, досады и гнева. Неужели разработка это вот ЭТО вот все?!

В общем и целом, как вы могли догадаться, надолго я там не задержался😅 Зато я получил необычный и, на мой взгляд, ценный опыт в разработке (не советую вам его повторять). Эта стажировка и работа с ABAP научили меня следующему:

1️⃣Работа с SQL - запросы в ERP системах бывают настолько сложными, что не каждый Senior сразу такой напишет… И все еще усугублялось большими таблицами и большим количеством данных. В итоге SQL был изучен на 200% и далее это мне помогло уже в работе в другой компании.

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

3️⃣И самое главное на мой взгляд — нужно постоянно изучать что-то новое, следить за трендами в IT и новыми технологиями. Не стоит тратить свою жизнь на legacy…

Потом, естественно, я узнал про Go, микросервисы, WEB разработку и стал в это погружаться, но это уже совсем другая история… 😉


А какой ваш первый опыт разработки? Какая была у вас первая задача?


P.S. картинка - это скриншот из SAP с программой на ABAP.

Продолжаем опросы)

Второй год подряд ребята из DevCrowd проводят большое исследование Go-разработчиков:
• Что входит в обязанности и каких навыков не хватает
• Сколько в среднем зарабатывают в профессии в зависимости от грейда
• Какие инструменты, сервисы наиболее популярны
• Что читают, слушают и смотрят для профессионального развития.

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

👀Посмотреть результаты прошлого года

Podlodka Go Crew снова в деле! Это онлайн-конференция, где обсуждаются актуальные темы для go-разработчиков.

В новом сезоне особое внимание уделяется архитектуре приложений на Golang. Сессии проводятся в удобное время — утром и вечером.

Чего ожидать?
- «От 1000 скриптов на Bash к (микро)сервисам на Go» — Максим Набоких поделится опытом миграции на Go в рамках крупнейшей kubernetes-платформы.
- «System design: Saga from zero to Temporal» — Антон Цитульский рассмотрит принципы оркестрации и хореографии, используя Temporal, и объяснит, как управлять бизнес-процессами в сложных системах.
- «Спецификации и код: Как выбрать правильный путь между генерацией и интеграцией?» — Леонид Ченский покажет плюсы и минусы разных подходов к работе с API-спецификациями и представит обзор инструментов, которые помогут с автоматизацией.

Билеты в продаже на сайте: https://podlodka.io/gocrew

Также делюсь с вами промокодом:

go_crew_4_drzJzG

Который даёт скидку в 500 руб💖

Делюсь свои докладом с Podlodka Go Crew 🧑‍💻

👀 Запись на YouTube

ЧТО БУДЕТ ПОСЛЕ МИКРОСЕРВИСОВ?

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

1️⃣Сложность управления. Увеличение количества микросервисов приводит к усложнению их координации, мониторингу и отладки. Каждый сервис требует отдельного управления, что увеличивает операционные затраты. Мониторинг становится по-настоящему сложной задачей, когда количество сервисов, инстансов БД и кешей переваливает за 10000.

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

3️⃣Сложность тестирования и отладки. Распределенная природа микросервисов затрудняет проведение интеграционного тестирования и отладки. Протестировать взаимодейтсие 2, 3, 4 сервисов еще вполне можно, но, когда фича затрагивает 10+ доменов, и в каждом домене еще по нескольку сервисов, учавствующих в цепочке взаимодействия, тестирование и координация интеграции превращается в тот еще квест)

4️⃣Снижение производительности из-за необходимости сериализации и передачи данных по сети между сервисами.

5️⃣Проблемы с управлением API, дороговизна изменения и актуализация API сервисов, передача лишних данных или наоборот недостаточных данных. У меня в сервисе был метод, на который было завязано более 80 других микросервисов, и потребовалось больше года, чтобы все клиенты смогли перейти на новый API.

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

Так, например, инженеры Google предложили разрабатывать приложения как логические монолиты, передавая их в автоматизированные среды выполнения, которые самостоятельно решают, где запускать рабочие нагрузки. По их словам, это позволило снизить задержки в 15 раз и сократить затраты до 9 раз. Для этого они разработали свой собственный фреймворк — Service Weaver

Команда Amazon Prime Video поделились своим опытом перехода от микросервисной к монолитной структуре для мониторинга видеопотоков, который привел к снижению операционных затрат на 90% и улучшению производительности.

Что это все значит? Да то, что ближайшие 2-3 года большие IT коммпании начнут пересматривать регламенты и подходы к разработке. Очевидно, мы будем наблюдать частичный возврат к монолитам и модульным монолитам. Разработчикам придется учиться работать с большой кодовой базой и уметь писать код так, чтобы в любой момент его можно было вынести на другой физический инстанс. В общем, господа разработчики, начинайте готовиться заранее 😉

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

AI В ПОВСЕДНЕВНОЙ РАБОТЕ РАЗРАБОТЧИКА

За последние 5 лет случился бум в области AI: появилось множество инструментов доступных широкой публике. Бытует мнение, что пройдет еще лет 5-7 и разработчики будут больше не нужны, ведь AI сможет все сделать сам. Я не согласен с этим мнением. Да, возможно, часть ниши сможет занять AI, где раньше нужно было нанять фрилансера или небольшую команду разработки для создания простенького сайта, приложения. Однако сложные системы полностью с нуля AI вряд ли сможет создать без какой либо корректировки со стороны экспертов в области разработки ПО.

Зато уже сейчас можно использовать все «блага цивилизации» (AI) и применять их в своей работе. Так, например AI-инструменты на подобие нашумевшего Github Copilot, можно встроить в IDE. Такие инструменты сильно ускоряют процесс разработки и сводят количество человеческих ошибок к минимуму. Если вас беспокоит вопрос безопасности вашей кодовой базы, то есть self hosted аналоги, например — tabby.

Также ChatGPT может стать реально вашим помощником, если научиться правильно пользоваться им (писать промты). Приведу плохой и хороший пример использования ChatGPT.

Задача: вам нужно интегрироваться с какой-то внешней системой (пусть это будет рассылка sms сообщений). У системы есть сайт с подробной документацией API. Правда, она текстовая, не в формате openapi, готовых SDK или клиентов на вашем языке нет…

Плохой пример: вы скармливаете ChatGPT ссылку на эту документацию и просите его, допустим, создать Go клиента к этой системе. С 99% вероятность ChatGPT вам выдаст, полурабочий код, который подойдет в качестве pet проекта для теста интеграции с системой, но никак не для enterprise разработки (банально эту будет тяжело поддерживать и вряд ли пройдет ревью от коллег). Поэтому дальше вам самим придется многое переписать, чтобы довести это до ума (или долго и упорно просить это сделать ChatGPT). Такой подход в лоб будет малоэффективным и ленивый разработчик быстро поплатится за то это🙂

Хороший пример:
Скоре всего, вы все же опытный и многоуважаемый разработчик. Ваш багаж знаний и опыт огромен, и, пожалуй, этим надо воспользоваться. Как бы вы интегрировались с системой по рассылке sms, не будь у вас ChatGPT? 🤔 «Если бы была openapi спецификация API, то я бы взял свой любимый инструмент кодогенерации, например oapi-codogen, сгенерировал клиента и готово! Имею поддерживаемый клиент с удобным API в коде»
Да, но у нас нет openapi спецификации… Тут на помощь и придет наш слуга — ChatGPT, который отлично подходит для рутинных задач. Заходим на страницу документации API. Сохраняем html страницы. Загружаем файл в ChatGPT и просим его перевести документацию в формат OpenAPI v3.0. Обязательно уточняем все наши пожелания (что обязательно должно попасть в спеку): какие методы, писать ли все коды ошибок, описание методов и моделей , приводить примеры и т.д. ChatGPT, как и разработчики, ленивый поэтому тут действует правило «Какое ТЗ, такой и результат». После этого у вас на руках готовая спецификация, и, если вдруг вы не работали с инструментами кодогенерации, можете также спросить у ChatGPT какие есть, и как с помощью них сгенерировать клиента. В нашем случае будет достаточно сделать //go:generate go run github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen --config=config.yaml ../../api.yaml. Готово! ✅

В будущем AI ассистенты станут неотъемлемой частью нашей жизни. Я уверен, что от разработчиков потом будут требовать навыки умения работы с AI ассистентами. Почему? Да потому, что это ускоряет разработку, а значит повышает его эффективность, значит бизнес получает быстрее результат, значит быстрее получит потенциальную прибыль 💰

Как я перешел из продуктовой команды в инфраструктуру: итоги за год

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

Продуктовая разработка: скорость, highload и бесконечные встречи

В продуктовой команде я занимался двумя совершенно разными проектами:
1️⃣Highload-проект — ключевая часть логистики Ozon с жесткими требованиями:
🔍350k+ RPS, постоянные стресс-тесты, оптимизации и «танцы с бубном»
🔍минимальный Response Time (10-50ms 99q),
🔍высокая стабильность (особое внимание к тестированию и релизам),
🔍отсутствие downtime. Этот проект постоянно горел, и каждый день был похож на марафон: срочные задачи, дедлайны, стабильность любой ценой.
2️⃣Данные и аналитика — здесь highload сменился глубоким анализом. Нужно было переварить огромный бэклог от бизнеса, объединить данные из множества сервисов и создать стратегическое и уникальное решение, которое могло работать автоматизированно.

Работа была насыщенной: постоянные встречи с бизнесом, интеграции с соседними командами, контроль сроков. На одном дыхании мы запускали проекты и закрывали эпики. Но однажды я понял: все проекты для меня превратились в «перекладывание JSON -чиков из одного сервиса в другой». Завершение задач больше не приносило удовольствия.

Зачем я ушел в инфраструктуру?

На фоне выгорания мне вспомнился опыт работы с highload: Kafka, Redis, Postgres, Kubernetes, Go. Мне захотелось использовать этот опыт в более глубокой технической среде. Я поговорил с руководством, и мне предложили перейти в инфраструктурную команду, где предстояло:
🔍собрать команду с нуля,
🔍погрузиться в новые технологии,
🔍построить процессы с чистого листа.
Это был шанс выйти из зоны комфорта!

Чему пришлось учиться?
Мой продуктовый опыт оказался полезен, но этого было недостаточно. Мне пришлось:
🔍углубляться в Kubernetes, сети, Ansible;
🔍разбираться с CI/CD, observability;
🔍чтение документации, эксперименты, изучение чужого кода стали ежедневной рутиной.

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

Ключевые различия между продуктом и инфраструктурой

1️⃣Отсутствие формальных ролей
В инфраструктуре нет системных аналитиков, проектных менеджеров, скрам-мастеров. Ты делаешь всё сам: от сбора требований до проектирования. Это требует универсальности, четкого подхода к задаче и дисциплины, но одновременно дает большую свободу.
2️⃣Характер задач
В продукте сложнее понять, что конкретно хочет бизнес (он сам иногда не знает), а реализовать это — проще. Это похоже на игру в «Дженгу», где каждый новый блок должен не разрушить систему.
В инфраструктуре всё наоборот: ты знаешь, что нужно сделать, но реализация почти всегда — неизведанный путь. Приходится учиться на ошибках и жить с MVP.
3️⃣Роль команды
Инфраструктурные проекты требуют сильной синергии команды. Никто не знает всё, поэтому слаженная работа определяет успех. Также важно собрать экспертов своей области. Тут не получится уже взять джуна/мидла и научить его всему.
4️⃣Изменение фокуса
Появился баланс между встречами и временем на код. Ушли бесконечные митинги, зато добавились глубокие технические исследования.

Сложности и выводы

1️⃣Оценка результатов
В продукте успех проекта измеряется деньгами и масштабом влияния на пользователей. В инфраструктуре оценить значимость работы можно только спустя время, что добавляет неопределенности.
2️⃣Недостаток компетенций
Чувство, что ты знаешь недостаточно, никогда не покидает. Но я понял, что это нормально. Инфраструктура требует времени на освоение.
3️⃣Новая роль лидера
Быть тимлидом в инфраструктуре — это значит учиться у своей команды. Люди в команде часто знают больше, чем ты, и это правильно. Главное — уметь организовать их работу.

Итоги года

Год прошел стремительно. Чувствую ли я себя в своей тарелке? Скорее нет. Но я вижу перспективы и планирую 2025 год посвятить углублению экспертизы.

⬆️Продолжение ⬆️

Больше книг, больше кода, больше экспериментов.
Признаться, иногда я скучаю по миру продуктовой разработки. Там была своя атмосфера: больше общения с бизнесом, больше видимого результата, чувствуешь себя значимым в команде. На неделю я бы с удовольствием вернулся в продукт. Но лишь на неделю)

Этот переход стал для меня настоящим вызовом. Если вы задумываетесь о смене направления в IT, знайте: это возможно. Главное — быть готовым учиться, ошибаться и адаптироваться.