Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 32
Не кажется, вместо того, чтоб выучить новый ЯП, вы учите как писать промты?
Плюс это надо ревьювить?
Во времена до ИИ, когда еще учился. Постоянно ловил ступоры, когда вылазит некая ошибка, которую вот прям непонятно как исправить. Быстрый гуглеж не помогает. решение - в недрах документаций. 2 часа потраченных впустую на исправление плевой ошибки. ИИ - исправит, объяснит, разжует, ответит на любой тупой вопрос. И мне например интереснее разобрать решение ИИшки, чем писать свой скушный код. Так что тут сильно зависит от характера использования ИИ
Помнится, вчера gpt 5.2 не смог найти причину простой ошибки в коде. Я пол часа его мучил ради интереса. Там просто у разных отношений свойство называлось одинаково и , когда второе отношение было null то соответственно была ошибка. Чего он только не галлюционировал - и ошибка сети, и "иногда не передается", предлагал мне наплодить абсолютно одинаковых дебагов для первого отношения, замаскировать все фоллбэками.. Проверить второе отношение он так и не догадался. Простое одинаковое свойство его сбило с толку. Интересно, что будут делать вайбкодеры в такой ситуации? Не бежать ли на фриланс, где им предложат переписать весь зафолбэченный нагенеренный говнокод с нуля?
Вместо "почини ошибку" сменить запрос на "помоги выяснить, почему может возникать эта ошибка, чтобы я ее исправил". Ну а чистый вайбкодер не программист вовсе, и готовое приложение не сделает никогда, даже если нейросети станут умнее.
У меня и был запрос "найди причину". В режиме агента я уже точно знаю,что он бы просто заблюрил проблему фоллбэками - ИИ всегда так делает. Более того я просил его отбросить все "иногда не передается" и искать проблему в коде и все равно он галлюционировал. В итоге найти не смог. Но он и никогда не находит в нестандартных ситуациях. Начинает писать ересь и тупость
Я лично ожидаю в ближайшее время взрыв мини-продуктов от одиночек и микро-коллективов — приложений, которые раньше никто не делал, потому что выигрыш не стоил затрат.
Я уже год+ это жду. Но пока не видно. Как только такие приложения начнут массово появляться, то можно начинать опасаться ИИ.
Причем, опасаться как программистам, так и (внезапно) вайбкодерам. Это будет означать, что теперь "программирование" доступно на естественном языке обычным людям (без "тайных знаний" как правильно писать промпты).
Во всей моей работе, меня больше всего раздражает ревью и ресерч чужого кода. Если делать честное ревью, то это надо погружаться в контекст. Никто этим не будет заниматься постоянно, так как требуется много сил. На свои задачи не останется. Поэтому многие ставят апрув на доверии - нет критичных мест, норм.
С нейросетями же нельзя так.
В итоге эта технология требует от людей больше ресурсов, чем она может освободить.
Для себя нашел стабильный способ использования, это рутина. Для однообразных задач, где надо что-то сделать взяв за основу уже написанный код - пойдет. В т.ч. написание unit тестов. К сожалению они и тут умудряются все делать по своему. Часто они не в курсе каких-то новых функций во фреймворке тестирования, даже если это уже было использовано. Суют наиболее тупое решение.
Короче просто расширенный автокомплит кода с какой-то вероятностью что придется переделывать половину кода. Такое...
Короче просто расширенный автокомплит кода с какой-то вероятностью что придется переделывать половину кода. Такое...
Ага у меня вот какое-то такое же отношение ко всем этим AI решениям. В целом штука удобная для рутины, но доверять что-то большее я бы не стал, ведь даже на простых вещах они порой косячат. Ревью (честное) тоже утомляет больше написания кода. 🤝
У TDD 3 недостатка как по мне
Тесты очень слабо покрывают реальное поведение. Контрактное программирование с проверкой утверждений в типах надёжнее. Типы > тесты для инвариантов. Тест проверяет точки, тип покрывает пространство.
Если надо надёжно, то тестов надо больше чем кода, причём много golden sample - "не знаю почему так, но чтобы как было раньше". То есть трудоемко.
Архитектура удобная для тестирования имеет недостатки. Overengineering. Куча абстракций и интерфейсов, которые существуют только чтобы подсунуть мок. В реальности за интерфейсом одна реализация навсегда. В C# это особенно видно — IRepository, IUnitOfWork, IMapper на каждый чих. Граф зависимостей раздувается, читаемость падает, а навигация по коду превращается в квест
А как гарантировать что поведение типа не поменялось? :)
"как гарантировать что поведение типа не поменялось".
property-based testing, golden tests для сериализации, но главное - если тип выражает инвариант, то компилятор не даст его нарушить. Поведение меняется сознательно, а не случайно.
не все инварианты/правила можно выразить в типах, но если удается то типы > тесты
Архитектура удобная для тестирования имеет недостатки. Overengineering
архитектура неудобная для тестирования это недоинжиниринг. брак/дефект/проынепригодность, а не вопрос эффективности.
в php например люди до сих пор не осознали что у них ООП инструмент, и пишут старый добрый процедурный код, завернутый в классы, и оч пугаются абстракций, любых.
концепт того, что эти абстракции = ментальная модель = способ осмыслять происходящее, и не охренеть от развилок логики "а если то", категорически непонятен в большинстве мест где я работал.
недавно дали на вход 5 бизнесовых правил, и ругали за введение одного интерфейса для них и _instanceof в symfony DI. "че не мог просто внутри одного метода 5 проверок сделать, зачем усложнять, зачем лишний интерфейс, ааа, паника", лол.
абстракции дают огромный профит на дистанции, но для этого нужно уметь рефлексировать и делать правильные выводы из опыта.
Граф зависимостей раздувается, читаемость падает, а навигация по коду превращается в квест
без абстракций будет такая портянка, что завоешь
архитектура неудобная для тестирования это недоинжиниринг. брак/дефект/проынепригодность, а не вопрос эффективности.
нет, конечно
Еще раз обращаю ваше внимание, что тесты не ловят ВСЕ что надо, их создание трудоемко само по себе и они ещё портят читаемость (в mainstream подходе: упомянутые DI и моки), т.е. калечим проверки человеком на ревью
Еще раз, проблема в том что тесты как инструмент верификации слабые при высокой трудоёмкости. Контракты в типах дешевле и надёжнее.
И по проектированию тоже недостатки
test-first как инструмент проектирования тянет дизайн снизу вверх от частных случаев. Вместо того чтобы сначала продумать модель предметной области, ты начинаешь с "а вот если на вход придёт 5 что вернётся" - и архитектура вырастает из этих ЧАСТНЫХ примеров. Получается локально разумный, но глобально бессвязный дизайн.
По сути противоположность domain-driven подходу, где сначала модель, потом код, потом тесты если нужны.
еще раз обращаю ваше внимание, что тесты не ловят ВСЕ что надо
какие требования ваши тесты проверяют, если то что у вас покрыто - не то что надо? почему они это делают?
если то что надо не покрыто, то почему? а точно это надо, или проблема выше/в другом слое/не в коде а в организационныш штуках вообще?
почти любая проблема с тестами подсвечивает какую то другую (противоречащие требования, неправильная модель, неудобные абстракции, качество кода), и это прекрасно
я говорю про неустранимые недостатки, но не всегда важные
а вы мне говорите что я не умею готовить TDD, переводите в плоскость компетенций, по существу это переход на личности
дискуссия зашла в тупик, вы меня не слышите
Дейкстра «Notes On Structured Programming» (1970): "Program testing can be used to show the presence of bugs, but never to show their absence." Это не мнение, это следствие из того что пространство входов/случаев бесконечно, а тесты проверяют конечное подмножество.
Гленфорд Майерс, "The Art of Software Testing" - исчерпывающее тестирование невозможно даже для тривиальных программ.
Безье, "Software Testing Techniques" - формализует это через понятие path coverage. Количество путей исполнения растёт экспоненциально с количеством ветвлений, полное покрытие путей нереалистично.
эти недостатки для вас неустранимы только потому что вы их не устраняете.
в чем дискуссия-то? в том что невозможно с помощью TDD надежно покрывать важные бизнес требования?
ну, это возможно, точка, о чем дискутировать?
исчерпывающее тестирование невозможно даже для тривиальных программ.
возможно, но цена неадекватна профиту.
поэтому разработчик делает проыессиональный выбор что покрывать а что не покрывать.
когда "что надо" оказывается не покрыто - надо покрыть, чтобы испытывать уверенность когда сдаешь таску.
эти недостатки для вас неустранимы только потому что вы их не устраняете.
переход на личности
цена неадекватна профиту
я и говорю - нужен баланс,
я сказал про недостатки TDD но не призываю от них отказаться во всех случаях
эти недостатки для вас неустранимы только потому что вы их не устраняете.
нет, недостатки часто можно снизить до приемлемых, но устранить полностью принципиально невозможно - ссылки на книги дал выше
я на вашу личность не переходил
вы заявили что ваши тесты не покрывают что вам надо, и это фундаментальная проблема TDD
я ответил что если ваши тесты не покрывают что вам надо - то это не проблема подхода, так как вы выбираете что покрывать
вы можете обижаться на меня сколько угодно, считать это глубочайшим оскорблением, или чем угодно, но я-то тут причем.
камни твердые, кипяток горячий, если ваши(или мои, чьи угодно) тесты не покрывают то что надо - вы (я, кто угодно) не покрыли тестами то что вам надо, и это не фундаментальная проблема TDD или тестирования как такового.
абсолютно безличное утверждение
Вы говорите: делайте хорошо, не делайте плохо.
Уровень дискуссии ясен. Достаточно
ну вот не надо, я очень четко выразил то что хотел сказать.
- у меня проблема, и мне кажется это проблема подхода, давайте дискутировать?
- давайте. нет, это не проблема подхода, ошибка вот здесь
- ОЙ НУ ЯСНО, ПРОСТО ДЕЛАЙ ХОРОШО НЕ ДЕЛАЙ ПЛОХО, УРОВЕНЬ ДИСКУССИИ ПОНЯТЕН, ХВАТИТ
это не взрослое поведение
А кто мешает писать тесты которые покрывают реальное поведение
Сейчас делаю сложную, сетевую, с математикой штуку. Пока codex проектирует. И все ооочень по умному, но куууча ошибок, несостыковок. Хотя он вроде бы находит их, но я не знаю где ещё остаются ошибки...
Короче опасная штука. Это как сделать ядерный реактор, потом ии находит критические уязвимости, исправляет их но ты все равно не знаешь остаются ли ещё уязвимости и что будет, если запустить в прод. Да он уже умеет в сложное, но делает ошибки и ты не владеешь в уме этой кодовой базой - то есть это чужой код, написан непредсказуемым, эгоцентричным мидлом, с хорошей фундаментальное базой. И у тебя нет времени изучать и вникать в этот код, так как надо выводить в прод, а сэкономил ты всего ну 20%, ну 30% времени. И у тебя просто не остаётся ресурса проверить этот собранный рЕАктор и ты запускаешь на авось:ну а чо, я всего инженер - отвечать будет начальник.
Но ещё раз повторюсь - да, штука крутая и делает сложное и да соглашусь с автором это 100% будущее и настоящее для кого-то.
На иллюстрации, кстати, правый человек находится ближе к пропасти.
Поделитесь ссылкой на TDD скиллы?
Из моего опыта, это быстрее, чем гуглить решение на Stack Overflow
Вот эту фразу постоянно вижу в разных статьях. Но ведь реально сложные задачи часто не найти ни на стеке, ни вообще в интернете (причём иногда задача как будто бы и ничего особенного, но готового решения нигде нет). И приходится самому сидеть придумывать, дебажить код сторонних библиотек, чтобы понять что к чему. Понятно, что такие задачи появляются нечасто, но раз в неделю или две они мне попадаются, и приходится все ИИ-инструменты откладывать в сторону и делать самому. У меня уже даже есть в голове список типов задач, с которыми многократно не справилось несколько разных моделей, поэтому я сразу делаю их сам.
Если агент наткнётся на такую задачу, он либо зациклится, либо воспримет результат ложноположительно. И потом придётся всё разгребать самому.
Собственно, мой вопрос в том, почему в статьях об агентской разработке не пишут про такие кейсы? У всех всегда либо 100% всё делает ИИ, либо человек архитектуру, а ИИ рутину, но ни у кого нет кейсов, где нужно ломать голову самому.
Я лично ожидаю в ближайшее время взрыв мини-продуктов от одиночек
И вот тут я вижу ответ на свой вопрос. Микропродукты от одиночек — это уровень фрилансеров (хотя бывают и исключения). То есть небольшой, малобюджетный и короткоживущий софт (те самые парсеры и телеграм-боты, которые почему-то делают все вайбкодеры).
В общем, я вижу, что серьёзные проекты будут делаться через AI-assisted разработку, а не полностью автономными роботизированными "заводиками".
Я лично ожидаю в ближайшее время взрыв мини-продуктов от одиночек и микро-коллективов — приложений, которые раньше никто не делал, потому что выигрыш не стоил затрат. А теперь такого будет полно
А для кого эти приложения? кажется уже сейчас быстрее попросить ии агента написать прогу, которая будет делать то что тебе нужно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
724 коммита, тесты, рефакторинг, бессонница. Моя история знакомства с вайб-кодом