Comments 26
SO на батарейках и в режиме совсем черного ящика. Если на форуме вам еще напишут, почему оно так, то тут вы все делаете на свой страх и риск.
Вот бы встроить в IDE AI, которая будет писать тесты к уже работающему коду, выглядит, что должно быть под силу. Не настоящий разработчик, но для меня это самая рутинная и не любимая часть.
Тогда перед этим надо удостовериться, что код действительно рабочий. Ведь если есть баг в каком-то редком случае, то система будет распознавать такое поведение как верное, на что честно напишет тест
Кстати, да: я пользуюсь CoPilot, и с ним очень помогает следующее: в начале теста я пишу, что буду проверять в виде комментария. При наличии уже написанных 2-3 тестов он «подхватывает» и очень экономит время, зачастую выдавая целые блоки подготовки моков и проверки результатов. Эдакий контекстно-зависимый интеллектуальный копипаст
так а что вам мешает сделать плагин? я например видел для vscode кажется, где автор просит chatgpt объяснить что делает декопилированный код
Есть же github copilot, tabnine etc
Предпоследний абзац. Архиверно. А работа потому и может состоять из того наполовину, что понаписанные библиотеки и повыдуманные интерфейсы и API на столько плохо структурированы и дурно документированы, что лазание по Гуглу и Стеку может составлять половину работы. Помогая с этим, a.k.a. «автоматизируя часть», AI инструменты позволят им быть ещё хуже структурированными и ещё плоше документированными.
ИМХО проблема стартовала на пути к катастрофе в тот момент, когда в программирование пришли деньги и основным результатом работы программиста стало приложение а не библиотека.
Резюмируя, я считаю, что в текущий момент современные AI модели ещё на слишком раннем этапе своего развития, чтобы полностью попытаться заменить в работе разработчика среднего уровня и выше.
Тут есть другой момент: эта штука уже в обозримом будущем будет мощным инструментом увеличения продуктивности в руках собственно опытного разработчика. А это означает, что он заберёт работу у кого-то другого, и это не обязательно будут не, кто предпочитает метод StackOverflow-Driven Development.
До сих пор никакой корреляции между ростом продуктивности и снижением количества разработчиков не было, хотя на каждом витке развития средств разработки об этом начинают писать тонны статей. Иначе программистов должно было бы сейчас быть меньше чем в 2000-м.
Иначе программистов должно было бы сейчас быть меньше чем в 2000-м.
Я программировал в 2000-м. Могу сказать, что период существенного роста продуктивности был за десятилетие до этого, он примерно совпал с ростом производительности компьютеров. С 2000-го года продуктивность существенно не выросла. Наоборот, когда в нулевых произошло смещение фокуса с десктопов в веб и мобильную разработку, продуктивность существенно упала, ввиду тогдашней отсталости инструментария на этих платформах. Только в последние годы оно как-то догнало десктопные средства разработки.
Также, есть и второй фактор, снижающий продуктивность, это усложнение библиотек, фреймворков и собственно кодовой базы существующих проектов. В 2000-е годы в скиллы одного программиста прекрасно помещались скиллы построения UI, логики приложения, знание используемой СУБД, и сопутствующие операции — сборка, создание дистрибутивов и так далее. Сейчас это всё разные специализации — фронт, бэк, дба, девопс.
Ну то есть вы сами подтверждаете, что само по себе наличие библиотек уже готовых, софта уже написанного и каких то чудо тулзовин сказывается на специализации, а не на количестве нанятого персонала. А на количестве сказываются другие факторы. Тот же вздутый и усиленный ковидом массовый найм джунов на космические зарплаты, а сейчас схлопывание этого пузыря. При всей очевидности искуственности раздувания и естественности в схлопывании, наверняка найдутся умники чтобы связать сокращение наймов с чатгпт )))
С 2000-го года продуктивность существенно не выросла
Конечно зависит от того, как считать продуктивность, но в целом нельзя согласиться с этим утверждением. Сегодня команда из 3-4х человек может слабать какой-то рабочий продукт буквально за пару недель. Есть удобные среды, готовые шаблоны и т.д. Да что там говорить, если в нулевых для контроля версий использовали, прости господи, VSS.
Кроме того, за счёт развития облаков, команда в несколько десятков человек может тянуть глобальный проект с миллионами и даже десятками миллионов пользователей. 20 лет назад такое даже представить было нельзя
Сегодня команда из 3-4х человек может слабать какой-то рабочий продукт буквально за пару недель
А как вы думаете, двадцать лет назад рабочие продукты лабались как-то иначе? Откуда этот миф, что в каменном веке двадцать лет назад пещерные программисты на каких-то жутко неудобных штуках долго и мучительно собирали софт из каких-то мелких кусочков, а потом так же мучительно его отлаживали? Двадцать лет назад у вас был фреймворк, создающий каркас приложения в пару кликов, у вас был визуальный дизайнер, который позволял быстро мышкой набросать UI и прям в дизайнтайме смотреть на его поведение, у вас были ORMы для работы с данными, где можно было легко строить запросы, и всё это биндилось к UI опять же таки, в дизайнтайме. Для коммуникаций через веб у вас не было REST, но был SOAP, который делал всё то же самое пусть и с бОльшим оверхедом, но зато это была RPC-модель, да с самоописанием, да с контролем данных, и с возможностью автоматически генерировать код клиента по описанию. Для контроля версий был популярен VSS, ну опять же таки, он не так уж и плох, это просто другая парадигма. Да, вы не могли одновременно работать над одним и тем же файлом. Но зато вы не могли и внести конфликтующие изменения, которые потом надо мучительно больно мерджить, и благодаря вынужденной синхронизации девелоперов друг с другом все знали, кто что меняет.
Поэтому нет. Если вы отмотаете ещё на десятилетие назад, то да. Но качественный скачок произошёл между «30 лет назад» и «20 лет назад», и с начала нулевых продуктивность действительно практически не выросла, просто сместился фокус на другие платформы и другие задачи.
Кроме того, за счёт развития облаков, команда в несколько десятков человек может тянуть глобальный проект с миллионами и даже десятками миллионов пользователей
Ну как… вы же не забываейте, что там где-то есть другая команда, которая обслуживает всю эту инфраструктуру. За очень немалые деньги.
Откуда этот миф, что в каменном веке двадцать лет назад пещерные программисты на каких-то жутко неудобных штуках долго и мучительно собирали софт из каких-то мелких кусочков, а потом так же мучительно его отлаживали?
оттуда, что JUnit, например появился, как раз 20 лет назад. До этого юнит-тесты писать было нечем. Без юнит-тестов всё мероприятие скатывается к мучительной отладке.
Двадцать лет назад у вас был фреймворк, создающий каркас приложения в пару кликов
Но не было веб-приложений. Соответственно, прекрасный каркас приложение превращался в увлекательный квест под названием: "а почему это приложение у этого клиента работает, а у того — нет?"
Для коммуникаций через веб у вас не было REST, но был SOAP, который делал всё то же самое пусть и с бОльшим оверхедом, но зато это была RPC-модель, да с самоописанием, да с контролем данных, и с возможностью автоматически генерировать код клиента по описанию
Это если повезло. А если нет, то DCOM.
Для контроля версий был популярен VSS, ну опять же таки, он не так уж и плох, это просто другая парадигма.
Да, вы не могли одновременно работать над одним и тем же файлом
Вы опровергаете себя следующим же предложением.
Поэтому нет. Если вы отмотаете ещё на десятилетие назад, то да.
Туда уложился переход с перфокарт на персоналки. По-этому, там, конечно был просто тектонический сдвиг и он несомненно был куда больше чем между 20 лет назад и сейчас. Но это не делает последний мелочью.
Ну как… вы же не забываейте, что там где-то есть другая команда, которая обслуживает всю эту инфраструктуру. За очень немалые деньги.
Естественно. Рост производительности за счёт разделения труда. Столбовая дорога цивилизации.
Без юнит-тестов всё мероприятие скатывается к мучительной отладке.
Хм. Почему? Я пользуюсь тестированием, но какой-то серебряной пули в TDD в упор не вижу. Существенная выгода есть на проектах определённой сложности, и главное — определённой связности.
Но не было веб-приложений. Соответственно, прекрасный каркас приложение превращался в увлекательный квест под названием
Вы так пишете, как будто эта ситуация — обыденность, а не один из стапицот случаев, как и сейчас бывает.
Это если повезло. А если нет, то DCOM.
Бывало. И что? Он вполне себе работал. Вот CORBA…
Туда уложился переход с перфокарт на персоналки.
… эээ, какие перфокарты в 1990-е? Их даже в 1980-е уже далеко не в каждом ВЦ было можно найти.
Со статьей полностью согласен, но в теории, в будущем, если грамотно обучить ИИ под конкретные узконаправленные задачи вашей компании, например, я думаю она вполне будет способна выдавать боевые решения. Но даже в этом сценарии кто то должен заниматься обучением и править код, доводя его до необходимого функционала. Тут история мне кажется как с конструкторами сайтов- можно конечно реализовать простой сайт на конструкторе, но как только нам нужно что то узконаправленное или максимально производительное на помощь приходит разработчик.
Но если ваша работа более чем на половину состоит из обращений к Google, работе со StackOverflow и другими публичными источниками и компиляцией информации оттуда в код, то я бы серьезно озадачился.
У меня у одного так? Все остальные знают какую-то магию программирования?
Через год вы удивитесь на сколько устарела данная статья)
вот это вот обучение на open source, а ведь в open source выкладывают и проекты закрытые к копированию и воспроизведению...
Программы пишут программы, или стоит ли разработчикам осваивать новые профессии