Всё о разработке | Леонид Ченский

Каждый второй go разработчик использует ChatGPT в своей работе согласно опросу dewcrowd.ru.

Интересная статистика, конечно, помогает понять основной тренд в индустрии.

Советую ознакомиться 🙂

ВЫГОРАНИЕ — НАЧАЛО ЧЕГО-ТО БОЛЬШЕГО?

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

Когда я был мидлом, я брался за любые задачи, какой бы сложности они не были. Это был вызов, драйв, возможность прокачаться! Новые технологии, нестандартные задачи — всё это превращалось в увлекательную игру, где каждый шаг приносил чувство прогресса. Я постоянно читал книги, проходил курсы, изучал лучшие практики… В общем, я изучал всё, что можно было уже на «следующий день» применить в работе и испытать кайф от того, что задача сделана «по красоте». Конечно, тогда я часто овертаймил, но оно того стоило.

Когда меня повысили до сеньора, задачи стали сложнее, но мой подход оставался прежним: чем больше закрытых задач — тем больше удовольствия и пользы.
Но, как это часто бывает, однажды я перегорел. И даже трехнедельный отпуск не помог: работать больше не хотелось, задачи перестали приносить радость. Всё казалось однотипным: прикрутить кэш, отправить данные в брокер, шардировать таблицу, штамповать юнит-тесты… Я перестал чувствовать интерес и драйв.

В этот момент мне предложили поучаствовать в проекте Route256 — образовательной программе для разработчиков от Ozon. Я подумал: «Почему бы и нет? Хоть что-то новое»…

И знаете что? Меня затянуло! Сначала три потока Route256, потом три потока своих курсов, несколько докладов на конференциях — всё это перевернуло моё понимание работы. Одно дело изучать что-то для себя, и совсем другое — объяснять это другим. Ты начинаешь копать так глубоко, что не просто заучиваешь best practices, а понимаешь их корни: почему так, а не иначе? Что стоит за каждой рекомендацией? Это невероятно прокачивает твои знания.

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

Сейчас я работаю над своим новым курсом по Go, и в планах — ещё много тем (где бы только найти на всё это время!). Ловлю настоящий кайф, когда удаётся простыми словами объяснить сложные вещи, а ещё больше радости приносит положительная обратная связь от коллег и учеников.

Был ли у вас подобный опыт выгорания или смена фокуса в карьере? Буду рад обсудить это в комментариях.

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 ассистентами. Почему? Да потому, что это ускоряет разработку, а значит повышает его эффективность, значит бизнес получает быстрее результат, значит быстрее получит потенциальную прибыль 💰

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

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

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 компаниях. Так что жду в следующем году на конференциях доклады касательно данного вопроса.

Как же быстро летит время...

Go исполнилось 15 лет! А кто застал работу на Go до 1.11?)

Настало время постигать opensource и делать свои проекты. Хочу поделиться с вами своей реализацией менеджера транзакций: https://github.com/moguchev/transaction_manager (не претендует на 1000 звезд). Посмотрим хватит ли времени ее развивать дальше😅

Для тех, кто не знаком с тем, что такое менеджер транзакций и зачем он нужен в Go советую прочесть эту статью от Авито. В ней очень хорошо передана вся боль работы с транзакциями в коде и обяснено зачем в чистой архитектуре он нужен и какие проблемы решает.

В выходные записал практикум по gRPC. Оказалось, что 3 часов записи мало, чтобы уместить все темы и фишки😥

Закрыт гештальт - мой первый контрибьют в "большой" OpenSource.

А вообще за последний год мне пришлось столкнуться с большим числом opensource проектов и погрузиться в них. Надеюсь сделаю когда-нибудь либу, которая наберет 1000 звезд на github😅

У кого есть принятые PR?)

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

👀 Запись на YouTube

ТРИ СПОСОБА РАБОТЫ С SQL БД В GO

