наверно зависит от инструмента, который используешь. В курсоре такой не наблюдал.
Ну и про МСP не хватает.
да, MCP категорически важная штука, тут как-то не акцентировал на этом акцент. А еще более важная она в том плане, что она жрет контекст и нужно очень аккуратно с ними быть
Не совсем согласен что задачу лучше делить на части. Агент может плохо делать куски задачи. Проще сформулировать всю задачу а потом посмотреть что он проигнорил и повторить.
ну просто зачастую не уследишь, где он что упустил. и в этом проблема. и не очень понятно , почему куски задачи делает плохо, но есть ожидание, что при этом как-то справится с большой задачей? Как раз кажется об этом пишите далее, что согласны с необходимостью экономии контекста. И если сразу отдать целую задачу под ключ (достаточно большую), то он сожрет его быстро. Но в любом случае нужно знать меру и понимать, когда стоит декомпозировать, а когда можно отдать целиком.
Переключение моделей тоже спорно.
Я и рассматриваю это, как один из вариантов, когда условно зашел в тупик.
Проблема любых договорённостей о коде в том, что их можно нарушать. Куда проще, когда есть инструмент, который заставляет правилам следовать. Мне понравилась концепция gofmt в golang, хоть я никак за этот язык не возьмусь и только мельком знаю отдельные факты. Тулза языка, которая за тебя форматирует код - это же гениально. Это не опциональный pylint. Круто же
Здорово, что лично вы хорошо пишите код. Я, надеюсь, тоже неплохо. Но как только речь начинает идти про большой и разнообразный коллектив, в котором в том числе джуны, то закон Мерфи начинает работать на полную катушку)
Приглашаю вас почитать и обсудить разное в моём ТГ-канале — Markwhen — инструмент для построения роадмапов — Подкаст про Роли в ИТ-проекте — Подборка материалов про архитектуру (зачем нужны архитектурные схемы, как их документировать, какие инструменты использовать)
Конкретно данный подход никак. Этот подход покрывает планомерное взаимодействие.
Если мы говорим о чем-то критическом, то в зависимости от ситуации встреча может быть устроена здесь и сейчас или в течение дня поставлена в календарь.
Но практика показывает, что такие вопросы с очень большой срочностью – редки. Люди зачастую сами эту срочность создают. Но если задаться вопросом, а так ли это срочно? Скорее всего окажется, что вопрос не такой срочный. Особенно, если этот вопрос задать на спокойную голову.
Предлагаю смотреть на эту метрику шире. Интерес может представлять вклад по языкам - в сабже вон смесь си, двух версих шелла, вкрапления perl-а. На мой взгляд, это хорошие звоночки будущих проблем в проекте. Как считаете?
Ещё можно смотреть на среднее отношение комментариев к коду - как детектор проектов вообще без комментариев, например
Представь: ты работаешь в команде, где каждый пишет коммиты как бог на душу положит. Один пишет "пофиксил баг", другой — "ну тут всё сломалось, я подправил", третий вообще оставляет "123". Потом через месяц ты пытаешься понять, что за изменения привели к новому багу. Идешь в историю коммитов, а там — ад. Ты тратишь кучу времени, чтобы просто понять, что вообще происходило.
Gitlint тут как строгий, но справедливый учитель. Он не даст закоммитить "123" или "чё-то сделал". Придётся писать нормально: "fix: исправлено падение при загрузке данных" или "feat: добавлена поддержка тёмной темы". В итоге история коммитов становится не свалкой, а читаемой историей изменений.
Но самое интересное — это когда ты начинаешь искать баг. Вместо того чтобы рыться в куче мусора, ты видишь сразу: "ага, вот тут был фикс бага с загрузкой данных, а вот тут добавили новую фичу". Это экономит время, нервы и делает жизнь чуть проще. Да, сначала все ворчат, что "ну зачем эти правила", но потом, когда история коммитов становится понятной даже через полгода, все начинают ценить этот порядок.
Так что gitlint — это не про "сделать из буханки что-то красивое", а про то, чтобы потом не пришлось разгребать бардак.
Насколько я знаю, и юнит тесты, и интеграционные тесты относят к функциональным. Или как вы определяете функциональные тесты?
В юнит тестах не обязательно всё мокать, на мой взгляд. Не вижу проблемы писать тесты, покрывающие вызов ряда функций. При этом, с моей точки зрения, это ещё не интеграционные тесты, которые должны покрывать более широкий тракт от входа до выхода.
Вообще говоря, увлечение моками мне кажется не лучшей практикой. Понятно, что внешние зависимости (сеть, бд, АПИ) стоит мокать. Но много чего лучше не мокать, а действительно вызывать. Не вижу противоречий с определением, модуль не обязан быть мельчайшим фрагментом кода.
100% покрытие тяжело достигается. А вот 80% покрытия совершенно несложно обеспечить.
Уточню – речь про длительную отладку. Когда в проекте 10к+ строк кода, то без юнит тестов иногда довольно болезненно локализовать проблему. Что именно сломалось? В этот момент отладка становится таким расследованием, занимающим время. А с тестами падает что-то конкретное. Мне это экономит время
В почти любом активно развивающемся инструменте в той или иной мере есть проблема фрагментации. Удивительно, как сложно было условному андроиду, какая боль была от питона 2->3, и прочее, и прочее. Вон выше график проблем для С++, хотя казалось бы. Вроде обратная совместимость есть, то есть можно просто со свежей версией стандарта собираться. Но, как всегда, возникают нюансы, и чем больше кодовая база, тем больше этих нюансов
наверно зависит от инструмента, который используешь. В курсоре такой не наблюдал.
да, MCP категорически важная штука, тут как-то не акцентировал на этом акцент. А еще более важная она в том плане, что она жрет контекст и нужно очень аккуратно с ними быть
ну просто зачастую не уследишь, где он что упустил. и в этом проблема. и не очень понятно , почему куски задачи делает плохо, но есть ожидание, что при этом как-то справится с большой задачей? Как раз кажется об этом пишите далее, что согласны с необходимостью экономии контекста. И если сразу отдать целую задачу под ключ (достаточно большую), то он сожрет его быстро. Но в любом случае нужно знать меру и понимать, когда стоит декомпозировать, а когда можно отдать целиком.
Я и рассматриваю это, как один из вариантов, когда условно зашел в тупик.
Максимально конкретный и конструктивный комментарий, спасибо, учту
Проблема любых договорённостей о коде в том, что их можно нарушать. Куда проще, когда есть инструмент, который заставляет правилам следовать. Мне понравилась концепция gofmt в golang, хоть я никак за этот язык не возьмусь и только мельком знаю отдельные факты. Тулза языка, которая за тебя форматирует код - это же гениально. Это не опциональный pylint. Круто же
Здорово, что лично вы хорошо пишите код. Я, надеюсь, тоже неплохо. Но как только речь начинает идти про большой и разнообразный коллектив, в котором в том числе джуны, то закон Мерфи начинает работать на полную катушку)
Проблема не в goto, а в неаккуратном его применении. Куда проще начинающему сказать "goto плох" и всё. Так меня больше 10 лет назад на Си учили
Сильно потом я понял причины. И вот излил их вам в виде небольшой заметки
Приглашаю вас почитать и обсудить разное в моём ТГ-канале
— Markwhen — инструмент для построения роадмапов
— Подкаст про Роли в ИТ-проекте
— Подборка материалов про архитектуру (зачем нужны архитектурные схемы, как их документировать, какие инструменты использовать)
Конкретно данный подход никак. Этот подход покрывает планомерное взаимодействие.
Если мы говорим о чем-то критическом, то в зависимости от ситуации встреча может быть устроена здесь и сейчас или в течение дня поставлена в календарь.
Но практика показывает, что такие вопросы с очень большой срочностью – редки. Люди зачастую сами эту срочность создают. Но если задаться вопросом, а так ли это срочно? Скорее всего окажется, что вопрос не такой срочный. Особенно, если этот вопрос задать на спокойную голову.
Чтобы "сверить часы" - поставить новые задачи, пересмотреть приоритеты текущих задач, подсветить текущие проблемы
Приятно выглядит. Плюс моего cloc - можно в CI/CD запихать при надобности
А зачем вы смотрите на строки кода? Потому что красиво или есть причины смотреть на эти метрики?
Предлагаю смотреть на эту метрику шире. Интерес может представлять вклад по языкам - в сабже вон смесь си, двух версих шелла, вкрапления perl-а. На мой взгляд, это хорошие звоночки будущих проблем в проекте. Как считаете?
Ещё можно смотреть на среднее отношение комментариев к коду - как детектор проектов вообще без комментариев, например
Это позволит оценить только число строк, без учёта комментариев. Можно грепнуть однострочные комментарии, конечно, а вот с многострочными уже никак
Не получится раскладку по языкам получить. Для проекта на одном языке, конечно, не актуально
Для проекта со вложенностью такой способ напрямую не работает, надо докручивать
Собственно, зачем докручивать, если есть рабочее решение?) Правда, зачем нужно знать число строк в проекте особого ответа у меня нет. Просто красивое
Представь: ты работаешь в команде, где каждый пишет коммиты как бог на душу положит. Один пишет "пофиксил баг", другой — "ну тут всё сломалось, я подправил", третий вообще оставляет "123". Потом через месяц ты пытаешься понять, что за изменения привели к новому багу. Идешь в историю коммитов, а там — ад. Ты тратишь кучу времени, чтобы просто понять, что вообще происходило.
Gitlint тут как строгий, но справедливый учитель. Он не даст закоммитить "123" или "чё-то сделал". Придётся писать нормально: "fix: исправлено падение при загрузке данных" или "feat: добавлена поддержка тёмной темы". В итоге история коммитов становится не свалкой, а читаемой историей изменений.
Но самое интересное — это когда ты начинаешь искать баг. Вместо того чтобы рыться в куче мусора, ты видишь сразу: "ага, вот тут был фикс бага с загрузкой данных, а вот тут добавили новую фичу". Это экономит время, нервы и делает жизнь чуть проще. Да, сначала все ворчат, что "ну зачем эти правила", но потом, когда история коммитов становится понятной даже через полгода, все начинают ценить этот порядок.
Так что gitlint — это не про "сделать из буханки что-то красивое", а про то, чтобы потом не пришлось разгребать бардак.
Спасибо, потыкаю, если время будет. Вот для linux я пока не нашёл решения удобного
Прикольное. Кому интересно, вот ссылки
https://github.com/koekeishiya/yabai
https://github.com/koekeishiya/skhd
Полностью согласен. В области тг-ботов, кажется, питон вообще доминирует
Прямо в точку
Ещё проекты без докера, что нередко встречается в data science, хрен запустишь
Насколько я знаю, и юнит тесты, и интеграционные тесты относят к функциональным. Или как вы определяете функциональные тесты?
В юнит тестах не обязательно всё мокать, на мой взгляд. Не вижу проблемы писать тесты, покрывающие вызов ряда функций. При этом, с моей точки зрения, это ещё не интеграционные тесты, которые должны покрывать более широкий тракт от входа до выхода.
Вообще говоря, увлечение моками мне кажется не лучшей практикой. Понятно, что внешние зависимости (сеть, бд, АПИ) стоит мокать. Но много чего лучше не мокать, а действительно вызывать. Не вижу противоречий с определением, модуль не обязан быть мельчайшим фрагментом кода.
100% покрытие тяжело достигается. А вот 80% покрытия совершенно несложно обеспечить.
Спасибо за ссылку, почитаю на досуге
Уточню – речь про длительную отладку. Когда в проекте 10к+ строк кода, то без юнит тестов иногда довольно болезненно локализовать проблему. Что именно сломалось? В этот момент отладка становится таким расследованием, занимающим время. А с тестами падает что-то конкретное. Мне это экономит время
А вы пишите тесты?
"Только ситхи всё возводят в абсолют"
В почти любом активно развивающемся инструменте в той или иной мере есть проблема фрагментации. Удивительно, как сложно было условному андроиду, какая боль была от питона 2->3, и прочее, и прочее. Вон выше график проблем для С++, хотя казалось бы. Вроде обратная совместимость есть, то есть можно просто со свежей версией стандарта собираться. Но, как всегда, возникают нюансы, и чем больше кодовая база, тем больше этих нюансов
Люблю теории заговора. Какой именно из аспектов отчёта имеет смысл для коммерческой манипуляции?