В качестве пожелания - было бы круто предусмотреть возможность подключения дополнительных MCP серверов. Например для периодической векторизации кода и метаданных проекта, для подключения собственных правил стат. анализа, интеграции с внешними источниками знаний (документация, ADR, архитектурные решения). Тогда ревью в MR сможет опираться не только на diff текущего изменения, но и на накопленный контекст по репозиторию. Может сильно повысить качество cr
Добрый день. Полез по вашей статье клепать "Статистику закрытых задач". Подскажите чем не устроило поле "Статус изменен"? Оно содержит время последнего изменения статуса
Статья на самом деле является пустой и немного вредной.
Использование неявного левого соединения - да, может аффектить, но тут все зависит от наложенных отборов на выборку и возможностей отсекания лишних данных условиями соединений, наличия индексов по соединяемым полям и тд. Само многоточие не является преступлением и аффектит далеко не всегда, выглядит так себе, тут без вопросов, сам нелюблю подобное многоточие.
Ну и циклы в цикле тоже не преступление в ряду случаев, банальный обход результата сгруппированой выборки запроса. Подача в статье такая - что это зло, а оно таковым не является.
Запросы в цикле - тут без разговоров, это плохо, но опять же все индивидуально, да, в 90% случаев такое можно оптимизировать и перестроить без использования запроса в цикле.
Вобщем нужно просто понимать что и когда можно делать, статья целиком применима под один конкретно описанный автором кейс, именно в его случае проблема заключалась в вышеперечисленных моментах.
В статье нет ни слова про способ поиска неоптимального участка кода, да, бывает такое что проблему видно сразу, но если рассматривать статью как нечто образовательное - такое должно быть, хотя бы упомянуть что сделали замер времени конфигуратором\ключевыми операциями\собрав ТЖ в конце концов.
В качестве пожелания - было бы круто предусмотреть возможность подключения дополнительных MCP серверов. Например для периодической векторизации кода и метаданных проекта, для подключения собственных правил стат. анализа, интеграции с внешними источниками знаний (документация, ADR, архитектурные решения).
Тогда ревью в MR сможет опираться не только на diff текущего изменения, но и на накопленный контекст по репозиторию. Может сильно повысить качество cr
Не хватает хотя бы одного скрина, как это выглядит в телеграме
Добрый день. Полез по вашей статье клепать "Статистику закрытых задач".
Подскажите чем не устроило поле "Статус изменен"? Оно содержит время последнего изменения статуса
Статья на самом деле является пустой и немного вредной.
Использование неявного левого соединения - да, может аффектить, но тут все зависит от наложенных отборов на выборку и возможностей отсекания лишних данных условиями соединений, наличия индексов по соединяемым полям и тд. Само многоточие не является преступлением и аффектит далеко не всегда, выглядит так себе, тут без вопросов, сам нелюблю подобное многоточие.
Ну и циклы в цикле тоже не преступление в ряду случаев, банальный обход результата сгруппированой выборки запроса. Подача в статье такая - что это зло, а оно таковым не является.
Запросы в цикле - тут без разговоров, это плохо, но опять же все индивидуально, да, в 90% случаев такое можно оптимизировать и перестроить без использования запроса в цикле.
Вобщем нужно просто понимать что и когда можно делать, статья целиком применима под один конкретно описанный автором кейс, именно в его случае проблема заключалась в вышеперечисленных моментах.
В статье нет ни слова про способ поиска неоптимального участка кода, да, бывает такое что проблему видно сразу, но если рассматривать статью как нечто образовательное - такое должно быть, хотя бы упомянуть что сделали замер времени конфигуратором\ключевыми операциями\собрав ТЖ в конце концов.