В Go существует множество инструментов для работы с SQL базами данных. На данный момент я выделяю три основных подхода: автогенерация, ORM, и Query Builder-ы. Каждый из них предлагает свои преимущества и ограничения. Давайте я поделюсь своим мнением о каждом из них, чтобы понять, когда какой стоит выбирать.


1️⃣ Автогенерация
Автогенерация - генерация Go-кода на основе SQL-запросов. Данный подход чем-то напоминает работу со спецификациями API. Самый популярный инструмент на данный момент, который используется многими: sqlc. Он позволяет писать SQL-запросы, которые затем транслируются в чистый Go-код. Этот подход отлично подходит для случаев, когда требуется строгий контроль над SQL и высокая производительность.

Плюсы:
1. Статическая типизация: генерация строго типизированного Go-кода снижает вероятность ошибок и экономит время.
2. Высокая производительность: работает с «чистым» SQL, без лишних оберток.
3. Простота: нет необходимости изучать ORM или API библиотеки для написания запросов.
4. Поддерживает MySQL, PostgreSQL, SQLite.

Минусы:
1. Отсутствие гибкости: не подходит для сложных запросов с динамической логикой.

Когда использовать: если проект требует строгого контроля над SQL, и важна производительность.

2️⃣ ORM
Ох, сколько вопросов мне задавали про ORM-ки в Go... Большинство разработчиков пришедших в Go из других языков любят ORM и ждут, что в Go они тоже есть. Да они есть (к сожалению или к счастью). Но мне, как человеку, работавшему с ERP системами, где приходиломь писать огромные SQL запросы, на разработку которых могло уйти несколько дней, чтобы сделать его оптимальным, правильным да еще подобрать нужные индексы, ORM кажутся чем-то несерьезным (хотя возможно это не так). В общем новичкам я бы советовал вначале избекать ORM любой ценой.

Однака в Go, как я уже упомянул выше, есть ORM, и самая известная — GORM. GORM — фантастическая (как ее называют) ORM, предлагающая множество инструментов для работы с БД в стиле Active Record. Подходит для проектов, где требуется сложная логика запросов и удобная работа с моделями.

Плюсы:
1. Абстракция: значительно упрощает взаимодействие с базой данных (считайте что SQL, индексы вам знать не обязательно🙂).
2. Большая поддержка разного функционала (все-таки Gorm довольно давно развивается активно, так что там можно найти все что нужно)

Минусы:
1. Производительность: за абстракцию приходится платить сниженной производительностью.
2. Нужно погрузится в API библиотеки.

Когда использовать: отлично подходит для CRUD-приложений, где важнее скорость разработки, чем производительность.

3️⃣ Query Builder-ы

Query Builder-ы — незаменимая класика: гибкость, баланс и универсальность. Query Builder-ы (например, squirrel) позволяют писать SQL-запросы в Go-коде, сохраняя гибкость, но без излишней абстракции ORM. Это средний вариант между sqlc и GORM.

Плюсы:
1. Гибкость: удобно для динамических SQL-запросов.
2. Читаемость: позволяет строить сложные запросы пошагово.
3. Производительность: близка к ручному SQL, но проще в использовании.
4. Универсальность: легко встроится в любой проект, а API Query Builder-ов интуитивно понятны.
5. Низкий порог входа (если знаете SQL).

Минусы:
1. Типизация: не так безопасен, как sqlc, т.к. не генерирует типизированный код.
2. Требует понимания SQL и логики работы базы и индексов (ну а как без этого?)).
3. Не все Query Builder-ы cпособны осилить сложные запросы.
4. Для простых CRUD может стать утомительно писать одно и тоже (решается путем генерации шаблонного кода)

Когда использовать: оптимально для приложений со сложными, динамическими запросами.

Ставь 👍, если хочешь углубиться в эту тему поподробнее.

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 руб💖

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

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

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

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

Онлайн трансляция GoFunc 2024

Если есть море Java, то почему нет Go🤔

А вообще мое хобби во время полета рассматривать карту мира и смотреть полеты в приложении Flight Radar😅

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

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

