Запостил новую статью про то как делать какие-то прикидки насколько быстро или долго может выполняться тот или иной запрос:
https://hackernoon.com/how-to-make-rough-estimates-of-sql-queries

Но конечно все равно такие вещи сводятся к мониманию архитектуры баз данных, а еще глубже - к знанию как работает железо.

Недавно дошло, почему у меня в целом редко бывают рутиные задачи в обычной деятельности, хотя почти на каждом рекрутинговом интервью спрашивают "А как ты относишься к рутиным задачам?".
Дело в том, что суть любого программиста - это автоматизировать рутину. И вот буквально каждый мой рабочий момент, где я сталкиваюсь с рутиной или местом, где мне нужно скопипастить сотни, а то и тысячи строк, чтоб добавить функциональность/фичи, я начинаю искать как же это можно автоматизировать или унифицировать и как-то само собой рутиная задача превращается в интересный челлендж "как же сделать правильно то, что не сделали до тебя другие". И почти всегда можно найти ошибки в дизайне / проектировании / идее, которые привели к появлению рутины в том месте, где этого можно было избежать или создать инструмент чтоб твои заказчики/пользователи сами с помощью инструмента решали свои рутиные хотелки.

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

Dependency Inversion для процессов разработки

Представьте, что у вас есть команда, отвечающая за бекофис банка. У вас есть несколько сотен тысяч клиентов, с которыми периодически что-то происходит - у кого-то баг, кому-то что-то не привезли, кто-то решил закрыть аккаунт. Выделена команда, которая реализует бекофисную "очередь запросов" требующую от менеджеров вовлечения - аппрув чего-либо, расширение лимитов, ревью из-за подозрения в мошенничестве или отмывании денег, запрос документов и т.д.

Команда может быть загружена на 100% реализацией каждого вида запроса - нужно делать серверную интеграцию, фронтенд часть, отображение информации и т.д. Но что если посмотреть на эту задачу с другой точки зрения? Можно создать инструмент для создания таких фич для других команд и сервисов, чтоб они сами регистрировали новые типы кейсов, требующих ревью менеджеров, и сообщали в наш сервис коллбек поинт с вариантами возможных действия для решения кейса.

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

Короче, такой "продуктовый DI" в конце концов изменяет процессы разработки и повышает эффективность работы и этой команды и других. Не стоит зацикливаться на реализации каждой отдельной фичи, лучше создать инструменты, которые позволят другим командам интегрировать свои сервисы самостоятельно.

Через пару недель вместе с замечательной @xuyanet планируем провести стрим с обсуждением IT рыночка и в качестве бонуса разберём и покритикуем несколько резюмешек. Если хотите чтоб ваша резюмешка попала в разбор - кидайте мне в личку, самые типовые ошибки обсудим, а самые интересные CVшки разберём на стриме.

На прошлой неделе схлестнулись мы с коллегами по одной теме о том, как же правильно писать компоненты на React, я из-за некоторых болячек пересмотрел подходы к базовому паттерну в проекте и имплементировал кое-что попроще (с моей точки зрения), но коллегам не нравилось это, хотя альтернативы были хуже и экстремальнее (с моей точки зрения). А их только одна небольшая деталь в общем-то не устраивала, но как ее сделать правильно ни я, с 6 месяцами опыта на реакте, ни кто-нибудь из них не втыкали. Вот так и просидели 4 мидло-сениора три часа на коле ничего не решив и только проспорив про подходы.

А на следующий день я вместе с ChatGPT обсудил проблему, рассказал ему чего там у меня в компонентах и он показал на примере как можно упростить мою штуку. Коллеги сказали "Да, это подходит".

А выводов пока что не будет. Вот посоветую только интересную статью как тот самый Т9 доэволюционировал до ChatGPT: https://thebell.io/evolyutsiya-neyrosetey-ot-t9-do-chatgpt-obyasnyaem-na-prostom-russkom-kak-rabotayut-yazykovye-modeli

Fill Factor для РСУБД

Fill Factor — это параметр, определяющий, какой процент каждого блока данных базы данных будет использоваться для операций вставки (INSERT). Оставшееся пространство будет использоваться для операций обновления (UPDATE). Это означает, что если в том же блоке имеется свободное пространство, строка будет перезаписана в тот же блок, что в свою очередь не потребует пересчета индекса.

Для некоторых паттернов нагрузки на таблицу, например, если ваша таблица часто получает запросы по определенному индексу (не первичному) и возвращает более одной строки, а также имеет много запросов на обновление отдельных записей, установка Fill Factor ниже 100% позволит хранить часто запрашиваемые данные вместе, избегая фрагментации. В результате, это приведет к уменьшению случайных чтений (Random Reads) с диска и увеличению процента последовательного чтения.

Применяя Fill Factor и команду CLUSTER в одном из моих недавних экспериментов на продакшен-базе на сервере Google Cloud SQL, мне удалось ускорить выполнение критических запросов в ~1000 раз для наиболее сложных сценариев. Конечно, все зависит от характера нагрузки на таблицы, но у меня сложилось ощущение что это может вылечить многие сложные случаи.

Снова про ChatGPT

В последнее время так получилось что я работаю с фронтендом и много пишу на React/TypeScript. До начачала использования ChatGPT я просто полагался на свой большой опыт в бекенде, некоторые интуитивные штуки и гуглеж. Но сейчас ИИ стал прям постоянным бадди который четко отвечает на вопросы, помогает писать некоторые куски кода, скидывает мне примеры, описывает плюсы и минусы разных подходов. По моим ощущениям продуктивность изучения технологии, эффективность реально ощутимо выросли. Изначально было и про выросшее качество кода но тут видел в тви ссылку на исследование что ИИ приводит к понижению качества кода, так что тут еще посмотрим :) субъективно - растет, объективно - не знаю.

