Комментарии 117
>Но на этом уровне LLM — враг, а не помощник. От вас ожидаются свежие идеи, а не пережеванный силос, срыгнутый средними разработчиками в публичное пространство.
Вот это просто прекрасно
Насчёт эрудиции вы очень чётко подметили. Всю жизнь наблюдаю, как из года в год растёт количество людей, которые любят говорить "зачем мне эта информация". С появлением ИИ-помощников этот рост лишь ускорился. Люди массово теряют способность запоминать информацию, и становятся зависимыми от интернета в том плане, что без интернета они не могут ничего сделать.
Люди массово теряют способность запоминать информацию, и становятся зависимыми от интернета в том плане, что без интернета они не могут ничего сделать.
Да, печально. Это почти так же ужасно, как последствия изобретения письменности и книгопечатания.
Я застал те древние времена, когда за знаниями надо было идти в библиотеку, тратить кучу времени на поиск нужной книги, потом в читальном зале искать нужную информацию и нести на ксерокс, чтобы отснять нужные страницы. И потом писать по этим ксерокопиям курсачи. Хочешь не хочешь, а запомнишь это всё в любом случае, потому что к каждой крупице информации прикрепляется огромный контекст, как ты это искал, ксерокопировал, правил после файнридера и т.д.
Сейчас же любую инфу можно найти за секунды или минуты, потом Ctrl+C Ctrl+V и забыл. Чем это плохо? Тем, что ты не можешь использовать в мыслительном процессе информацию, которую ты не помнишь. Древний человек, проведя много времени за книгами, держит в голове большой объём информации, из-за чего он может мгновенно строить в голове сложные рассуждения. А когда вся твоя информация находится в интернете, а не в голове, то тебе, чтобы построить мысленно длинную цепочку рассуждений, буквально на каждом шаге придётся обращаться к интернету за дополнительной информацией.
Собственно, так и устроена работа так называемых 10х разработчиков. Пока один тыкает палкой в промпт, чтобы получить рабочий код, или смотрит в интернете туториалы, другой просто садится и пишет из головы всё буквально за пару минут.
Я застал те древние времена, когда за знаниями надо было идти в библиотеку, тратить кучу времени на поиск нужной книги, потом в читальном зале искать нужную информацию и нести на ксерокс
Вооот! С ксерокса и началась деградация. То ли дело в мои времена - ручку в руку и пошла писать губерния в тетрадь общую. Пока нужное перепишешь - часть уже и усвоится!/s
Ну ксерокс в научно-технической библиотеке - удовольствие недешёвое. Он стоил в 3-5 раз дороже, чем в других местах. Когда я там был в первый раз, я смог отксерить ровно столько, на сколько хватило денег, и ещё пару страниц пришлось переписать.
Ну ксерокс в научно-технической библиотеке - удовольствие недешёвое. Он стоил в 3-5 раз дороже, чем в других местах.
Похоже, вы застали далеко не все времена: например, вы не застали времена, в которые ксерокса "в других местах", т.е. - общедоступного за деньги, не было. А где ксерокс был - на предприятиях - то был он под присмотром бдительных сотрудников, чтобы все кому попало всякие "архипелаги гулаги" не ксерили..
До сих пор помню «Гадких лебедей», распечатанных на УВВПЧ, со скачущими вверх-вниз буквами, половина из которых была цвета #DDDDDD, потому что хорошую ленту никто на такое непотребство не дал бы. Рулон такой, неразрезанный, раввину бы понравилось.
Отец дочитал в два ночи, а мне нужно было утром её обратно коллегам в Физтех нести :)
Мне так первый раз в руки попала Роза Мира, в рулоне :-)
Вдруг отчетливо вспомнилась история, про которую я уже и забыл бы начисто, если бы не этот диалог.
Год 88-й, наверное, гласности и перестройки во всех телевизорах, но ненужный пиетет в коленях перед ментами всё еще в наличии… Еду в метро с каким-то очередным рулоном, «Осенний крик ястреба», вроде. И вдруг за мной почти впритирку нарисовываются два прислужника закона. Оба — в звании сержант (да еще и из милиции метро — то есть умные, самый цвет интеллигенции). И тут один второму говорит, с такой отеческой умудренностью, с отттенком горечи, в голосе: «Совсем народ обнищал. Смотри вон пацан какой-то рулон грязный домой тащит, вместо туалетной бумаги, небось».
Я попал в компанию старичков.
Глядя на себя в зеркало и подтягивая пузо:
От, какой я джигит! Ещё 50 не исполнилось!
Такая же фигня. В мои времена ксерокс уже был в вузе, где я учился. Но во первых: он стоял на первом этаже, а библиотека была на втором... Во вторых он стоил приличных денег, и работал только до 16.00. В итоге в подавляющем большинстве случаев до него дело не доходило. Вынести книжку из библиотеки можно было только заполнив формуляр. А вот читать там же, если правильно помню, вообще ничего не надо было делать, пришел, сказал данные книги, и сиди, самообразуйся. Ради пары страниц смысла не имело. Дралоскопировали вручную))
У некоторых к этому времени уже были домашние ПК (от спектрумов и 286-х и до первых пентиумов) , и уж совсем у некоторых даже матричные принтеры. (В "природе" были уже и домашние струйники, но на первом курсе таких счастливчиков у нас еще не было, и даже на втором, когда они сильно подешевели, распечатка на нем была космически дорогой в сравнении с матричным). Поэтому то, что можно было достать в электронном виде и если оно того стоило, немедленно распечатывалось и пускалось "по кругу" на ксерокс, несмотря на цены. Но в те времена основная масса знаний была в бумажном виде и никто даже не думал это все тащить в комп, потому что муторно и дорого, проще ручками переписать.
ксерокс был на предприятиях ...
если правильно помню ксероксы начали поставлять в 70х, в 60х были так называемые "Эры", смешно вспомнить, такой солидный шкаф в отдельной комнате под замком, слегка пришлось поработать в студенческие времена, селеновые пластины которые надо было заряжать и т.д., надо признать, кое-что копировал налево, типа французский журнал мод для одной из коллег бесплатно конечно, вообще практически в полном распоряжении установка была, но тогда еще спокойно было более-менее, строго учитывать их стали чуть позже
Хочешь не хочешь, а запомнишь это всё в любом случае, потому что к каждой крупице информации прикрепляется огромный контекст, как ты это искал, ксерокопировал, правил после файнридера и т.д.
«Запомнишь», а не «поймёшь».
Мой личный опыт… тьфу ты, чего я всё эти приписки пишу. Так вот, чем более доступна информация, чем меньше времени надо тратить на ритуалы, тем больше времени и сил остаётся на то, чтобы эту информацию осознать и усвоить, а не просто оттарабанивать.
А как вы это наблюдаете? Поделитесь вашими исследованиями. Любое исследование требует рецензентов. Вдруг ваша методология, или дизайн эксперимента имеют изъяны. Или просто в расчетах ошибка.
Интерфейсы надо определять на этапе проектирования, а не выделять когда-то потом.
В хелловорлде на парах программирования ЭВМ да. В реальной жизни не работает идея, особенно в корпоративе, где требования почти всегда приходят во время написания кода или после.
от бойлерплейта — выбор адекватного языка
Язык выбирает бизнес по ситуации на рынке труда. Никому не нужен новый код на коболе, чтобы потом платить от полумиллиона в год редчайшему спецу, что шарит за сию срань. И тем более, никому не нужны риски "модно-молодежных языков", которые слетают с поддержки вместе с окончанием хайпа по ним.
Продуктивность программиста напрямую зависит от IDE
Истино так. Автодополнение это считай активная документация кода, без которой разработка превращается в мучение. Отдельные гики со сверхспособностью к зубрению гигабайт статики могут кодить хоть в notepad.exe, почему нет... Стандарт отрасли же - хорошая IDE с кучей фич: автодополнение, рефакторинг, генерация, построение графа сущностей с навигацией по нему, дебаг, доступ к БД, и так далее.
LLM
Оно работает только там, где нужно делать шаблонный generic-код. А такого в нормальной большой разработке почти нет. Публичный LLM не знает особенностей вашего проекта, обучать же локальную большую модель пока что намного дороже, чем набрать еще армию программистов.
используя
vimс минимумом плагиновзнакомство с хаскелем и идрисом
Шутка про деда и таблетки. В современном мире концепт "я знаю всё" уже не работает, широкий кругозор - признак поверхностных, неполных, зачастую устаревших знаний. Ибо выучить даже 2-3 языка с их популярными фреймворками сейчас задача уровня "слетать на Марс", если ты не гик-задрот без личной жизни, конечно.
В современном мире концепт "я знаю всё" уже не работает
Смею предположить, что @cupraer имел ввиду, что в большинстве случаев эрудированный девелопер сможет разобраться, даже не зная всего. И тут я согласен, что заглядывая в код незнакомых мне языков бывает понятно, что происходит. Но тут огромную роль играет дизайн языка, сомневаюсь, что даже Автор с полпинка разберется что делает код написанный на Brainfuck и ему подобным.
Прям согласен. Вообще статья выглядит как очередные старперские переживания в духе "в наше время страдали и жили в пещере, и вы страдайте и живите, электричство и канализация не нужны".
Интерфейсы надо определять на этапе проектирования, а не выделять когда-то потом
Бггг , в ООП постоянно такое. Рефакторинг без остановки. Потому, например, что ХЗ кому именно отдать ответственность.
Разброд и шатания. Страдания юного Вертера.
У меня много кода в опенсорсе, и фактически весь он оплачен моими работодателями: им было выгодно, чтобы я делал то, что хочу.
Надеюсь он в курсе, что вы не способны правильно решить даже простейшую задачу с турникетом.
Как ни странно, расширение кругозора не отнимает много времени: мне любопытно, что там как происходит у коллег в параллельных цехах. И не пора ли нам что-то оттуда потырить в свою кладовку.
Вы уже освоили Объектное Реактивное Программирование?
Все эти навыки делают из меня (надеюсь) неплохого архитектора: широкий кругозор позволяет найти «идеальное» решение в рамках существующих парадигм и реализаций, а потом уж думать, как его поженить с текущим стеком, и возможно ли это в принципе.
Забавно это слышать от человека, который любую прикладную задачу, даже с неограниченным числом состояний, пытается решить через.. Конечные Автоматы; ничего не понимает в тестировании; и усугубляет проблемы динамической типизации Elixir, написанием на нём сложного кода, с которым даже IDE не сможет помочь, сколько бы ресурсов не было вложено в LSP:
я всегда производил в несколько раз больше самого сложного в компании кода, используя
vimс минимумом плагинов
В принципе, использование vim - уже показатель косности мышления, застрявшего в 90-x, и не способного угнаться за прогрессом. Рационализация через написание кучи статей на Хабре в поиске одобрения от таких же отбитых - тоже маркер: "Мой редактор не понимает что я пишу, напишу-ка статью, где объясню всем, что IDE не нужны, а все проблемы легко решаются регулярками и мифическим написанием идеального кода с первой попытки". То же самое когда-то говорили гоферы про дженерики до их появления, яваскриптеры про статическую типизацию до выхода тайпскрипта, растеры про исключения до появления макроса try!, и тому подобные "неплохие архитекторы", выдающие свои привычки и убеждения за лучшие практики.
Держите: 🧯🧯🧯
(в сердцах выбрасывает в мусор тазик с попкорном) ну нельзя же так разочаровывать зрителей. Взрослые люди уже давно достали бы и измерили.
Болельщики, даже те, которые из другой лиги/песочницы и не понимают половины обсуждаемого, будут благодарны если срачег дискуссия будет иметь конструктивное продолжение, не обязательно здесь и сейчас, но несущее что-нибудь интересное.
В принципе, использование vim - уже показатель косности мышления, застрявшего в 90-x, и не способного угнаться за прогрессом.
Сижу на neovim + (coc.nvim | idris-vim | agda-vim ) + telescope.nvim + ещё пара плагинов по мелочи. Мои задачи решает норм. Что я упускаю в прогрессе?
Вдруг вы попробуете SuperPuperIDE и ваша жизнь засияет всеми красками?
Это концептуальня проблема - новый инструмент может оказаться лучше старого, но надо потратить время на освоение.... а заранее ж неизвестно - лучше он или хуже.
Так мне вот интересно, что это за краски такие будут, и чего вообще ожидать. А то вдруг я попробую, но как-то не так, или какую-то особую кнопочку не нажму и не найду, и упущу такую возможность улучшить свою жизнь, пройдя буквально в миллиметре мимо неё?
Мы Пастернака осуждаем только после прочтения.
то я упускаю в прогрессе?
"настоящий программист считает плохим следующий принцип редактора: "То, что вы видите, то вы и получите". Настоящий программист желает редактор с принципом: "Вы это просили, вот вам"; т.е. редактор, который был бы сложным, шифрованным, мощным, непрощающим и опасным. Редактор TECO - чтобы быть точным.
Было замечено, что последовательность команд TECO более напоминает помехи в линии передачи, чем читаемый текст. Одна из самых развлекательных игр с TECO - напечатать в качестве командной строки свою фамилию и попытаться догадаться, что она сделает. Точно так же любая случайная опечатка при работе с TECO может разрушить вашу программу, или, хуже того, внести неуловимые и мистические ошибки в уже работающую программу." ;-)
Спасибо, попробую писать код в Microsoft Word.
А чем это будет отличаться от кода в блокноте?
У майкрософта неплохие редакторы коды, бтв.
А чем это будет отличаться от кода в блокноте?
Ко мне не будет применим сарказм из цитаты предыдущего комментатора:
настоящий программист считает плохим следующий принцип редактора: "То, что вы видите, то вы и получите"
MS Word — WYSIWYG'овее некуда!
У майкрософта неплохие редакторы коды, бтв.
Я разве спорю? Но MSVS — это C++ с C#, которыми я не пользуюсь, а VSCode с плагинами и lsp — так чем это будет отличаться от nvim в лучшую сторону?
У неандертальцев объем мозга был даже больше, чем у сапиенсов. Но эволюционную гонку они проиграли. Нам неизвестно точно почему, пока удалось лишь исключить несколько гипотез, например популярную одно время гипотезу о геноциде сапиенсами. Они тихонько вымерли и все. Быть может, они не хотели пользоваться копьеметалкой? Она не делает ничего нового, метает то же копье, причем при меньших усилиях копье летит дальше, а это ведет к деградации, уже не нужно тренироваться столь усердно. Но сделав ставку на физиологию, гордые и надменные неандертальцы проиграли прагматичным сапиенсам, поставившим на технологии. В нас около 3% неандертальской днк, вероятно сапиенсы иногда жалели голодных неандертальских жен и брали их себе в наложницы. Такая гипотеза пришла мне в голову при прочтении статьи. Странно, ведь статья не связана с палеонтологией.
все верно про эрудицию и образование, но по опыту ничто не дает так много, как общение с умными людьми, повезло в этом смысле, Виктор Петрович Иванников доброй ему памяти, ИСП РАН его имени, супер давно дело конечно было, один из его советов был типа всегда выбирайте людей с кем работать, мне это помогло, возможно также поможет еще кому-нибудь
Именно так. Но на это мы не всегда можем повлиять.
верно, что многое от нас не зависит, но повлиять на судьбу таки можно всегда, даже когда лодка тонет, хотя возможно именно это Вы тоже имели в виду
ИМХО, эрудиция начинается с детской любознательности. В детстве единственным источником знаний была библиотека, и много времени провел просто листая энциклопедии. Есть некоторые перегибы: зачем-то знаю металлургию, металло- и деревообработку, кубометр инструментов дома и 10+ лет риелторства. Но как остановиться - кто бы сказал?!
2-3 месяца назад прочитал интересную мысль, которая созвучна. Если семени дать землю, воду и солнце, то семя не может не прорасти и вырастет в огромное дерево. И вот тоже про людей.
"Дед опять забыл таблетки выпить"
Попробуйте идти в ногу со временем, истина где-то посередине.
пережеванный силос, срыгнутый средними разработчиками в публичное пространство
Это называется "типовые решения". Если перестать пилить велосипеды на каждый чих, и начать пользоваться готовыми библиотеками, то и LLM-ки не понадобятся. Правда, остаётся фатальный недостаток, а этого никак нельзя допустить.
От вас ожидаются свежие идеи, а не пережеванный силос, срыгнутый средними разработчиками в публичное пространство.
Если вам кажется что вы изобрели что-то новое и необычное, это значит что вы недостаточно хорошо знакомы с чужими проектами. (Зато LLM, благодаря условиям пользовательского соглашения, с чужими проектами (будет) знакома очень хорошо. Вот этого может и следует опасаться, когда будете брать LLM в помощники.)
Все велосипеды уже изобретены. Просто откройте каталог, и выберите подходящий. Это вам любое LLM скажет (в недалеком будущем).
Любая мало-мальски сложная задача поставит LLM в тупик, а простая — растренирует ваши профессиональные навыки
Правильно. Не надо ни с кем делиться работой. Надо все делать самому.
Может быть, мне просто нравится моя работа — и зачем мне тогда её кому-то отдавать, да еще и бесплатно?
Отлично, покажите мне уже готовую реализацию Web4, чтобы я не изобретал велосипед.
"Если вам кажется что вы изобрели что-то новое и необычное, это значит что вы недостаточно хорошо знакомы с чужими проектами".
Спорно.
-А можно велосипед с перламутровыми пуговицами?
-Можно, но пуговицы плохо совместимы с велосипедами, придется разработать новые конструкции и пуговиц и велосипедов.
Странно видеть в треде целых два упоминания про деда и таблетки, хотя автор даже младше Кармака или Торвальдса, которых дедушками язык не повернется назвать.
У меня оффтоп. Поделитесь, пожалуйста, что должно входить в джентельменский набор плагинов для vim?
Я ленивый минималист, в принципе. Использую LunarVim.
Список плагинов
lvim.plugins = {
{ 'shaunsingh/nord.nvim' },
{ "elixir-tools/elixir-tools.nvim" },
{ "nvim-pack/nvim-spectre" },
{ 'mg979/vim-visual-multi' },
{ 'chrisbra/unicode.vim' },
{ 'hkupty/iron.nvim' },
{ 'kdheepak/lazygit.nvim' },
{ 'wakatime/vim-wakatime' },
{ 'tpope/vim-unimpaired' },
{ 'tpope/vim-projectionist' },
{ 'hrsh7th/nvim-cmp' },
{ 'MattesGroeger/vim-bookmarks' },
{ 'wsdjeg/vim-fetch' },
{ 'jeffkreeftmeijer/vim-numbertoggle' },
{ "tpope/vim-fugitive" },
{ "mattn/vim-gist" },
{ "mrjones2014/nvim-ts-rainbow", },
{ "nvim-telescope/telescope-project.nvim" },
{ "rmagatti/goto-preview" },
{ "folke/trouble.nvim" },
{ "cloudhead/neovim-fuzzy" },
{ "gbprod/yanky.nvim" },
{ "farmergreg/vim-lastplace" },
{ "cseickel/diagnostic-window.nvim" },
}
Зур рахмат! Я со списком фичей/плагинов ознакомился, дважды сходил покурить и удалил с компьютера глючное недоразумение под названием Visual Studio Code. Те, кто пишет, что "vim - это привет из 90х", по всей видимости представляют черный экран с мигающим курсором-прямоугольником, тильдами с краю и надписью "1,0-1 All" в нижнем углу.
vi — привет из 70-х, vim — из 90-х. А то, про что вы тут друг друга хвалите — это уже другое. Да, оно в основе как бы да, но нет. Поэтому ходить и рвать на себе рубашку на тему собственной крутости от использования кошерного вима вместо харамного vscode — ну такое себе занятие (простите нас, что мы с вами на одной планете летим). Тем более все знают, что на самом деле правильный редактор для программистов — emacs.
правильный редактор для программистов — emacs
Да, но в evil mode.
Речь не про крутость, мне нужен был совет - я спросил. И 80% времени я вообще пользуюсь VS 2019 (см. С/С++ бойлерплейт для DX11/12 + отладка собственного говнокода под винду) и удалять ее не собираюсь. VS Code пользовал для остальных своих поделок, и, сказать по правде, работа в ней меня действительно бесила, отчего и постепенно стал переходить сначала на notepad++, а потом и vim.
А считается эрудицией знание MFC или это уже слабоумие?
Что-то ну очень странное. С самого начала хочется поспорить.
не рефакторинг
Тут мне видится подмена понятий. Все это вполне себе рефакторинг.
От рутины прекрасно избавляет карьерный рост, от бойлерплейта — выбор адекватного языка, а от траты недель на написание кода — час обдумывания его структуры.
Все же, карьерный рост - это не пара месяцев, и не год. Чтобы задачи были более интересные, могут уйти многие годы. И все равно всегда будет хотя бы часть рутины.
Выбор языка как спасение от бойлерплейта - какая-то глупость. Если, например, я хочу писать банковское ПО, то почти везде это Java. А если хочу писать серьезные игры на современных движках - скорей всего буду использовать какой-нибудь С++ или C#.
А час обдумывания далеко не от всего спасет. Потому что в ходе решения возникает много новых моментов, которые сразу не надумаешь. Потому что решение может поменяться уже через день из-за изменений требований. Потому что каким бы ни был крутым программистом, все равно найдется что исправить.
кто верит в повышение КПД при помощи автодополнения
Не понимаю, чем автору не угодили функции IDE. Современные средства может и не повышают производительность в десятки раз, но зато дают намного безопасней писать код: делают много проверок, позволяют быстро и без ошибок изменять код. В общем, всячески упрощают работу над задачей, когда ты можешь спокойно думать о бизнес логике, не переживая, что неаккуратным действием все сломаешь и не переключаясь на ручные манипуляции в виде переноса функции и переименования ее во всех местах.
Хорошему (действительно хорошему) разработчику платят больше, чем тимлидам и архитекторам.
Кажется, что такой разработчик - уже вполне себе по навыкам тех. лид. И тогда вполне возможно, что зарабатывает больше тимлида. Но в среднем по больнице тимлид получает больше просто разработчика.
Хорошим разработчиком практически невозможно стать, не покидая пределы своего стека... это всё про позиции «мидл» и ниже
Тогда что, бегать между разными стеками? А когда тогда развивать глубину знаний, если приходится постоянно учить базу по новому языку и фреймворку? Я вот спустя 5 лет в текущем стеке еще далеко не все знаю.
Ну и что за глупость, что разработчик на одном стеке не может быть сеньором, а только мидл и ниже? Тут даже аргументировать не вижу смысла.
Все эти навыки делают из меня (надеюсь) неплохого архитектора
А если речь про архитектора, то да, ему не надо быть привязанным к языку. Но это уже и не разработчик, это архитектор. Это другие задачи, другой кругозор, другие навыки. Там уже важнее ширина знаний, чем глубина.
LLM
По поводу LLM спорить не буду. Нужно в первую очередь думать своей головой, а LLM использовать для ограниченного числа задач.
Ближе к концу статьи прям уже какое-то самолюбование, простите. Хотя по сути с Вами согласен: и рефакторинг проще руками сделать, чем вспомнить, как заставить IDE сделать именно то преобразование, которое мне надо прямо сейчас. И автопополнение не обязательно. И кругозор обязателен просто для того, чтобы знать о существовании молотка, когда тебе предлагают микроскопом гвозди забивать
Интерфейсы надо определять на этапе проектирования, а не выделятькогда-то потом.
Ну да, и код сразу писать правильный, без багов, зачем нам баги. И бизнес-логику не менять потом, зачем менять, можно же сразу навсегда правильно сделать. И рефакторинг будет не нужен, удобно.
Плюсик поставил - зачётный стёб.
Когда был молодой, ни как не мог понять - почему руководство считает, что "можно не ошибаться". А потом дошло - всё они понимают. Просто, им нужен "рычаг давления", и подобный обман - один из них. Потому, встретил такого начальника - беги...
Всё-таки желательно хотя бы пытаться писать так, чтобы хотя бы иметь шанс потом не рефакторить. И чтобы изменения бизнес-логики не превращались в катастрофу, когда для добавления одного поля приходится поиском по коду пользоваться, чтоб не забыть прописать его в десятке мест. А потом фиксить баги, потому что обязательно кто-нибудь что-нибудь забудет
Это когнитивное искажение. Стараться нужно, но это никогда не гарантирует что менять не придётся. И не редко изменения из-за доработок, новых требований, улучшений и других внешних кейсов, которых физически не существовало в секунду написания кода. Машину времени пока не изобрели.
Для рефакторинга и чтобы не забыть - как раз и нужна IDE. Конечно зависит от языка. В Ruby попытка навигации по коду и автоматический рефакторинг полей - это квест с приключениями, слишком много динамики, IDE особо не поможет. Но и код сильно проще и интерфейсов как таковых там и нет. В JS уже получше, меньше динамики и там одной кнопкой можно переименовать поле, удобно. Но не всегда - иногда промахивается. В TS сильно лучше - там IDE твой друг. Есть кейсы с тем что чего-то не найдёт, но там сверху компилятор ещё отсыпет. А вот в Rust вообще надо очень сильно постараться и через макросы, чтобы умудрится не смочь отрефакторить что-то в одну кнопку - там IDE разворачивается по полной. Это по языкам моего стека, но на сколько я знаю также в Java и языках подобного уровня.
Так что изменение имени поля в промышленных языках это буквально, в прямом смысле слова - комбинация клавиш и пишешь новое имя. Поменяет везде. Также с навигацией, просмотром мест использования, перемещением, сменой сигнатуры и конечно же автокомплит.
Другое дело когда пишешь в редакторе кода вместо IDE. Ну да, на лошадях тоже можно ездить, и вообще это престижно и интересный опыт. И редактор можно запустить на древнем оборудовании. На этом преимущества заканчиваются.
Всё, на что способна IDE, — это не рефакторинг, это переливание из пустого в порожнее. Рефакторинг — это изменение структуры (архитектуры) кода, а не имён функций и нагруженности интерфейсов.
А чо, команда "Выделить метод" - это разве не изменение структуры программы? А такая команда в IDE есть - в частности, в V2022 сам ей пользовался неоднократно.
команда «Выделить метод» — это разве не изменение структуры программы?
Нет. На это способен компилятор типа gcc образца 2000 года.
Дайте, что ли, определение понятия "структура программы", как оно вам видится. А то у меня возникает ощущение, что вы тут пишете про одно, а все прочие - про другое.
PS А у gcc, ЕМНИП, в 2000 IDE не было, и, соответственно, команды "Выделить метод" тоже быть .не могло. Конечно, руками я методы выделял и в Delphi (а, может, и в TurboPascal, не помню), но команда таки удобнее.
у gcc, ЕМНИП, в 2000 IDE не было, и, соответственно, команды «Выделить метод» тоже быть не могло
gcc команда и не требуется, компилятор может заинлайнить ваш «метод», или, наоборот выделить набор инструкций и закэшировать результат. Это действие диффеоморфно вашим кликам мышью.
Изенение структуры программы должно менять ответственности из SRP, а выделение методов его не меняет, это косметика.
gcc команда и не требуется, компилятор может заинлайнить ваш «метод», или, наоборот выделить набор инструкций и закэшировать результат.
Дык, рефакторинг - это преобразование исходного текста программы. А компиляторы обычно занимаются совсем другим. Отличие тут - в том, что исходный текст предназначен для чтения человеком, а результат компиляции - не предназначен. Так что работа компилятора вообще не имеет отношения к рефакторингу.
Это действие диффеоморфно вашим кликам мышью.
А можно как-нибудь выражать мысли словами, понятными простому программисту? Заранее спасибо.
Изенение структуры программы должно менять ответственности из SRP, а выделение методов его не меняет, это косметика.
А что такое эта самая "ответсвенность из SRP", не задумывались? Как по мне, это - мутное, плохо определенное понятие, реальное содержание которого слишком сильно зависит от контекста, чтобы им можно было пользоваться без уточнений.
Если вернуться к нашим баранам, то непонятно, что является объектом ответственности в случае метода: сам метод как единица кода или же объект в целом, в котором он определен. Второй вариант определения объекта ответсвенности плох тем, что ограничивает использование этого понятия исключительно парадигмой ООП. В то время как сам прием выделения части кода в отдельную кодовую единицу полезен и в других парадигмах. Например в процедурном программировании - на Pascal или C - я этот прием тоже использовал, несмотря на то, что там единица кода именуется не методом, а процедурой или функцией.
Ну, а в первом варианте определения ответсвенности выделение метода (равно как и функции или процедуры в процедурных языках) приводит к изменению этой самой "ответственности из SRP"- если по простому, то для изменения логики куска кода, подлежащего выделению, вы полезете менять разные файлы.
Так что ваше (теоретическое) определение плохо тем, что имеет слишком узкую область применимости, не покрывающую область применимости хорошего, годного практического приема - выделения части кода в отдельную кодовую единицу.
А что такое эта самая "ответсвенность из SRP", не задумывались?
Задумывался. Грубо говоря, это модуль, у которого есть экспортируемый API. Как там внутри модуля хитровыплетены функции, методы и процедуры — вообще фиолетово.
область применимости хорошего, годного практического приема — выделения части кода в отдельную кодовую единицу
А зачем как-то называть вот эту мастурбацию программиста, таскающего туда-сюда куски кода? Кому это вообще, кроме него самого, интересно?
Я вам не скажу за всех программистов, но лично я использую этот прием как первую часть процесса повторного использования своего кода. Я в курсе, что вы верите в возможность неизменности кода, конечно, но на практике код менять приходится.
И вот когда при изменении возникает необходимость использовать ранее написанный кусок кода ещё раз в другом месте - а она возникает почему-то часто, и нередко в неожиданном месте - то первое действие при этом - Ctrl+C-Ctrl+V выделить этот кусок в отдельную единицу. И то, что эту операцию в современных IDE (в частности - в Visual Studio) автоматизировали - это мне нравится.
PS По своему обычаю: если эта дискуссия никого кроме нас с вами больше не заинтересует, я в ней участвовать не буду: свою мысль я уже высказал, а вас-то я все равно не переубежу.
Интересует, и как можно спорить с тем, что выделение метода - это рефакторинг, не понимаю. Правда этими быстрыми рефакторингами особо не пользуюсь: слишком мало кода пишется в уже сложившихся проектах, не в лом и руками все сделать) А вот за Find usages IDE надо памятник ставить)
Изолента для ремонта издержек ООП, когда код привязан к классу и потому не может быть повторно использован непосредственно.
Нет ООП - нет проблемы, код с самого начала можно синтаксически разбить по семантическим единицам.
Самое жуткое, что придумал программистский разум (после оператора EQUIVALENCE и концепции UB) - это привязка кода к данным.
Изолента для ремонта издержек ООП, когда код привязан к классу и потому не может быть повторно использован непосредственно.
Тут на ум сразу приходит фраза Альфа "да вы просто не умеете их готовить". Ну ладно, даже если не умеете, то что мешает вырезать кусок кода метода и передать в него поля объекта как параметры? В C# есть только методы - ни процедур, ни фукций нет. Поэтому "я работаю с выделить метод". Если же надо отвязать метод от объекта , то в C# есть статические методы, там вся привязка классу - его пространство имен. Методы в татические иногда преобразовывать тоже приходится - чтобы не грузить мусором сборщик.
Нет ООП - нет проблемы, код с самого начала можно синтаксически разбить по семантическим единицам.
Дык с ООП тоже можно разбить, я написал, как. А ещё есть проблема что процедура или функция может работать с глобальной переменной: все гуру против такого, но по жизни без этого в процедурных языках обойтись трудно. Ну, и как в этом раскладе тогда вам помогут эти семантические единицы? Уж явно не атоматически - код-то все равно придется читать и осмыслять.
А как глобальные переменные связаны с семантическими единицами?Это просто возможное операционное представление семантики, но на обозначаемый предмет (денотат) оно никак не влияет.
Мне все это ваше наукообразие из умных слов даже разбирать не хочется. Я тут - больше с чисто практической стороны смотрю: зависимость от глобальной переменной очень неудобна для рефакторинга, потому что неочевидно, где связь через нее вылезет.
Это факт. А видит ли этот факт ваша теория - это уже дело вторичное.
Кстати, ООП в данном контексте иеет то преимущество, что зависимость от полей объекта имеет зону действияЮ ограниченную этим объектом (та самая инкапсуляция), а потому в ООП на практике мегьше соблазн использовать глобальные переменные. Но это, конечно, общий случай, а в конкретном реальном коде всё может быть не так.
Если вы пишете программу так, что она нуждается в рефакторинге и при этом рефакторинг вам неудобен, то вы пишете программу как-то неправильно. Возможно, как раз из-за непонимания теории.
Мне лично глобальные переменные никак не мешают. Хотя я их использую редко. Скажем, одну переменную на 100 функций.
вы пишете программу как-то неправильно.
Нельзя просто так взять и написать прграмму сразу правильно и для текушиъ требований, и для требований, которые появятся в будущем. А они появятся.
30 лет программирую за деньги, из них одним проектом в фазе разработки непрерывно занимался до 18 лет подряд, и не припомню, чтобы проблема рефакторинга была актуальна. Хотя видел, как это получается в плохо спроектированных программах. Но их, честно говоря, зачастую проще в таких случаях заменить другими.
У меня при этом бывал в программах заимствованный код, который я с удовольствием бы отрефакторил, если бы смог понять (я детально разбирался, как именно он работает, но не мог понять стоящую за этим идею - в некоторых случаях по своей необразованности, а в некоторых - по странности автора). В одном случае такой код был получен переводом с Фортрана, работал только в определённом режиме трансляции и включал выход за границу массива как необходимый элемент свой нормальной работы. Ну что я могу сказать: не надо изначально писать такой код. Но семантически он представляет собой чёрный ящик. Если б мне какой-нибудь LLM предложил вариант его модификации, я бы никогда не согласился.
Не пишите монолит - не придётся рефакторить в процессе расширения.
Не пишите длинные последовательные фрагменты кода - будет вообще нечего рефакторить.
Код должен по возможности выражать чистую идею. Идея не нуждается в рефакторинге.
Наверное, если бы я был наёмным программистом (и при этом хотел бы им остаться до пенсии), - я примерно так же и думал бы. Но я в основном по другую сторону баррикад. Сам-то тоже программирую по необходимости и для души, но если какой-то проект взлетит - не мечтаю вечно поддерживать его в одну каску и планирую таки при первой финансовой возможности вверять начатое специально нанятым людям. По возможности минимизировав свой геморрой с поиском таких людей и свои затраты на их оплату.
И вот с этой другой стороны баррикад скажу, что описанный в статье синьор бизнесу в большинстве случаев не то, что не нужен, но прямо-таки конкретно вреден. Потому как ладно ему придётся платить все деньги мира, он, может, их и стóит. Но его ж и заменить крайне сложно. И заданные им высокие стандарты программирования на концептуально идеальном уровне мало кто сможет потянуть, когда мы упрёмся в лимит его личной производительности. А задачи у бизнеса довольно редко требуют именно такого всесторонне развитого сеньора. И даже если он с высот своей эрудиции может задачу решить несколько более оптимальным способом - целесообразно решать её способом менее оптимальным, но доступным большему количеству людей.
Опять же, мне странно видеть столь успешного в своём деле профессионала, который мечтает лишь о том, чтобы в своей работе по найму получать всё более пафосные лычки. Казалось бы, когда ты уже видишь общую картинку, самое время отправляться в самостоятельное плавание. А тут, внезапно, вступают в силу все те резоны, которые я изложил выше. И оказывается, что хоть ты и познал прелести Эрланга, но оптимальной стратегией оказывается начать проект на Go, а нанятым за скромный прайс кодерам оплатить подписку на Cursor, потому что они с ним реально работают быстрее, что бы ты сам ни думал про LLM :)
Всегда есть (минимум) две стратегии:
1. "Мы не настолько богаты чтобы покупать дешевые ботинки"
2. "После нас хоть потоп"
На длительной перспективе выгодней опытные синьоры программисты (умные)
Но на короткой перспективе, когда срок жизни проекта недолог (или неясен) выгодней конечно ХХП и дешевые проги (сильные)
Наоборот. В короткой перспективе я могу нанять одинокого гения, который напишет мне шедевральный код. В длинной, если проект взлетит, я физически не найду такого количества гениев, чтобы такой код поддерживать (даже оставив за скобками вопрос финансов). Не говоря уже про то, что у каждого гения своё мнение о единственно правильном подходе, в корне несовместимое с мнением других гениев (см. предыдущую статью автора хотя бы :), так что гении вообще фигово масштабируются.
Так что если проект нацелен на перспективу - он должен быть более или менее industry standard в выборе ЯП, архитектуры, фреймворков, тулинга и пр.
А как обеспечить качество кода без гениев - это уже совсем другая длинная и интересная история. И тут тоже нужны таланты, но совсем другого рода.
Не надо путать гениев с умными
Умный напишет код так чтобы он легко понимался и сопровождался
Перемудрят как раз или гении-одиночки или нубы еще не умеющие работать в команде
А вот нанять на долгий проект толпу джунов, оставить их без контроля - получить дикое забагованное легаси за год-два из одних костылей
Дорабатывать и поддерживать это будет нереально - остается только выкинуть и переписать нормально, уже наняв сеньоров с мидлами
Ну а кто говорит про "толпу джунов". Джунов как раз LLM теснят, а вот ревью хоть за джунами, хоть за LLM, делать надо тем самым мидлам и сеньорам. До определённого масштаба можно самому в такой роли выступать, но тут быстро получится управленческий антипаттерн обратного делегирования :)
Я же писал не про сеньоров в принципе, а про тот тип сеньора, который описан автором статьи. Который бескомпромиссно следует своим представлениям о прекрасном и смело применяет те языки, концепции и подходы, которые считает наиболее правильными, без оглядки на бизнес-процесс разработки в целом с его объективными кадровыми, организационными и финансовыми ограничениями.
У вас странное представление о том, что такое хороший код
Хороший код - это такой, в котором человек без большого опыта и трёх килограммов мозгов разберётся, сделает что надо и не создаст проблем
А не такой, в котором любое изменение должно быть шедевром
Казалось бы, когда ты уже видишь общую картинку, самое время отправляться в самостоятельное плавание.
Я люблю писать код гораздо больше, чем деньги.
хоть ты и познал прелести Эрланга, но оптимальной стратегией оказывается начать проект на Go
До сих пор существуют, и на мою жизнь хватит, интересные и сложные проекты, которые не решить на Go.
Так вопрос же не в деньгах. Более того, в самостоятельном плавании надо ещё постараться заработать (а особенно - стабильно зарабатывать) столько, сколько топовый эксперт получает в найме. И уж точно задолбаться в процессе придётся кратно больше. Но вопрос самореализации - приятно же, чёрт возьми, когда проект на самом деле твой, ты выбираешь направление, устанавливаешь правила, ощущаешь успех как свой личный... Особенно на фоне атмосферы в крупных корпорациях (в которых ты неизбежно оказываешься, достигая определённых высот карьерного роста, т.к. только у них и есть на тебя деньги). Впрочем, конечно, это субъективно...
Минуточку, вот вы выше писали что в определенный момент делегируете написание кода соответствующим специалистам. И сразу встает вопрос, а эти специалисты как должны к нему относится?
Вот это про самореализацию, ощущение успеха от выполненной задачи как свой личный - это все к таким специалистам не относится? Они не могут считать свой вклад в проект как свой личный успех?
Вы действительно считаете, что владение проектом, ваше нахождение у истоков так до конца проекта и остается только лично вашим успехом? А вот эти вот наемные рабочие, ну, кто они такие раз их в любой момент можно уволить и никакого юридического отношения к проекту они не имеют. Да еще и им запрещено устанавливать правила, выбирать направление. Или не запрещено? Но тогда откуда будет это ощущение своего личного успеха? Или может все таки успех общий?
По моему, получается, что вопрос именно в деньгах. Т.е. если изначально ради этого все и задумывалось, и поэтому дальнейшее отношение к работникам соответствующее.
Я не работаю в крупных корпорациях по морально-этическим соображениям. Но все проекты, за которые мне плятят 90% времени — мои: я выбираю направление, устанавливаю правила, ощущаю успех и еще выкладываю всё в опенсорс.
На позициях Principal и выше — бизнес даёт практически неограниченную свободу просто в надежде, что ты что-нибудь родишь между делом.
Можно пример проекта который не решить на Голанге?
Согласен что он идеально подходит в основном для микросервисов на бэке, но ограничений там нет
Имхо наблюдается синдром вахтера, когда некую технологию отрицают, хотя она очень неплоха в своей отрасли
Тот же Питон так же хаем или нет? Хотя он откровенно убог и стал некой заменой Бейсика
Казалось бы, когда ты уже видишь общую картинку, самое время отправляться в самостоятельное плавание.
"Есть много причин стремиться быть одним из меньших."(С)
А в целом, благодарю за комментарий: вы избавили меня от необходимости писать самому многое из того, что написали вы.
На данной веб-странице есть ошибка: тут задротство называют эрудицией. Не путайте эти понятия.
Если рассматривать вопрос что мозг человека лучше чем LLM - на данный момент существенно лучше, но мы все всё равно пользуемся такими моделями даже не осознавая этого - переводчики, новости, изображения, видео контент, фильмы и прочее. Давно вошло в нашу жизнь, и такие модели дают лучший результат.
LLM слишком убоги для программирования? - не совсем, большая часть ими пользуется в разной степени увлечённости, возможно даже не осознавая этого. Автодополнение в тех же ide это тоже результат очень похожих моделей.
LLM не обеспечивают нужной степени гениальности в ответе ? Если есть материал, то можно дообучить, можно сделать экспертную систему. У кого нет своей экспертной системы? пусть она не структурирована, только уверен что откладывают понравившийся материал, и иногда и используют.
И большинство задач довольно однотипно; тут с текущими задачами хоть как то бы справиться в приемлемые сроки и лимитированные деньги - я вообще за последние 20 лет не видел ни одного человека, которому разрешали свободный поиск идей "на будущее". Видел целые отделы в крупных корпорациях, у которых в дополнение к рутине в заданиях стояли "генерация прорывных идей". Обычно они выдавали такую хрень, что это стыдно было озвучивать и отваливалось в первые две минуты обсуждения. А что ещё генерировали такие отделы? - полное незнание теоретической базы - это полный итог их деятельности.
Память человека склонна к забыванию, и без записей, без ide, llm, экспертных систем нам бы жилось намного труднее. И это не критика статьи - в целом я почти согласен, только где же нам взять таких интеллектуалов? ; скорее взгляд немного с другой стороны на эти же вопросы.
Работать с людьми — это специальный навык, во многом ортогональный умению решать сложные задачи и писать хороший код.
IMHO, очень правильно написано.
Дважды ходил в "начальники" - был "Техническим директором", был "Начальником отдела ДБО", но больше года ни там ни там не продержался. Понял, что мне не нравится сидеть на совещаниях, управлять народом... а более всего не нравится, что программировать приходилось всё меньше и меньше, и навык при этом терялся.
тоже несколько раз туда и обратно, с людьми работать нет проблем, если своим примером показывать, с начальниками труднее, редко адекватные встречаются, вверх по лестнице зависимость от начальника, или хозяев больше
Насколько я понимаю, уже на 3-4 уровне человек вырождается в передаста, ну может слегка творческого...
разное видел за несколько десятков лет в программировании, если проекты уровня гуано, то адекватные люди только случайно могут быть, мой опыт от principal до sw. director в больших компаниях us, чем интересней проекты, тем проще людей подобрать на всех уровнях,
в старом немецком воинском уставе было написано типа "отдать приказ командир имеет право только если уверен, что сам может его выполнить", вероятно это было бы полезно также тем, кто занимается разработкой sw, особенно руководителям
Сквозь строки читается:
"Знаете, я и сам своего рода LLM"
Хотелось бы, что бы все это было правдой для всех. Я не о том, что в статье все "правильно". Нет, дискуссионных и противоречивых моментов очень много. Я о том, что действительно можно конвертировать опыт, увлеченность, желание, знания в работу на которой можно будет себя реализовать. К сожалению, львиная доля джунов, мидлов, сеньоров сталкивается с совершенно с другой картиной мира.
Что бы дойти до вот этого преисполненного состояния автора очевидно нужно время. А когда на рынке от тебя требуют работу на результат их мало волнует эрудированность соискателя. Нет строчки в резюме по работе над проектами с определенным стеком? Тебе уже 50 лет, а ты хочешь сменить работу? А нафиг ты нам такой нужен? Уже на уровне айчаров тебя отсеют.
То что работало 5-10-20 лет назад оно точно работает сейчас? Точно у джуна, мидла, сеньора будет время преисполнится, и он не попадет под сокращение, а заодно и еще тысячи таких как он?
Я увидел больше акцент на то, что все это сработало для конкретно данного индивидуума, для конкретно данного времени. При этом как это работает системно в статье не затронуто.
Тупиковый синьёр или при чем тут эрудиция?