В последнее время мне часто попадаются заметки и комментарии о том, что, дескать, гейткиперы (опытные программисты-миллениалы и старше) искусственно ставят препоны и просят решать никому не нужные алгоритмические задачи, тогда как они давно закодированы в библиотеках. Это — с одной стороны. С другой стороны — ругают LLM, потому что код там не всегда чистый и, дескать, программирование с LLM — это не программирование вовсе, и навыки такого программиста ничего не стоят.
Мне приходит на ум то, что в принципе мы подобный слом уже видели лет 15–20 назад. Для программиста старой школы сутью программирования, собственно, было постановка задачи, её реализация с помощью алгоритма и оптимизация этого алгоритма по скорости. Сам инструмент — язык, а уж тем более чистота кода — считалась вторичной. Задачей программиста было написание в принципе работающей программы.
Что касается чистоты кода: использование отступов и понятных названий функций, переменных и классов уже считалось большой аккуратностью. Для первого поколения ПО, в общем-то, и не предполагалось, что можно эффективно и полноценно работать с чужим кодом. Появление специализированных библиотек считалось подспорьем, но предполагало, что программист и сам должен быть способен написать подобное с нуля. Программист, который пользовался только библиотеками, считался не настоящим, а ламером, «пользователем».
Требования к программистам поменялись из-за изменения бизнес-требований. Если раньше задачей программиста было придумать и реализовать программу (он одновременно был и бизнес-аналитиком, и дизайнером, и архитектором, и алгоритмистом), то сейчас появилась возможность создавать ТЗ и интерфейс не программистам. Все алгоритмы сосредоточены в библиотеках, и ключевыми качествами стали работа в команде и аккуратность.
Однако нужно понимать, что это не суть программирования. Программирование — это умение решать любые задачи с помощью ЭВМ, а поддержка кода лишь часть работы. Этот навык востребован лишь локально, исходя из конкретного пула задач (типизированные большие проекты, рассчитанные на конвейерное проектирование).
Сейчас, с появлением языковых моделей, мы видим очередную смену парадигмы: часть процессов кодирования стала беспрецедентно дешёвой. То же самое можно сказать про рефакторинг и анализ кода. Текущее поколение, считающее своим ключевым навыком не креатив и алгоритмизацию (в отличие от их предшественников), а аккуратность, стабильность и софт-скиллы, воспринимает создание ПО с помощью LLM как бы «ненастоящим» (так же, как в 90-х «системные программисты» презрительно относились к «прикладушкам»). Но всё будет решать требования бизнеса и, соответственно, бизнес-процессы.
Сложно сказать, как это будет выглядеть в дальнейшем, но скорее всего чистота кода уйдёт на второй план, так как непосредственно с кодом люди перестанут работать, а его надёжность будет обеспечиваться автоматическим тестированием. Понимая скепсис в отношении надёжности такого подхода, можно возразить, что такие проблемы давно решаемы, в том числе с помощью независимых систем.
В каком-то смысле 2020-е — это новые 90-е в IT, когда на сломе старых систем они становятся дорогостоящими, медленными и неэффективными, и снова становятся востребованными «хакеры», которые смогут быстро, дёшево и эффективно строить новые модели IT-систем, в том числе используя интуитивный, креативный подход. На передний план выйдут архитекторы и бизнес-аналитики, причём ключевым навыком будет именно построение самих моделей бизнес-процессов в разработке ПО.
Впрочем, пока не ясно, в какой степени можно будет доверять создание архитектуры LLM. Уже сейчас она справляется с базовыми шаблонами, но где границы — непонятно. С другой стороны, совершенно очевидно, что со снижением цены разработки коммерческое ПО станет в разы сложнее, а нынешние лидеры уйдут со сцены (пример — ABBYY, который резко потерял востребованность и перспективы после появления языковых моделей, особенно опенсорсных).
Можно также предположить, что появятся совершенно новые должности и профессии — что-то вроде совмещённого архитектора и архитектора бизнес-процессов: специалиста, который настраивает системы для автоматического создания и тестирования ПО с одновременным включением в процессы тестирования отделов продаж, дизайна, UI и так далее.
Проекты полностью созданные вайбкодингом
https://youscriptor.com - транскрибация аудио/видео, конспекты лекций по youtube, инструмент для вайб-хайринга и вайб-менеджмента
https://healthymeals.space - телеграм-бот и веб приложения для анализа каллорий, ии-нутрициолог
Комментарии (141)
anonymous
01.11.2025 17:26
Anti2024
01.11.2025 17:26Посмотрим на эту вашу браваду года через три, когда будете искать работу в маке. Программисты, не умеющие работать с ллм, станут медленными и устаревшим мусором.
shornikov
01.11.2025 17:26Если ллм будет способна генерить готовый продукт - уж задание себе она будет в состоянии сгенерить и без вайбкодров. Чисто по каракулям учредителя на салфетке.
aamonster
01.11.2025 17:26Программист, не умеющий работать с llm – оксюморон. Когда ты можешь объяснить код компьютеру на весьма ограниченном и формализованном языке (и, что ещё важнее, можешь понять код и исправить его) и можешь объяснить задачу джуну и поправить его – работа с llm даже не требует обучения.
А когда у тебя в анамнезе 5-10 языков программирования – не так уж сложно "расширить рамки" и включить в них работу с llm.
Вот наоборот хуже: если у тебя нет навыка понимания кода – ты не разберёшься, что llm тебе написал, и не сможешь это использовать.
plustilino
01.11.2025 17:26скорее всего чистота кода уйдёт на второй план, так как непосредственно с кодом люди перестанут работать, а его надёжность будет обеспечиваться автоматическим тестированием
Чистота кода (хорошо бы точно определить, что это) - это более дешевое его обслуживание в дальнейшем. Говнокодовую функциональность может быть проще переписать заново, чем править. Если нет, то много тестов надо будет. Автоматическое тестирование само себя разрабатывает?
TimReset
01.11.2025 17:26А ещё тесты нужно писать понятными, т.е. вот эту пресловутую "чистоту кода" нужно использовать в тестах. Иначе непонятный код будет покрыт непонятными тестами из которых непонятно будет что они вообще что-то проверяют.
rdo
01.11.2025 17:26Тесты тоже будет писать ЛЛМ, так, чтобы они проходили.
OlegZH
01.11.2025 17:26Подождите! А зачем LLM писать какой-то код? Вам нужно решить задачу. Прикладную. Путь LLM сама сделает то, что Вам нужно. Без посредство какого-то кода.
K0styan
01.11.2025 17:26Это тоже подход. Не очень хорошо тиражируемый в силу вычислительной требовательности, но - может и работать.
Я встречал некое OCR приложение, у которого в качестве фоллбэка для сложных случаев была белковая нейросеть - т.е. буквально подключались живые люди, если движок не вытягивал. И это тоже нормальное решение, в т.ч. с инженерной точки зрения.
K0styan
01.11.2025 17:26LLM позволяют и переписывать дёшево, так что это становится сильно меньшей проблемой.
С тестированием несколько сложнее. Описывать требуемое поведение, definition of done - так и так человеку. Но дальше... Сгенерировать систему, которая кидает на вход тестируемому нужные данные и сравнивает выход с ожидаемым - тоже решаемая задача. И опять же, эту систему можно хоть под каждую итерацию заново генерировать.
OlegZH
01.11.2025 17:26В последнее время мне часто попадаются заметки и комментарии о том, что, дескать, гейткиперы (опытные программисты-миллениалы и старше) искусственно ставят препоны и просят решать никому не нужные алгоритмические задачи, тогда как они давно закодированы в библиотеках.
Скажите, пожалуйста, а хорош ли, вообще, подход к программированию, когда всё, что делается, оформляется в виде библиотеки?
Во-первых, когда у Вас есть библиотечная функция, то Вы не знаете до конца, как она работает. У Вас не всегда есть её исходный код. Ситуация с чёрным ящиком суть неизвестность. Тут Вы, хотя бы, насторожитесь и постараетесь проверить работу функции. Если у Вас есть исходный код, то, конечно, Вы можете проверить этот код, но надо всегда делать скидку на компилятор. У Вас никогда не будет того самого компилятора. Да и, вообще, на самом деле, у Вас всегда будет ситуация серого ящика, когда о функции, вроде бы, многое известно, но это всё одно собрание гипотез, приходится верить на слово, а полноценное регрессионное тестирование оказывается невозможным.
Помниться, ещё в книге "Софтостроение изнутри" говорилось о безысходном программировании. Вот было бы здорово, если бы приложение печатало бы свой исходный код! Могла бы и отдельная функция печатать. Для этого надо, чтобы сами функции писались на некотором мета-языке, чтобы в коде явным образом фиксировались принятые предположения, базовые (точнее, базисные, в математическом смысле некоего базиса, из которого можно построить полностью всё пространство). Это и есть чистый код. Код, в котором нет никаких умолчаний. Код, который сам себя документирует. Код, который сам управляет своей дальнейшей трансляцией.
Во-вторых, выбор функции обрекает нас на пребывание в заложниках у её реализации. Выбрали функцию сортировки получили свои варианты работы на различных данных. А был бы использован оператор сортировки, то вопрос выбора способа сортировки можно было бы отложить на потом. Можно было бы в ОС хранить несколько различных конфигураций таких управляющих параметров на разные случаи жизни. Не говоря о такой возможности, как выбор плана выполнения приложения в момент запуска.
В этом смысле, ИИ отчасти решает эту проблему, но ИИ, фактически, работает как кривой "костыль", а для чистоты кода нужно системное решение. Ближе всего к такому системному решению находится аспектное программирование, когда код сопровождается якорями-аннотациями, к которым "прикрепляется" дополнительная функциональность, которая при дальнейшей трансформации (трансляции) программы, может стать частью основного кода. Тут, над кодом надо произвести что-то вроде ортогонализации Грамма-Шмидта, чтобы получить эффективный функциональный базис. Для этого надо будет понять, что такое ортогональность в программировании.
Наконец, в-третьих, что, отчасти, продолжает предыдущее рассуждение, засилие библиотек тормозит развитие самих языков программирования. Языки становятся похожими друг на друга, и вопрос сводится, в итоге, только к выбору определённого синтаксиса, уже готового набора инструментов и развитого сообщества. Между тем, было бы удобнее иметь отельные языки для создания пользовательских интерфейсов, для работы с базами данных, для научных вычислений, для организации тестирования, для документирования и написания компиляторов. Отдельные примеры таких специализированных языков, конечно же, существуют, но у нас до сих пор нет единой парадигмы написания программного кода с соответствующей данной парадигме программной экосистемы.
ИИ пытается заполнить эту нишу, но, за неимением указанной парадигмы, всё что делает ИИ, всегда будет в большей степени суррогатом, хотя, может быть, и имеющим яркую оболочку. Но это, как раз, говорит о засилии в индустрии суррогатного кода, создатели которого мало думают об обоснованности принятых ими решений. В этом смысле, библиотечный подход оказывается, по сути, генератором этого самого программного суррогата...
А всё должно быть наоборот: ИИ должен предложить чёткую, надёжную и достаточно полную классификационную схему алгоритмов вместе с автоматическим выводом допустимых вариантов реализации (на уровне низкоуровневых кодов, форматов хранения данных, сетевых протоколов и обобщённых вычислительных архитектур). И тогда можно будет построить некое пространство программных систем и функцию выбора определённой системы в заданных обстоятельствах и ограничениях.
akod67
01.11.2025 17:26Скажите, пожалуйста, а хорош ли, вообще, подход к программированию, когда всё, что делается, оформляется в виде библиотеки
Мне кажется все эти обсуждения хорошо / плохо происходят на планете ремесленников, которые забывают, что деньги им платит бизнес с другой планеты, которому всё это малость по барабану. Бизнес волнуют косты, а библиотеки - необходимое зло (а может и добро, если написаны более скиловаными людьми, чем собственные гребцы) для сокращения издержек.
Так же и с LLMами будет (да и уже происходит) - их использование будет требовать бизнес, так как они увеличивают скорость разработки в умелых руках. А с неумелыми и упрямыми руками что будет - думаю понятно. Будут скоро примерно в той же роли тётенек из отдела бухгалтерии в начале времён, живущих в своём изолированном мире, а потом вдруг окажется, что этот мир легко аутсорсится куда угодно, достаточно выпилить старые неэффективные, закрученные сами на себя процессы.
OlegZH
01.11.2025 17:26Никто никогда ничего не выпилит. Так и останется. А LLM только покроют этот управленческий туман новым слоем абстракций.
Jijiki
01.11.2025 17:26не знаю, главное чтобы было представление того, что вы хотите в коде например
я сделаю подсказку, может вы хотите текстовый редактор, пробуйте не ждите, не бойтесь дизайна, начинайте делать свой текстовый редактор
K0styan
01.11.2025 17:26Не уверен, что вы именно об этом. Но одно точно скажу: у кучи людей есть "страх белого листа" - это не страх в чистом виде, но психологический барьер. И возможность сделать хотя бы первый прототип, сразу пощупать руками то, что пока только в голове - уже очень большое дело.
OlegZH
01.11.2025 17:26Задачей программиста было написание в принципе работающей программы.
Это не так.
Почему появлялись различные языки программирования? Потому, что учёные (а этим тогда занимались учёные) искали способы наиболее ясного выражения вычислительных концепций. Чего, только, стоят алголо-подобные языки (Pascal, Modula, Ada)! Попробовал бы сегодня кто-нибудь произвести сравнение реализации одной и той же прикладной задачи на "старом" языке и на современном. Я бы с интересом посмотрел бы.
Кроме того, некоторые языки сами выросли на определённых концепциях: всё есть список (Лисп), всё есть связка рекурсивных функций (Форт). И, вообще, всё функциональное программирование.
А ещё имеется целая ветвь: доказательное программирование, сигма-программирование (Ю.Л.Ершов этим в Новосибирске занимался)...
Это сейчас царит подход сделать в принципе работающую программу. Гигабайт памяти не жалко. Дали бы старым программам нынешние объёмы памяти (как дисковой, так и оперативной), мы бы, наверное, удивились как они работают, но тогда не пришлось бы писать новые программы, плодить новые ошибки, и снова переписывать (далее — по кругу). Потому ИИ так и "взлетел", потому что сократилось время появления новой версии ПО. В принципе, работает? Да, работает. А теперь, покажите, пожалуйста, полученный таким образом код. Может быть, он, действительно, то, что нам нужно. Тогда его надо вписывать в учебники и делать основой для образовательных курсов. Очень хочется увидеть такой образцовый код. А то нам всякие гуру описывают, каким должен быть хороший ("чистый", "совершенный") код, а его не видно. Был бы такой код, все бы так писали. Как прописи в первом классе. (Хотя, все всё-равно. потом пишут как курица лапой. Особенно те, кто "в аптеке". ) Был бы такой код, можно было бы издать всемирный справочник, что-то вроде, Камке для дифференциальных уравнений, и пользоваться по мере необходимости. Или всё глобально автоматизировать.
SquareRootOfZero
01.11.2025 17:26Попробовал бы сегодня кто-нибудь произвести сравнение реализации одной и той же прикладной задачи на "старом" языке и на современном.
Rosetta code есть.
OlegZH
01.11.2025 17:26Программист, который пользовался только библиотеками, считался не настоящим, а ламером, «пользователем».
В прежние времена, многое приходилось изобретать самому. Обмен информации не был таким быстрым. Многое, просто объективно, со временем попадает в какую-то библиотеку и становится частью словарного запаса любого мало-мальски профессионального программиста. Сегодня надо знать, что какая-то задача уже имеет некое решение, зато это известное решение с известными свойствами. (Но и не забываем слова, сказанные ранее про "серый ящик". Это суть другая. оборотная сторона проблемы.)
Никто не мешает и сегодня называть постоянного «пользователя» библиотек таким же «ламером». Тогда, правда, придётся называть таковыми довольно много людей, включая и особо продвинутую часть сообщества, включающую т.н. «мид(д)лов» и «сеньоров», которые чрезвычайно глубоко знают целые стеки технологий. Но! Многие ли из них, действительно, способны что-то изобрести поперёк хорошо им знакомого подхода? А как же критическое мышление? Надо же уметь видеть и слабые стороны используемых инструментов! Ведь. отсюда берётся и потребность в создании новых инструментов, включая и новые, более понятные и удобные (в заданных отношениях) языки программирования!
Мы все являемся пользователями ОС. Но ОС не предлагает «из коробки» никакого средства (кроме разве что, командной строки и скриптов) для автоматизации.
Вот, смотрите, текст, который я сейчас пишу, я пишу в специальной форме, которая открывается на сайте. Неосторожное движение мышкой или нажатие не на ту клавишу может заставить браузер "дёрнуться" не в ту сторону, и я потеряю свой текст. Чтобы как-то сохранить этот текст у себя, мне приходится его копировать. Но всё могло бы быть и иначе. Я мог бы писать свой текст в приложении самой ОС, по сути, как текстовое поле локальной базы данных, в которой хранились бы все сообщения, когда-либо мною написанные на всех посещаемых мною в разные годы форумах и площадках. Можно было бы реализовать и такое, но чтобы такое сделать, надо выйти за пределы повседневного использования существующих технологий и изобрести новые протоколы передачи данных и, и, вообще, представить себе интернет без сайтов, как таковых, интернет, который ближе к фидо, бибис и гоферу.
OlegZH
01.11.2025 17:26Требования к программистам поменялись из-за изменения бизнес-требований.
Если быть точным, то эти самые бизнес-требования появились. Изначально, ведь, были только научные задачи. А уже потом подтянулся бизнес. А бизнесу нужна скорость выпуска новой продукции. Хорошо проработанное решение мешает создавать новое: зачем делать чт-то новое, если есть хорошо работающее старое?
Все алгоритмы сосредоточены в библиотеках, и ключевыми качествами стали работа в команде и аккуратность.
Такие требования были всегда. Поменялись сами программисты, и творчества среди них тоже стало меньше. Раньше программист мог задумываться о собственном языке программирования, собственной СУБД или CRM-системе. А сейчас? Некогда даже задуматься об этом.
shornikov
01.11.2025 17:26> А бизнесу нужна скорость выпуска новой продукции.
Разве? А я считал, что хороший бизнес это когда доходы растут быстро, а расходы - медленно.
Новый код - это расходы. Рефакторинг - ВООБЩЕ расходы в пустоту.
Выгодно, это может быть только в одном случае - если вы продаете софт.
youscriptor Автор
01.11.2025 17:26Бизнес думает о прибыли, а не о коде, чистота кода ему вообще до лампочки, это больше для удобства самих программистов.
4wards1
01.11.2025 17:26А прибыль как считается, не напомните? Я всегда считал, что это доходы минус расходы, а говнокод - это огромные расходы из-за быстрого роста стоимости каждой новой фичи.
Видимо, я очень сильно заблуждаюсь. Расскажите, пожалуйста, как всё устроено на самом деле.
youscriptor Автор
01.11.2025 17:26Все зависит от жизненного цикла. Если вы лепите MVP и проверяете рынок вам говнокодистость вообще до лампочки. Не все фичи будут приняты рынком и заказчиком. И т.д. требования к поддерживаемости и расширению кода далеко не всегда ключевые. Часто важнее скорость и цена.
4wards1
01.11.2025 17:26Но ведь изначально вы чётко говорили о бизнесе в целом, а теперь оказывается, что речь уже только про MVP для проверки гипотезы?
Так тут же соотношение хорошо если 1 к 10 (на 1 разраба, пилящего MVP, приходится 10 разрабов, развивающих зрелый продукт). А скорее всего ещё хуже.
Безусловно, если ваша сфера деятельности - штамповать телеграм-ботов для кальянных, то конечно, вайбкодинг рулит, все дела. У заказчика бюджет 30 тысяч и те в рассрочку. А вот давайте мы с вами посмотрим на РЕАЛЬНЫЙ бизнес, в котором вращается 90% всех денег в IT: финтех, ритейл, телеком, промышленность. Там 1 задача может занимать десятки и сотни человекочасов. И что говорите, что для них говнокод - это вообще не проблема, да? :)
Ну то есть придут нам новые правила резервирования товаров на складах, и будем мы вместо 20 часов вносить эти правки 200 часов, потому что у нас сотни тысяч строк разношёрстного говнокода, в котором никто не ориентируется, потому что на этапе написания никто в него не вникал. Зато когда мы пилили MVP, мы его сделали за 1 месяц, а не за 3. Звучит очень выгодно, нужно внедрять в каждый бизнес безотлагательно.
akod67
01.11.2025 17:26это как? от затраченных лишних двух недель на дополнительные слои ООП и прочей луковицы появятся кнопки на сайте?
K0styan
01.11.2025 17:26А тут лучше не гадать, а сходить к чуваку "из бизнеса" у себя же на работе и с ним поговорить)
Скорость, а точнее time to market - очень важная штука. Сделали дополнительную кнопку "продать" на страничке на месяц раньше - получили за этот месяц дополнительную тыщу покупателей.
OlegZH
01.11.2025 17:26Выгодно, это может быть только в одном случае - если вы продаете софт.
Вот компании и продают софт. Для того, чтобы продавать, нужно всегда делать новый. Это может быть и хорошо, если таким образом, методом последовательных приближений делается продукт, который действительно нужен. Но это может быть и плохо, если втюхивается нечто сомнительного качества, а конкуренты медленно затираются, чтобы не было выбора. Каждая компания выбирает сама свой путь.
akod67
01.11.2025 17:26Компании нынче продают не софт, а услугу, причём стараются делать это по подписке. И у услуги понятие "качество кода" прослеживается ещё сложнее, чем у коробки.
shornikov
01.11.2025 17:26Кажется у вас программисты - это исключительно отдельная независимая финансово структурная единица.
У нас, например, склад - и прибыль компании генерируют упаковщики заказов.
А я, как разработчик, - только расходы. Никаких продаж софта, никаких конкурентов.
killyself
01.11.2025 17:26Разработчик, скорее всего, генерирует прибыль путем замены расходов на неавтоматизированный процесс на автоматизированный + расходы на автоматизацию. Или если он сайт компании пилит - значит приводит клиентов, участвует (пусть и немного сбоку) в цепочке продаж и генерации выручки. Не генерирует прибыль какой-нибудь сисадмин, который поддерживает систему в рабочем состоянии. Ну или уборщица склада.
akod67
01.11.2025 17:26Достаточно осознать, что в годовом отчёте компании нет слова "код". Хорошо, если он там будет в виде графы IP. Соответственно бизнес такой категорией не думает. Если CTO подумал - ок, но это ДАЛЕКО не везде.
OlegZH
01.11.2025 17:26Сейчас, с появлением языковых моделей, мы видим очередную смену парадигмы: часть процессов кодирования стала беспрецедентно дешёвой. То же самое можно сказать про рефакторинг и анализ кода.
Давайте, вместо общих слов, возьмём какую-нибудь прикладную задачу и рассмотрим её различные решения и сравним их с тем. что предлагает ИИ. Если ИИ предлагает что-то дельное, то весь этот кипишь вокруг ИИ можно расценивать как проявления страха большого числа людей, к которым, наконец, пришёл оценщик (как этот бычок из детской сказки, который всех считал), и сейчас общество узнает реальную цену разработчикам. Если есть какие-то внятные принципы разработки, то почему мы им все не следуем, и не изучаем прямо в школе? Если же ИИ предлагает какую-то лажу, хотя бы и яркой упаковке (когда, на первый взгляд, всё работает, то есть — работает в принципе), то это означает (опять же!), что обучающая выборка содержит множество артефактов, то есть — общепринятым является суррогатное программирование. Куда ни кинь — всюду клин!
Всё это не означает, что настоящее программирование должно быть дорогим. Но оно обязательно должно рождаться в результате приложения определённых усилий на то, чтобы понять задачу, на то, чтобы увидеть различные варианты реализации, и выбрать из них наилучший (или предложить некую комбинацию решений, когда, в зависимости от контекста, выбирается свой вариант).
А что Вы скажете про анализ кода и рефакторинг? Зачем Вы хотите проанализировать код? Для чего Вам нужен рефакторинг?г
akod67
01.11.2025 17:26Берите конкретику. Некоторые кейсы решаются LLMами на раз. В нашей компании был опыт переезда с MSSQL на Postgres за месяц, о чём даже боялись до появления LLM думать - куча легаси хранимок, которые даже понять сложно, не то что переписать. А LLMке в этой субстанции ковыряться не страшно. Берёт и делает. Задачи переведи с одного языка на другой делаются на раз.
OlegZH
01.11.2025 17:26Сложно сказать, как это будет выглядеть в дальнейшем, но скорее всего чистота кода уйдёт на второй план, так как непосредственно с кодом люди перестанут работать, а его надёжность будет обеспечиваться автоматическим тестированием.
Подождите! Как это обеспечиваться? Что же такое чистый код? Разве надёжность и чистота — это не две оборотные стороны одной медали?
Допустим, где-то в программе написано:
s = input()Допустим, выбран язык программирования Python. Здесь приведён пример чистого кода? Я, конечно же, утрирую. Но, однако, продолжим. Что мы вводим? Интересный вопрос! Это строка или число? Мы знаем, что функция
input()возвращает символьную строку. Но такая строка может содержать и число! Но мы хотим застраховаться от ошибок. Мы попытаемся написать что-то вроде.s = input() try: i = int(s) except ValueError: ...Это уже чистый код?
А если мы захотим получить число с плавающей запятой? Переделывать код? А может быть, можно переделать саму функцию
input(), чтобы она сразу возвращала значение нужного типа? А (кстати!) а от чего зависит тип возвращаемого значения? Мы могли бы сразу написать, как в Pascal'е:i: integer i = input()Это как? Ещё чище? И где, и какое тестирование здесь проводить?
youscriptor Автор
01.11.2025 17:26надежность - это покрытие тестами, а чистота - это для поддержки людьми. Не обязательно надежный код может быть читым
OlegZH
01.11.2025 17:26Чистый код (если, такой код, вообще, может быть написан) не нуждается в поддержке. В нём всё понятно. Он полностью управляем. И, кстати, полностью покрываем тестами. Мы никогда не сможем проверить все возможные входные данные, но мы мы можем проверить важнейшие классы входных данных.
Хорошим примером чистого кода является математика.
Вспомните школьную математику. Вы хотите решить уравнение или исследовать функцию. Вы понимаете. что у функции есть область определения. Если Вы об этом забудете, то Вы рискуете получить несуществующие корни. И при изложении материала, всегда явно указывается, что из чего и как определяется, разбираются пограничные случаи (например, что у нас в нуле, как расшифровывается неопределённость, вроде 0/0)...
Не стоит делать упор на покрытие тестами. Борьбы за надёжность начинается с самого начала работы над приложением, и покрывать тестами нужно уже сами исходные требования, чтобы устранить основные причины возникновения проблем ещё до начала самого кодирования. Это азы тестирования.
akod67
01.11.2025 17:26Ну вот с какого? Чистым кодом можно реализовать абсолютно неправильный бизнес кейс и именно бизнес кейс нуждается в долговременной поддержке. Меняется кейс - требуется переписывать код, и вот именно там некая "чистота и универсальность" может окупиться. Только вот правда жизни такова, что бизнес кейсы часто меняются с викидыванием кода и программистов вообще с заменой на что-то своё. Например более крупный конкурент покупает менее крупного и постеменно замещает его софт своим. 3 раза на моей практике такое было.
OlegZH
01.11.2025 17:26Меняется кейс - требуется переписывать код, ...
Вот меня и интересует, почему меняется кейс? Для меня это — краеугольный вопрос разработки: можно ли писать код (и, вообще, создавать ПО) так, чтобы не надо было ничего переписывать? "Вот, в чём вопрос." (с)
akod67
01.11.2025 17:26Потому что мы не пишем бизнес, мы пишем ПОД бизнес. А бизнес не статичен во времени, если только он не в стадии помирания.
K0styan
01.11.2025 17:26Даже в космических миссиях, которые длятся годами, и в случае которых обновление ПО - та ещё задачка, были случаи возникновения новых задач и удалённых апдейтов. В большинстве приземлённых задач ситуация в разы динамичнее.
shornikov
01.11.2025 17:26ИМХО.
Те случаи, которые на слуху, типа Вояджера: Миссия завершена, код был написан и всё. То, что потребовалось обновление, так это они на "старом железе" решили еще поработать. Изначально такой задачи не было.
Прикиньте - у вас миссия на 10+ лет, а программисты каждый год переписывают код того, что уже отлетело на миллионы километров от Земли на актуальные фреймворки. Ну а вдруг понадобится? И все это за счет налогоплательщиков.K0styan
01.11.2025 17:26А при чём тут "а вдруг понадобится?" Я как раз про прямо противоположное говорю - именно требования могут меняться, даже если тыщу раз их утвердили. Даже если объект этих требований за миллионы км улететь успел.
shornikov
01.11.2025 17:26Раз требования могут измениться (вот вдруг и понадобилось) - вы считает хорошим планом поддерживать 30-летнию кодовую базу в актуальном состоянии?
OlegZH
01.11.2025 17:26А что? Если 30-летняя кодовая база позволяет решать практически любую современную задачу за малое (по отношению к современной кодовой базе, которую приходится создавать по ходу реализации проекта) время, то лучше пользоваться и поддерживать старую базу.
OlegZH
01.11.2025 17:26На передний план выйдут архитекторы и бизнес-аналитики, причём ключевым навыком будет именно построение самих моделей бизнес-процессов в разработке ПО.
Архитекторы никогда не будут на первом плане. Всякая архитектура предполагает строго последовательный способ создания любой системы. Водопадная модель! Сначала составляется полный список требований. он закрывается. Затем, по нему делает проект, где для каждого вопроса предлагается решение (ещё только "на бумаге"). И уже когда на все вопросы получены какие-то ответы, начинается, собственно кодирование. В реальности, бизнес навязывает другую модель разработки, когда, вмешательства оказываются возможны на любом этапе. В результате, полученное "здание" приходится снабжать "костылями", поскольку все элементы оказываются довольно далекими от расчётных значений. Предсказать поведение такой "системы" довольно трудно. Если, вообще, возможно.
С точи зрения архитектуры, чистый код — это такой код, который можно один раз написать и растиражировать везде. А у нас вся история программирования — это история разработи и реализации многочисленных библиотек, которые благополучно отправляются на свалку всемирной истории. Было бы качество — мы бы сейчас, могли бы писать на Хабр, например, при помощи приложения, написанного на Turbo Vision. Текстовый режим... У него были преимущества. И в смысле безопасности тоже. Не говоря о том, сколько проблем не надо было решать (там, с HTML/CSS/JavaScript).
akod67
01.11.2025 17:26Водопадная модель! Сначала составляется полный список требований. он закрывается.
Вы из какого года пишете? Agile появился именно потому, что водопада не существует в реальной жизни проектов крупнее мелкой консольной утилиты, если не рассматривать аквариумы типа NASA с одноразовой выкаткой кода в прод.
OlegZH
01.11.2025 17:26Это и есть проблема. Корень проблемы. Хорошо можно сделать только последовательно. Не перескакивая через этапы. (Поэтому поводу, даже, сказка есть. Называется "12 месяцев".))) Все эти гибкие способы разработки они вполне естественны для раскрутки какого программного кода из состояния отельных разрозненных заготовок до полноценного рабочего состояния. А ситуация, когда клиент "вспоминает", что ему нужно что-то ещё, плохая ситуация. Да, такая ситуация является общепринятой. Но это, что называется, увы и ах. А в нормальной ситуации, для хорошего дома всегда возводится прочный фундамент. Для программных систем таким фундаментом является набор базовых библиотек (программная платформа) и проектная документация, где на каждый вопрос по проекту даётся ответ (выбирается способ решения, способ сопряжения и оцениваются риски).
akod67
01.11.2025 17:26У исполнителя свои проблемы, у бизнеса - свои. Кто платит деньги, тот и заказывает. Возникающее по мере появления результатов понимание, а что собственно надо делать - реалии жизни и софтовость софта этому способствует, ибо относительно несложно переделать сделанное, в отличие от той же стройки.
OlegZH
01.11.2025 17:26Как выясняется, все эти переделки довольно дорого обходятся. Вопрос для меня в том, почему практически никогда с самого начала не удаётся понять, а что, собственно, надо делать?
akod67
01.11.2025 17:26Это тупо невозможно в мало мальски большом проекте. Основной каркас накидать да, а цвет обоев и в процессе можно выбрать. С парочкой дополнительных перегородок. И дополнительной вертолётной площадкой. И бассейном на крыше. И вообще в другом городе.
michael_v89
01.11.2025 17:26почему практически никогда с самого начала не удаётся понять, а что, собственно, надо делать?
Наверно по тем же причинам, по которым вы сами не всегда с самого начала понимаете, что, собственно, надо делать? Почему вам можно ошибаться, а от других вы требуете идеальных действий?
akod67
01.11.2025 17:26Именно заказчик - основная энтропия в разработке. Семь красных линий и одна котиком.
OlegZH
01.11.2025 17:26А кто заставляет исполнителя торопиться писать код?
akod67
01.11.2025 17:26Эм... Желание выписать счет за трудочасы - желание норм или не норм? Или будем сидеть на скамейке и сражаться за хз кому нужные идеалы?
OlegZH
01.11.2025 17:26Есть очень просто вопрос. Возьмите какой-нибудь свой работающий код. Как Вы его писали? Сколько шишек набили? И! Могли ли Вы действовать так, чтобы написать примерно такой же код, но без набивания шишек и, возможно, за меньшее время? Вот в чём вопрос. (с)
akod67
01.11.2025 17:26А может быть мне нравится процесс набивания шишек? Особенно, если за него ещё и платят =) А потрачу в 3 раза меньше времени - в 3 раза меньше заплатят. В этом плане LLM конечно зло =)
outlingo
01.11.2025 17:26Опять эджайл против водопада? Ну не бывает в чистом виде ни того ни другого. Любой сколь-нибудь крупный проект начинается с ватерфолла в виде постановки задачи, архитектуры, выделения компонентов и моделей данных, разделения на сервисы/компоненты и реализации оных.
А эджайла там остаётся правило "мы можем вкинуть фичу и приоритезировать ее, соответственно сдвинув остальной граф сроков реализации фич".
Но опять же вкинутые фичи делаются так чтобы не переделывать их потом - то есть им делается тот же цикл мини-ватерфолла, и реализации общих щавтсимостей - разве что "продуктом" становится сама фича.
Так что эджайл нормальный это не работа без ТЗ, а по сути распиливание одного монолитного процесса на множество небольших субпроцессов. И если для фичи вам нужен компонент который сейчас отсутствует, то он становится отдельной фичей, которая объявляется блокером и пилится вне приоритетов.
K0styan
01.11.2025 17:26сколь-нибудь крупный проект
Не всё существует в виде проектов. Есть ещё и продукты. У которых требования появляются и отмирают постоянно в течение жизненного цикла. Иногда очень резко - как, например, всем ритейлам в 2020-м пришлось очень быстро запиливать онлайн-продажи и доставку. Но даже если нет такого форс-мажора, ситуации когда сегодня вверху бэклога одно, а завтра оказывается, что надо достать другое - вполне реальны.
И да: называть серию микроводопадиков по фиксированному набору требований эджайлом - это большая ошибка. Эджайл в принципе не модная самоцель, это просто способ выжить в ситуации быстро меняющихся внешних требований.
OlegZH
01.11.2025 17:26Иногда очень резко - как, например, всем ритейлам в 2020-м пришлось очень быстро запиливать онлайн-продажи и доставку.
(с вызовом) А что случилось в 2020 году?
akod67
01.11.2025 17:26Ещё раз. Agile ПОЯВИЛСЯ, так как водопад не работает. Всё. Других утверждений не было.
OlegZH
01.11.2025 17:26Почему не работает?
akod67
01.11.2025 17:26По определению. И по факту - нет смысла пыжиться и продумывать всё заранее до последней кнопки. Всем проще делать итерациями. Да, за непредсказуемый бюджет. Но денег много где как грязи. Выделили условный лярд в год на ИТ разработку и всё, можно аджилить и не напрягать сильно мозги макулатурой.
OlegZH
01.11.2025 17:26Итерации будут всегда. Но, в целом, нужно обязательно всё продумывать. Непродуманность потом и оборачивается значительными тратами этого самого бюджета.
akod67
01.11.2025 17:26Это просто невозможно в условиях, когда заказчик сам не знает, чего хочет. А узнает, только когда пощупает первые MVP. И то не факт. Такое сплошь и рядом.
OlegZH
01.11.2025 17:26Это всё — констатация печальных фактов нашей повседневной обыденности. Но это не значит, что не надо думать о лучшем.
akod67
01.11.2025 17:26Я не согласен, что написание талмудов документации с невозможностью изменений посередине - это лучшее. Опять же, agile в том числе и про это. У меня, в результате первой работы, где были аналитиками написанные талмуды с требованиями к разработке выработалось стойкое презрение к этому виду деятельности. Ну не могут люди на берегу руководить экипажем подводной лодки.
akod67
01.11.2025 17:26То, что люди, которые не программируют, выдвигают требования к тому КАК программировать и что делать. Ну это ладно, личное. бОльшая проблема - то, что уже на середине разработки документация катастрофически деградирует относительно реалий
новые требования (да, заказчику не скажешь пошёл нафиг с новыми требованиями, приходи после завершения проекта), особенно если он готов платить за change requests
невозможно всё продумать, многое додумывается на местах
пишут документацию часто совсем не эксперты. хорошо, если они сами хоть что-то серьёзное программировали, чаще нет.
OlegZH
01.11.2025 17:26Представим, что чистый код существует. Это значит, что можно в интернете завести сайт, где будет этот самый чистый код храниться. Каждый отдельный алгоритм будет иметь свой уникальный идентификатор. И тогда можно будет формировать свою программу, ссылаясь на это хранилище. Все будут пользоваться общим кодом, а не самописными конструкциями.
michael_v89
01.11.2025 17:26Это значит, что можно в интернете завести сайт
можно будет формировать свою программу, ссылаясь на это хранилище
Все будут пользоваться общим кодомOlegZH
01.11.2025 17:26Замечательный комментарий! Который очень хорошо говорит о том, насколько мне трудно донести сою мысль. Я оказался совершенно не понятым.
Я говорю не о каком-то хранилище, куда люди добровольно выставляют свой код (может быть, даже, очень хороший и востребованный) на всеобщее обозрение, а про ресурс, который является базой данных работающего кода (то есть — универсальным репозиторием), с которого постоянно загружается (тиражируется) код. Смысл такого репозитория в том, чтобы:
Задать для всех единую систему координат, чтобы все разработчики разговаривали на одном языке, в одних и тех же терминах и алгоритмах.
Создать базу данных проверенного кода или, как любят иногда здесь выражаться, покрытого тестами.
Указать проблемные места, на доработку которых следует направить силы разработчиков.
Гитхаб, разумеется, во многом, позволяет достигать похожих результатов, но даже этот сайт не является искомым решением, и более концентрируется на п.3.
michael_v89
01.11.2025 17:26В чем разница между github и искомым решением? Я ее не замечаю.
все разработчики разговаривали на одном языке, в одних и тех же терминах и алгоритмах
Они и так это делают, даже github тут ни при чем.
Представим, что чистый код существует. Это значит
Каждый отдельный алгоритм будет иметь свой уникальный идентификатор.Нет, не значит. Чистый код не задает правила для единственной реализации. Для некоторого логического алгоритма может быть много разных реализаций, которые соответствуют критериям чистого кода.
OlegZH
01.11.2025 17:26Разработчики всегда пользуются какими-то своими библиотеками. В каждом языке программирования есть свои библиотеки. В СУБД — свои. Все разговаривают на разных языках, используют различные реализации. Трудно сравнивать. Было бы удобнее ссылаться на что-то одно и иметь в виду конкретную реализацию.
michael_v89
01.11.2025 17:26В каждом языке программирования есть свои библиотеки.
А почему вы думаете, что от чистого кода на одном языке все другие языки вдруг исчезнут? Ваш код библиотеки на Java может быть сколько угодно чистым, но если у меня проект на PHP, то мне нужна библиотека на PHP, а не ваша реализация на Java.
Было бы удобнее ссылаться на что-то одно и иметь в виду конкретную реализацию
А при чем тут чистый код? Правила написания кода, который можно считать чистым, не ограничивают количество реализаций. А в некоторых случаях более важна производительность кода, даже если он не соответствует некоторым из этих правил.
OlegZH
01.11.2025 17:26Вы куда-то уходите в сторону. Я говорил о том, что все разговаривают на различных языках программирования не в смысле самих языков программирования, а в смысле трудностей понимания, в общечеловеческом смысле, просто программирование приводит к тому, что, фактически, мы пользуемся различным ПО, хотя подразумеваем одно и то же.
Чистый код — это код, который не надо править и который можно смело использовать. Это вещь с известными хорошо проверяемыми свойствами (включая и производительность).
Вот, Вы. Вы можете писать код так, чтобы его не надо было мучительно править, исправляя собственные ошибки? Вот сейчас я учусь писать код. И меня очень занимает вопрос, откуда берутся ошибки, и можно ли мыслить так, чтобы запускать редактор кода уже тогда, когда в голове уже сложилось практически всё, что надо. В этом смысле, идеальный программист — это тот, который сначала долго думает, а, потом, быстро делает.
michael_v89
01.11.2025 17:26Чистый код — это код, который не надо править и который можно смело использовать.
С чего это вдруг? Это не входит в критерии чистого кода.
Это вещь с известными хорошо проверяемыми свойствами (включая и производительность)
Ну и что с того, что я проверил, что производительность библиотеки, написанной чистым кодом, для моей задачи недостаточна? Мне-то надо, чтобы работало быстрее.
программирование приводит к тому, что, фактически, мы пользуемся различным ПО, хотя подразумеваем одно и то же.
И? При чем тут чистый код-то?
В этом смысле, идеальный программист
А идеальные программисты тут при чем?
Оффтоп обсуждать мне неинтересно. Вы написали про сайт, я вам сказал, что такой сайт уже есть. Вы сказали, что он не подходит, но на вопрос почему ответить не можете.Вот сейчас я учусь писать код. И меня очень занимает вопрос, откуда берутся ошибки
Это вас надо спрашивать, почему вы сначала неправильно написали. Откуда другие люди должны это знать?
можно ли мыслить так, чтобы запускать редактор кода уже тогда, когда в голове уже сложилось практически всё, что надо
Вот когда сформулируете ответ на предыдущий вопрос о причинах, тогда можно будет и ответить, можно или нельзя их избежать.
OlegZH
01.11.2025 17:26С чего это вдруг? Это не входит в критерии чистого кода.
Для меня это так. Если для других всё иначе, то я с этим ничего не могу поделать. Хотелось бы, конечно, всегда говорить об одном и том же. Но каждый акын дует в свою дуду.
Ну и что с того, что я проверил, что производительность библиотеки, написанной чистым кодом, для моей задачи недостаточна? Мне-то надо, чтобы работало быстрее.
Уберите из Ваших рассуждений словосочетание "чистый код". Вы хотите получить некий код. У Вас два варианта. Взять уже готовый. Или написать самому. Какой выберете?
Все хотят быстрее. Но мы знаем, что многое зависит от самих данных. Отсюда вопрос: на каких данных (быстрее)? И... быстрее чего?
И? При чем тут чистый код-то?
Всегда мечтается о том, что что-то можно один раз написать и пользоваться.
Вы написали про сайт, я вам сказал, что такой сайт уже есть. Вы сказали, что он не подходит, но на вопрос почему ответить не можете.
ВП:НЕСЛЫШУ
А что Вы можете сделать с ГитХабом?
Это вас надо спрашивать, почему вы сначала неправильно написали. Откуда другие люди должны это знать?
Всегда надеешься на то, что более опытный человек умеет лучше организовывать свою работу. Да и, вообще, опытного человека всегда интересно послушать.
akod67
01.11.2025 17:26У математиков такая база доказанных теорий есть со спецсофтом, где переиспользуешь в своих доказательствах уже доказанные ранее другими "блоки". Лень пруфы искать, в подкасте у Лекса с Теренсом Тао слышал.
OlegZH
01.11.2025 17:26Математика сама есть доказательная база и пример хорошего подхода. Большинство книг по математике дают все необходимые определения и теоремы (всё своё ношу с собой).
akod67
01.11.2025 17:26Но она в плане чёткости требований и проверяемости результата всё таки кардинально лучше.
OlegZH
01.11.2025 17:26А всё почему? Потому что она состоит из исходников. Мы долгие годы в вузах изучаем исходники. Потом пользуемся. Да и само строение математики. Математика — это язык! Сам себя объясняющий и сам себя проверяющий. В теоремах водятся посылки, к теоремам ведёт чёткая мотивация (зачем).
akod67
01.11.2025 17:26Главное - в математике как правило есть чёткий результат, который можно и нужно валидировать. Если в программировании условный алгоритм сортировки можно абсолютно полностью покрыть тестами, то условный респонс тайм распределённой системы под плавающей нагрузкой покрыть и детерменировать вообще - вопрос сложности совсем других порядков.
Andrey_Gromov
01.11.2025 17:26Время идет, прогресс не остановишь. И с течением времени всегда меняются подходы к разработке. Такова жизнь и с этим ничего не поделаешь.
fixikus
01.11.2025 17:26Ну вот и хотелось бы уже пройти этот этап поскорей, а то по вашей логике получается, что все хайповые подходы к разработке были хороши, вспомнить те же микросервисы - как только расхайпились, то пихали их куда только можно не задумываясь ни о чем, итог предсказуем - "кусок грязи".
DarthVictor
01.11.2025 17:26В последнее время мне часто попадаются заметки и комментарии о том, что, дескать, гейткиперы (опытные программисты-миллениалы и старше) искусственно ставят препоны и просят решать никому не нужные алгоритмические задачи, тогда как они давно закодированы в библиотеках. Это — с одной стороны. С другой стороны — ругают LLM, потому что код там не всегда чистый и, дескать, программирование с LLM — это не программирование вовсе, и навыки такого программиста ничего не стоят.
Неудачный пример, поскольку именно алгоритмы общего назначения, которые так любят на собеседованиях, LLM-ки пишут хорошо. У них проблемы с написанием реального кода, которому приходиться взаимодействовать с остальным проектом.
Вообще LLM-ка — это как раз идеальный проходитель (или проходимец?) алгособесов. И появление LLM-мок как раз показало, что все эти требования к программистам решить задачи на листочке, это как требования к автомеханику поменять колесо при помощи только балонного ключа. И тут резко выяснилось, что андроиды делают это лучше. Хотя в реальной работе для смены колеса и кожаный и электронный автомеханик возьмут домкрат.
youscriptor Автор
01.11.2025 17:26Алгособесы - это тест не фундаментальные знания в IT и больше про умение думать. Сейчас в библиотеках, и нужны массовые исполнители, где больше не про ум, а про усидчивость и аккуратность. Поменяются требования бизнеса (который вам не друг, а инструмент как выжать из вас максимум за минимум денег) - поменяются и требования к работничкам
akod67
01.11.2025 17:26Вообще ни разу не про думать. Ну никто не изобретает исполнение этих алгоритмов из головы, заучивают в том или ином виде. Думающий человек будет выглядеть тугодумом на фоне конкурирующих кандидатов, бодро строчащих код на листочке под выученный алгоритм.
youscriptor Автор
01.11.2025 17:26Не изобретает, но адаптирует под задачу. Математика ведь тоже не про зубрежку, хотя на прикладном уровне никто теоремы не передоказывает с нуля
akod67
01.11.2025 17:26Контекст свыше - собесы. На экзамен ПДД по теории в конечном итоге билеты тоже заучиваются, работает визуальная память. Хоть и пройдена теория, но те слои мозга не задействуются, нет необходимости, если на автомате визуалка выдаёт правильный ответ. Так и тут.
youscriptor Автор
01.11.2025 17:26Собесы организовывают обычные программисты, каждый исходя из своего понимания о профессии. Кто в чем силен, то на то и напирает.
fixikus
01.11.2025 17:26Это бред полный, картинки в билете и ситуации в жизни не всегда точно совпадаю, поэтому нужно именно понимать правила, иначе галлюцинировать начнете
fixikus
01.11.2025 17:26Вообще очень интересно, кстати. Получается, что llm при обучении дают только практику, обучая на куче примеров, при этом теорию она сама должна выработать. Как то странно это.
Это даже сама llm понимает, иронично)
«Практика без теории слепа» — это часть знаменитой цитаты Александра Васильевича Суворова «Теория без практики мертва, практика без теории слепа». Она означает, что без понимания теоретических основ, практическая деятельность становится бессмысленной и неэффективной, поскольку человек не знает, почему он что-то делает и как сделать это
Без теории, практика — это просто слепое следование инструкциям или привычкам, без понимания сути
akod67
01.11.2025 17:26Ну это не странно, если учесть, что на нынешнем этапе развития ПОНИМАНИЯ в нашем понимании (извините за тавтологию) у ЛЛМ просто нет.
akod67
01.11.2025 17:26Собесы и экзамен - это не жизнь и подходы к подготовке поэтому разные по эффективности.
fixikus
01.11.2025 17:26Блин, без чистоты в коде ваше ПО рано или поздно превратиться в "кусок грязи". Llm, которая в трех соснах плутает, эту ситуацию только усугубляет.
zubrbonasus
01.11.2025 17:26Я считаю что хайп на (де)генеративные нейросети пройдёт и их применение будет ограничено некоторой необходимостью использования. Иначе человек превратится в обезьяну и начнёт снова учится пользоваться дубиной и каменным топором с повторением уже пройденных жизненных процессов.
gun_dose
01.11.2025 17:26Плюсанул статью, потому что автору удалось создать просто идеальную иллюстрацию эффекта Даннинга-Крюгера.
amazingname
01.11.2025 17:26Автоматизированное тестирование не поможет, потому что в запутанном коде запутается и сам AI тоже.
Наоборот, теперь мы будем иметь объективный критерий чистоты кода: это код который AI легко дорабатывает. Хотя, да, критерии чистоты при этом могут несколько измениться.
Что касается сегодняшнего момента, то я например перестал заботиться о некоторых критериях чистоты кода тестов. А зачем, если их AI пишет и сам же переписывает.
SWATOPLUS
01.11.2025 17:26Я всё жду не дождусь, когда мне LLM будет генерировать нормальный код без утечек памяти. Я всего-лишь хотел сделать node-addon для работы с окнами на windows linux mac.
Две функции: вывод список окон и поиск активного окна.
Но нет, LLM не решает задачу. Мне просто нужен любой говнокод без архитектуры и чистоты, который я смогу прикрутить к node. Но память течет, функции не работают. Приходиться самому задавать архитектуру, говорить какие системные вызовы использовать, поправлять алгоритмическую сложность, руками тестировать, искать утечки памяти.
Для меня польза в том, что я не знаком со swift для macos и не привык к синтаксису, быстрее исправлять ошибки компиляции через llm, чем самому. А вот с c++ такой роскоши нет, он тут даже список аргументов не всегда понимает, фикси сам мои галлюцинации.
youscriptor Автор
01.11.2025 17:26А на rust пробовали, который принципиально не течет? Какую модель использовали?
itstranger
01.11.2025 17:26Если отвечать, на вопрос, то конечно чистый код будет. К слову, чистый код, это не только про пробелы и отступы.
Почитав комментарии вайбкодеров долго смеялся над их позицией. Мол нейронка любой код понимает, поэтому чистый код нужен только программистам...
Чистый код будет всегда, просто поменяется в будущем под особенности работы нейронок. LLM хорошо понимает именно языковые конструкции, которыми языки программирования и являются, следовательно в будущем, чистым кодом будет тот, который не только понятен и удобен человеку, но и так же понятен и удобен самим LLM. Поэтому не надейтесь, что стандарты куда-то исчезнут. Они уже активно формируются.
В комментариях, активно пишут, что программисты не нужны, сейчас вторые 90-ые и время возможностей. Скоро мол вайбкодеры заменят программистов, что читать смешно.
Вас заменят ещё быстрее, чем нас. Как раз, потому-что вы умеете только табать, без понимания тех. контекста. Для вас нейронки это не понятный инструмент, а бог из машины, что работает на магии.
Помню, когда только появились background агенты, тот же codex, многие таберы писали: "Выглядит круто, но что такое github? Консоль какая-то, этим как пользоваться, то вообще? А где скачать?". Сейчас бэкграунд агенты не редкость и уже часть таберов отсеялось. Потом агенты стало популярно деплоить локально и тут таберы офигели с docker и контейнеризации. Что-то таб не помогает разбираться, сложна.
Уже появились первые паттерны для работы с нейросетями. Например, как лучше передавать/получать данные в чатах. Какие температуры использовать, как правильно организовывать тот же RAG и как правильно использовать MCP. Дальше разработка вместе с нейросетями будет только усложняться и это нормально. Следовательно, станут востребованы настоящие программисты, с базой знаний/скилов, которым будет довольно просто будет во всём разобраться. Намного легче, чем человеку без тех. базы. Так что кардинально ничего не поменяется, а порог входа только вырастет.
youscriptor Автор
01.11.2025 17:26Вы сами себе противоречите. С одной стороны пишите что вайбкодинг никогда не заменит обычный, потом пишите что он вытеснит. Вайбкодинг не подразумевает что вайбкодер хуже разбирается в программировании - а только то что его проивзодительность выше. Я полностью перешел на вайбкодинг и только благодаря этому продолжаю зарабатывать. Хотя вскоре доходы вайбкодеров упадут - просто пересчитаю нагрузку и все. А обычное программирование станет нерентабельным.
fixikus
01.11.2025 17:26Вайбкодер ничего не хочет понимать в коде, да и впринципе мозг загружать не хочет, он хочет кружевные тру..кхм.. и общаться с llm, в код он впринципе не лезет, а задрачивает нейросеть, чтобы та все сделала. Вы считаете у такого подхода будущее есть? На мой взгляд будущее вайбкодера это быть рабом llm
youscriptor Автор
01.11.2025 17:26ну так вы описали обычную наемную работу. бизнесмен тоже не хочет ничего делать а нанять людей что бы ему сделали и желательно бесплатно
fixikus
01.11.2025 17:26Ну если у него деньги есть, почему нет? Вас зависть гложет?
youscriptor Автор
01.11.2025 17:26ну а вас что зависть гложет, что кто то вайбкодингом занимается? По сути этот тот же бизнес, только не человека нанимаешь что бы он за тебя сделал, а LLM
fixikus
01.11.2025 17:26Вы как обезъяна, с ветки на ветку. Без обид. Тема статьи: чистота кода. Рассматривая вайбкодинг с этой стороны - то это выгребная яма. Вайбкодинг как бизнес - не вопрос, зарабатывайте деньги не здоровье, это ваша ответственность
itstranger
01.11.2025 17:26Вайбкодинг не подразумевает что вайбкодер хуже разбирается в программировании
В том, то и дело, что по определению это и есть подход, когда пользователь ничего в коде понимать не должен, а нейронка всё делает за него.
Программист, использующий нейронки в работе, не равно вайбкодер. Так что в моих словах противоречия нет.
michael_v89
01.11.2025 17:26Будет ли важна чистота кода в ближайшем будущем
"В ближайшем будущем" она еще будет важна, потому что будут нужны программисты, которые могут в нем разобраться и поправить вручную, когда нейронка не справляется. А в будущем чуть подальше, когда нейронка будет со всем справляться сама, не нужны будете уже вы. У вас есть только то, что есть в настоящем. То будущее, в котором вы лихо пишете промпты, а нейронка сама вносит изменения в сложный проект с запутанным и далеким от чистоты кодом, не наступит никогда.
ayevdoshenko
01.11.2025 17:26За всеми концепциями стоят банальные реальные потребности, в том числе и за Чистым кодом. Для человека, не разбирающегося в реальных движущих силах того или иного инструмента, естественно этот инструмент превращается в фетиш, а действия с ним - в карго-культ.
Смешно читать про противопоставление тестирования и чистого кода. Смешно читать, что чистый код не нужен, потому что он мешает писать программы быстро. Это непонимание чистого кода, его функций - портрет вайбкодера : ) Между тем - Чистый код просто форма борьбы со сложностью кода и закладка фундамента под то, чтобы код был структурирован и его можно было бы развивать. Это актуально для любого интеллекта - хоть человеческого, хоть искусственного: запутанный, плохо структурированный код будет приводить к деградации понимания что происходит и что код выражает экспоненциально с ростом количества кода.
При этом я ничего против LLM не имею. Они просто не справляются на больших проектах - и это факт из моего практического, постоянного и довольно обширного опыта применения LLM для кодинга. В последнее время я стал еще и натыкаться на то, что модели отстают от актуального знания - свежих библиотек - и генерят устаревший код, а зачастую и миксуя несовместимые версии. Плачевно обстоит дело и с рефакторингом крупных проектов - нужно либо продумать этот рефакторинг и описать от и до: где и что поменять конкретно и в полуручном режиме пройтись последовательно по изменяемым программным сущностям вместе с LLM, еще и попутно поправляя ее - но тогда в чем выигрыш?; либо получить взрыв на макаронной фабрике : )
Я не против, если бы LLM могла писать код за меня - и даже знания в прграммировании мне бы не мешали при этом : ) Но - это не работает так, как пишут нам восторженные вьюноши.
Ждем следующую статью: "Будут ли важна булева алгебра в ближайшем будущем" : )
Arragh
Влажные мечты вайбкодера о том, что когда-нибудь (желательно поскорее) с него перестанут требовать какие-то непонятные фундаментальные знания по языку и будут брать на работу за одно только упоминание ллм.
Ну может когда-нибудь так и будет, но и зарплатой у таких «работничков» будет ветка.
youscriptor Автор
Почему вы так беспокоитесь про доходы программистов? Понятно что всю маржу с LLM заберет бизнес
Arragh
Может быть потому, что я программист и это отразится на мне?
youscriptor Автор
Как на вас отразяться чьи-то "влажные мечты"?
Arragh
Пытаешься так незаметно стрелку перевести? Твой вопрос был не про влажные мечты.
P.S.: Я забыл сразу тебя поправить, что вайбкодер и программист - это 2 абсолютно разные сущности.
youscriptor Автор
Жалко бизнес с тобой не согласен - сейчас все больше компаний требуют вайбкодинг в резюме
Arragh
Ну в моем стеке (.NET) я такого не наблюдаю.
А судьба вайбкодера - работать за миску похлебки. Ибо вас, вайбкодеров, будут орды, и за каждую вакансию будете устраивать мортал комбат.
youscriptor Автор
ты на какой планете живешь? Зайди на HH - джунов типа тебя 3000 человек на вакансию
Arragh
На той самой планете, где у замечтавшихся вайбкодеров рвутся пуканы.
4wards1
А покажите конкретные примеры трудоустройства вайбкодеров на реальную работу, пожалуйста. А то у меня ни одного коллеги-вайбкодера почему-то нет и даже сама мысль кажется смешной.
youscriptor Автор
Индустрия просто повышает норму выработки в 1.5-2 раза, а там пользуетесь ЛЛМ или нет это уже ваша проблема. При одновременном срезании зарпла. Теперь смейтесь от души.
4wards1
Вот смотрите, я вас попросил показать факты. Вы в ответ выдаёте фантазию, причём ещё и тему пытаетесь в сторону увести. Очевидная логическая ошибка, но похоже, что очевидная не для всех.
Давайте я вам контекст разговора напомню. Хотя он состоит всего из пары сообщений, но вы уже успели его потерять. Я попросил показать конкретные кейсы трудоустройства вайбкодеров на реальную работу за деньги. Потому что среди моих коллег нет ни одного вайбкодера, и мне искренне интересно, неужели хоть какие-то работодатели на полном серьёзе доверяют IT-инфраструктуру бизнеса ллм-обезьянкам, которые просто генерят код без понимания?
youscriptor Автор
Я встречал вакансии где опыт вайбкодинга указывался как необходимое требование, обезъяны, дебилы - это ваша эмоциональная оценка. Понятно что нужно понимать что нагенерила сеть, но в прочем это не всегда обязательно. Я недавно навайбкодил проект за 2 недели за 300 тыс рублей, заказчик был рад до усрачки, потому что сэкономил ему примерно 2 млн. На пайтоне, который я почти не знаю.
4wards1
Именно об этом я и говорю :) Вы шлёпаете простенькие проекты с жизненным циклом 2 недели (!) в то время, как 90% индустрии занимается совершенно другими вещами, ощутимо более сложными. Затем вы экстраполируете свой опыт из микропроектов на всю отрасль и делаете весьма сомнительные выводы. Эти выводы естественно оспариваются теми, кто работает над полноценными проектами, потому что их опыт говорит о полностью противоположном.
Приведу простую аналогию. Допустим, вы строите гаражи. И тут Boston Dynamics выпускает робота, который умеет строить гаражи любых цветов и размеров. Вы пишете статью: "В будущем сопромат будет не нужен, ведь робот уже умеет строить сам!". После чего проектировщики, рассчитывающие сложные металлоконструкции и использующие в работе всякие там ЛИРА и Advance Steel, крутят пальцем у виска, а вы искренне считаете, что они тупые, а вам виднее, ведь вы этих гаражей по 10 штук каждый месяц заказчикам сдаёте без всякого там сопромата и прочей ненужной мути.
Вот только, повторюсь, 90% строительной отрасли не гаражи строит. И такие выводы насчёт сопромата от строителя гаражей их действительно насмешат.
youscriptor Автор
как раз 95% современной работы программиста очень простые. Современные говнокодеры не знают ни математики, ни теории алгоритмов, а просто собирают из готовых блоков. Сама сложность не в умении думать, а зазубить новые библиотеки. То что вы делаете, что просто как страус засовываете голову в песок. В IT гигантах уже массовые увольнения (то там то сям уволили по 5000 чел) и по разным сведениям больше половины кода генерируют нейросети. Я в индустрии 20 лет и работал в компаниях разных размеров, в том числе и в больших корпорациях, и в стартапах .
dmitrijtest24
То то везде в больших компаниях спрашивают алгоритмы ))) а в каких супер больших компаниях вы работали если не секрет? А по увольнению 5к сотрудников вообще смешно, смотрите кого увольняют и почему, ИИ это предлог не более.