🎢 Как я использую Chat GPT
С удивлением узнал от коллег, что у нас не все еще юзают ChatGPT на постоянку. ( Да как так-то ⁉️) Во многом потому, что не вполне понимают, чем им этот инструмент может помочь (считают слишком тупой эту штуку, если по-честному)

Короче, я посчитал, что просто обязан теперь всем пропагандировать работу с чатом ГПТ. Посему, решил показать, как я сам пользуюсь этой штукой, и как она мне помогает на примерах:
1️⃣ Проверяю смысл иностранных слов. К примеру у меня был выбор названия классов между Location и Coordinates. В чем разница? Оказалось, что Location более абстрактная структура данных, и может содержать в себе Coordinates, но вдобавок содержит в себе скорость, направление и прочие штуки.
2️⃣ Строю SQL запросы. Описываю свои таблицы и взаимоотношения между ними, индексы, которые там есть и прошу построить оптимальный запрос. Если что-то не выходит, то уточняю запрос.
3️⃣ Пишу всякие yml для Github Actions и прочего. Мне всегда лень это делать, а эта штука сильно ускоряет процесс. Просто говоришь, что тебе нужно и какие есть параметры и на выходе получаешь готовое решение.
4️⃣ Формирую Regex'ы. Вот это самое облегчающее мою жизнь действо. Если помните, то были даже всякие конструкторы для Regex'ов. Вот они теперь нахер не нужны. Даешь пару шаблонов, говоришь, какую последовательность нужно вытащить и получаешь рабочий Regex. Да а еще XPath'ы идут в ту же копилку.
5️⃣ Пишу бойлерплейт. К примеру код хэндлера просто генерирую в этой штуке. В идеале хочу прийти к AI aided testing, чтобы писать сразу тесты и код промптом. Но это подходит только для хорошо организованного проекта со стандартной структурой. Если там какой-то лютый велосипед, то все идет прахом.
6️⃣ Если учитывать копилот, который я себе недавно поставил, то он пока не приносит такого удовольствия, как я ожидал. То, что подсказывает, порой не подходит, но в целом что-то он упрощает, это да.
7️⃣ Пишу посты сюда (Да да, я сюда только матерок вставляю, а вы не знали? Ладно, это просто смехуечек. Посты здесь ручной работы!)

👍 Если подводить какой-то Rule of Thumb для использования ChatGPT в работе, то для меня он звучит примерно так "отдавать этой штуке все, что мне самому было бы скучно делать".

Так скажу, что ChatGPT на данном этапе сделал работу несравненно лучше. Если когда-то испытывали восторг от использования ReSharper (если кто-то вообще еще помнит, что это такое), то тут примерно те же ощущения.

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

🔬Мелкая декомпозиция, как она ускоряет разработку в разы?

Одна из самых полезных фишек, которую мне вдолбили в голову в Додо — задачу нужно дробить максимально мелко.

Если честно, я был убежден, что в Додо это очевидно всем, но недавно меня спросили: "А в чем плюс мелкого дробления задач?" Я рассказал на пальцах. Но меня еще раз спросили. Я снова рассказал. Но МЕНЯ ЕЩЕ РАЗ СПРОСИЛИ СЕГОДНЯ. Решил расписать, чтобы просто кидаться ссылочкой.

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

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

👯‍♀️ Две команды делали два новых сервиса. Сервисы предельно схожи по функционалу. В обоих нужно было собирать из шины сообщения и показывать цифры на телевизоре (разумеется в красивой оболочке, чтобы было секси и все такое).

Первая команда выбрала путь самурая: выкатить сразу некий рабочий мвп, который можно показать в пиццерии. До момента состояния пригодного к демонстрации сервис разрабатывался только на дев стендах и локально.

Вторая команда выбрала вариант с выкаткой пустого сервиса в прод и постепенным доведением, мелкими шагами, до пригодного для демки вида.

Казалось бы, первый вариант правильный. Зачем тратить место на проде, если сервис еще не готов? Вот тут и произошла загвоздочка!

В какой-то момент в командах произошла одна и та же ошибка: сообщение из шины консьюмилось неверно и приводило к падению приложения. Разумеется на момент ошибки это было неизвестно, поэтому команды взялись за разбирательства

У команды номер один в момент поломки был готов и фронт и бэк, поэтому матрица диагностики состояла из трех вариантов:

1️⃣ Сломан бэк, фронт в порядке
2️⃣ Бэк в порядке, сломан фронт
3️⃣ Самый худший вариант: Сломано и то и другое.

У команды номер два матрица диагностики была такая:
1️⃣ Что-то сломано в бэке.

Чувствуете разницу? Три варианта против одного. Более того, в случае, если команда один сломала и фрон и бэк, то поиск проблемы усложняется многократно!

У команды два диагностика минимальна: "Мы выкатили коммит, где всего десять строчек. В них что-то видимо и сломалось."

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

В первом случае выкатка заняла время разработки + долгое время диагностики. (2 месяца в сумме)

Во втором случае только время разработки. (1 месяц в итоге)

И это то самое преимущество, которое дает мелкое дробление задач — устойчивость перед так называемыми Черными Лебедями. Вроде все очевидно.

И вы спросите, Димас, ну все же очевидно! Почему тогда люди не понимают, что дробить задачи нужно мелко?

Дело в том, что, если, у обеих команд все пошло бы гладко, то вся эта матрица проблем свелась бы к нулю. И тогда мелкая декомпозиция и время её выкатки не сильно отличится от времени выкатки БОЕВОГО МЕГАКОНЯ.

Тут я упомяну Канемана в суе. У него есть хорошая теория, что человеческое сознание делится на две системы Система 1 и Система 2.

Система 1 - это штука, которая работает быстро, не тратит энергию мозга, но и результаты выдает скверные. Она задействуется всегда, по делу и без.

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

Так вот. Чтобы расписать вышеприведенную матрицу надо напрячь мозги. Более того, нужно еще где-то на подкорке понимать, что может случиться ⬛️ 🦢Черный Лебедь. А это мысль неприятная, думать её тоже больно, что дополнительно толкает мозг думать проще "Выкатим все разом, ну там же ломаться нечему!"

🅰️ Итого, ТЛДР: Мелкая декомпозиция не помогает сделать быстрее в идеальном случае, она обеспечивает устойчивость по отношению к Черным Лебедям. Но вообще, по-честному, скажу так. В айти закон Мерфи работает всегда: "Если что-то может сломаться, то оно сломается" А это значит, что мелкая декомпозиция с ОЧЕНЬ большой вероятностью действительно ускорит разработку.

Если будут спрашивать, то расскажу, до каких пор рационально мельчить задачи, и где найти грань. Ну я по своему опыту, расскажу, конечно)))
#опыт