Comments 144
Влажные мечты вайбкодера о том, что когда-нибудь (желательно поскорее) с него перестанут требовать какие-то непонятные фундаментальные знания по языку и будут брать на работу за одно только упоминание ллм.
Ну может когда-нибудь так и будет, но и зарплатой у таких «работничков» будет ветка.
Почему вы так беспокоитесь про доходы программистов? Понятно что всю маржу с LLM заберет бизнес
Может быть потому, что я программист и это отразится на мне?
Как на вас отразяться чьи-то "влажные мечты"?
Пытаешься так незаметно стрелку перевести? Твой вопрос был не про влажные мечты.
P.S.: Я забыл сразу тебя поправить, что вайбкодер и программист - это 2 абсолютно разные сущности.
Жалко бизнес с тобой не согласен - сейчас все больше компаний требуют вайбкодинг в резюме
Ну в моем стеке (.NET) я такого не наблюдаю.
А судьба вайбкодера - работать за миску похлебки. Ибо вас, вайбкодеров, будут орды, и за каждую вакансию будете устраивать мортал комбат.
А покажите конкретные примеры трудоустройства вайбкодеров на реальную работу, пожалуйста. А то у меня ни одного коллеги-вайбкодера почему-то нет и даже сама мысль кажется смешной.
Индустрия просто повышает норму выработки в 1.5-2 раза, а там пользуетесь ЛЛМ или нет это уже ваша проблема. При одновременном срезании зарпла. Теперь смейтесь от души.
Вот смотрите, я вас попросил показать факты. Вы в ответ выдаёте фантазию, причём ещё и тему пытаетесь в сторону увести. Очевидная логическая ошибка, но похоже, что очевидная не для всех.
Давайте я вам контекст разговора напомню. Хотя он состоит всего из пары сообщений, но вы уже успели его потерять. Я попросил показать конкретные кейсы трудоустройства вайбкодеров на реальную работу за деньги. Потому что среди моих коллег нет ни одного вайбкодера, и мне искренне интересно, неужели хоть какие-то работодатели на полном серьёзе доверяют IT-инфраструктуру бизнеса ллм-обезьянкам, которые просто генерят код без понимания?
Я встречал вакансии где опыт вайбкодинга указывался как необходимое требование, обезъяны, дебилы - это ваша эмоциональная оценка. Понятно что нужно понимать что нагенерила сеть, но в прочем это не всегда обязательно. Я недавно навайбкодил проект за 2 недели за 300 тыс рублей, заказчик был рад до усрачки, потому что сэкономил ему примерно 2 млн. На пайтоне, который я почти не знаю.
Именно об этом я и говорю :) Вы шлёпаете простенькие проекты с жизненным циклом 2 недели (!) в то время, как 90% индустрии занимается совершенно другими вещами, ощутимо более сложными. Затем вы экстраполируете свой опыт из микропроектов на всю отрасль и делаете весьма сомнительные выводы. Эти выводы естественно оспариваются теми, кто работает над полноценными проектами, потому что их опыт говорит о полностью противоположном.
Приведу простую аналогию. Допустим, вы строите гаражи. И тут Boston Dynamics выпускает робота, который умеет строить гаражи любых цветов и размеров. Вы пишете статью: "В будущем сопромат будет не нужен, ведь робот уже умеет строить сам!". После чего проектировщики, рассчитывающие сложные металлоконструкции и использующие в работе всякие там ЛИРА и Advance Steel, крутят пальцем у виска, а вы искренне считаете, что они тупые, а вам виднее, ведь вы этих гаражей по 10 штук каждый месяц заказчикам сдаёте без всякого там сопромата и прочей ненужной мути.
Вот только, повторюсь, 90% строительной отрасли не гаражи строит. И такие выводы насчёт сопромата от строителя гаражей их действительно насмешат.
как раз 95% современной работы программиста очень простые. Современные говнокодеры не знают ни математики, ни теории алгоритмов, а просто собирают из готовых блоков. Сама сложность не в умении думать, а зазубить новые библиотеки. То что вы делаете, что просто как страус засовываете голову в песок. В IT гигантах уже массовые увольнения (то там то сям уволили по 5000 чел) и по разным сведениям больше половины кода генерируют нейросети. Я в индустрии 20 лет и работал в компаниях разных размеров, в том числе и в больших корпорациях, и в стартапах .
Посмотрим на эту вашу браваду года через три, когда будете искать работу в маке. Программисты, не умеющие работать с ллм, станут медленными и устаревшим мусором.
facepalm.jpeg
Чукча не читатель, чукча писатель.
А че не раньше то?
Если ллм будет способна генерить готовый продукт - уж задание себе она будет в состоянии сгенерить и без вайбкодров. Чисто по каракулям учредителя на салфетке.
Программист, не умеющий работать с llm – оксюморон. Когда ты можешь объяснить код компьютеру на весьма ограниченном и формализованном языке (и, что ещё важнее, можешь понять код и исправить его) и можешь объяснить задачу джуну и поправить его – работа с llm даже не требует обучения.
А когда у тебя в анамнезе 5-10 языков программирования – не так уж сложно "расширить рамки" и включить в них работу с llm.
Вот наоборот хуже: если у тебя нет навыка понимания кода – ты не разберёшься, что llm тебе написал, и не сможешь это использовать.
скорее всего чистота кода уйдёт на второй план, так как непосредственно с кодом люди перестанут работать, а его надёжность будет обеспечиваться автоматическим тестированием
Чистота кода (хорошо бы точно определить, что это) - это более дешевое его обслуживание в дальнейшем. Говнокодовую функциональность может быть проще переписать заново, чем править. Если нет, то много тестов надо будет. Автоматическое тестирование само себя разрабатывает?
А ещё тесты нужно писать понятными, т.е. вот эту пресловутую "чистоту кода" нужно использовать в тестах. Иначе непонятный код будет покрыт непонятными тестами из которых непонятно будет что они вообще что-то проверяют.
Тесты тоже будет писать ЛЛМ, так, чтобы они проходили.
Подождите! А зачем LLM писать какой-то код? Вам нужно решить задачу. Прикладную. Путь LLM сама сделает то, что Вам нужно. Без посредство какого-то кода.
Это тоже подход. Не очень хорошо тиражируемый в силу вычислительной требовательности, но - может и работать.
Я встречал некое OCR приложение, у которого в качестве фоллбэка для сложных случаев была белковая нейросеть - т.е. буквально подключались живые люди, если движок не вытягивал. И это тоже нормальное решение, в т.ч. с инженерной точки зрения.
LLM позволяют и переписывать дёшево, так что это становится сильно меньшей проблемой.
С тестированием несколько сложнее. Описывать требуемое поведение, definition of done - так и так человеку. Но дальше... Сгенерировать систему, которая кидает на вход тестируемому нужные данные и сравнивает выход с ожидаемым - тоже решаемая задача. И опять же, эту систему можно хоть под каждую итерацию заново генерировать.
В последнее время мне часто попадаются заметки и комментарии о том, что, дескать, гейткиперы (опытные программисты-миллениалы и старше) искусственно ставят препоны и просят решать никому не нужные алгоритмические задачи, тогда как они давно закодированы в библиотеках.
Скажите, пожалуйста, а хорош ли, вообще, подход к программированию, когда всё, что делается, оформляется в виде библиотеки?
Во-первых, когда у Вас есть библиотечная функция, то Вы не знаете до конца, как она работает. У Вас не всегда есть её исходный код. Ситуация с чёрным ящиком суть неизвестность. Тут Вы, хотя бы, насторожитесь и постараетесь проверить работу функции. Если у Вас есть исходный код, то, конечно, Вы можете проверить этот код, но надо всегда делать скидку на компилятор. У Вас никогда не будет того самого компилятора. Да и, вообще, на самом деле, у Вас всегда будет ситуация серого ящика, когда о функции, вроде бы, многое известно, но это всё одно собрание гипотез, приходится верить на слово, а полноценное регрессионное тестирование оказывается невозможным.
Помниться, ещё в книге "Софтостроение изнутри" говорилось о безысходном программировании. Вот было бы здорово, если бы приложение печатало бы свой исходный код! Могла бы и отдельная функция печатать. Для этого надо, чтобы сами функции писались на некотором мета-языке, чтобы в коде явным образом фиксировались принятые предположения, базовые (точнее, базисные, в математическом смысле некоего базиса, из которого можно построить полностью всё пространство). Это и есть чистый код. Код, в котором нет никаких умолчаний. Код, который сам себя документирует. Код, который сам управляет своей дальнейшей трансляцией.
Во-вторых, выбор функции обрекает нас на пребывание в заложниках у её реализации. Выбрали функцию сортировки получили свои варианты работы на различных данных. А был бы использован оператор сортировки, то вопрос выбора способа сортировки можно было бы отложить на потом. Можно было бы в ОС хранить несколько различных конфигураций таких управляющих параметров на разные случаи жизни. Не говоря о такой возможности, как выбор плана выполнения приложения в момент запуска.
В этом смысле, ИИ отчасти решает эту проблему, но ИИ, фактически, работает как кривой "костыль", а для чистоты кода нужно системное решение. Ближе всего к такому системному решению находится аспектное программирование, когда код сопровождается якорями-аннотациями, к которым "прикрепляется" дополнительная функциональность, которая при дальнейшей трансформации (трансляции) программы, может стать частью основного кода. Тут, над кодом надо произвести что-то вроде ортогонализации Грамма-Шмидта, чтобы получить эффективный функциональный базис. Для этого надо будет понять, что такое ортогональность в программировании.
Наконец, в-третьих, что, отчасти, продолжает предыдущее рассуждение, засилие библиотек тормозит развитие самих языков программирования. Языки становятся похожими друг на друга, и вопрос сводится, в итоге, только к выбору определённого синтаксиса, уже готового набора инструментов и развитого сообщества. Между тем, было бы удобнее иметь отельные языки для создания пользовательских интерфейсов, для работы с базами данных, для научных вычислений, для организации тестирования, для документирования и написания компиляторов. Отдельные примеры таких специализированных языков, конечно же, существуют, но у нас до сих пор нет единой парадигмы написания программного кода с соответствующей данной парадигме программной экосистемы.
ИИ пытается заполнить эту нишу, но, за неимением указанной парадигмы, всё что делает ИИ, всегда будет в большей степени суррогатом, хотя, может быть, и имеющим яркую оболочку. Но это, как раз, говорит о засилии в индустрии суррогатного кода, создатели которого мало думают об обоснованности принятых ими решений. В этом смысле, библиотечный подход оказывается, по сути, генератором этого самого программного суррогата...
А всё должно быть наоборот: ИИ должен предложить чёткую, надёжную и достаточно полную классификационную схему алгоритмов вместе с автоматическим выводом допустимых вариантов реализации (на уровне низкоуровневых кодов, форматов хранения данных, сетевых протоколов и обобщённых вычислительных архитектур). И тогда можно будет построить некое пространство программных систем и функцию выбора определённой системы в заданных обстоятельствах и ограничениях.
Скажите, пожалуйста, а хорош ли, вообще, подход к программированию, когда всё, что делается, оформляется в виде библиотеки
Мне кажется все эти обсуждения хорошо / плохо происходят на планете ремесленников, которые забывают, что деньги им платит бизнес с другой планеты, которому всё это малость по барабану. Бизнес волнуют косты, а библиотеки - необходимое зло (а может и добро, если написаны более скиловаными людьми, чем собственные гребцы) для сокращения издержек.
Так же и с LLMами будет (да и уже происходит) - их использование будет требовать бизнес, так как они увеличивают скорость разработки в умелых руках. А с неумелыми и упрямыми руками что будет - думаю понятно. Будут скоро примерно в той же роли тётенек из отдела бухгалтерии в начале времён, живущих в своём изолированном мире, а потом вдруг окажется, что этот мир легко аутсорсится куда угодно, достаточно выпилить старые неэффективные, закрученные сами на себя процессы.
не знаю, главное чтобы было представление того, что вы хотите в коде например
я сделаю подсказку, может вы хотите текстовый редактор, пробуйте не ждите, не бойтесь дизайна, начинайте делать свой текстовый редактор
Задачей программиста было написание в принципе работающей программы.
Это не так.
Почему появлялись различные языки программирования? Потому, что учёные (а этим тогда занимались учёные) искали способы наиболее ясного выражения вычислительных концепций. Чего, только, стоят алголо-подобные языки (Pascal, Modula, Ada)! Попробовал бы сегодня кто-нибудь произвести сравнение реализации одной и той же прикладной задачи на "старом" языке и на современном. Я бы с интересом посмотрел бы.
Кроме того, некоторые языки сами выросли на определённых концепциях: всё есть список (Лисп), всё есть связка рекурсивных функций (Форт). И, вообще, всё функциональное программирование.
А ещё имеется целая ветвь: доказательное программирование, сигма-программирование (Ю.Л.Ершов этим в Новосибирске занимался)...
Это сейчас царит подход сделать в принципе работающую программу. Гигабайт памяти не жалко. Дали бы старым программам нынешние объёмы памяти (как дисковой, так и оперативной), мы бы, наверное, удивились как они работают, но тогда не пришлось бы писать новые программы, плодить новые ошибки, и снова переписывать (далее — по кругу). Потому ИИ так и "взлетел", потому что сократилось время появления новой версии ПО. В принципе, работает? Да, работает. А теперь, покажите, пожалуйста, полученный таким образом код. Может быть, он, действительно, то, что нам нужно. Тогда его надо вписывать в учебники и делать основой для образовательных курсов. Очень хочется увидеть такой образцовый код. А то нам всякие гуру описывают, каким должен быть хороший ("чистый", "совершенный") код, а его не видно. Был бы такой код, все бы так писали. Как прописи в первом классе. (Хотя, все всё-равно. потом пишут как курица лапой. Особенно те, кто "в аптеке". ) Был бы такой код, можно было бы издать всемирный справочник, что-то вроде, Камке для дифференциальных уравнений, и пользоваться по мере необходимости. Или всё глобально автоматизировать.
Попробовал бы сегодня кто-нибудь произвести сравнение реализации одной и той же прикладной задачи на "старом" языке и на современном.
Rosetta code есть.
Что значит образчовый код и кому он нужен и для чего?
Программист, который пользовался только библиотеками, считался не настоящим, а ламером, «пользователем».
В прежние времена, многое приходилось изобретать самому. Обмен информации не был таким быстрым. Многое, просто объективно, со временем попадает в какую-то библиотеку и становится частью словарного запаса любого мало-мальски профессионального программиста. Сегодня надо знать, что какая-то задача уже имеет некое решение, зато это известное решение с известными свойствами. (Но и не забываем слова, сказанные ранее про "серый ящик". Это суть другая. оборотная сторона проблемы.)
Никто не мешает и сегодня называть постоянного «пользователя» библиотек таким же «ламером». Тогда, правда, придётся называть таковыми довольно много людей, включая и особо продвинутую часть сообщества, включающую т.н. «мид(д)лов» и «сеньоров», которые чрезвычайно глубоко знают целые стеки технологий. Но! Многие ли из них, действительно, способны что-то изобрести поперёк хорошо им знакомого подхода? А как же критическое мышление? Надо же уметь видеть и слабые стороны используемых инструментов! Ведь. отсюда берётся и потребность в создании новых инструментов, включая и новые, более понятные и удобные (в заданных отношениях) языки программирования!
Мы все являемся пользователями ОС. Но ОС не предлагает «из коробки» никакого средства (кроме разве что, командной строки и скриптов) для автоматизации.
Вот, смотрите, текст, который я сейчас пишу, я пишу в специальной форме, которая открывается на сайте. Неосторожное движение мышкой или нажатие не на ту клавишу может заставить браузер "дёрнуться" не в ту сторону, и я потеряю свой текст. Чтобы как-то сохранить этот текст у себя, мне приходится его копировать. Но всё могло бы быть и иначе. Я мог бы писать свой текст в приложении самой ОС, по сути, как текстовое поле локальной базы данных, в которой хранились бы все сообщения, когда-либо мною написанные на всех посещаемых мною в разные годы форумах и площадках. Можно было бы реализовать и такое, но чтобы такое сделать, надо выйти за пределы повседневного использования существующих технологий и изобрести новые протоколы передачи данных и, и, вообще, представить себе интернет без сайтов, как таковых, интернет, который ближе к фидо, бибис и гоферу.
Требования к программистам поменялись из-за изменения бизнес-требований.
Если быть точным, то эти самые бизнес-требования появились. Изначально, ведь, были только научные задачи. А уже потом подтянулся бизнес. А бизнесу нужна скорость выпуска новой продукции. Хорошо проработанное решение мешает создавать новое: зачем делать чт-то новое, если есть хорошо работающее старое?
Все алгоритмы сосредоточены в библиотеках, и ключевыми качествами стали работа в команде и аккуратность.
Такие требования были всегда. Поменялись сами программисты, и творчества среди них тоже стало меньше. Раньше программист мог задумываться о собственном языке программирования, собственной СУБД или CRM-системе. А сейчас? Некогда даже задуматься об этом.
> А бизнесу нужна скорость выпуска новой продукции.
Разве? А я считал, что хороший бизнес это когда доходы растут быстро, а расходы - медленно.
Новый код - это расходы. Рефакторинг - ВООБЩЕ расходы в пустоту.
Выгодно, это может быть только в одном случае - если вы продаете софт.
Бизнес думает о прибыли, а не о коде, чистота кода ему вообще до лампочки, это больше для удобства самих программистов.
А прибыль как считается, не напомните? Я всегда считал, что это доходы минус расходы, а говнокод - это огромные расходы из-за быстрого роста стоимости каждой новой фичи.
Видимо, я очень сильно заблуждаюсь. Расскажите, пожалуйста, как всё устроено на самом деле.
Все зависит от жизненного цикла. Если вы лепите MVP и проверяете рынок вам говнокодистость вообще до лампочки. Не все фичи будут приняты рынком и заказчиком. И т.д. требования к поддерживаемости и расширению кода далеко не всегда ключевые. Часто важнее скорость и цена.
Но ведь изначально вы чётко говорили о бизнесе в целом, а теперь оказывается, что речь уже только про MVP для проверки гипотезы?
Так тут же соотношение хорошо если 1 к 10 (на 1 разраба, пилящего MVP, приходится 10 разрабов, развивающих зрелый продукт). А скорее всего ещё хуже.
Безусловно, если ваша сфера деятельности - штамповать телеграм-ботов для кальянных, то конечно, вайбкодинг рулит, все дела. У заказчика бюджет 30 тысяч и те в рассрочку. А вот давайте мы с вами посмотрим на РЕАЛЬНЫЙ бизнес, в котором вращается 90% всех денег в IT: финтех, ритейл, телеком, промышленность. Там 1 задача может занимать десятки и сотни человекочасов. И что говорите, что для них говнокод - это вообще не проблема, да? :)
Ну то есть придут нам новые правила резервирования товаров на складах, и будем мы вместо 20 часов вносить эти правки 200 часов, потому что у нас сотни тысяч строк разношёрстного говнокода, в котором никто не ориентируется, потому что на этапе написания никто в него не вникал. Зато когда мы пилили MVP, мы его сделали за 1 месяц, а не за 3. Звучит очень выгодно, нужно внедрять в каждый бизнес безотлагательно.
А тут лучше не гадать, а сходить к чуваку "из бизнеса" у себя же на работе и с ним поговорить)
Скорость, а точнее time to market - очень важная штука. Сделали дополнительную кнопку "продать" на страничке на месяц раньше - получили за этот месяц дополнительную тыщу покупателей.
Выгодно, это может быть только в одном случае - если вы продаете софт.
Вот компании и продают софт. Для того, чтобы продавать, нужно всегда делать новый. Это может быть и хорошо, если таким образом, методом последовательных приближений делается продукт, который действительно нужен. Но это может быть и плохо, если втюхивается нечто сомнительного качества, а конкуренты медленно затираются, чтобы не было выбора. Каждая компания выбирает сама свой путь.
Компании нынче продают не софт, а услугу, причём стараются делать это по подписке. И у услуги понятие "качество кода" прослеживается ещё сложнее, чем у коробки.
Кажется у вас программисты - это исключительно отдельная независимая финансово структурная единица.
У нас, например, склад - и прибыль компании генерируют упаковщики заказов.
А я, как разработчик, - только расходы. Никаких продаж софта, никаких конкурентов.
Разработчик, скорее всего, генерирует прибыль путем замены расходов на неавтоматизированный процесс на автоматизированный + расходы на автоматизацию. Или если он сайт компании пилит - значит приводит клиентов, участвует (пусть и немного сбоку) в цепочке продаж и генерации выручки. Не генерирует прибыль какой-нибудь сисадмин, который поддерживает систему в рабочем состоянии. Ну или уборщица склада.
Достаточно осознать, что в годовом отчёте компании нет слова "код". Хорошо, если он там будет в виде графы IP. Соответственно бизнес такой категорией не думает. Если CTO подумал - ок, но это ДАЛЕКО не везде.
Сейчас, с появлением языковых моделей, мы видим очередную смену парадигмы: часть процессов кодирования стала беспрецедентно дешёвой. То же самое можно сказать про рефакторинг и анализ кода.
Давайте, вместо общих слов, возьмём какую-нибудь прикладную задачу и рассмотрим её различные решения и сравним их с тем. что предлагает ИИ. Если ИИ предлагает что-то дельное, то весь этот кипишь вокруг ИИ можно расценивать как проявления страха большого числа людей, к которым, наконец, пришёл оценщик (как этот бычок из детской сказки, который всех считал), и сейчас общество узнает реальную цену разработчикам. Если есть какие-то внятные принципы разработки, то почему мы им все не следуем, и не изучаем прямо в школе? Если же ИИ предлагает какую-то лажу, хотя бы и яркой упаковке (когда, на первый взгляд, всё работает, то есть — работает в принципе), то это означает (опять же!), что обучающая выборка содержит множество артефактов, то есть — общепринятым является суррогатное программирование. Куда ни кинь — всюду клин!
Всё это не означает, что настоящее программирование должно быть дорогим. Но оно обязательно должно рождаться в результате приложения определённых усилий на то, чтобы понять задачу, на то, чтобы увидеть различные варианты реализации, и выбрать из них наилучший (или предложить некую комбинацию решений, когда, в зависимости от контекста, выбирается свой вариант).
А что Вы скажете про анализ кода и рефакторинг? Зачем Вы хотите проанализировать код? Для чего Вам нужен рефакторинг?г
Берите конкретику. Некоторые кейсы решаются LLMами на раз. В нашей компании был опыт переезда с MSSQL на Postgres за месяц, о чём даже боялись до появления LLM думать - куча легаси хранимок, которые даже понять сложно, не то что переписать. А LLMке в этой субстанции ковыряться не страшно. Берёт и делает. Задачи переведи с одного языка на другой делаются на раз.
Сложно сказать, как это будет выглядеть в дальнейшем, но скорее всего чистота кода уйдёт на второй план, так как непосредственно с кодом люди перестанут работать, а его надёжность будет обеспечиваться автоматическим тестированием.
Подождите! Как это обеспечиваться? Что же такое чистый код? Разве надёжность и чистота — это не две оборотные стороны одной медали?
Допустим, где-то в программе написано:
s = input()Допустим, выбран язык программирования Python. Здесь приведён пример чистого кода? Я, конечно же, утрирую. Но, однако, продолжим. Что мы вводим? Интересный вопрос! Это строка или число? Мы знаем, что функция input() возвращает символьную строку. Но такая строка может содержать и число! Но мы хотим застраховаться от ошибок. Мы попытаемся написать что-то вроде.
s = input()
try:
i = int(s)
except ValueError:
...Это уже чистый код?
А если мы захотим получить число с плавающей запятой? Переделывать код? А может быть, можно переделать саму функцию input(), чтобы она сразу возвращала значение нужного типа? А (кстати!) а от чего зависит тип возвращаемого значения? Мы могли бы сразу написать, как в Pascal'е:
i: integer
i = input()Это как? Ещё чище? И где, и какое тестирование здесь проводить?
надежность - это покрытие тестами, а чистота - это для поддержки людьми. Не обязательно надежный код может быть читым
Чистый код (если, такой код, вообще, может быть написан) не нуждается в поддержке. В нём всё понятно. Он полностью управляем. И, кстати, полностью покрываем тестами. Мы никогда не сможем проверить все возможные входные данные, но мы мы можем проверить важнейшие классы входных данных.
Хорошим примером чистого кода является математика.
Вспомните школьную математику. Вы хотите решить уравнение или исследовать функцию. Вы понимаете. что у функции есть область определения. Если Вы об этом забудете, то Вы рискуете получить несуществующие корни. И при изложении материала, всегда явно указывается, что из чего и как определяется, разбираются пограничные случаи (например, что у нас в нуле, как расшифровывается неопределённость, вроде 0/0)...
Не стоит делать упор на покрытие тестами. Борьбы за надёжность начинается с самого начала работы над приложением, и покрывать тестами нужно уже сами исходные требования, чтобы устранить основные причины возникновения проблем ещё до начала самого кодирования. Это азы тестирования.
Ну вот с какого? Чистым кодом можно реализовать абсолютно неправильный бизнес кейс и именно бизнес кейс нуждается в долговременной поддержке. Меняется кейс - требуется переписывать код, и вот именно там некая "чистота и универсальность" может окупиться. Только вот правда жизни такова, что бизнес кейсы часто меняются с викидыванием кода и программистов вообще с заменой на что-то своё. Например более крупный конкурент покупает менее крупного и постеменно замещает его софт своим. 3 раза на моей практике такое было.
Меняется кейс - требуется переписывать код, ...
Вот меня и интересует, почему меняется кейс? Для меня это — краеугольный вопрос разработки: можно ли писать код (и, вообще, создавать ПО) так, чтобы не надо было ничего переписывать? "Вот, в чём вопрос." (с)
Потому что мы не пишем бизнес, мы пишем ПОД бизнес. А бизнес не статичен во времени, если только он не в стадии помирания.
Даже в космических миссиях, которые длятся годами, и в случае которых обновление ПО - та ещё задачка, были случаи возникновения новых задач и удалённых апдейтов. В большинстве приземлённых задач ситуация в разы динамичнее.
ИМХО.
Те случаи, которые на слуху, типа Вояджера: Миссия завершена, код был написан и всё. То, что потребовалось обновление, так это они на "старом железе" решили еще поработать. Изначально такой задачи не было.
Прикиньте - у вас миссия на 10+ лет, а программисты каждый год переписывают код того, что уже отлетело на миллионы километров от Земли на актуальные фреймворки. Ну а вдруг понадобится? И все это за счет налогоплательщиков.
А при чём тут "а вдруг понадобится?" Я как раз про прямо противоположное говорю - именно требования могут меняться, даже если тыщу раз их утвердили. Даже если объект этих требований за миллионы км улететь успел.
На передний план выйдут архитекторы и бизнес-аналитики, причём ключевым навыком будет именно построение самих моделей бизнес-процессов в разработке ПО.
Архитекторы никогда не будут на первом плане. Всякая архитектура предполагает строго последовательный способ создания любой системы. Водопадная модель! Сначала составляется полный список требований. он закрывается. Затем, по нему делает проект, где для каждого вопроса предлагается решение (ещё только "на бумаге"). И уже когда на все вопросы получены какие-то ответы, начинается, собственно кодирование. В реальности, бизнес навязывает другую модель разработки, когда, вмешательства оказываются возможны на любом этапе. В результате, полученное "здание" приходится снабжать "костылями", поскольку все элементы оказываются довольно далекими от расчётных значений. Предсказать поведение такой "системы" довольно трудно. Если, вообще, возможно.
С точи зрения архитектуры, чистый код — это такой код, который можно один раз написать и растиражировать везде. А у нас вся история программирования — это история разработи и реализации многочисленных библиотек, которые благополучно отправляются на свалку всемирной истории. Было бы качество — мы бы сейчас, могли бы писать на Хабр, например, при помощи приложения, написанного на Turbo Vision. Текстовый режим... У него были преимущества. И в смысле безопасности тоже. Не говоря о том, сколько проблем не надо было решать (там, с HTML/CSS/JavaScript).
Водопадная модель! Сначала составляется полный список требований. он закрывается.
Вы из какого года пишете? Agile появился именно потому, что водопада не существует в реальной жизни проектов крупнее мелкой консольной утилиты, если не рассматривать аквариумы типа NASA с одноразовой выкаткой кода в прод.
Это и есть проблема. Корень проблемы. Хорошо можно сделать только последовательно. Не перескакивая через этапы. (Поэтому поводу, даже, сказка есть. Называется "12 месяцев".))) Все эти гибкие способы разработки они вполне естественны для раскрутки какого программного кода из состояния отельных разрозненных заготовок до полноценного рабочего состояния. А ситуация, когда клиент "вспоминает", что ему нужно что-то ещё, плохая ситуация. Да, такая ситуация является общепринятой. Но это, что называется, увы и ах. А в нормальной ситуации, для хорошего дома всегда возводится прочный фундамент. Для программных систем таким фундаментом является набор базовых библиотек (программная платформа) и проектная документация, где на каждый вопрос по проекту даётся ответ (выбирается способ решения, способ сопряжения и оцениваются риски).
У исполнителя свои проблемы, у бизнеса - свои. Кто платит деньги, тот и заказывает. Возникающее по мере появления результатов понимание, а что собственно надо делать - реалии жизни и софтовость софта этому способствует, ибо относительно несложно переделать сделанное, в отличие от той же стройки.
Как выясняется, все эти переделки довольно дорого обходятся. Вопрос для меня в том, почему практически никогда с самого начала не удаётся понять, а что, собственно, надо делать?
Это тупо невозможно в мало мальски большом проекте. Основной каркас накидать да, а цвет обоев и в процессе можно выбрать. С парочкой дополнительных перегородок. И дополнительной вертолётной площадкой. И бассейном на крыше. И вообще в другом городе.
почему практически никогда с самого начала не удаётся понять, а что, собственно, надо делать?
Наверно по тем же причинам, по которым вы сами не всегда с самого начала понимаете, что, собственно, надо делать? Почему вам можно ошибаться, а от других вы требуете идеальных действий?
Именно заказчик - основная энтропия в разработке. Семь красных линий и одна котиком.
А кто заставляет исполнителя торопиться писать код?
Эм... Желание выписать счет за трудочасы - желание норм или не норм? Или будем сидеть на скамейке и сражаться за хз кому нужные идеалы?
Есть очень просто вопрос. Возьмите какой-нибудь свой работающий код. Как Вы его писали? Сколько шишек набили? И! Могли ли Вы действовать так, чтобы написать примерно такой же код, но без набивания шишек и, возможно, за меньшее время? Вот в чём вопрос. (с)
Опять эджайл против водопада? Ну не бывает в чистом виде ни того ни другого. Любой сколь-нибудь крупный проект начинается с ватерфолла в виде постановки задачи, архитектуры, выделения компонентов и моделей данных, разделения на сервисы/компоненты и реализации оных.
А эджайла там остаётся правило "мы можем вкинуть фичу и приоритезировать ее, соответственно сдвинув остальной граф сроков реализации фич".
Но опять же вкинутые фичи делаются так чтобы не переделывать их потом - то есть им делается тот же цикл мини-ватерфолла, и реализации общих щавтсимостей - разве что "продуктом" становится сама фича.
Так что эджайл нормальный это не работа без ТЗ, а по сути распиливание одного монолитного процесса на множество небольших субпроцессов. И если для фичи вам нужен компонент который сейчас отсутствует, то он становится отдельной фичей, которая объявляется блокером и пилится вне приоритетов.
сколь-нибудь крупный проект
Не всё существует в виде проектов. Есть ещё и продукты. У которых требования появляются и отмирают постоянно в течение жизненного цикла. Иногда очень резко - как, например, всем ритейлам в 2020-м пришлось очень быстро запиливать онлайн-продажи и доставку. Но даже если нет такого форс-мажора, ситуации когда сегодня вверху бэклога одно, а завтра оказывается, что надо достать другое - вполне реальны.
И да: называть серию микроводопадиков по фиксированному набору требований эджайлом - это большая ошибка. Эджайл в принципе не модная самоцель, это просто способ выжить в ситуации быстро меняющихся внешних требований.
Ещё раз. Agile ПОЯВИЛСЯ, так как водопад не работает. Всё. Других утверждений не было.
Почему не работает?
По определению. И по факту - нет смысла пыжиться и продумывать всё заранее до последней кнопки. Всем проще делать итерациями. Да, за непредсказуемый бюджет. Но денег много где как грязи. Выделили условный лярд в год на ИТ разработку и всё, можно аджилить и не напрягать сильно мозги макулатурой.
Итерации будут всегда. Но, в целом, нужно обязательно всё продумывать. Непродуманность потом и оборачивается значительными тратами этого самого бюджета.
Это просто невозможно в условиях, когда заказчик сам не знает, чего хочет. А узнает, только когда пощупает первые MVP. И то не факт. Такое сплошь и рядом.
Это всё — констатация печальных фактов нашей повседневной обыденности. Но это не значит, что не надо думать о лучшем.
Я не согласен, что написание талмудов документации с невозможностью изменений посередине - это лучшее. Опять же, agile в том числе и про это. У меня, в результате первой работы, где были аналитиками написанные талмуды с требованиями к разработке выработалось стойкое презрение к этому виду деятельности. Ну не могут люди на берегу руководить экипажем подводной лодки.
А что именно вызвало у Вас отторжение?
То, что люди, которые не программируют, выдвигают требования к тому КАК программировать и что делать. Ну это ладно, личное. бОльшая проблема - то, что уже на середине разработки документация катастрофически деградирует относительно реалий
новые требования (да, заказчику не скажешь пошёл нафиг с новыми требованиями, приходи после завершения проекта), особенно если он готов платить за change requests
невозможно всё продумать, многое додумывается на местах
пишут документацию часто совсем не эксперты. хорошо, если они сами хоть что-то серьёзное программировали, чаще нет.
Представим, что чистый код существует. Это значит, что можно в интернете завести сайт, где будет этот самый чистый код храниться. Каждый отдельный алгоритм будет иметь свой уникальный идентификатор. И тогда можно будет формировать свою программу, ссылаясь на это хранилище. Все будут пользоваться общим кодом, а не самописными конструкциями.
Палата мер и весов для кода? Придется "напильником" очень часто работать
Это значит, что можно в интернете завести сайт
можно будет формировать свою программу, ссылаясь на это хранилище
Все будут пользоваться общим кодом
Замечательный комментарий! Который очень хорошо говорит о том, насколько мне трудно донести сою мысль. Я оказался совершенно не понятым.
Я говорю не о каком-то хранилище, куда люди добровольно выставляют свой код (может быть, даже, очень хороший и востребованный) на всеобщее обозрение, а про ресурс, который является базой данных работающего кода (то есть — универсальным репозиторием), с которого постоянно загружается (тиражируется) код. Смысл такого репозитория в том, чтобы:
Задать для всех единую систему координат, чтобы все разработчики разговаривали на одном языке, в одних и тех же терминах и алгоритмах.
Создать базу данных проверенного кода или, как любят иногда здесь выражаться, покрытого тестами.
Указать проблемные места, на доработку которых следует направить силы разработчиков.
Гитхаб, разумеется, во многом, позволяет достигать похожих результатов, но даже этот сайт не является искомым решением, и более концентрируется на п.3.
В чем разница между github и искомым решением? Я ее не замечаю.
все разработчики разговаривали на одном языке, в одних и тех же терминах и алгоритмах
Они и так это делают, даже github тут ни при чем.
Представим, что чистый код существует. Это значит
Каждый отдельный алгоритм будет иметь свой уникальный идентификатор.
Нет, не значит. Чистый код не задает правила для единственной реализации. Для некоторого логического алгоритма может быть много разных реализаций, которые соответствуют критериям чистого кода.
Разработчики всегда пользуются какими-то своими библиотеками. В каждом языке программирования есть свои библиотеки. В СУБД — свои. Все разговаривают на разных языках, используют различные реализации. Трудно сравнивать. Было бы удобнее ссылаться на что-то одно и иметь в виду конкретную реализацию.
В каждом языке программирования есть свои библиотеки.
А почему вы думаете, что от чистого кода на одном языке все другие языки вдруг исчезнут? Ваш код библиотеки на Java может быть сколько угодно чистым, но если у меня проект на PHP, то мне нужна библиотека на PHP, а не ваша реализация на Java.
Было бы удобнее ссылаться на что-то одно и иметь в виду конкретную реализацию
А при чем тут чистый код? Правила написания кода, который можно считать чистым, не ограничивают количество реализаций. А в некоторых случаях более важна производительность кода, даже если он не соответствует некоторым из этих правил.
Вы куда-то уходите в сторону. Я говорил о том, что все разговаривают на различных языках программирования не в смысле самих языков программирования, а в смысле трудностей понимания, в общечеловеческом смысле, просто программирование приводит к тому, что, фактически, мы пользуемся различным ПО, хотя подразумеваем одно и то же.
Чистый код — это код, который не надо править и который можно смело использовать. Это вещь с известными хорошо проверяемыми свойствами (включая и производительность).
Вот, Вы. Вы можете писать код так, чтобы его не надо было мучительно править, исправляя собственные ошибки? Вот сейчас я учусь писать код. И меня очень занимает вопрос, откуда берутся ошибки, и можно ли мыслить так, чтобы запускать редактор кода уже тогда, когда в голове уже сложилось практически всё, что надо. В этом смысле, идеальный программист — это тот, который сначала долго думает, а, потом, быстро делает.
Чистый код — это код, который не надо править и который можно смело использовать.
С чего это вдруг? Это не входит в критерии чистого кода.
Это вещь с известными хорошо проверяемыми свойствами (включая и производительность)
Ну и что с того, что я проверил, что производительность библиотеки, написанной чистым кодом, для моей задачи недостаточна? Мне-то надо, чтобы работало быстрее.
программирование приводит к тому, что, фактически, мы пользуемся различным ПО, хотя подразумеваем одно и то же.
И? При чем тут чистый код-то?
В этом смысле, идеальный программист
А идеальные программисты тут при чем?
Оффтоп обсуждать мне неинтересно. Вы написали про сайт, я вам сказал, что такой сайт уже есть. Вы сказали, что он не подходит, но на вопрос почему ответить не можете.
Вот сейчас я учусь писать код. И меня очень занимает вопрос, откуда берутся ошибки
Это вас надо спрашивать, почему вы сначала неправильно написали. Откуда другие люди должны это знать?
можно ли мыслить так, чтобы запускать редактор кода уже тогда, когда в голове уже сложилось практически всё, что надо
Вот когда сформулируете ответ на предыдущий вопрос о причинах, тогда можно будет и ответить, можно или нельзя их избежать.
С чего это вдруг? Это не входит в критерии чистого кода.
Для меня это так. Если для других всё иначе, то я с этим ничего не могу поделать. Хотелось бы, конечно, всегда говорить об одном и том же. Но каждый акын дует в свою дуду.
Ну и что с того, что я проверил, что производительность библиотеки, написанной чистым кодом, для моей задачи недостаточна? Мне-то надо, чтобы работало быстрее.
Уберите из Ваших рассуждений словосочетание "чистый код". Вы хотите получить некий код. У Вас два варианта. Взять уже готовый. Или написать самому. Какой выберете?
Все хотят быстрее. Но мы знаем, что многое зависит от самих данных. Отсюда вопрос: на каких данных (быстрее)? И... быстрее чего?
И? При чем тут чистый код-то?
Всегда мечтается о том, что что-то можно один раз написать и пользоваться.
Вы написали про сайт, я вам сказал, что такой сайт уже есть. Вы сказали, что он не подходит, но на вопрос почему ответить не можете.
ВП:НЕСЛЫШУ
А что Вы можете сделать с ГитХабом?
Это вас надо спрашивать, почему вы сначала неправильно написали. Откуда другие люди должны это знать?
Всегда надеешься на то, что более опытный человек умеет лучше организовывать свою работу. Да и, вообще, опытного человека всегда интересно послушать.
Но каждый акын дует в свою дуду.
Пока что выглядит так, что только вы дуете в свою дуду. Остальные пользуются общепринятыми определениями.
Взять уже готовый. Или написать самому. Какой выберете?
У нас был разговор о том, почему не может быть одного варианта реализации. У меня есть выбор взять готовый чистый код, который работает медленно, или готовый не очень чистый код, который работает быстро. Поэтому нельзя "ссылаться на алгоритм генерации UUIDv4" или "на алгоритм веб-сервера" и иметь в виду одну конкретную реализацию. Одному нужны понятные исходники, другому производительность. Чистый код обычно подразумевает меньшую производительность. Поэтому реализацией одной функциональности будет больше одной.
- производительность библиотеки, написанной чистым кодом, для моей задачи недостаточна? Мне-то надо, чтобы работало быстрее.
Отсюда вопрос: на каких данных (быстрее)? И... быстрее чего?
У меня это написано прямым текстом. Быстрее библиотеки, написанной чистым кодом. На тех же самых данных, которые она обрабатывает. Например, на HTTP-запросах, которые приходят на веб-сервер.
Всегда мечтается о том, что что-то можно один раз написать и пользоваться.
https://github.com
Всё, что там есть, уже написано, пользуйтесь.
А что Вы можете сделать с ГитХабом?
Хранить там код. Пользоваться общим кодом, который уже написали один раз другие люди. Формировать свою программу, ссылаясь на это хранилище. Я это всё уже процитировал в начале ветки. У вас цель потроллить или что?
Всегда надеешься на то, что более опытный человек умеет лучше организовывать свою работу.
Более опытный человек умеет лучше организовывать свою работу. Но он понятия не имеет, почему вы в своем коде делаете ошибки. Я вообще не понимаю, почему вы требуете от других, чтобы они писали сразу идеально, хотя сами так не делаете. Если вы допустили ошибку, значит вы чего-то не знали или не заметили. У других людей те же причины.
У математиков такая база доказанных теорий есть со спецсофтом, где переиспользуешь в своих доказательствах уже доказанные ранее другими "блоки". Лень пруфы искать, в подкасте у Лекса с Теренсом Тао слышал.
Математика сама есть доказательная база и пример хорошего подхода. Большинство книг по математике дают все необходимые определения и теоремы (всё своё ношу с собой).
Но она в плане чёткости требований и проверяемости результата всё таки кардинально лучше.
А всё почему? Потому что она состоит из исходников. Мы долгие годы в вузах изучаем исходники. Потом пользуемся. Да и само строение математики. Математика — это язык! Сам себя объясняющий и сам себя проверяющий. В теоремах водятся посылки, к теоремам ведёт чёткая мотивация (зачем).
Главное - в математике как правило есть чёткий результат, который можно и нужно валидировать. Если в программировании условный алгоритм сортировки можно абсолютно полностью покрыть тестами, то условный респонс тайм распределённой системы под плавающей нагрузкой покрыть и детерменировать вообще - вопрос сложности совсем других порядков.
Время идет, прогресс не остановишь. И с течением времени всегда меняются подходы к разработке. Такова жизнь и с этим ничего не поделаешь.
В последнее время мне часто попадаются заметки и комментарии о том, что, дескать, гейткиперы (опытные программисты-миллениалы и старше) искусственно ставят препоны и просят решать никому не нужные алгоритмические задачи, тогда как они давно закодированы в библиотеках. Это — с одной стороны. С другой стороны — ругают LLM, потому что код там не всегда чистый и, дескать, программирование с LLM — это не программирование вовсе, и навыки такого программиста ничего не стоят.
Неудачный пример, поскольку именно алгоритмы общего назначения, которые так любят на собеседованиях, LLM-ки пишут хорошо. У них проблемы с написанием реального кода, которому приходиться взаимодействовать с остальным проектом.
Вообще LLM-ка — это как раз идеальный проходитель (или проходимец?) алгособесов. И появление LLM-мок как раз показало, что все эти требования к программистам решить задачи на листочке, это как требования к автомеханику поменять колесо при помощи только балонного ключа. И тут резко выяснилось, что андроиды делают это лучше. Хотя в реальной работе для смены колеса и кожаный и электронный автомеханик возьмут домкрат.
Алгособесы - это тест не фундаментальные знания в IT и больше про умение думать. Сейчас в библиотеках, и нужны массовые исполнители, где больше не про ум, а про усидчивость и аккуратность. Поменяются требования бизнеса (который вам не друг, а инструмент как выжать из вас максимум за минимум денег) - поменяются и требования к работничкам
Вообще ни разу не про думать. Ну никто не изобретает исполнение этих алгоритмов из головы, заучивают в том или ином виде. Думающий человек будет выглядеть тугодумом на фоне конкурирующих кандидатов, бодро строчащих код на листочке под выученный алгоритм.
Не изобретает, но адаптирует под задачу. Математика ведь тоже не про зубрежку, хотя на прикладном уровне никто теоремы не передоказывает с нуля
Контекст свыше - собесы. На экзамен ПДД по теории в конечном итоге билеты тоже заучиваются, работает визуальная память. Хоть и пройдена теория, но те слои мозга не задействуются, нет необходимости, если на автомате визуалка выдаёт правильный ответ. Так и тут.
Собесы организовывают обычные программисты, каждый исходя из своего понимания о профессии. Кто в чем силен, то на то и напирает.
Это бред полный, картинки в билете и ситуации в жизни не всегда точно совпадаю, поэтому нужно именно понимать правила, иначе галлюцинировать начнете
Вообще очень интересно, кстати. Получается, что llm при обучении дают только практику, обучая на куче примеров, при этом теорию она сама должна выработать. Как то странно это.
Это даже сама llm понимает, иронично)
«Практика без теории слепа» — это часть знаменитой цитаты Александра Васильевича Суворова «Теория без практики мертва, практика без теории слепа». Она означает, что без понимания теоретических основ, практическая деятельность становится бессмысленной и неэффективной, поскольку человек не знает, почему он что-то делает и как сделать это
Без теории, практика — это просто слепое следование инструкциям или привычкам, без понимания сути
Собесы и экзамен - это не жизнь и подходы к подготовке поэтому разные по эффективности.
Блин, без чистоты в коде ваше ПО рано или поздно превратиться в "кусок грязи". Llm, которая в трех соснах плутает, эту ситуацию только усугубляет.
Я считаю что хайп на (де)генеративные нейросети пройдёт и их применение будет ограничено некоторой необходимостью использования. Иначе человек превратится в обезьяну и начнёт снова учится пользоваться дубиной и каменным топором с повторением уже пройденных жизненных процессов.
Плюсанул статью, потому что автору удалось создать просто идеальную иллюстрацию эффекта Даннинга-Крюгера.
Автоматизированное тестирование не поможет, потому что в запутанном коде запутается и сам AI тоже.
Наоборот, теперь мы будем иметь объективный критерий чистоты кода: это код который AI легко дорабатывает. Хотя, да, критерии чистоты при этом могут несколько измениться.
Что касается сегодняшнего момента, то я например перестал заботиться о некоторых критериях чистоты кода тестов. А зачем, если их AI пишет и сам же переписывает.
Я всё жду не дождусь, когда мне LLM будет генерировать нормальный код без утечек памяти. Я всего-лишь хотел сделать node-addon для работы с окнами на windows linux mac.
Две функции: вывод список окон и поиск активного окна.
Но нет, LLM не решает задачу. Мне просто нужен любой говнокод без архитектуры и чистоты, который я смогу прикрутить к node. Но память течет, функции не работают. Приходиться самому задавать архитектуру, говорить какие системные вызовы использовать, поправлять алгоритмическую сложность, руками тестировать, искать утечки памяти.
Для меня польза в том, что я не знаком со swift для macos и не привык к синтаксису, быстрее исправлять ошибки компиляции через llm, чем самому. А вот с c++ такой роскоши нет, он тут даже список аргументов не всегда понимает, фикси сам мои галлюцинации.
Если отвечать, на вопрос, то конечно чистый код будет. К слову, чистый код, это не только про пробелы и отступы.
Почитав комментарии вайбкодеров долго смеялся над их позицией. Мол нейронка любой код понимает, поэтому чистый код нужен только программистам...
Чистый код будет всегда, просто поменяется в будущем под особенности работы нейронок. LLM хорошо понимает именно языковые конструкции, которыми языки программирования и являются, следовательно в будущем, чистым кодом будет тот, который не только понятен и удобен человеку, но и так же понятен и удобен самим LLM. Поэтому не надейтесь, что стандарты куда-то исчезнут. Они уже активно формируются.
В комментариях, активно пишут, что программисты не нужны, сейчас вторые 90-ые и время возможностей. Скоро мол вайбкодеры заменят программистов, что читать смешно.
Вас заменят ещё быстрее, чем нас. Как раз, потому-что вы умеете только табать, без понимания тех. контекста. Для вас нейронки это не понятный инструмент, а бог из машины, что работает на магии.
Помню, когда только появились background агенты, тот же codex, многие таберы писали: "Выглядит круто, но что такое github? Консоль какая-то, этим как пользоваться, то вообще? А где скачать?". Сейчас бэкграунд агенты не редкость и уже часть таберов отсеялось. Потом агенты стало популярно деплоить локально и тут таберы офигели с docker и контейнеризации. Что-то таб не помогает разбираться, сложна.
Уже появились первые паттерны для работы с нейросетями. Например, как лучше передавать/получать данные в чатах. Какие температуры использовать, как правильно организовывать тот же RAG и как правильно использовать MCP. Дальше разработка вместе с нейросетями будет только усложняться и это нормально. Следовательно, станут востребованы настоящие программисты, с базой знаний/скилов, которым будет довольно просто будет во всём разобраться. Намного легче, чем человеку без тех. базы. Так что кардинально ничего не поменяется, а порог входа только вырастет.
Вы сами себе противоречите. С одной стороны пишите что вайбкодинг никогда не заменит обычный, потом пишите что он вытеснит. Вайбкодинг не подразумевает что вайбкодер хуже разбирается в программировании - а только то что его проивзодительность выше. Я полностью перешел на вайбкодинг и только благодаря этому продолжаю зарабатывать. Хотя вскоре доходы вайбкодеров упадут - просто пересчитаю нагрузку и все. А обычное программирование станет нерентабельным.
Вайбкодер ничего не хочет понимать в коде, да и впринципе мозг загружать не хочет, он хочет кружевные тру..кхм.. и общаться с llm, в код он впринципе не лезет, а задрачивает нейросеть, чтобы та все сделала. Вы считаете у такого подхода будущее есть? На мой взгляд будущее вайбкодера это быть рабом llm
ну так вы описали обычную наемную работу. бизнесмен тоже не хочет ничего делать а нанять людей что бы ему сделали и желательно бесплатно
Вайбкодинг не подразумевает что вайбкодер хуже разбирается в программировании
В том, то и дело, что по определению это и есть подход, когда пользователь ничего в коде понимать не должен, а нейронка всё делает за него.
Программист, использующий нейронки в работе, не равно вайбкодер. Так что в моих словах противоречия нет.
Будет ли важна чистота кода в ближайшем будущем
"В ближайшем будущем" она еще будет важна, потому что будут нужны программисты, которые могут в нем разобраться и поправить вручную, когда нейронка не справляется. А в будущем чуть подальше, когда нейронка будет со всем справляться сама, не нужны будете уже вы. У вас есть только то, что есть в настоящем. То будущее, в котором вы лихо пишете промпты, а нейронка сама вносит изменения в сложный проект с запутанным и далеким от чистоты кодом, не наступит никогда.
За всеми концепциями стоят банальные реальные потребности, в том числе и за Чистым кодом. Для человека, не разбирающегося в реальных движущих силах того или иного инструмента, естественно этот инструмент превращается в фетиш, а действия с ним - в карго-культ.
Смешно читать про противопоставление тестирования и чистого кода. Смешно читать, что чистый код не нужен, потому что он мешает писать программы быстро. Это непонимание чистого кода, его функций - портрет вайбкодера : ) Между тем - Чистый код просто форма борьбы со сложностью кода и закладка фундамента под то, чтобы код был структурирован и его можно было бы развивать. Это актуально для любого интеллекта - хоть человеческого, хоть искусственного: запутанный, плохо структурированный код будет приводить к деградации понимания что происходит и что код выражает экспоненциально с ростом количества кода.
При этом я ничего против LLM не имею. Они просто не справляются на больших проектах - и это факт из моего практического, постоянного и довольно обширного опыта применения LLM для кодинга. В последнее время я стал еще и натыкаться на то, что модели отстают от актуального знания - свежих библиотек - и генерят устаревший код, а зачастую и миксуя несовместимые версии. Плачевно обстоит дело и с рефакторингом крупных проектов - нужно либо продумать этот рефакторинг и описать от и до: где и что поменять конкретно и в полуручном режиме пройтись последовательно по изменяемым программным сущностям вместе с LLM, еще и попутно поправляя ее - но тогда в чем выигрыш?; либо получить взрыв на макаронной фабрике : )
Я не против, если бы LLM могла писать код за меня - и даже знания в прграммировании мне бы не мешали при этом : ) Но - это не работает так, как пишут нам восторженные вьюноши.
Ждем следующую статью: "Будут ли важна булева алгебра в ближайшем будущем" : )
Если за чистотой кода не следить то там после десятка итераций ллм нагенерит такое что он сам уже не разберется че там происходит да и ты глазами умрешь разглядывать эти завитушки галлюциногенных грибов
Трудно спорить, когда знаешь рабочий способ распределения 28 танков по 13 штук в 7 рот.
Будет ли важна чистота кода в ближайшем будущем