Comments 40
Не та нынче молодежь? Ничего, не будут в геймдеве работать, пойдут в CRUD-ошлёпы. Там всех берут.
Молодежь та как раз, пользуется новыми технологиями, а не др...т документацию по неделе. На что у меня уходит два часа, джун тоже делает за два часа. Вопрос, нафига я неделю читал доки? Осталось научить не только промпты писать, но и дебагером пользоваться, ну и чтобы это не приводило к поездке в QA отдел
Мне кажется, оптимальный подход ещё зависит от того насколько код "долгоживущий". Разработка с прицелом "на несколько лет вперёд" очень сильно отличается от разработки "тяп-ляп и в продакшен".
Например, я занимался в Яндексе c машинным обучением - там требовалось как можно быстрее учить модельки и проверять какие-то идеи, качество кода вообще никого не волновало. Я прям страдал - хотелось сделать красивые удобные решения (хотя бы скрипты для автоматизации, чтобы руками всё не вызывать), но зачастую это занимало х3-х5 к времени выполнения задачи руками. В итоге через восемь месяцев работы мне всё жутко надоело. Коллегам было норм, быстро-криво что-то написали, потом выкинули и в следующий раз опять всё руками делать. При такой организации работы подход с ctrl+c/ctrl+v вполне работал. Хотя я до сих думаю, что большую часть рутины можно было бы упростить и в итоге производительность команды была бы выше. Но в одиночку я не смог, а оценивали индивидуальные успехи.
И что интересно - я такое не выносил, но коллег всё устраивало. Возможно, это ещё как-то зависит от характера и подхода к работе. Или от желания выделять абстракции и разбираться в коде.
Последние три года работаю в продуктовой компании над одной и той же системой. И это совсем другие впечатления. Поначалу я думал, что страдаю излишним перфекционизмом и слишком много времени трачу на попытки сделать код "лучше" - но нет, на долгой дистанции оно великолепно работает. Хорошо написанный код потом почти не требует сил на поддержку. И при переписывание какого-нибудь сложнозапутанного кода часто оказывается, что в нём было несколько багов, а ещё что то же самое можно сделать куда проще.
Но правда не понятно как это оценивать и как объяснить людям, которые привыкли делать тяп-ляп. Например, при появлении какого-нибудь NullPointerException можно воткнуть проверку прямо в месте появления, а можно закопаться в код на несколько часов или дней, понять что на совсем другом уровне абстракции какие-то две подсистемы используют разные допущения и не стыкуются и исправлять надо там (причём иногда переделывать надо много).
Всегда удивляло как это можно взять и скопипастить. Проще понять идею и на свой лад сразу написать чем ковыряться адаптировать чужой код под свои условия.
Тут главное не скатиться в другую крайность - все писать руками вместо того, чтобы взять нужную библиотеку. И часто это как раз приятнее и надо удерживать себя от соблазна.
Библиотеки это компромисс, разработка настолько усложнилась, что мы не можем осознать сложность в рамках даже обычного printf. Поэтому часть логики выносим в библиотеки, снижая локальную сложность проекта. Я уже не готов писать вывод строк в буфер видеопамяти, хотя еще лет 20 назад, это было еще в ходу. Но посмотрите на игрострой, все упражняются как бы похитрее и побыстрее выводить полигоны в видеокарту, чуть ли не на регистрах программируют. К последнему skylines это не отсится :)
Библиотеки - это же не просто код. Это проверенный код. Это чья-то экспертиза. Это тесты. Это сообщество.
Другой вопрос, что библиотека - это не просто вызов функции, это еще и анализ того, что ты используешь
Библиотека это ещё и лишняя зависимость. Поэтому надо хорошо подумать чтобы потом её не тащить как чемодан без ручки.
Как будто это что-то страшное
Чемодан без ручки тоже кажется что тащить не страшно. Пока не заманаешься. Раз и несовместимость при обновлении тулчейна. А вот библиотека уже заброшена и не сопровождается. И код закрыт. А если не закрыт, то без плясок вприсядку не пересоберёшь её, потому что что-то где-то только в голове её разработчика и нормально не задокументировано.
Определенно, в какой-то момент наш внутренний порт тфлайт для консолей оказался заброшенным, потому что ушел человек. Переезд и тестирование с 2.8 на на 2.15 занял месяц работы сеньора. Цена зависимости оказалась 7к + невыполненные таски за месяц. Бог с ним с деньгами, но человек реально был оторван от задач отдела почти месяц
Ужас. Вы вообще как библиотеки подключаете? Своему коду ревью проводите, а чужому проекту - нет?
Знаете, стрелять себе в колени - вот исходная проблема. А не библиотека.
Это проблема ваша / вашего техруководства, а не абстрактной библиотеки.
Хорошие библиотеки перестанут обновляться далеко в будущем, и об этом можно не волноваться; а тащить зависимость от рандомного репо на гитхабе с 5 звездами, а потом плакаться, что она перестала обновляться - ну слушайте, это тупизм
В боевых условиях gpt-программисты выявляются. А в вузе как их выявлять ?
Ведь вся учеба - это фактически развитие мозгов.
А он свои мозги не развивает, а использует искусственные.
И что с этим делать? Типа работает же...
Адаптировать, давать задачи по силам. Имхо, они используют другие инструменты. Скорее уж обычный программер станет редкостью, как кнопочный телефон
Мы даем задачи по силам. Любое обучение, и обучение программированию в том числе, происходит от простого к сложному. У нас много заданий, которые постепенно развивают программистские мозги.
Использование чат-гопоты в данном случае сродни использованию калькулятора вместо учения таблицы умножения. И если калькулятор ненароком сломается, то чел ничего посчитать не сможет.
Или "зачем учиться писать (ручкой в тетради), если на компе кнопочки просто нажимать" - примерно то же самое.
В общем, появиласть проблема с реальным обучением
А они не хотят. От слова совсем, ну или почти совсем. 98%. Второй курс, ООП... Не идет. Начинаю разбираться почему, выяснилось, что с трудом применяют базовые конструкции языка. Ну то есть они их знают, но прошлый семестр посчитали слишком простым, опять циклы, опять условия и т.д., лабы сдали в лоб, тренироваться поленились.
Чего то перечитал, чего то заставил переделать, что то усложнил. Уткнулись в полное неумение в базовые алгоритмы: перебрать массив тяжело, сделать по нему поиск какое то запредельное сложное задание. Оказалось, что предмет, где это давали, сдавали копипастой. Отстаем уже на месяц. Какое там ООП. И все из под палки. Лишь бы сдать.
С ужасом думаю, что им в следующем семестре мне им паттерны читать.
Потом придут на хабр, будут плакать как их плохо учили.
З.Ы. Мне только не понятно, как они собеседования преодолевать умудряются?
Из-за массовой удаленки сломался процесс очного собеса, кмк, гпт только это все ускорил. Когда я учился (2001-07) учились тоже 20% группы, остальные както сдавали лабы. Был например преподаватель по с++, если прога компилилась ставил трояк. Все что выше надо было объяснить словами как работает и поменять на лету, для пятерки надо было найти ошибки в чужой лабе . Нечестно конечно, я пятерку получил всего пару раз, но работало. Плюс была локальная система антиплагиата, один раз написанный код/работа потом детектились на всем универе
Самое обидное, что они потом работают только за деньги =)
Ваши ожидания от людей сильно завышены.
З.Ы. Мне только не понятно, как они собеседования преодолевать умудряются?
Что значит "умудряются"? Чтобы пройти нынешний собес, программистом быть и не обязательно даже. Типовой набор теоретических вопросов, типовой набор задачек на лайвкодинге. Всё это аккуратно штудируется и прорешивается. Не повезло не фартануло - просто идём к следующему работодателю. PROFIT!!1
Я собственно полез смотреть как сейчас на работу нанимают, когда оказалось, что человек, который пишет диплом на PHP, в лоб, в стиле 90-x, без изысков, прямо реально в лоб, midle+ java программист, причем с явой там все очень печально, что он даже на ней диплом писать не взялся. Другой дипломник ведущий аналитик данных в крупном банке, 5 табличек связать не может. Я когда узнал кем и где он работает, чуть со стула не упал. Третий вообще «сеньор фронтенд разработчик», в самом крупном банке, ну не то, что он совсем не может, но как то там все... плохо.
Это не стажеры, не джуны, это элита... Какие скиллы, если доклад по две недели репетируем.
С другой стороны, ребята, которые реально могут, по полгода работу ищут.
А в вузе как их выявлять ?
Задавать вопросы. Просить внести изменения в программу.
Можно вообще с другой стороны зайти и просить найти ошибки в программе, которую сгенерировала нейросеть.
Это по сути индивидуальные занятия получаться. А преподаватели и так из аудиторий не вылезают. По учебному плану на 38 часов лекций и 38 часов семинаров положено 72 часа самостоятельной работы. Это семестр по одному предмету. Но кто же занимается самостоятельно.
Массовать образования, конечно, времени не оставляет совсем.
Если на семинаре группа 10-15 человек, то за полтора часа можно какое-то время всем уделить, или почти всем. По крайней мере довольно быстро становится понятно, кто действительно головой работает, а кто в лучшем случае копирует у других.
А то что самостоятельно никто не работет - это проблема, казалось бы, давняя, но сейчас всё большее распространение получившая.
В 2023 году это какая-то надуманная проблема. Берете профиль человека с
Play with Programming - CodinGame или десятков подобных и просите рассказать как решал задачу. Т.е. вон они элементы тестирования и ранжирования.
Очень интересно, как вы сможете избавиться от дублирования кода в микросервисах?
Хорошо вам профессиональным разрабам, в нам начинающим энтузиастам приходится выбирать разбираться в коде с нуля или скопипастить что накалякала нейронка(а че, работает ведь).
Так у вас намного больше возможностей, чатгпт офигенный, он сразу дает ответы без нудного копания в интернете, причем распишет еще каждую строку. Такого препода еще поискать надо. Не надо только бездумно копипастить, посмотрел пример - написал руками. Я такой код на уровне нейронки начал писать хорошо если года через три подзатыльников от лида. Не понимаешь как работает, не отправляй на ревью. Разберись с кодом, потрать 2-3 часа если надо, никому не выгодно брать Вас на позицию чтобы уволить через два месяца. Поверьте компания теряет намного больше чем вы в этом случае.
чатгпт офигенный, он сразу дает ответы без нудного копания в интернете, причем распишет еще каждую строку. Такого препода еще поискать надо.
Лучше не надо. Ответы он конечно дает, и даже каждую строку распишет, как она работает (ну, как чатгпт считает). Только это зачаcтую бывает отборной бредятиной. Например, я своими глазами видел, как чатгпт предлагал итерироваться по кортежу примерно таким образом:
auto t = std::make_tuple(...);
std::for_each(std::begin(t), std::end(t), ...);Я нифига не шучу.
Хорошо вам профессиональным разрабам, в нам начинающим энтузиастам приходится выбирать разбираться в коде с нуля или скопипастить что накалякала нейронка(а че, работает ведь).
Это у нас, профессионалов, есть выбор разбираться с нуля, или скопипастить, если с виду и так сойдёт. А у вас, начинающих, нет выбора. Только разбираться в коде с нуля, чтобы по-настоящему понимать как всё устроено и работает.
Вопрос поднят хороший. Но в нём есть множество нюансов. Читая статью я не однократно ловил себя на мысли, что эта статья про сферическую идеальную ситуацию в вакууме. К которой, без сомнения, нужно стремиться. Когда код пишется под конкретный проект, учитываются все его особенности. Но реальность часто бывает не располагающей к правильным, подходящим решениям.
Пример. У меня только на днях закончилась долгая задача. Код был влит в основной репозиторий. И там он стал жить. Предшествовали этому месяца подгонки к коду основного репозитория решения, которое я написал за относительно недолгое время ещё на страте задаи. При чём, я изначально использовал то решение, которое уже было написано не мной, я рефакторил его. То есть по логике статьи, имеющееся решение должно было ускорить работу. Но этого не произошло. И по сути не важно, было бы моё решение именно написано мной с нуля, или же зарефакторено, так как подгонка выявила проблемы, которые я уже в рамках свой задачи решить не мог. Не потому что не хотел, а потому, что не разрешали. Так как исправление требовало дополнительное время, а его не было. Это я к ему, бывает так, что начальное состояние проекта, под которое будет ставится задача - говно. И бывает так, что не важно кто и как будет задачу выполнять, важен результат. И это приводит к тому, что решения, которые принимаются для выполнения задачи могут быть забракованы, потому что требуют много времени на реализацию. Я был неоднократным свидетелем того, когда MVP становилось конечным продуктом. То есть проект не создавался с нуля, с новой правильной архитектурой, с учётом всех выявленных ошибок. Он просто из тестовой группы уходит в прод. И дальнейшее развитие проекта шло уже на том фундаменте, который был построен при разработке MVP. И есть люди, которые по факту учатся на таких проектах. Они получают опыт говно-кода, или, как в названии статьи указано, «Плохо девелопмента». Они по другому просто уже не умеют.
Простите за духоту. Мне кажется у вас слишком идеализированное представление о том, как должен выглядеть коддинг. В этом не ничего плохого. Даже наоборот, это хорошо, когда такое возможно поддерживать. Хорошая высокая планка качества. Но, опять же, не везде такое возможно, что печально
да это понятно, нет идеального кода, как нет идеального продукта. Я просто хотел предупредить ребят, которые ринулись в объятия нейронок, выдавая их решения за свои. Не понимаешь код, не комить его, разберись.
Тогда не совсем понятен посыл статьи по наполнению. С нейронками нам придётся жить. Тут надо смотреть с другой стороны. Проблема же не в самих нейронках, как я понимаю. Я исхожу из той информации, что получил из статьи. И я не знаю ситуации, из-за которой вы решили написать статью.
Я к примеру не пользуюсь нейронками. Я с ними знаком. Я немного их тыкал, когда они хайповали, но не нашёл для себя паттерна их использования. Но как я понимаю, они станут поисковиками 2.0 (или 3.0), если уже не стали. Если раньше (очень давно) поисковики выдавали сайты, где располагались ответы на некоторые вопросы, за что собственно поисковики стали быстро очень популярными. Были тематические форумы. Всякие блоги крутых дядек, которые рассказывали, как они «первопроходили» решения. И поисковики были очень удобным способом найти именно подходящий форум с темами, вопросами, а может даже и ответами, по проблеме. То некоторое время назад, до нейронок, всё изменилось. Появились всякие otvet_mail, reddit, stackoverflow и иже с ними, а тематические форумы скукожились в совсем нишевые темы. На форумах остались только те, кто там давно, и «свежей» крови там стало меньше. Потому что поисковики стали «портить» выдачу. Поиск информации усложнился. Не только из-за того, что поиск «испортился», но из-за того, что информации стало слишком много. И какой-нибудь reddit или stackoverflow стали таким новыми «поисковиками», но не конкретного сайта, а сразу решения на конкретный вопрос. Пользователь бросал вопрос, а через какое-то время ему ответ, да ещё и детально описанный. Это же пытались сделать и всякие компании типа Google, Yahoo, Yandex, но их решения были плохими, так как тогда нейронок не было, а алгоритмы всякие уже были. И reddit или stackoverflow выигрывали за счёт того, что отвечали там живые люди, а не алгоритмы. Вот получается, что сейчас мы пришли к Эре ChatGPT (не хочется так называть, но что есть). Нейронка фактически становится персональным поисковиком. Из неё хотят уже и персонального ассистента сделать. Люди очень легко привыкают к простоте. Потому ChatGPT так легко вошёл в жизнь некоторых людей. Он сильно упрощает для них работу. Не пишет за них код, конечно же, но помогает найти решение.
Я эту портянку выкатил к тому, что так решает проблему ваш специалист. Ему так проще. И это становится нормой. То есть когда-то искали документацию, так как не было форумов с их ответами. Потом стали пользоваться reddit или stackoverflow, потому что поисковики фактически уничтожили суть «поиска». Теперь эволюционно пришли к ChatGPT, который не заставляет ждать ответ
Согласен это так, мой посыл к любому разработчику не копипастить, найти решение да, скопировать решение - возможно (если не хватает своих знаний). Но не брать готовый код выдавая его за свой. Весь рассказ можно уложить пару предложений про двух джунов, которые не хотят учиться. Но такое читать не будут, я и попробовал это облечь в мини советы почему не надо.
...мой посыл к любому разработчику не копипастить, <...> не брать готовый код выдавая его за свой.
А вот тут уже начинаются проблемы. Я наверное опять портянку накину. Предупрежу заранее.
Многие элементарные решения однотипны. Ряд языков имеют свои гайдлайны, которые строго рекомендуют (или вовсе запрещают) определённые действия. Всякие шаблоны (или паттерны) проектирования, типа Банды Четырёх. Это я к тому, что в любом случае будут одинаковые однотипные решения. И опять же, упрощая себе работу, программист будет копировать готовое решение (подгонять или нет будет понятно по факту копипасты). Это норма сегодняшнего дня. Да, в каких-то моментах это плохо выглядит со стороны, но только тогда, когда это решение не выполняет свою функцию, или не соответствует гайдлайнам принятым в компании. Во всех остальных случаях разницы между, сам ли программист написал код, или взял готовое решение не будет. Потому что разные программисты пишут по разному. Только внутренний гайдлайн компании будет удерживать всех в одной общей стилистике. А ещё и код ревью, конечно.
У меня, как C++ программиста постоянно меняется «подчерк», потому что по мере того, как я развиваюсь я замечаю, что некоторые определённые строки кода я не могу писать как раньше, мне лично не нравится, так как я замечаю, что спустя время я перестаю понимать, что я сам написал, или же мне становится неудобно читать свой же код. Я стал более многословным в коде, хотя раньше любил однострочники (сейчас понимаю, что они зло). Но в компании, где я сейчас работаю я так писать не могу, потому что так не принято. Поэтому моё решение в любом случае будет похожим на чужое. То есть проявление индивидуальности нивелируется подходами к разработке внутри компании. Зачем тогда проявлять индивидуальность или уникальность решения? (вопрос риторический)
С другой стороны видится уже настоящая проблема. Зачем учиться, или тратить время на разработку, если есть уже готовое решение. Достаточно потратить время на поиски. Тут уже как раз дилемма. Потратить время на разработку, или на поиски решения и подгонку. Для молодых специалистов первое может быть по времени куда более трудоёмким, нежели второе. В то время, как для специалиста уровнем выше так казаться не будет. И здесь возникает вопрос постановки задачи. Жёсткие ли сроки для выполнения задачи, верно ли они рассчитаны, учитывая возможности исполнителя? Если жесткие или расчёт был сделан неверно в худшую сторону, то нет ничего удивительного в выборе простого пути.
Весь рассказ можно уложить пару предложений про двух джунов, которые не хотят учиться.
Вот это уже похоже на проблему, которую стоило бы осветить в полной мере. Но и тут нужно определиться с понятием «учиться». Учится новому, или учиться кодовой базе? У меня есть пример коллеги, который пришёл из другой компании, где всё было сделано для разработчика. Кодовая база хорошая. Документация отличная. Внутренние юнит тесты. Многоуровневый код ревью. Задачи декомпозируются вплоть до того, что описывается как это задача должна быть сделана. То есть решение уже описано, нужно только написать его в виде кода. И вот пришёл в нашу компанию программист, который привык к такой простоте, и сразу стал отказываться от задач, где ему нужно было думать. А так как документации по многим вещам у нас нет, то отказывался он много от чего. Почему ему это позволяли? Потому что вариантов не было. Его в конечно итоге уволили, но были задачи, с которыми он справился. Потому что он знал как их решать, так как уже делал практически тоже самое на предыдущем месте работы. Возможно он скопировал тот, уже готовый код.
Я, конечно же, за всё хорошее, против всего плохого.
Существует экономическая составляющая, которая является основной движущей силой в коммерческой организации.
Риск-менеджент, который утверждает, что если вы не делаете ошибок, то вы недостаточно эффективны.
А в итоге разработчик всегда плохой, как минимум по одному пункту.
Плохо девелопмент