Это вот то самое пресловутое "рост производительности труда". Как писали умные люди - к безработице это не приведет, но приведет к необходимости переучиваться, еще большему количеству новых рабочих мест, и росту среднего благосостояния.

Наскринил рандомных мест из диалога для примера (появятся в комментариях к посту). Это по сути я в новой для себя технологии занимаюсь архитектурными делами + одновременно изучаю эту самую технологию и докапываюсь до всяких непонятных мне деталей. А этих непонятных деталей в каждой новой технологии всегда полно.

Так что если вам не хватает ментора - за 20 долларов в месяц его легко сейчас найти :)

Скоро еще сделаю пост с различными хаками которые помогают работать с ИИ эффективнее.

Сидел сейчас рефакторил очередной сложный кусок и интересная мысль пришла в голову:
Написание чистого кода требует чистой головы. А чтоб ваш разум был чист в процессе работы - он не должен быть забит знаниями о том, как будут работать те или иные вызовы на 4 уровнях абстракции ниже или выше. Чем большим количеством текущего контекста забита голова, тем меньше места остается на непосредственную текущую задачу.

Я люблю писать красивый и чистый код, и наверное поэтому я постоянно пытаюсь все упростить до максимального состояния :) и именно доведение каждого слоя приложения до самостоятельного независимого состояния в итоге и приводит к тому что очень легко становится с ним разбираться и не нужно "знание" о том как работает другой уровень, чтоб внести изменения на текущем.

Завтра залейтайте к нам на стрим! :) мы немного изменили планируемую тему с рекрутинговой на ИИшную но надеюсь это будет более интересно :)

во всем многообразии современных технологий не забывайте простую вещь.
я наверное по этой причине часто не пишу о чем-то думая что это и так всем очевидно 🥲

по мотивам использования ChatGPT написал в итоге статью с кучей рабочих скриншотов, читать тут:
https://ru.hexlet.io/blog/posts/chatgpt-kak-instrument-programmista

нашу прожарку заходов от рекрутеров полугодовой давности выложили на хабр:

https://habr.com/ru/articles/749992/

а вас что бесит в письмах от рекрутеров (кроме их отсутствия если вы только вкатываетесь 🥲) ?

Заметил, что в добротном микросервисном проекте уже не такую большую роль играют правильные слои controller/service/db, потому что когда в принципе в сервисе 2-3 сущности (а в некоторых сервисах - одна), то и "толстый контроллер" в этом случае сложно получить, ну потому что размеры не позволят. Конечно, не привызваю всю логику писать в один слой, хотя бы даже потому что тогда тестирование будет затруднено, но удивляюсь насколько же высокоуровневая архитектура влияет на низкоуровневую организацию. И избавляет от старых болячек.

Еще одно следствие правильной микросервисной архитектуры - отсутствие высоких нагрузок в пересчете на сервис. В проекте, в котором работаю, зарегистрированны миллионы  пользователей, сотни тысяч из которых совершают транзакции ежедневно. До такого уровня развития доживают считанные доли процентов проектов. И даже в такой ситуации в проекте нет никакого хайлоада или бигдаты. А из используемых технологий - Java, Postgres да Google Cloud. Да, даже кэш системы реализованы на основе СУБД. Очереди и асинхронная обработка - тоже базируются на базе данных и запускаются внутри сервисов, как Java классы из подключаемых зависимостей со своими конфигами.

И запаса по производительности еще кажется два порядка.

В итоге - не нужны дополнительные технологии, ни редисы и мемкеши, ни кафки и альтернативы с кучей обвязок типа дебезиума. А значит не нужны и отдельные инженеры или девопсы, которые умеют обслуживать и знают особенности дополнительных технологий. А все что нужно - люди, которые умеют работать с джавой и с постгресом. Более того, так как все технологии "in-house" - можно имплементировать самим дополнительные фичи если понадобится. По стабильности - меньше единых точек отказа, так как обычно всю инфрастуктуру обслуживает один кластер кафки и один кластер мемкеша. И по стоимости инфраструктуры - тоже выигрыш. На самом деле впервые столкнулся с таким подходом, но чем больше об этом думаю, тем больше вижу насколько много здесь очевидных плюсов.

Впервые обратил внимание что в ChatGPT наконец-то добавили дисклеймер что он может делать ошибки 👍

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

KISS в архитектуре

Пару последних и несколько следующих постов хочется объединить этим заголовком. И для продолжения повествования - напомню что это такое:

KISS - Keep It Simple, (Stupid/Soldier/Sailor). Это принцип, который говорит что использование максимально простого подхода или решения предпочтительнее оверинжиниринга. С моей точки зрения это важно помнить и при написании кода, и при планировании базы данных, и при когда проектируете продукт любого масштаба.

И еще один термин который понадобится это:

Bus factor - неформальный термин относящийся к управлению проектами, который определяет количество критически важных сотрудников на проекте. Это то количество сотрудиков, попадание которых "под автобус", нанесет критически серьезный ущерб проекту. Например, если на проекте только один человек обладает специфичными знаниями, то bus factor равен единице. И это, разумеется, рискованно для проекта.

Небольшой и, наверное, очевидный спойлер: использование KISS на высокоуровневом проектировании проекта автоматически повышает bus factor и снижает риски для проекта.