Нервный программист

Сегодня немного пололировал с поста на реддите, где до чувака на собесе по golang докопались с вопросом о том, как реализовать перегрузку методов. Вот уж реально, когда на собесах не знают, как бы изъебнуться, чтоб... а я даже не знаю, чтобы что 🤷хуже только вопрос, почему канализационные люки круглые. Но меня это навело на определенные мысли. Когда-то давно я начинал свой путь в айти с книги Брюса Эккеля про java. И я прям помню, как там много говорили про перегрузку методов, и как это круто. Ну я тогда ваще ничо не понимал в погромировании. Даже меньше, чем щас 😱 раз сказали, что это круто, значит круто. а. ну мы еще лабы на плюсах писали в универе с перегрузкой операторов. С джавой у меня так и не задалось. Но код писать продолжил. И все это время писал на ЯП, которые не поддерживают перегрузку. А это кстати все популярные скриптовые языки. И даже не скриптовые (типа go, rust). И вот щас будет наброс. Че то я не особо ощущаю какой-то дискомфорт от отсутствия перегрузки в бизнес коде. Мне кажется, это вообще самая переоцененная фича в ЯП. Один пример, который можно набросить в качестве удобства перегрузки - это перегрузка конструктора. Ну типа, было бы удобно иметь у агрегата разные конструкторы - как разные источники происхождения агрегата. Но в целом, эта проблема решается через наследование. С точки зрения типов, перегрузка это так называемы ad-hoc полиморфизм: конкретная реализация выбирается в зависимости от типов. И кажется, что это збс. Но по факту, хуйня. Ну используем мы одно и тоже слово в названии метода, и чо. Сэкономили на записи. Как это читать потом? Поди потом разберись, какая реализация тут отработала. В языках без перегрузки у нас параметрический полимфорфизм, т.е. мы принимаем пачку типов на вход, на выходе также пачка типов, а реализация уже там разбирается, чо к чему. На первый взгляд кажется, что такой подход это больший пиздейшн. Но у нас же есть тулинг. Например, typescript поддерживает перегрузку функций. В phpstan есть conditional

Приношу заранее извинения за пост о ллм. Сам от этого устал🫠но разок-то можно🙏 По моим ощущениям, большиство разработчиков используют агентов в TUI. Потому что почти каждый из них предоставляет TUI версию. И это типа универсально. Я же продал очко душу ide от jetbrains, поэтому сразу искал решение - плагин. Поэтому когда-то давно я выбрал cline, ибо у них был адекватный плагин. И таким образом, я выбрал DX, который трудно найти, легко потерять и довольно тяжело повторить. 3го дня все ide от jetbrains обновились на мажорную версию. Из-за этого cline плагин перестал работать. И тут я понял, что время TUI версии пришло. И охерел от того, что там все не то и не так. Прежде всего стоит отметить, что я использую ллм в режиме "ты конечно генерируй, но я блэт все чекаю". Потому что я тот еще контрол фрик. В ide это видно как diff после каждого изменения. Пока я не заапрувлю diff, дальше ничо не двигается. Обычно изменения ллм делает разумными чанками, и это все реально просмотреть (ну кроме тестов, там пиздейшн портянка обычно). Есть ли что-то похожее в Cline TUI? вообще нет! все, что там можно сделать - это поставить аппрув на каждый tool call. но это просто ужас как заебывает. Потому что, сюрприз-сюрприз, под капотом агент делает десятки таких вызовов даже для простых задач. И, главное, он не показывает дифф🤷короче это вообще не то. в TUI ты должен просто проверять в конце все. Кроме того, когда я смотрю диффы, я ж могу еще и сам код менять. Потому что это все-таки редактор! и если я че то поменяю, то ллм чекнет мои изменения, и дальше уже с учетом их будет действовать. В TUI это просто невозможно. Другой момент, заключается в том, что плагин "видит" все ошибки ide. То есть фактически он использует стат анализатор, который уже есть в ide (а он то крутой). TUI агенты обычно предлагают еще lsp прикрутить рядом. В целом можно, но зачем? В ide у меня не только стат анализ для основного языка, но и для всего сопутствующего. Например, если ide показывает ошибку в sql, аг

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

А кстати, зачем нам в век ллм вообще изучать DDD. Ведь весь код пишет агент. Не пофиг ли, как там оно будет в итоге с DDD или без DDD? Последние месяца 3-4 из каждого утюга говорят про Spec-Driven-Development (SDD). Появляются тулзы типы OpenSpec, SpecKit и миллионов аналогов. Вариации подхода разные. Но суть идеи в том, чтоб хорошенько пошевелить мозгулькой на этапе планирования, родить тонну md файлов, а затем скормить их агенту, и спокойно идти пить кофеек, пока клод перемалывает ваши спеки в рабочий код. Также среди преимуществ данного подхода выделяют возможность разделить планирования разного уровня по разным агентами, чтоб бороться с разрастанием контекста. Типа совсем высокоуровневую архитектуру одному агенту, чуть пониже другому (а на вход то, что первый агент родил), и т.д. В конце концов реализацию можно оставить агенту со слабой моделью, но с очень классной спекой. Зачем же нам тогда DDD?🤔 Во-первых, как я уже отмечал в предыдущем посте, использование "единого языка" в спеке помогает ЛЛМке не запутываться. Доказательство от обратного: если у вас одна и та же вещь называется по-разному, агенту будет тяжело все это собирать. Возможна путанница и в спеках, и в коде. Во-вторых, стратегическое проектирование будто бы работает вообще на другом уровне. Выделение ключевых поддоменов и ограниченных контекстов должно проводиться до привлечения ЛЛМ. Не, посовещаться то с ней можно. Но вот чтоб просто отдать архитектуру на откуп агентам - тут че-то хз. И в третьих, если говорить про тактическое проектирование, я не уверен, что вот эти спеки в виде md файлов (и человеческий язык в целом) хорошо подходят для описания сложной бизнес логики. Конечно, требования собираются с использованием человеческого языка. Но мой опыт показывает, что этот процесс итеративный, и итерация как раз возникает, когда на этапе реализации ты утыкаешься в конкретный кейс. Поэтому не особо верится в возможность как подготовить всю спеку сразу (у меня не вышло), так и в саму возможность