Программирование я начал изучать с первого курса. За год изучения я уже знал на уверенном уровне С, С++ и немного 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.

🤔ТАК ЛИ GOLANG ХОРОШ В HIGHLOAD?

Golang обладает многими преимуществами для разработки высокопроизводительных, многопоточных программ. Именно за свои простоту и эффективность Go занял свое почетное место среди самых популярных языков для разработки микросервисов.

Однако при разработке высоконагруженных приложений на Go, в которых очень важны минимальные задержки, отзывчивость , могут возникнуть неожиданные проблемы…

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

Go использует ограниченное число потоков (М) для выполнения множества горутин (G), и увеличение числа горутин приводит к увеличению накладных расходов: балансировка горутин (G) между потоками (M), блокировки в глобальной очереди горутин, переключение контекста в потоке и т.д.

Также планировщик в Go не гарантирует четкого порядка исполнения горутин. Это означает, что каждый раз, когда мы создаем горутину, блокируемся где-то на мьютексе, системном вызове или канале, она идет «парковаться». Через какое время горутине посчастливится вновь исполняться дальше на потоке — мы не знаем… Чем больше горутин, тем выше шанс, что какой-то из них (а может нескольким) сильно не повезет и она будет очень долго ждать своего часа… Все это замедляет выполнение пользовательского запроса в нашем сервисе, особенно в 99 перцентиле.

Проблема 2. Сборщик мусора.

Go - язык со сборщиком мусора (GC) и его тюнинг может стать тем еще испытанием.
Частые паузы на сбор мусора (Stop The World) создают задержки, что непременно усугубляет проблемы с производительностью. Но это не главная проблема (операции STW довольны быстрые и не заметные в последних версиях Go). Главная боль - это сканирование heap-а за счет Mark Assist горутин- специальные горутины, которые начинают исполняться на потоках вместо наших горутин. Таким образом приложение по сути испытывает голодание потоков, потому что они заняты «полезной работой» по разметке объектов в куче. Когда сборщик мусора работает часто, наше приложение работает не на полную мощность и это все также ведет к замедлению обработки пользовательских запросов…

Как понять, что вы столкнулись с этими проблемами?

Вот метрики, за которыми точно нужно следить и подскажут вам, что что-то идет не так:
- Количество горутин. Тут нет конкретной универсальной цифры. Для каждого приложения есть свой определенный порог, после которого необходимо увеличивать количество инстансов вашего приложения.
- Время ожидания горутины на исполнение. Тут все просто: если 0.99q >= 1ms, стоит напрячься: добавить ресурсов приложению, увеличить количество потоков, увеличить число инстансов приложения, оптимизировать сборку мусора.
- Количество вызовов сборки мусора за минуту. В идеале этот показатель стоит держать в диапазоне 1-10 раз в минуту (не для всех типов приложений такое число актуально). Если чаще, стоит начать оптимизировать ваш код, и стараться добиться уменьшения количества вызовов GC.

В своем старом докладе рассказывал про работу сборщика мусора в Go и варианты его оптимизации.

🦫ВНИМАНИЕ ГОФЕРЫ - КОНФЕРЕНЦИЯ!

3 октября пройдет онлайн конференция GoFunc, на которой я буду выступать с очень интересным докладом 🧑‍💻

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

🙏 С ДНЕМ ПРОГРАММИСТА!

Друзья, сегодня отмечается день программиста (256 день года). И в честь этого приглашаю всех вас на свой открытый урок:

🆓«ПАТТЕРНЫ ОТКАЗОУСТОЙЧИВОСТИ МИКРОСЕРВИСОВ НА GO»

📆 14 сентября 18:00 по МСК

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

🔗 Регистрация по ссылке

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

А вообще словил невероятный кайф от оффлайн обучения, знакомств и курса в целом.

Поделитесь в комментариях, какой последний курс проходили, или какую книгу читали, для прокачивания своих скилов?