Comments 116
Угу, разгружает мидла, делая его вечным мидлом. Былаб моя воля - давал-бы ГПТ помощников сеньерам и выше, ибо мидлам нужна практика и оттачивание целой кучи навыков, которое происходит во время обдумывания и написания кода. Но, похоже, это уже не остановить.
Ну почему, с диким кол-во ошибок у chatgpt его готовые решение Г . Частое забывание контекста и галлюцинации. Не возможность сделать то, на чего у него не было обучение, а при схожести задачи на другом языке , он будет вечно совать функции оттуда. Как быстрая справочная или быстро сделать шаблон и какие то вещи да, но без погружение контекста, человек не сможет распознать псевдо код, лишние вещи. Поэтому мидл все равно будет топать к сеньеру :)
>Частое забывание контекста и галлюцинации.
Купите подписку, GPT4 может несколько дней к ряду держать контекст. Проверено на практике. Как раз заменяет мне ассистента-миддла. Но выдавать его "в помощь" джунам или миддлам я бы не стал. Как сказал комментатор выше - это их погубит.
Дело не в днях, а в количестве токенов, которые может хранить модель.
При каждой отправке сообщения обрабатываются последние 8к (а может уже 32к?) токенов, в бесплатной же версии - 4к.
Плюс, в четвёрке вполне может быть другая токенизация для русского языка.
Разумеется о токенах. Но я имел ввиду 4 полноценных рабочих дня с кодингом и сложным контекстом в рамках одной сессии. В течение которых, если нужно, можно было апеллировать даже к самым ранним сообщениям. Скажем так, при работе в том же режиме, версия 3.5 ловила симптомы размытия контекста уже спустя час-полтора.
В четвёрке, думаю, еще какие-то оптимизации накрутили сверху. Такое чувство, что контекст вне "горячего окна" не откидывается, а как-то упрощается, заменяясь на более абстрактные конструкты.
Не знаю, я пробовал с ним (в смысле с gpt) разобраться в одной задаче, он меня запутал - терял контекст, менял ответы, дал вообще противоположный. В общем мне не понравилось. Но вот тесты на простые классы (не те где есть прям очень интересная логика) он пишет действительно неплохо, но контекст все же теряет - правда юзал я 3.5 модель (платную), не 4.
Рукалицо. После "не знаю" мог больше ничего не писать. Действительно не знаешь. Ты бы ещё gpt2 использовал.
Тебе ЯВНО сказали про gpt4.
Ты чего такой токсичный то? Я не сильно верю в улучшения после того как оно мне несуществующую либу предложило :)
Улучшения будут. Но ещё очень важно правильно к нему обращаться. Я видел примеры, когда ему пишут, например, "придумай решение такой-то задачи", а потом ругают, что он использует выдуманные библиотеки, либо выдуманные API и тд.
Надо помнить, что это все ещё компьютер, и что он делает то, что мы просим его сделать.
Особенно, когда речь идет о 3.5, которую хлебом не корми, дай погаллюционировать. Четверка не в пример мощнее и стабильнее.
Потому что я очень сильно верю в то, что мнения "не читал, но осуждаю" не стоят и выеденного яйца
Между 3.5 и 4 разница - небо и земля. 3.5 после четвёрки кажется деревенским дурачком :)
С ним далеко не уехать, если речь идёт о чем-то, что требует хоть какой-то "усидчивости". А если еще и код большой, то 3.5 начнет бредить разочаровывающе быстро. Четверка стоит 20 баксов, но... оно того стоит. Если плотно пользоваться, покупает себя с лихвой.
Как раз заменяет мне ассистента-миддла.
А это как? Middle Developer - это же специалист, а не секретарь. Если нет микроменеджмента, то у человека будет долгая задача (на месяцы), которые сам человек разбивает на более мелкие куски (с небольшой помощью от команды), а потом постепенно создает PRы, которые более-менее легко читаемые.
А что значит "ассистента-миддл"?
А это значит ассистент, для которого декомпозицию и четкую формулировку делаю я, именно на микроменеджменте, но скилл в плане кодинга у него на уровне миддла. Простые задачи, которые мне лень кодить, решает на отлично даже при довольно низкой декомпозиции. Сложные решает сносно, но при очень высокой декомпозиции. Электронный code-monkey, в общем.
Я понял. Понятно, что тут вопрос в терминологии, но это ближе к стажеру/интерну, ибо тот же выпускник уже умеет навык самостоятельной работы (курсовые, дипломы и тд).
Навык самостоятельной работы это хорошо, но еще есть вопрос навыка программирования и знание матчасти, которое у выпускника и миддла будут на совершенно разных уровнях.
Вот и выходит, что по уровню скилла эта штука сойдёт за миддла, но по глубине интеграции в процесс разработки - за кодера-ассистента.
Кодить умеет, разрабатывать нет :)
Вы точно видели мидлов? Миллы вот такие задачи как в статье делать уже не будут. Они доходчиво расскажут что это глупость. И быстренько нагуглят какое-то автоматическое решение. Не лучшее, но мидлы таки.
Вы говорите о стажерах в лучшем случае. Но в целом и стажеры умнее. Они коре таких глупостей могут что-то нормальное писать временами. В отличии от.
А можно немного конкретики? Просто насчет навыков программирования GPT-4 имеются и другие мнения (1, 2). Опять же, в декабре-январе было много рассказов уровня "Как мы джунов/миддлов с помощью ChatGPT заменили" (иногда заменяли даже сеньоров), но вот код показывать никто не спешил. Итог мы знаем. Сейчас происходит то же самое, только теперь с GPT-4. Потому такие истории вызывают недоверие.
К слову говоря, на фоне неприличной кучи рекламы уровня "Научим вас работать с нейросетями, покупайте наш курс со скидкой в 50% всего за 20000 рублей" фразы уровня "ChatGPT дурачок совсем, а вот GPT-4 и контекст держит, и код пишет как миддл" со стороны выглядит как деятельность инфоцыган. Так что возникает ещё более сильное желание увидеть примеры задач, код для которых написан GPT-4.
Спорно, мы экономим время на простых задачах чтоб заниматься более сложными и качать скилы)
также заберите у них ide, помню были ребята которые считают IDEA продуктом дьявола.
у меня есть коллега, который юзает chatgpt, - возник вопрос, ну и зачем мне тебе столько платить тогда?
За выполняемую работу. Не?
если в конторе все стоят за кульманами, а кто-то освоил автокад и применяет его в работе, причём результат всех устраивает, это повод платить ему меньше?
А вы юристу, например, платите за знания и опыт или за "выполняемую работу"? Или например... автодиагносту вы платите за умение найти хитрую неочевидную поломку в вашей машине или за умение закрутить гайку?
Думаю что скорее первое, т.к. закрутить гайку может любой Васян за сильно меньшую сумму.
Так и тут: есть виды работ где чат жпт выдает или лень или непрофессионализм
А если ваш Васян за свои деньги купил себе УльтраГайковёрт3000 и крутит их в 3 раза быстрее, вы ему тоже побольше работы накидаете?
Будет к этом устремится. Мы с вами смотрим с позиции обычного работника, вот задача вот оплата, если одно выполнено, то второе перечислят на карточку. А капиталист видит ресурс, раз васян 2/3 времени ковыряется в носу, значит это свободный/неиспользуемый ресурс, значит ресурс надо либо использовать, либо выбросить иначе оплата неиспользуемого ресурса это убытки.
Когда коллеге не будет смысла платить ему платить перестанут. В текущий момент времени коллега с чат-гпт должен стоить дороже чем без него, потому что его производительность выше при прочих равных. Сейчас и чатик и копилот - инструменты для ускорения набора бойлерплэйт кода в первую очередь и замена гугла во вторую. Т.е. неленивый разработчик условно тратит на задачу - восемь часов на чтение документации, восемь на обдумывание и реализацию, восемь на написание тестов и документирование. Ленивый - тратит три часа на анализ документации с помощью АИ, те-же самые восемь на саму задачу, и час на тесты и документацию. В результате за 3SP ленивый разработчик закрывает две таски, а неленивый одну.
инструменты для ускорения набора бойлерплэйт кода в первую очередь
Я! Я! У меня такой инструмент есть! Копипаста называется!
(Ну, на самом деле макросы в FAR-е, но тем не менее).
вы немного не поняли из примера, что у нас с вами разные отрасли...
В текущих условиях его производительность - фикция, потому что никто не доверяет результатам такой работы. Причем фикция трудно и долго проверяемая
Не спорю с сутью, но все же режет глаз такое исполнение слова лень. Работник, который делает работу быстрее это не ленивый работник, а трудяга. Ленивый работник это тот, который нихрена не делал, пинал балду, а потом, когда проспал все сроки кое как сделал на отстаньте.
Сейчас и чатик и копилот - инструменты для ускорения набора бойлерплэйт кода в первую очередь и замена гугла во вторую.
Вы знаете, я пробовал. По итогу тратилось больше времени и усилий, на проверку того что он нагенерировал/сообщил (как замена гугла, да).
Вот таски типа "перепиши этот текст в более вежливой форме" - норм в принципе.
Особенно учитывая, что производительность у него, в отличие от коллег, стала в разы больше...
Что ж, плати тому, кто решает задачи медленнее, зато сам. Есть же любители ручной работы, ничего плохого в этом нет. Но ниша узкая, конечно.
Спрос на джунов упадёт. Минусами этого не изменишь.
Спрос на джунов не упадет. Упадет спрос на недоучек со скиллбокса, которые отслушали курс "освой 5 профессий за 3 месяца" и штурмуют галеры, называя себя джунами. А слово "джун", в итоге, снова станет означать то, что должно - "полноценный специалист с профильным образованием, но отсутствием\нехваткой реального опыта".
Автоматизация не пощадит и их. У гениев существенно выше среднего проблем не будет, однако "выше среднего" себя считают очень многие. Сравните с кузнецами. Спрос на них есть, но он совсем небольшой, потому что очень много автоматизировано.
Автоматизация кодинга - благо. Однако, она не лишит специалиста рабочего места. По своему опыту:
1) Чатгпт - отличный кодер, но ужасный разработчик. Он не умеет решать сложные задачи без предварительной декомпозиции. Но если ему разжевать желаемое от и до, он отлично это реализует в коде. Вывод - разработчик все ещё нужен. Даже джун-разработчик все ещё нужен. Просто потому что в декомпозицию он уже может, а стоит дешевле миддла. А вот code-monkey с очередных 3-месячных курсов, который, зачастую, совершенно беспомощен, конкуренцию с чатгпт не выдержит, факт.
2) Чатгпт - отличный кодер, но его код обязательно нужно ревьювить. Иногда приходится давать ему фидбек, чтобы вносил правки, если где-то выбранный путь решения не устраивает. Вывод - ему все равно нужен человек, не только на "входе", но и на "выходе". И нужен не "гений сильно выше среднего". Нужен просто специалист, уровень квалификации которого соответствует задаче. Для джуновских задач и джун подойдёт.
Автоматизация никого не убьёт, скорее профильтрует рынок кадров. Повысит требования по качеству к джунам. Это все пойдёт только на пользу индустрии.
Эта штука - такая же революция, как и IDE в свое время. Но, как и IDE, это инструмент, совершенно бесполезный без специалиста рядом. Каким бы крутым этот инструмент ни был.
Я пользуюсь им каждый день. Пишет ли он за меня код? Да, и много. Но разработчик этого кода - я. Ревьювер - я. В чистом виде он редко идет в работу, я его интегрирую. По факту эта штука не автоматизирует мою работу как разраба. Она снимает с меня рутину кодинга, экономя тонну времени именно для разработки, повышая производительность. Но если не понимать, что происходит, не знать специфику, каши с ним не сварить.
Опять же, ему нет смысла ставить глобальные задачи. Глубокая декомпозиция -> решение атомарных подзадач -> интеграция.
отличный кодер, но ужасный разработчик. Он не умеет решать сложные задачи без предварительной декомпозиции.
А знаете, как называется декомпозированная задача, записанная языком, не допускающим двояких толкований? "Код".
Не всегда. Иногда такое называется "список требований".
Не соглашусь. Она называется "алгоритм". Код - это конечная реализация алгоритма в конкретном языке.
В принципе да, но преобразование алгоритм -> код тривиально (а мы уже договорились, что двоякие толкования исключены).
А я не говорил, что это преобразование - сложно. Это просто, да. Как перекладывание бумажек, например. И, как перекладывание бумажек, это чисто формальная рутина, которая, тем не менее, отнимает время... Сокращение этого времени повышает производительность. Собственно, цель любой автоматизации - снижение рутинной нагрузки.
Имхо, спрос упадет как раз на миддлов.
Джунам работа будет - вручную править ошибки в сгенерированном коде. Сеньорам тоже - ставить задачи. Миддлы - в пролете.
У вас деньги платят за кодинг ручками или за результат?
Извиняюсь за нелепый вопрос, а что вы тестируете в dto: как язык умеет отрабатывать setter и getter?
Может это специфика php...
Видимо GPT на большее не способен. Тестить такую рутину не обязательно, если там всё обложено типами, ну разве что в погоне за процентом покрытия всего кода
Это не специфика, а нелепые тесты. В данном случае мы имеем какой-то массив данных и просто куча методов пустышек. Профита от такого кода 0.
В разных компаниях разные требования к реализации. Чаще всего требуется полное покрытие того функционала что ты написал, дабы не уменьшать общий coverage
Спасибо, а то я сначала не понял чё вообще хотели такими "тестами" добиться. Думал может это я плохо язык всё ещё понимаю.
Класс DTO, который надо покрыть unit тестами
И нам тут прям никак без одной из самых замороченных систем на свете стоимостью в миллиарды баксов.
Это же тупо через рефлексию и метапрограммирование решается. Самым обычным посконным алгоритмическим кодингом. Причем решается со 100% точностью раз и навсегда и потом тиражируется на все другие DTO в пару кликов.
Пример намеренно взят самый примитивный в статье на это делается упор)
Пример даже не примитивный, а бессмысленный.
Вот на реальной задаче было бы интересно
Понимаете, вне зависимости от примитивности задачи, ее можно решать по-сеньорски или по-джуновски. Вот у вас на пару с Чятиком получилось прям махрово по-джуновски. Потратить время на промпты и родить одноразовое решение - это вот вообще ни разу не "ChatGPT помогает разгрузить Middle разработчика". В сухом остатке Чятик вам никак не помог. Он, например, не заметил, что его просят сделать какой-то бред и не подсказал обобщенное решение. Произошел типичный garbage in garbage out. Вы тоже не стали скилловее, т.к. на заметили, что здесь просится обобщенное решение и, соответственно, не написали его. На успех Чятика в реальных типичных миддловских задачах вообще рассчитывать не приходится.
Не могли бы вы уточнить, что такое обобщённое решение?
Очевидно, решение, которое автоматически проверяет все геттеры/сеттеры для имеющихся в классе полей. С циклом.
Если бы у меня в конторе стояла задача 100% покрытия дата-классов, то я бы написал плагин и джобу для Gradle/Maven (пишем на JVM) для генерации этих тестов по классам в заданной директории или по маске имени файла. Потом бы вся контора этим пользовалась. А потом бы еще на гитхаб выложил, чтобы на собесах козырять.
Интересно за что минусуют? Я спросил потому что не знаю правильного ответа.
На Хабре разный контингент. Что бы вы ни сказали, всегда найдётся кто-нибудь, кто будет чем-то недоволен. Причин масса - "вот только не надо подкалывать", "нечего дурость тут свою демонстрировать", "я слишком ценю своё время, чтобы читать комменты-пустышки" ну и т.д. Слишком большая аудитория слишком разных людей. Я как-то сформулировал и опубликовал тут же свой ответ на вопрос "почему минусуют" - "потому что могут". Забанили на год под предлогом "вас взломали!". Ну, вот так это тут работает. Просто не относитесь серьёзно к минусам и банам :)
Осталось понять, на кой хвост здесь ChatGPT, когда задача "покрыть кусок кода 100% тестами" элементарно алгоритмизуется (просто написанием тулзовины, которая бы это делала, никто не заморачивался).
Кстати, PVS-Studio( @Andrey2008), не желаете заняться? Это ж прямо-таки по вашему профилю.
просто написанием тулзовины, которая бы это делала, никто не заморачивался
На гитхабе есть https://github.com/search?q=php dto testing&type=repositories.
На мой взгляд, задачка для студентов и интернов на изучение рефлексии в языке.
Кстати, PVS-Studio( @Andrey2008), не желаете заняться? Это ж прямо-таки по вашему профилю.
А какой смысл в этих тестах? PVS-Studio должно без спаммерства в кодовую базу проверять такие участки.
testMissingPhoneValue()
Семь раз повторенный одинаковый тест у вас вообще ревью кода-то пройдет? Надеюсь нет.
Впринципе, если сначала писать код, а потом мучительно добавлять для него тесты, то наверное и правда в каком-то таком простом случае ChatGPT прямо поможет. Но кто же пишет тесты после кода )))
Что мы имеем в сухом остатке: чат достаточно неплохо справляется с решением примитивных задач, как в примере выше.
...вот только мне уже давно не надо решать такие примитивные задачи. А как только задача становится сложнее, выхлоп становится сильно хуже.
Клиентский код скармливаете ГПТ?
Вы сгенерили гору ненужного плохого кода. И зачем? Это точно поможет дальнейшей жизни продукта?
Такое тестировать не надо вообще. Да и писать скорее всего не стоит. Если очень хочется можно генерить любым подходящим классическим генератором. Их много на любой вкус.
Понимаю конечно, что суть статьи в демонстрации способностей ChatGPT и задание могло быть любым... Но зачем покрывать тестами геттеры DTOшки? И в названии кликбейт получается. Это явно не задача для "Middle разработчика".
это 3.5 или 4 ?
Да, пример unit теста на DTO идеален. Ведь DTO всегда имеют разветвлённую логику. отличный пример, который доказывает, что притянуть в проект ChatGPT - отличная идея.
Вот только один вопрос остался по итогу - вы действительно потратили бы на этот юнит 1-2 часа? Я навскидку однозначно могу сказать, что на Java написал бы его минут за 15 максимум (с проверкой на негативные и позитивные сценарии). Может это конечно специфика PHP, я с пыхой не друг…
Да, пример unit теста на DTO идеален. Ведь DTO всегда имеют разветвлённую логику. отличный пример, который доказывает, что притянуть в проект ChatGPT - отличная идея.
Это ведь ирония, правда? DTOшкам крайне нежелательно быть большими, они для аггрегации нескольких объектов в одном. Условно, они отлично подойдут, чтобы объединить Name, Surname, Middle Name в FullName.
Даже если говорить про Java (то есть про довольно бедный язык в плане таких вещей, по сравнению с другими JVM-совместимыми языками), то там было бы или:
record FullName(@Nonnull Name name, @Nonnull Surname surname, @Nonnull MiddleName middleName){}
или
@Value
class FullName {
@Nonnull Name name;
@Nonnull Surname surname;
@Nonnull MiddleName middleName;
}
Так что тестировать такой класс не пришлось бы, ибо корректность кода мы перекладываем на язык/генератор.
Если говорить про DTO с разветвлённой логикой, то они перестают быть DTO (просто по определению). Мне кажется, что самое близкое к ним - это Rich Domain Model, а это очень спорный подход в контексте расширяемости, ибо сложный объект очень и очень сложно будет разбивать в будущем.
Так что тестировать такой класс не пришлось бы, ибо корректность кода мы перекладываем на язык/генератор.
Да вот не фак. Рекорды ещё ничего, но вот Lombok это сложная библиотека и не факт, что вы правильно расставите аннотации. Плюс там таки встречаются баги, хотя это уже реже.
Вот именно поэтому я против использования lombok. С одной стороны приятно спрятать лишний код, а с другой - может быть неочевидно что конкретно там спрятано + возможные и труднонаходимые баги в этом + вот это вот "не факт, что вы правильно расставите аннотации" и можете и не заметить этого.
С одной стороны приятно спрятать лишний код
С моей точки зрения польза от lombok не в том, что можно спрятать лишний код, а в том, что можно добавить в класс поле и к нему автоматически сгенерируются все обвязки. И геттеры и сеттеры и конструктор и билдер и всё остальное. Чтобы убедиться, что я ничего из этого не забыл - нужны юнит тесты. Точно такие же, как к ДТО с использованием lombok, только более подробные.
По итогу мне не нравится lombok, но я за его использование, потому что без него получается ещё хуже.
и к нему автоматически сгенерируются все обвязки
== "спрятать лишний код" :)
Чтобы убедиться, что я ничего из этого не забыл - нужны юнит тесты. Точно такие же, как к ДТО с использованием lombok, только более подробные.
И выходит так, что спрятав через lombok обвязку, приходится писать еще больше бессмысленного кода (юнит тесты на все это спрятанное).
И выходит так, что спрятав через lombok обвязку, приходится писать еще больше бессмысленного кода (юнит тесты на все это спрятанное).
Эти юнит тесты нужны не зависимо от того, пишет программист код сам или делегирует это lombok. Но если код написан вручную, то в юнит тестах ещё надо как-то проверять, что при добавлении нового поля, программист поправил код так, чтобы он его тоже обрабатывал. А если мы используем lombok, то это не нужно, потому что lombok делает это за нас
Эти юнит тесты нужны не зависимо от того, пишет программист код сам или делегирует это lombok.
Я вот про это:
Чтобы убедиться, что я ничего из этого не забыл - нужны юнит тесты. Точно такие же, как к ДТО с использованием lombok, только более подробные.
Т.е. возникает необходимость тестирования простейших геттеров/сеттеров например.
Плюс к этому следующее:
Нельзя исключать баги в генерации обвязки. Да, я знаю, что по идее все должно тестироваться разрабами lombok, но это не гарантия.
Штуки вроде
AllArgsConstructorмогут провоцировать на антипаттерны со 100500 свойствами класса.Мне лень искать - как оно работает с AOP и рефлексией?
А если мы используем lombok, то это не нужно, потому что lombok делает это за нас
Лично мне вот не нравится, что lombok делает это за меня :) Так и базовые навыки и понимание работы кода растерять можно. А уж рекомендовать это джунам, например, я бы точно не стал.
А мне понравилось. Создаём некий массив а потом пишем стопку тестов на проверку того, что в массиве есть всё то, что мы туда написали. Хотя я, кажется, знаю как тесты немного упростить - надо просто получить весь записанный массив и сравнить его с тем что писалось, есть ведь и такой готовый тест в phpunit. Но если нет метода получить весь массив целиком, то да - каждый ключ по отдельности. Кстати, тест на то, что в том массиве нет лишних ключей напрашивавется. Но для этого надо сделать константы для всех ключей, константу массива всех ключей и тому подобные вещи, реализация которых займёт время, которое, разумеется, гораздо полезнее и интереснее потратить на общение с ChatGPT )
З.Ы. для тех кто не знаком с PHP - встроенный в язык массив здесь используется как Hash Map, ключи - строки, значения - строки. PHP - таки могучая языка! )
Название навеяло : "Как перестать беспокиться и начать жить?" (Дейл Карнеги) - Использовать ChatGPT :-)
Я работаю один, и частенько мне не хватает обсуждения задачи с кем-нибудь. Особенно, когда есть дилемма. Чат может озвучить дополнительные аргументы для того или в другого варианта.
IMHO, тестирование DTO — это уже карго-культ. Тест проверяет логику работы. Что вы проверяете в DTO — правильно ли геттеры и сеттеры скомпилируются? Или вы полагаете что любой тест, проверяющий процессы вокруг этого DTO ни разу не вызовет геттер и сеттер? Сначала придумали себе не пойми что, потом притянули AI решать несущетсвующую задачу… Как дети, ей богу!
А где же дтошка соответствующая финальному тесту? Та что приводится вначале не пройдёт его вторую половину, её можно создать из пустого массива, по тестам должна быть ошибка.
Вот она, долгожданная финальная структура теста, который можно затащить к себе в проект
Серьёзно? Закроем глаза на то что это тест дто (и на то что не того, что в статье), но вот он в остальном таком виде вас устраивает в проекте?
Там треть методов имеют идентичное тело и вводят в заблуждение своим именем - по именам набора тестов можно предположить, что каждое поле в дто обязательно, по факту же проверяемый объект для удовлетворения этим тестам должен допускать отсутствие любого поля в момент создания, но не всех одновременно. Кроме того, протестировано создание с частичным присутствием полей, но не протестирована логика чтения отсутствующего поля.
И это всё подозрительно. Скорее всего тест некорректен, а объект позволяет слишком многое.
Теперь про исходную дтошку. Прекрасная штука. Жрёт на вход что угодно, лишь бы в массиве и помалкивает, бережно хранит всё это в себе, даже если оно ей не упёрлось, вытаскиваем содержимое по ключу, но зачем то через хэлпер Arr, падаем только при несоответствии типов в момент чтения и то при strict_types=1. То есть по системе могут гулять захламленные лишними данными, невалидные объекты и наткнемся мы на ошибку в непредсказуемый момент в непредсказуемом месте. Читать чудо дтошку надо видимо в try catch.
Ну и вишенка - статанализ видимо в проекте отсутствует.
как не делать 1-2 часа 5 минутную задачу
final readonly class UserCrmDto
{
public function __construct(
private string $phone,
private string $id,
private string $pwd,
...
) {
}
}тесты не требуются.
и отписать в задаче, что потратили на это 2 часа времени
А через месяц PM такой - «коллеги, мы же знаем, что вы на эти задачи тратите 5 минут - пишите актуальное время и не завышайте». И себе такую ачивку за повышение перфомансов команды добавят ?
1) а не проще самому было сделать? У меня бы на 2м промте терпение закончилось, наверное
2) может это и не по канону, но все эти проверки умещаются в 1 тест, где потом сравниваются 2 списка, исходный и итоговый. А по сути, этот тест проверяет правильность написания строковых литералов-ключей
Святая вера в то, что нейросеть не сможет ошибиться и покроет именно то что нужно именно теми тестами которые нужны?
Ну-ну...
Не хочу показаться луддитом, но что-то мне видится в этом нехорошее.
О, прям дежавю какое-то словил. Недавно пытался (в какой-то мере успешно) заставить его написать скрипт в powershell для отработки invoke-command вложенных друг в друга, когда во внутренний передаётся аргументом список серверов, а внешний отрабатывает по другому списку (может тут сумбурно написал, но лень вспоминать как я формулировал).
В общем - он реально может сделать, если учесть что "правильно заданный вопрос - половина ответа". То есть нужно писать запросы максимально точно, максимально понятно и достаточно подробно (но при этом кратко). Иначе он в первом ответе что-то напишет, после дополнений он может добавить что-то как надо, а дальше забывает какие-то детали из исходного запроса и может что-то сделать не так. Но самое обидное - можно потратить много времени, но не добиться результата просто потому, что этот AI вполне может выдать некорректные результаты (да, типа галлюцинаций). Я пытал его довольно долго как сделать авторизацию при выполнении invoke-command, так как мог выполнить команды на удалённых серверах, но эти сервера не могли уже дальше пройти и выполнить команды на других серверах по списку. В интернете попалось вот такое: "В данном случае мы столкнулись с проблемой второго шага (Second-hop). Она заключается в том, что находясь в удаленной сессии нельзя подключиться к другому компьютеру со своими учетными данными. По умолчанию передача учетных данных по сети запрещена." Об этом нюансе AI упорно молчал и всё делал так, будто нет таких ограничений.
Если нельзя (не получается) сформулировать достаточно коротко все важные нюансы задачи, то в итоге придётся самостоятельно разбивать её на короткие, и "скармливать" ему эти части, а дальше объединять самому. То же вышеописанное я частично решил как хотел, но заставить AI сделать, чтобы все запросы выполнялись параллельно, но первого уровня через foreach - так и не вышло. То он в одном месте не так сделает, то в другом, в итоге не работает как надо, и приходится доделывать самому.
При этом я заметил, что его вполне можно использовать как "программиста-джуна", при этом быстро и бесплатно получать результаты (но также с ошибками и не всегда то, что просили). И в целом - ускоряет работу. Вместо того, чтобы загуглить какой-то вопрос, почитать документацию, посмотреть какие-то форумы и найти хоть какие-то ответы, потом с их учётом сделать что-то -- можно просто задать 2-4 вопроса к AI, и получить то же самое, но заметно быстрее. Но нужно владеть предметом вопроса, то есть иметь возможность проверить то, что он выдаст - я не удивлюсь если на 1 апреля он выдаст кому-то посреди скрипта rm -rf --no-preserve-root /, и кто-то использует это не глядя...
О, вы смоги от него хоть что-то дельное получить, это успех :)
Я сколько не заходил к электронному болвану - он такое фэнтэзи выдает, что просто шик. Очень красиво, но не работает ни сразу, ни после переделки.
Хотел, чтобы он мне с nginx помог - не, отказать, самостоятельно прочитанные маны и никак иначе.
Хотел хитрый вариант ленивого таск-менеджера - получил ответы в стиле кулинарных реврайтов "Впервые рис начали выращивать...", ну, вы знаете. По существу никаких новых разумных идей у него в базе нет.
В продвинутом тайпскрипте он тоже как курсер на собесе.
К счастью для программистов, нейросети пока бесполезны для программирования. Не встречал ни одного примера их полезного применения для этой сферы.
Недавно нужен был прототип из говна и палок, чтобы просто работало. Чатгпт и копайлот вместе сэкономили мне наверное процентов тридцать рабочего времени которое я бы так и так потратил на написание всякого разного бойлерплейта. Особенно с учетом того что сам я уже программирую не то чтобы много - сильно глубоко ушел и в менеджмент и в инфраструктуру - а значит руки еще помнят, конечно, но уже не прям так как раньше.
Прям натурально просишь сделать на реакте и mui компонент с фабом и всплывающей менюшкой и чтобы там прямо в этой менюшке еще инпут появлялся (что кстати вряд ли соответствует гайдлайнам, но у нас же прототип), потом просишь перевести в тайпскрипт, потом с mui 4 на mui 5 - прекрасно работает. Копайлот штуки типа валидации grpc запросов со всякими заковыристыми енумами, да и просто базовые обработчики по перекладыванию объектов из реквестов в сервисы, да и сами сервисы в общем-то (невелика уникальность) щелкает на раз.
Все это позволило мне просто сосредоточиться на действительно важных и сложных аспектах прототипа и не тратить время на то, на что его тратить не стоит.
Другой очень хороший юзкейс для копайлота это когда пишешь на незнакомом языке или инструменте. Т.к. он продуцирует в большинстве случаев весьма типичный код, влиться становится проще и быстрее. Но нужна некая "начитанность", конечно (ну или сеньерность, если хотите) чтобы понимать где оно нормальные вещи предлагает, а где ахинею.
Ну и да, это ведь только начало.
Согласен, неплохо работает, если незнакомый язык. Мне недавно потребовалось во фронтенде на JS что-то сделать, на котором я совсем не пишу (пару POST-запросов, и вывести результат в нужные поля в нужном формате). ChatGPT помог оформить значительно быстрее, чем если бы я сам упирался в мелкие детали реализации "где тут async и как его правильно написать? в каком формате приходит результат?" и пр.
Чатгпт и копайлот вместе сэкономили мне наверное процентов тридцать рабочего времени которое я бы так и так потратил на написание всякого разного бойлерплейта.
А некоторым это время уже который год экономит магия под названием "макросы"...
хороший юзкейс для копайлота это когда пишешь на незнакомом языке или инструменте.
Хм, весьма интересный вопрос. И как часто Вы нанимаее в свою команду, скажем, С++-разработчиков программистов, которые всю жизнь писали, скажем, на фортране и C++ для них "незнакомый язык или инструмент"?..
А некоторым это время уже который год экономит магия под названием "макросы"...
Они бы у меня были если бы я на постоянной основе что-то такое писал, да еще и однотипное. Но на постоянной основе я этим уже очень давно не занимаюсь.
Хм, весьма интересный вопрос. И как часто Вы нанимаее в свою команду, скажем, С++-разработчиков программистов, которые всю жизнь писали, скажем, на фортране и C++ для них "незнакомый язык или инструмент"?..
Вообще обычно нанимаем инженеров-разработчиков, а не с++ программистов. Но если хочется более конкретных примеров - то условным джавистам/котлинщикам нет-нет да и приходится лазить в питон или в гошечку или иногда даже в с# или в ноду, а фронтендщикам, например, в эту самую джаву/котлин. И ничего страшного в этом нет, растет экспертиза, растет скорость внедрения изменений, увеличивается уровень взаимопонимания.
По задачам сложнее можно написать скрипт, который бы повторял ему его же код при этом каждый раз попрошая что-то вроде: "ты уверен в коде?".
Из личного опыта: обычно для 99% работающего кода хватает около 26-28 таких повторений (число не преувеличено)
Сам пока не написал: лень.
Можно в этом плане глянуть на автогпт...
ChatGPT помогает разгрузить Middle разработчика: как за 5 минут сделать 1-2 часовую задачу