Никак не можете найти в себе силы поменять работу? Просто выполните этот sql запрос, и за вами скоро придут

Вчера прилетел код на ревью от фронтенда. А там цепочки вложенных тернарников. Кучи их🫠 И я поймал себя на мысли, что эти цепочки мне капец как тяжело воспринимать. Я прям все мыслетопливо на них сжег и устал.

Вот сравните

это

const buttonText = 
   action === 'manage' && selectedProductId === purchasedPlan?.subscriptionProduct
     ? strings.manage_button
     : action === 'downgrade'
       ? strings.downgrade_button
       : strings.upgrade_button;

или это

let buttonText;  

if (action === 'manage' && selectedProductId === purchasedPlan?.subscriptionProduct) {   
  buttonText = strings.manage_button; 
} else if (action === 'downgrade') {   
  buttonText = strings.downgrade_button; 
} else {
  buttonText = strings.upgrade_button; }

И это относительно легкая цепочка, в которой я намеренно упростил айдишники строк. По факту, там больше буков.

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

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

Кроме того, цепочки тернарников работают по разному в разных ЯП. И если в js цепочки правоассоциативные (если условие false, то весь хвост - это новое выражение), то в той же пыхе до версии 8 они были левоассоциативные. А щас так вообще вложенные тернарники без скобок запрещены. Может быть это меня и травмировало🤔

А в питоне смарите какая красота 😀

score = 85

grade = "A" if score >= 90 else "B" if score >= 80 else "C"
print(grade) # Хуй знает че тут будет

че думаете? лучше старый проверенный if - else или тернарники зато const?

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

(получается, что в итоге лох не я, а фронтендщики)

Внатуре

Херасе! Скорости закрытия тикета на отъебись у jetbrains даже дед из phpunit может позавидовать!⚡

Не вижу ничего смешного. Он предложил создавать PRы с помощью AI. Но он не обещал, что будет их мержить.

И потом сам бы не нашел никогда

А кстати, зачем нам в век ллм вообще изучать 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 выстрелит. Мне это кажется отличным компромиссынм вариантом между полностью агентской разработкой и мануальным кодингом.

Единственный чистый код, который ты можешь позволить себе в 2к26🥲

рандомный коммент на ютубе, и я горю сракой😡️️️️️️даже дизлайк ебанул, вот на столько выбесился