Лично я, вообще отказался от copilot, потому что он больше мешает, чем помогает. Он совершенно не понимает контекста и такое ощущение, что просто берёт код из чужих репозиториев, вообще никак его не меняя... Включаю его только для документации, переводов и прочей рутинной мишуры.
GPT чат использую с функционалом проектов. Прошу в основном либо найти баги (он это делает нормально, если настроить проект), сгенерировать боллерплейты, шаблоны, заготовки и т.д. Чаще всего он генерирует рабочий код, но требующий доработки. Так же, прошу его генерировать, не больше одного класса/модуля/компонента. Чем меньше код, тем лучше он его пишет. Прошу GPT не переписывать код при каждой правке, а описать кратко только варианты изменения. Так быстрее и понятнее. Под каждую задачу делаю новый чат в проекте. С таким подходом вполне удаётся быть более эффективным, при этом не теряя навык и не делегируя всё нейронке.
Далеко не всегда нейронка генерит, то что нужно. Более-того, она обожает уходить в цикл. Например, у вас ошибка в программе. GPT посоветует, допустим, откатить версию, какого-нибудь модуля. Ошибка не пропала? Обновите модуль обратно. Ещё есть ошибка? Удалите модуль и поставьте обратно. Ошибка сохранилась? Попробуйте эту версию модуля (ссылка на несуществующую страницу). И так по кругу, хотя ошибка оказывается вообще в другом месте и по другой причине, а модуль не причём.
Никто не отменял необходимость думать и тестить всё самому. Почти всегда пробежаться дебагером или посмотреть логи, поможет быстрее решить проблему, чем мучить GPT.
Имхо, но GPT, как тот самый мифический идеальный джун. Идеально знает теорию, но плохо кодит и решает проблемы.
Причём, часть отечественного софта вполне себе неплохая. Та часть, что создавалась частными компаниями на правах честной конкуренции. Как на зло они чаще всего и не могут просто получить нужные аккредитации. За то "правильные" компании получают всё необходимое создавая порой такую фигню... Да ладно компании. Помню в списке отечественного по от минцифры (вроде так она сейчас называется), видел буквально курсовые работы на вин формах...
После 2022 года миф «Россия — не IT-страна» начал разваливаться, но не потому, что все вдруг поверили в отечественные технологии, а потому, что альтернативы исчезли.
Дальше не читал... Как раз после 2022 Россия и перестала быть IT страной, а утечка кадров стала на уровне 90-ых. Причём огромное количество оставшихся программистов пытается работать на забугор никуда не уезжая банально, потому что больше возможностей и зарплаты. Я не знаю, вообще какие-то комментарии здесь нужно оставлять? Тема оторвана от реальности сильно, как в политическом аспекте так и в аспекте развития отечественного IT.
У gpt есть удобный функционал, в виде создания проектов. В проекте можно дать промпты, которые будут действовать на каждый чат в нём. Обычно там пишу стэк, особенности проекта и разные просьбы, по типу не использовать canvas для кода, писать комментарии и т.д.
Так же в проект можно добавить файлы. Как обычно делаю я. Беру только исходники с кодом проекта, без доп. библиотек и склеиваю всё в один txt файл по шаблону: имя файла код имя файла код, с разделителями. После чего загружаю в проект gpt. По итогу, качество ответов не ухудшается, а gpt, всегда пишет то, что нужно и в рамках проекта. Это очень круто и облегчает жизнь.
Конечно пропустил момент, когда определение вайб кодинга поменялось из написания кода ради удовольствия, например создавая интересные пет проекты в обычный скучный рутинный кодинг, где код пишет ИИ...
Думаю уже есть тестовые нейронки, что могут писать низкоуровневый код без абстракций. Только вот это порождает новые проблемы. Во-первых, чтобы обучить такие нейронки, нужен датасет, что очевидно. А откуда он возьмётся в должном количестве и качестве, да ещё и с контекстом задач, если на ЯП специально для нейронок или даже на полу машинном коде никто особо задачи не решает. Скармливать, то что начудили компиляторы? Так там эффективный код генерируется редко. Как подобный код тестировать и фиксить, если нейронка зашла в тупик, непонятно. Причём, не говорю про llm, которые для подобных задач, как раз не очень подходят, разе что для понимания задач от человека, чтобы передать их в правильном формате нейронке, что кодит.
Думаю, что АИ раздутость современного кода за нас не решит. Мы должны сами это сделать.
Знаете почему Дима получил повышение и бухает с начальником, а герой статьи получил только выгорание? Потому что, когда Дима гуглил "как тестировать API", наткнулся на рекламу Minervasoft, воспользовался их решениями и его дела пошли в гору. 😎
Касаемо тегов согласен. Наверное надо было пояснить какие случаи имею ввиду.) Например, если мы разрабатываем плагин для какой-нибудь CMS, то всё-равно придётся проставлять версии в основном файле плагина или каком-нибудь манифесте иначе CMS банально не увидит изменения версии. Я про такие случаи, для которых тегирование так же никто не отменял.)
Ситуация, когда взял задачу в обед, комит сделал вечером иногда может быть, при сложной задаче, где изменяется всего 1-2 файла. Например, при оптимизации или фиксе не очевидного бага с внешними сложными зависимостями. Понимаю, что имел ввиду автор, не нужно делать огромный комит с многими изменениями, лучше разбить его на несколько. Как по мне, это проще определить по названию. Если у вас в названии идут перечисления, например Fix account and add permissions явно видно, что это 2 комита, а не один. Если хочется назвать комит в стиле "Save changes", "State changes". То скорее всего изменений в нём столько и по разным задачам, что даже лень описывать и это ужасно. Почему так происходит? Самый банальный пример программист решает задачу, по ней появляется срочная подзадача. Часть кода по задаче уже написана, но пока не рабочая, а правки подзадачи нужно сделать сейчас. По итогу и задача, и подзадача идёт в один коммит. Этого можно избежать, используя git stash.
Очень желательно писать названия комитов всегда на английском языке. Даже если ваша команда работает только в России, даже если никто кроме вас код не увидит. Имхо, но это важно для единообразия. Если вы смените работу на интернациональную, то вам же проще будет привыкнуть писать комиты по новому. Так же с названиями комитов иногда бывают технические баги, когда например сервера со специфичными дистрибутивами линукса не поддерживают кириллицу.
Не согласен, что если работаешь один над проектом, нужно каждую задачу оборачивать в отдельную ветку. При работе в команде это правильно, но имхо когда ты один разработчик, проще вести 2 ветки (dev и main например) и/или использовать версии через теги. Понимаю, что "одна задача, одна ветка" это база, но мне кажется при работе одного разработчика с одним репозиторием немного избыточно.
Думаю стоит сказать о вроде очевидной, но частой проблеме. Если вы меняете окружение проекта или версию, всегда делаете это отдельным комитом. Даже если поменяли одну циферку, всегда это должен быть отдельный комит. Потому что на практике встречал такие моменты, когда истрия ветки скажем такая:
Change version 1.0.1
Fix smth
Change version 1.0.0
И вот ты решил откатиться до версии 1.0.0, думая что разница между версиями всего в один какой-то фикс, а оказывается, что в комит Change version 1.0.1 помимо изменении версии добавлено ещё дофига правок, которые тебе придётся изучать в коде. Хорошая история комитов - когда её можно скопировать почти без изменений в Change log проекта.
Ещё момент. Иногда нужно передать не рабочий код скажем коллеге. Порой проще и быстрее это сделать через комит. Делайте это только через unstable ветку (даже если в ней всего один комит), которую потом удалите. Если так вышло, что вы работаете в одной ветке вместе, то лучше прекращайте так работать и используйте принцип (одна ветка - одна задача), а на данный момент обязательно пометьте в названии комита, что он содержит проблемный код. Потому что сегодня вы сделали комит с поломанным кодом и проблему потом решили, через год вернётесь к коду и будете недоумевать почему, при загрузке комита ничего не работает вы же точно помните, как фиксили проблему. Опять же, эту проблему можно избежать при помощи CI/CD. Совет скорее маленьким командам в 1-3 человека, где часто git flow пренебрегают.
Либо у вас путаница в голове, либо вы слишком скомкано пишите.
Event loop (ноды), управляет асинхронными задачами в рамках одного потока, а менеджер потоков, что понятно из названия, управляет потоками (паралелит, балансирует, обеспечивает передачу данных между ними и т.д.). Как человек, который много писал на C# и хорошо знаком с работой потоков (не путать с асинхронностью, это не одно и тоже), немного не понимаю ваш тейк, что якобы event loop делает менеджер потоков, не нужным. Это 2 разных инструмента, которые используются на разных слоях приложения. В той же наде насколько я помню, потоки под капотом тоже используются, например для работы с файлами.
Так же для организации асинхронности event loop не всегда используется в разных яп. У C#, C++ и Java для асинхронности используются другие инструменты и подходы. Даже в Go о котором в статье речь используется насколько помню goroutine manager или как-то так.
Опять же почему личные данные парсят, вместо того, чтобы обратиться к рекрутинговым сервисам напрямую и не запросить официально обезличенную информацию для обучения нейронки? Всё же речь о взаимоотношениях юридических лиц идёт.
А так да, требования к сбору и хранению ДП в России довольно жёсткие. Сам с этим по работе сталкивался. Например, сервисы, хранящие определённые данные (например паспорта) должны получить для этого аккредитацию.
Во всех остальных случаях - против удалёнки только неадекватны, не имеющие видения, боящиеся что сотрудник недорабатывает, либо менеджеры, которые боятся остаться на улице за ненадобностью.
Причём именно на удалёнке толковые менеджеры намного более востребованные, чем в офисе, т.к. работы на удалёнке у них обычно больше.
Про эффективность тоже особо страхов не понимаю. Мне кажется в офисе куда проще держаться за рабочее место с плохой производительностью, чем на удалёнке. Видел разных работодателей. От тех, кто буквально поминутно просил трекать работу, до адекватных с подходом, чуть ли не со свободным графиком (т.к. международные команды, сильно разные часовые пояса). По моим наблюдениям работники во втором случае показывали результаты лучше, т.к. есть задача, есть дедлайн и есть всё для её решения при этом ничего лишнего. Обычно если человек не справляется с работой, на удалёнке это видно сразу. В офисе по моим наблюдениям это не так, хотя многое зависит от организации работы, если в офисе следят за каждым чихом, то понятное дело тоже быстро выявят.
Касаемо последнего тезиса, то он применим и к офису. Если человеку нравится работа, он будет работать с энтузиазмом, а если не нравится, то будет отлынивать, а зумеры просто убегут при удобном случае.
Команда из сениор-джавистов/дотнечиков с 15+ лет опыта набирается за месяц.
Команда из сеньоров это что-то странное, но видимо сейчас для части компаний это стало нормой. Причуды смещения грейдов по навыкам.
Да, это всё так, но мой вопрос был немного про другое. Условно я знаю gRPC на уровне просмотра 10 часового стрима и небольшой личной практики, а компания требует хорошее знание gRPC, то разве не будет враньём, если скажу на собеседовании, что знаю эту технологию твёрдо и чётко? По идее, это обман работодателя, чего лучше делать не стоит исходя из статьи.
Моё мнение, что лучше никогда не обманывать работодателя, касаемо хард скилов. Касаемо опыта, софт скилов и т.д. можно, т.к. это второстепенно, а вот хард скилы для программистов важнее всего.
Банальный пример с тем же Юрой, если бы он честно сказал на собеседовании, что плохо знает gRPC, то наверное работодатель не стал бы ему давать сложные задачи, с которыми он явно справится и Юре не пришлось "убегать после обеда". Я вот про это. 😊
Что-то многие сервисы сейчас подобное разрабатывают. Имхо но включение только платных комментариев для своего тг канала - это буквально совершить его суицид. Единственное, как можно было это грамотно реализовать, например сделать так, что платные комментарии всегда будут первыми в списке, это ещё как-то может жить, в остальном не вижу реализации, которая бы имела хоть какую-то пользу.
Лично я, вообще отказался от copilot, потому что он больше мешает, чем помогает. Он совершенно не понимает контекста и такое ощущение, что просто берёт код из чужих репозиториев, вообще никак его не меняя... Включаю его только для документации, переводов и прочей рутинной мишуры.
GPT чат использую с функционалом проектов. Прошу в основном либо найти баги (он это делает нормально, если настроить проект), сгенерировать боллерплейты, шаблоны, заготовки и т.д. Чаще всего он генерирует рабочий код, но требующий доработки. Так же, прошу его генерировать, не больше одного класса/модуля/компонента. Чем меньше код, тем лучше он его пишет. Прошу GPT не переписывать код при каждой правке, а описать кратко только варианты изменения. Так быстрее и понятнее. Под каждую задачу делаю новый чат в проекте. С таким подходом вполне удаётся быть более эффективным, при этом не теряя навык и не делегируя всё нейронке.
Далеко не всегда нейронка генерит, то что нужно. Более-того, она обожает уходить в цикл. Например, у вас ошибка в программе. GPT посоветует, допустим, откатить версию, какого-нибудь модуля. Ошибка не пропала? Обновите модуль обратно. Ещё есть ошибка? Удалите модуль и поставьте обратно. Ошибка сохранилась? Попробуйте эту версию модуля (ссылка на несуществующую страницу). И так по кругу, хотя ошибка оказывается вообще в другом месте и по другой причине, а модуль не причём.
Никто не отменял необходимость думать и тестить всё самому. Почти всегда пробежаться дебагером или посмотреть логи, поможет быстрее решить проблему, чем мучить GPT.
Имхо, но GPT, как тот самый мифический идеальный джун. Идеально знает теорию, но плохо кодит и решает проблемы.
Причём, часть отечественного софта вполне себе неплохая. Та часть, что создавалась частными компаниями на правах честной конкуренции. Как на зло они чаще всего и не могут просто получить нужные аккредитации. За то "правильные" компании получают всё необходимое создавая порой такую фигню... Да ладно компании. Помню в списке отечественного по от минцифры (вроде так она сейчас называется), видел буквально курсовые работы на вин формах...
Дальше не читал... Как раз после 2022 Россия и перестала быть IT страной, а утечка кадров стала на уровне 90-ых. Причём огромное количество оставшихся программистов пытается работать на забугор никуда не уезжая банально, потому что больше возможностей и зарплаты. Я не знаю, вообще какие-то комментарии здесь нужно оставлять? Тема оторвана от реальности сильно, как в политическом аспекте так и в аспекте развития отечественного IT.
Я бы даже сказал 2 комментария
У gpt есть удобный функционал, в виде создания проектов. В проекте можно дать промпты, которые будут действовать на каждый чат в нём. Обычно там пишу стэк, особенности проекта и разные просьбы, по типу не использовать canvas для кода, писать комментарии и т.д.
Так же в проект можно добавить файлы. Как обычно делаю я. Беру только исходники с кодом проекта, без доп. библиотек и склеиваю всё в один txt файл по шаблону: имя файла код имя файла код, с разделителями. После чего загружаю в проект gpt. По итогу, качество ответов не ухудшается, а gpt, всегда пишет то, что нужно и в рамках проекта. Это очень круто и облегчает жизнь.
Это скорее на какой-то дарк солс похоже.)
А сделал второй проездной и второй загран другой страны и ни о чём не жалею)
Конечно пропустил момент, когда определение вайб кодинга поменялось из написания кода ради удовольствия, например создавая интересные пет проекты в обычный скучный рутинный кодинг, где код пишет ИИ...
Думаю уже есть тестовые нейронки, что могут писать низкоуровневый код без абстракций. Только вот это порождает новые проблемы. Во-первых, чтобы обучить такие нейронки, нужен датасет, что очевидно. А откуда он возьмётся в должном количестве и качестве, да ещё и с контекстом задач, если на ЯП специально для нейронок или даже на полу машинном коде никто особо задачи не решает. Скармливать, то что начудили компиляторы? Так там эффективный код генерируется редко. Как подобный код тестировать и фиксить, если нейронка зашла в тупик, непонятно. Причём, не говорю про llm, которые для подобных задач, как раз не очень подходят, разе что для понимания задач от человека, чтобы передать их в правильном формате нейронке, что кодит.
Думаю, что АИ раздутость современного кода за нас не решит. Мы должны сами это сделать.
Эхх, про Defold не вспомнили. 🥲
Знаете почему Дима получил повышение и бухает с начальником, а герой статьи получил только выгорание? Потому что, когда Дима гуглил "как тестировать API", наткнулся на рекламу Minervasoft, воспользовался их решениями и его дела пошли в гору. 😎
Касаемо тегов согласен. Наверное надо было пояснить какие случаи имею ввиду.) Например, если мы разрабатываем плагин для какой-нибудь CMS, то всё-равно придётся проставлять версии в основном файле плагина или каком-нибудь манифесте иначе CMS банально не увидит изменения версии. Я про такие случаи, для которых тегирование так же никто не отменял.)
Как говорится это классика, это знать надо.)
От себя могу добавить:
Ситуация, когда взял задачу в обед, комит сделал вечером иногда может быть, при сложной задаче, где изменяется всего 1-2 файла. Например, при оптимизации или фиксе не очевидного бага с внешними сложными зависимостями. Понимаю, что имел ввиду автор, не нужно делать огромный комит с многими изменениями, лучше разбить его на несколько. Как по мне, это проще определить по названию. Если у вас в названии идут перечисления, например Fix account and add permissions явно видно, что это 2 комита, а не один. Если хочется назвать комит в стиле "Save changes", "State changes". То скорее всего изменений в нём столько и по разным задачам, что даже лень описывать и это ужасно. Почему так происходит? Самый банальный пример программист решает задачу, по ней появляется срочная подзадача. Часть кода по задаче уже написана, но пока не рабочая, а правки подзадачи нужно сделать сейчас. По итогу и задача, и подзадача идёт в один коммит. Этого можно избежать, используя git stash.
Очень желательно писать названия комитов всегда на английском языке. Даже если ваша команда работает только в России, даже если никто кроме вас код не увидит. Имхо, но это важно для единообразия. Если вы смените работу на интернациональную, то вам же проще будет привыкнуть писать комиты по новому. Так же с названиями комитов иногда бывают технические баги, когда например сервера со специфичными дистрибутивами линукса не поддерживают кириллицу.
Не согласен, что если работаешь один над проектом, нужно каждую задачу оборачивать в отдельную ветку. При работе в команде это правильно, но имхо когда ты один разработчик, проще вести 2 ветки (dev и main например) и/или использовать версии через теги. Понимаю, что "одна задача, одна ветка" это база, но мне кажется при работе одного разработчика с одним репозиторием немного избыточно.
Думаю стоит сказать о вроде очевидной, но частой проблеме. Если вы меняете окружение проекта или версию, всегда делаете это отдельным комитом. Даже если поменяли одну циферку, всегда это должен быть отдельный комит. Потому что на практике встречал такие моменты, когда истрия ветки скажем такая:
И вот ты решил откатиться до версии 1.0.0, думая что разница между версиями всего в один какой-то фикс, а оказывается, что в комит Change version 1.0.1 помимо изменении версии добавлено ещё дофига правок, которые тебе придётся изучать в коде. Хорошая история комитов - когда её можно скопировать почти без изменений в Change log проекта.
Ещё момент. Иногда нужно передать не рабочий код скажем коллеге. Порой проще и быстрее это сделать через комит. Делайте это только через unstable ветку (даже если в ней всего один комит), которую потом удалите. Если так вышло, что вы работаете в одной ветке вместе, то лучше прекращайте так работать и используйте принцип (одна ветка - одна задача), а на данный момент обязательно пометьте в названии комита, что он содержит проблемный код. Потому что сегодня вы сделали комит с поломанным кодом и проблему потом решили, через год вернётесь к коду и будете недоумевать почему, при загрузке комита ничего не работает вы же точно помните, как фиксили проблему. Опять же, эту проблему можно избежать при помощи CI/CD. Совет скорее маленьким командам в 1-3 человека, где часто git flow пренебрегают.
Либо у вас путаница в голове, либо вы слишком скомкано пишите.
Event loop (ноды), управляет асинхронными задачами в рамках одного потока, а менеджер потоков, что понятно из названия, управляет потоками (паралелит, балансирует, обеспечивает передачу данных между ними и т.д.). Как человек, который много писал на C# и хорошо знаком с работой потоков (не путать с асинхронностью, это не одно и тоже), немного не понимаю ваш тейк, что якобы event loop делает менеджер потоков, не нужным. Это 2 разных инструмента, которые используются на разных слоях приложения. В той же наде насколько я помню, потоки под капотом тоже используются, например для работы с файлами.
Так же для организации асинхронности event loop не всегда используется в разных яп. У C#, C++ и Java для асинхронности используются другие инструменты и подходы. Даже в Go о котором в статье речь используется насколько помню goroutine manager или как-то так.
Опять же почему личные данные парсят, вместо того, чтобы обратиться к рекрутинговым сервисам напрямую и не запросить официально обезличенную информацию для обучения нейронки? Всё же речь о взаимоотношениях юридических лиц идёт.
А так да, требования к сбору и хранению ДП в России довольно жёсткие. Сам с этим по работе сталкивался. Например, сервисы, хранящие определённые данные (например паспорта) должны получить для этого аккредитацию.
Потому что реальные проблемы LLM не решат, а вот "умный" фильтр сделать при помощи них, это пожалуйста.
Да и видимо тренд нейронок, только сейчас стал добираться до российских компаний, в то время как забугром уже все с ними "наигрались".
Причём именно на удалёнке толковые менеджеры намного более востребованные, чем в офисе, т.к. работы на удалёнке у них обычно больше.
Про эффективность тоже особо страхов не понимаю. Мне кажется в офисе куда проще держаться за рабочее место с плохой производительностью, чем на удалёнке. Видел разных работодателей. От тех, кто буквально поминутно просил трекать работу, до адекватных с подходом, чуть ли не со свободным графиком (т.к. международные команды, сильно разные часовые пояса). По моим наблюдениям работники во втором случае показывали результаты лучше, т.к. есть задача, есть дедлайн и есть всё для её решения при этом ничего лишнего. Обычно если человек не справляется с работой, на удалёнке это видно сразу. В офисе по моим наблюдениям это не так, хотя многое зависит от организации работы, если в офисе следят за каждым чихом, то понятное дело тоже быстро выявят.
Касаемо последнего тезиса, то он применим и к офису. Если человеку нравится работа, он будет работать с энтузиазмом, а если не нравится, то будет отлынивать, а зумеры просто убегут при удобном случае.
Команда из сеньоров это что-то странное, но видимо сейчас для части компаний это стало нормой. Причуды смещения грейдов по навыкам.
Да, это всё так, но мой вопрос был немного про другое. Условно я знаю gRPC на уровне просмотра 10 часового стрима и небольшой личной практики, а компания требует хорошее знание gRPC, то разве не будет враньём, если скажу на собеседовании, что знаю эту технологию твёрдо и чётко? По идее, это обман работодателя, чего лучше делать не стоит исходя из статьи.
Моё мнение, что лучше никогда не обманывать работодателя, касаемо хард скилов. Касаемо опыта, софт скилов и т.д. можно, т.к. это второстепенно, а вот хард скилы для программистов важнее всего.
Банальный пример с тем же Юрой, если бы он честно сказал на собеседовании, что плохо знает gRPC, то наверное работодатель не стал бы ему давать сложные задачи, с которыми он явно справится и Юре не пришлось "убегать после обеда". Я вот про это. 😊
Что-то многие сервисы сейчас подобное разрабатывают. Имхо но включение только платных комментариев для своего тг канала - это буквально совершить его суицид. Единственное, как можно было это грамотно реализовать, например сделать так, что платные комментарии всегда будут первыми в списке, это ещё как-то может жить, в остальном не вижу реализации, которая бы имела хоть какую-то пользу.