Кароче, в комментах пришли к выводу, что я лох, и надо было добавить switch - case в опросник, ибо это единственный норм варик (с чем не поспорить). Но что ж фронтендщики вообще его не используют?🤔
(получается, что в итоге лох не я, а фронтендщики)
(получается, что в итоге лох не я, а фронтендщики)
🤣10
Я тут путешествую. Вчера заехал в Воронеж, и, кажется, нашел там место, где пыхарей приводят в порядок🤩 ну либо это замаскированный офис @sergei_predvoditelev. Других вариков нет.
😁21❤5🤣4😍2
Please open Telegram to view this post
VIEW IN TELEGRAM
😁14🔥4🤡2❤1🤯1
Херасе! Скорости закрытия тикета на отъебись у jetbrains даже дед из phpunit может позавидовать!⚡
YouTrack
CLion integrated terminal incorrectly renders ncurses output when 7+ identical characters are drawn consecutively on the same row…
Environment: - IDE: CLion 2026.2.1 - OS: macOS - Library: ncurses /opt/homebrew/opt/ncurses/lib/libncursesw.6.dylib (compatibility version 6.0.0, current version 6.0.0) Description: When running an ncurses application inside CLion's integrated terminal, output…
😁8
А кстати, зачем нам в век ллм вообще изучать DDD. Ведь весь код пишет агент. Не пофиг ли, как там оно будет в итоге с DDD или без DDD?
Последние месяца 3-4 из каждого утюга говорят про Spec-Driven-Development (SDD). Появляются тулзы типы OpenSpec, SpecKit и миллионов аналогов. Вариации подхода разные. Но суть идеи в том, чтоб хорошенько пошевелить мозгулькой на этапе планирования, родить тонну md файлов, а затем скормить их агенту, и спокойно идти пить кофеек, пока клод перемалывает ваши спеки в рабочий код.
Также среди преимуществ данного подхода выделяют возможность разделить планирования разного уровня по разным агентами, чтоб бороться с разрастанием контекста. Типа совсем высокоуровневую архитектуру одному агенту, чуть пониже другому (а на вход то, что первый агент родил), и т.д. В конце концов реализацию можно оставить агенту со слабой моделью, но с очень классной спекой.
Зачем же нам тогда DDD?🤔
Во-первых, как я уже отмечал в предыдущем посте, использование "единого языка" в спеке помогает ЛЛМке не запутываться. Доказательство от обратного: если у вас одна и та же вещь называется по-разному, агенту будет тяжело все это собирать. Возможна путанница и в спеках, и в коде.
Во-вторых, стратегическое проектирование будто бы работает вообще на другом уровне. Выделение ключевых поддоменов и ограниченных контекстов должно проводиться до привлечения ЛЛМ. Не, посовещаться то с ней можно. Но вот чтоб просто отдать архитектуру на откуп агентам - тут че-то хз.
И в третьих, если говорить про тактическое проектирование, я не уверен, что вот эти спеки в виде md файлов (и человеческий язык в целом) хорошо подходят для описания сложной бизнес логики. Конечно, требования собираются с использованием человеческого языка. Но мой опыт показывает, что этот процесс итеративный, и итерация как раз возникает, когда на этапе реализации ты утыкаешься в конкретный кейс. Поэтому не особо верится в возможность как подготовить всю спеку сразу (у меня не вышло), так и в саму возможность выразить все в этой спеке, всю цикломатическую сложность бизнес процесса.
Когда я использую тактические приемы из DDD, у меня буквально возникает ощущение, что я говорю о бизнесе, но на языке программирования. И хоть в этом и была вся суть работы разработчиком испокон веков, но это не тоже самое, что взять фреймворк, нахуячить там контроллеров, моделей и вьюх.
И в этом смысле я не понимаю, чем писать спеку на обычном языке лучше, чем, например, нагенерить ValueObject'ов. Разве ValueObject - это не часть спеки? И это при том, что IDE еще и помогают писать их быстро. А в конструкторе можно явно защитить необходимые инварианты. Но нет, давайте писать это словами. Тем более, что уже есть примеры того, когда код является спецификацией (OpenAPI, protobuf).
Или вот, например, события. События могут быть неотъмлемой частью бизнес контракта. Так нафига их тогда описывать человеческим языком, когда ЯП подходит для этого гораздо лучше.
Короче говоря, возникает ощущение, что отдельные тактические приемы DDD могут использоваться в качестве спецификации. Даже с учетом того, что сама спека в SDD генерится агентами с помощью скиллов и тулзов, шоб оператор ллм лишних букав на клавиатуре не дай бох не нажал, мы ведь также можем попросить ллм вместо текста спеки генерить конкретные классы с полями. Зачем нам тогда вообще этот промежуточный этап в виде текста?
Ладно-ладно. Текст все же нужен. Иначе это будет сплошная реализация. Но пусть был бы текст + код. И в тексте уже ссылки на конкретные объекты из кода.
Однако в тулинге я не вижу движения в этом направлении🤷так шо может все это херня и мои влажные фантазии. А может сама по себе сложность DDD мешает такому случиться. Или может md файлы все же гораздо удобнее, как артефакт.
Также хочется отметить, что раньше, когда код генерировали руками, аргументом против DDD часто была бойлерплейтная стоимость. Но сейчас то агенты как раз и могут с этим помочь.
Короче, я все же надеюсь, что SDD + DDD выстрелит. Мне это кажется отличным компромиссынм вариантом между полностью агентской разработкой и мануальным кодингом.
Последние месяца 3-4 из каждого утюга говорят про Spec-Driven-Development (SDD). Появляются тулзы типы OpenSpec, SpecKit и миллионов аналогов. Вариации подхода разные. Но суть идеи в том, чтоб хорошенько пошевелить мозгулькой на этапе планирования, родить тонну md файлов, а затем скормить их агенту, и спокойно идти пить кофеек, пока клод перемалывает ваши спеки в рабочий код.
Также среди преимуществ данного подхода выделяют возможность разделить планирования разного уровня по разным агентами, чтоб бороться с разрастанием контекста. Типа совсем высокоуровневую архитектуру одному агенту, чуть пониже другому (а на вход то, что первый агент родил), и т.д. В конце концов реализацию можно оставить агенту со слабой моделью, но с очень классной спекой.
Зачем же нам тогда DDD?🤔
Во-первых, как я уже отмечал в предыдущем посте, использование "единого языка" в спеке помогает ЛЛМке не запутываться. Доказательство от обратного: если у вас одна и та же вещь называется по-разному, агенту будет тяжело все это собирать. Возможна путанница и в спеках, и в коде.
Во-вторых, стратегическое проектирование будто бы работает вообще на другом уровне. Выделение ключевых поддоменов и ограниченных контекстов должно проводиться до привлечения ЛЛМ. Не, посовещаться то с ней можно. Но вот чтоб просто отдать архитектуру на откуп агентам - тут че-то хз.
И в третьих, если говорить про тактическое проектирование, я не уверен, что вот эти спеки в виде md файлов (и человеческий язык в целом) хорошо подходят для описания сложной бизнес логики. Конечно, требования собираются с использованием человеческого языка. Но мой опыт показывает, что этот процесс итеративный, и итерация как раз возникает, когда на этапе реализации ты утыкаешься в конкретный кейс. Поэтому не особо верится в возможность как подготовить всю спеку сразу (у меня не вышло), так и в саму возможность выразить все в этой спеке, всю цикломатическую сложность бизнес процесса.
Когда я использую тактические приемы из DDD, у меня буквально возникает ощущение, что я говорю о бизнесе, но на языке программирования. И хоть в этом и была вся суть работы разработчиком испокон веков, но это не тоже самое, что взять фреймворк, нахуячить там контроллеров, моделей и вьюх.
И в этом смысле я не понимаю, чем писать спеку на обычном языке лучше, чем, например, нагенерить ValueObject'ов. Разве ValueObject - это не часть спеки? И это при том, что IDE еще и помогают писать их быстро. А в конструкторе можно явно защитить необходимые инварианты. Но нет, давайте писать это словами. Тем более, что уже есть примеры того, когда код является спецификацией (OpenAPI, protobuf).
Или вот, например, события. События могут быть неотъмлемой частью бизнес контракта. Так нафига их тогда описывать человеческим языком, когда ЯП подходит для этого гораздо лучше.
Короче говоря, возникает ощущение, что отдельные тактические приемы DDD могут использоваться в качестве спецификации. Даже с учетом того, что сама спека в SDD генерится агентами с помощью скиллов и тулзов, шоб оператор ллм лишних букав на клавиатуре не дай бох не нажал, мы ведь также можем попросить ллм вместо текста спеки генерить конкретные классы с полями. Зачем нам тогда вообще этот промежуточный этап в виде текста?
Ладно-ладно. Текст все же нужен. Иначе это будет сплошная реализация. Но пусть был бы текст + код. И в тексте уже ссылки на конкретные объекты из кода.
Однако в тулинге я не вижу движения в этом направлении🤷так шо может все это херня и мои влажные фантазии. А может сама по себе сложность DDD мешает такому случиться. Или может md файлы все же гораздо удобнее, как артефакт.
Также хочется отметить, что раньше, когда код генерировали руками, аргументом против DDD часто была бойлерплейтная стоимость. Но сейчас то агенты как раз и могут с этим помочь.
Короче, я все же надеюсь, что SDD + DDD выстрелит. Мне это кажется отличным компромиссынм вариантом между полностью агентской разработкой и мануальным кодингом.
martinfowler.com
Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl
Notes from my colleagues on AI-assisted software delivery
👍6