Два уже стандартных вопроса для митапов
На всех митапах или конференциях которые я посещал по теме производительности СУБД PostgreSQL, я всегда задавал этот вопрос : - Что такое производительность СУБД и как и вы рассчитываете метрику чтобы понять эффективность оптимизации? Каждый раз, когда задавал этот вопрос докладчик всегда начинал плавать… Как правило - ну производительность это время выполнения запроса, это комплекс метрик и т.д. и т.п. Что всегда вызывало у меня недоумение - как вы собрались оптимизировать то, что не умеете сосчитать?
В последнее время , в связи с всеобщим трендом - “а вот у нас еще есть AI -агент и он дает советы по оптимизации.” Я теперь задаю ещё один вопрос : - А как вы решаете проблемы галлюцинаций и не детерминизма ответов нейросети? И снова - докладчик начинает плавать - ну советы ИИ нужно проверять и т.д. и т.п. . Хм, зачем мне такой дорогой джун?
· 24.09
Мне кажется мерить производительность в попугаях не стоит. Просто не должно быть долгих запросов и подлагов при работе приложения. Синтетические тесты полезны, когда конфигурацию железа сравниваешь между собой.
Касательно ИИ, его ответы нужно проверять, как и любые примеры кода и утверждения со StackOverflow и Github. Плюс код ИИ, редко работает без пары правок (напр. использовал класс OrderTable, вместо реально существующего Order), но намётанный глаз сразу видит такие ошибки и быстро правит. Когда ИИ за минуту генерирует готовый код на 300 строк и в нём всего пара багов - это просто подарок, потому что 300 строк программист пишет за пол дня-день даже если это очень простой код.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 24.09
"Мне кажется мерить производительность в попугаях не стоит." - а как вы собрались оптимизировать то, что не измеряете ?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 24.09
"Касательно ИИ, его ответы нужно проверять" если мне нужно тратить время на постоянную проверку ответов сотрудника - зачем мне такой сотрудник ? Проблема решается несколько иначе - доменные инструкции , эпистимический подход и структурированные чистые входные данные. В таком и только таком случае - ответы нейросети можно использоват, и используются, в инженерной практике. В частности , я уже давно в PostgreSQL DBA
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 24.09
Поступает жалоба на медленную работу её и ускоряю. Когда какие-то жалобы повторяются, то конкретно этот участок начинаю отслеживать метрики через какой-нибудь Zabbix, чтобы проблема решалась ещё до того, как кто-то пожалуется.
На опыте и знании специфики предприятия можно таких метрик заранее создать. Но, если мы рассматриваем абстрактный пример, то выстраивать систему измерений заранее под гипотетические проблемы - это яркий пример овер инжиниринга.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 24.09
Вы наращивание сложность системы ради безупречного результата. А я говорю что вполне возможно использовать не безупречный результат. Лучше в 300 строках кода от ИИ пару багов самому поправить, чем усложнять всю систему и, соответственно, интерфейс к ней.
Вы видимо этот нюанс из внимания и упускаете, что чем сложнее инструмент тем сложнее с ним взаимодействовать. Я уже не говорю о техподдержки такого инструмента.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён