Среди множества задач, решаемых программистом, одной из самых частых является подумать и добавить новый функционал в приложение. И там уже может быть много похожего функционала, он может быть хорошо написан, хорошо документирован. Искушение заключается в том, поддаться своей лени и задействовав специфические мышцы левой руки поместить чужой код в "новый" функционал. Другими словами, очень хорошо спроектированный код (равно как и очень плохой) готовит к разработке методом копипасты последующие поколения разработчиков. То есть мы находим в нашем коде что-то похожее на то, что мы хотим добавить, копируем это и вставляем, меняя небольшие детали, специфичные для нашей новой функции. Или находим что-то похожее на stackoverflow. Я отнюдь не против поиска и даже отдельных моментов разработки методом анализа чужих решений, в любом случае код придется понять, принести, адаптировать. Да чего греха таить, я тоже не пишу весь код из головы.
Намного хуже, когда это входит в привычку, которая отключает мозг, на автомате выполняя мелкие изменения. Есть очень хороший принцип DRY (Don't Repeat Yourself), то есть в разработке стараемся избегать дублирования кода, по крайней мере, когда это разумно. Много раз обсуждали этот момент с коллегами, и сошлись на том, что это больше про самодисциплину в разработке, чем про кодинг.
Если приходится копировать логику больше двух раз, хорошо трех, значит мы где-то накосячили с архитектурой, значит это будет техдолгом, который когда-то придется оплачивать, значит ошибка в этом месте будет продублирована еще два или три раза. Скорее всего в проектах, где функциональность стоит на первом месте, а разработке ведется по дендро-фекальным технологиям трудно избежать копирования, стоит ли бороться с копипастой каждый решает сам, только легкость копипасты существующего кода все сильнее будет вас затягивать в ловушки легкой разработки.
Ловушка легких решений
Нас попросили добавить новое поле в объект, или свойство. К счастью, в объекте много полей, много свойств, и все они в какой-то степени похожи, за исключением некоторых специфических частей новой логики. Вы расширяли функционал таким способом?
Ловушка заключается в том, чтобы просто скопировать и вставить существующий код, как сделали другие разработчики до нас, игнорировать документацию и не пытаться понять структуру модуля. Если нет четкого понимания вносимых изменений, уверенность что этот код работал до нас, не дает нормально разобраться как оно работает. Время поджимает и надо побыстрее закрыть таску и взять другую. Работа сделана, код работает, тесты проходят.
Ловушка мертвого кода
С кодом всегда сложно разбираться, с чужим кодом особенно. Даже если это три строки, даже если вы пишите print("Hello world"). Вы задумывались, как это выводится на экран? Там в асме колстек из 20 вызовов. Это отлично, что я не вижу эти 20 вызовов, что от меня скрыли сложность работы с ОС, что я могу одной строкой кода сделать то, что мне действительно надо.
Но это не снимает с меня необходимости в общих чертах понимать колстек вызовов и код, который скопипастил. А код надо понимать, потому что чужой код может быть мертвым. Мертвый код, одна из причин избегать копипасты, скопированное может содержать часть, которая не нужна в вашем случае, но код цепляется друг за друга, вы не можете скопировать часть слов, и выбросить другую часть, оно просто не будет работать.
Самое забавное, что это осознание обычно приходит сильно позже внедрения каких то зависимостей, так было и с моей задачей, которая требовала подключения библиотеки
eigen для выполнения специфичных операций с матрицами. Из всей библиотеки, а там их более полутора тысяч, нам нужно было 4 функции. Но зависимость классов не позволяла их просто выдернуть и использовать. Более того, немного пошерстив нашу библиотеку математики я нашел похожую реализацию, которую надо было немного поправить. А ведь все могло закончиться втаскиванием ненужного фреймворка на 10к файлов. Более того, я потом полез смотреть реализацию в eigen и оказалось, что и там функция разложения Якоби (Jacobi SVD) содержит лишние проверки, которых можно избежать, тем самым улучшив перф.
Добавление мертвого или бесполезного кода ненужно, если не сказать вредно. Это делает код в общем более тяжелым. Следующему сотруднику придется больше понимать и дольше разбираться, или он забьет и попадет в ловушку легких решений. К тому же мертвый код не дает ничего, кроме бесполезной траты тактов.
С кодом всегда сложно разбираться, но понимание того, что вы копируете, даже если это смутное понимание для чего используется каждая часть, сделает изменения простыми, а может и вообще заставит отказаться от копипасты.
Ловушка отложенных зависимостей
Скорее всего, вам всё равно придется понять код, который вы скопипастили. У меня еще не было случая, чтобы новая функция в старом коде заработала без ошибок с первого раза, наверное я просто не умею программировать. Почти всегда нужно внести изменения, чтобы они работали и охватывали все кейсы. Но если нет понимания, как работает код, нельзя сказать какие кейсы могут быть. В этом случае тесты ограничены нашим незнанием, и не помогут устранить проблемы нового функционала до их возникновения.
Самая неприятная ситуация - это когда код "вроде как" работает, а потом QA присылают баг, причем падает оно в 90% в другом месте. Тогда приходится возвращаться к скопированному коду, но код уже встроен в основную логику и имеет новые зависимости, приходится разбираться и с ними. Вобщем копипаста это всегда плохо, не думайте что чужой код будет работать у вас без ошибок. Любая написанная строка содержит ошибку, пока не доказано обратное. Не спасают даже юниттесты.
А раз так, если придется разбираться в коде в любом случае, то лучше делать это с самого начала и писать правильно тоже с самого начала. Смотрите на пример, но код пишите руками, не прибегая к комбинациям из трех кнопок. Потратив время на понимание нового кода или модуля, вы расширяете свою экспертизу, а умение писать код без гугла сегодня многого стоит, знание - это сила.
Ловушка чужого решения
Я стал разработчиком, потому что мне нравится решать задачи. Но копипаста это не решение задачи, задачу уже решили до меня, не получится придумать свое решение. Вы можете думать, что подсмотрите чужое решение и напишите свое, но это не так. Вы отравлены знанием чужого решения, это как посмотреть в конец учебника и потом подгонять свое под ответ - довольно глупое занятие. Конечно, не найдя своего, пусть не полностью правильного решения, все равно придется идти в гугл за ответом, но это будет позже, когда серые клетки поработают.
Мне нравится программировать, особенно нравится понимать как работают сложные системы. Копипаста лишает меня главного - процесса понимания как устроена система. Тренирует мышечную память, а не серые клеточки. Если вы понимаете код, который вы копируете, то лучше напишите его сами, так вы сможете лучше понять функциональные возможности нового кода. Это также дает вам возможности для поиска общего кода в рамках всего проекта. Код, который вы написали сами откладывается в памяти. Код, который скопипастили забудется через пару дней. В какой-то момент объем знаний/памяти будет достаточным, чтобы видеть общие паттерны в рамках всего фреймворка. Если вы копируете код, этого не происходит, и вы остаетесь на уровне пользователя фреймворка, движка, редактора и т.д.
В следующий раз попробуйте "переписать" код, а не копировать его. Почему бы не использовать мозг на полную мощность для понимания кода, а не только мышечную память расположения кнопок C + V.
О чем это я...
В отделе появилась пара ребят, нормальные по знаниям (в теории да), прошли собес, довольно неплохо написали тестовое (всё на удаленке было). Первые месяц-два, как обычно притирка к проекту, к друг-другу, таски-обучалки, мелкий ресерч. Кривая обучения растет, ребята получают все более сложные задачи, пока не начинают их фейлить. Первому задача вроде несложная попалась, собрать вектор скоростей во время движения монстра на уровне, найти усреднение и выдать предсказание на дельту времени из текущей точки. Вторым проходом загнать те же точки в фильтр Калмана, посмотреть какое из предсказаний точнее и отдать команду на стрельбу с упреждением. Проходит 10 ревью, вижу что человек не справляется, вроде и код тот что нужен, но все время какие-то огрехи, которые не позволяют его пустить дальше в репо. Сажусь рядом, говорю - "Рисуй на листочке как бегает монстр, рисуй стрелки куда направлена скорость, пиши рядом псевдокод алгоритма". Человек впал в ступор, т.е. ручку то он взял, но дальше рисования пары точек дело не шло. Сидим два часа, разговариваем, пытаюсь получить хоть какие-то наброски алгоритма, идею написать на листочке уже оставил как несбыточную, думаю ну ладно, я сам нечасто на листке что-то решаю уже, что же я от молодых требую? Пока это "чудо" не спрашивает - "А можно я в гугле посмотрю решение?". В первых двух нормальных ссылках я вижу код, который мне приходил на ревью: Здравствуйте, приехали. До меня дошло почему не справлялся конкретно этот коллега, решения этой задачи нет, надо собирать по частям. Но с таким еще можно жить, ведь надо сформулировать вопрос, отсеять лишнее, найти решение и адаптировать, т.е. работы хватает, пусть не свое решение, но потребовалось время и усилия. Надеюсь со временем, количество перейдет в качество и человек начнем думать сам, а не через гугл.
Пошел ко второму, даю туже задачу, даю листок и ручку, говорю: "Пиши, Федя!". Не написал, даже гугл не помог. Со вторым еще хуже, это оказался gpt-программист, думаю дальше рассказывать смысла особо нет. Последней каплей были слова, "А че реджект, работает же".
Ну ок, сегодня работает, а завтра луна не в той фазе будет. Ребята неплохие, но уехали в QA отдел на стажировку и наподумать, думаю не вернутся. И я зря, чтоли, два месяца обучал их получается?
Не подумайте, я не динозавр и пользуюсь chatGPT для автоматизации рутинных задач. Если не можешь объяснить код, который написал, не отдавай его на ревью. Просто кто потом баги в том коде дебажить будет, тоже chatGPT?
Хочу оставить тут ссылку на хорошую статью почему надо понимать, что пишешь. Может кто из переводчиков доберется.
https://philippe.bourgau.net/you-should-refuse-to-develop-what-you-dont-understand/
Комментарии (32)
lgorSL
11.11.2023 14:12+8Мне кажется, оптимальный подход ещё зависит от того насколько код "долгоживущий". Разработка с прицелом "на несколько лет вперёд" очень сильно отличается от разработки "тяп-ляп и в продакшен".
Например, я занимался в Яндексе c машинным обучением - там требовалось как можно быстрее учить модельки и проверять какие-то идеи, качество кода вообще никого не волновало. Я прям страдал - хотелось сделать красивые удобные решения (хотя бы скрипты для автоматизации, чтобы руками всё не вызывать), но зачастую это занимало х3-х5 к времени выполнения задачи руками. В итоге через восемь месяцев работы мне всё жутко надоело. Коллегам было норм, быстро-криво что-то написали, потом выкинули и в следующий раз опять всё руками делать. При такой организации работы подход с ctrl+c/ctrl+v вполне работал. Хотя я до сих думаю, что большую часть рутины можно было бы упростить и в итоге производительность команды была бы выше. Но в одиночку я не смог, а оценивали индивидуальные успехи.
И что интересно - я такое не выносил, но коллег всё устраивало. Возможно, это ещё как-то зависит от характера и подхода к работе. Или от желания выделять абстракции и разбираться в коде.
Последние три года работаю в продуктовой компании над одной и той же системой. И это совсем другие впечатления. Поначалу я думал, что страдаю излишним перфекционизмом и слишком много времени трачу на попытки сделать код "лучше" - но нет, на долгой дистанции оно великолепно работает. Хорошо написанный код потом почти не требует сил на поддержку. И при переписывание какого-нибудь сложнозапутанного кода часто оказывается, что в нём было несколько багов, а ещё что то же самое можно сделать куда проще.
Но правда не понятно как это оценивать и как объяснить людям, которые привыкли делать тяп-ляп. Например, при появлении какого-нибудь NullPointerException можно воткнуть проверку прямо в месте появления, а можно закопаться в код на несколько часов или дней, понять что на совсем другом уровне абстракции какие-то две подсистемы используют разные допущения и не стыкуются и исправлять надо там (причём иногда переделывать надо много).
Leetc0deM0nkey
11.11.2023 14:12+2Всегда удивляло как это можно взять и скопипастить. Проще понять идею и на свой лад сразу написать чем ковыряться адаптировать чужой код под свои условия.
nightlord189
11.11.2023 14:12+3Тут главное не скатиться в другую крайность - все писать руками вместо того, чтобы взять нужную библиотеку. И часто это как раз приятнее и надо удерживать себя от соблазна.
dalerank Автор
11.11.2023 14:12+1Библиотеки это компромисс, разработка настолько усложнилась, что мы не можем осознать сложность в рамках даже обычного printf. Поэтому часть логики выносим в библиотеки, снижая локальную сложность проекта. Я уже не готов писать вывод строк в буфер видеопамяти, хотя еще лет 20 назад, это было еще в ходу. Но посмотрите на игрострой, все упражняются как бы похитрее и побыстрее выводить полигоны в видеокарту, чуть ли не на регистрах программируют. К последнему skylines это не отсится :)
Ilusha
11.11.2023 14:12Библиотеки - это же не просто код. Это проверенный код. Это чья-то экспертиза. Это тесты. Это сообщество.
Другой вопрос, что библиотека - это не просто вызов функции, это еще и анализ того, что ты используешь
Leetc0deM0nkey
11.11.2023 14:12+1Библиотека это ещё и лишняя зависимость. Поэтому надо хорошо подумать чтобы потом её не тащить как чемодан без ручки.
Ilusha
11.11.2023 14:12+1Как будто это что-то страшное
Leetc0deM0nkey
11.11.2023 14:12Чемодан без ручки тоже кажется что тащить не страшно. Пока не заманаешься. Раз и несовместимость при обновлении тулчейна. А вот библиотека уже заброшена и не сопровождается. И код закрыт. А если не закрыт, то без плясок вприсядку не пересоберёшь её, потому что что-то где-то только в голове её разработчика и нормально не задокументировано.
dalerank Автор
11.11.2023 14:12Определенно, в какой-то момент наш внутренний порт тфлайт для консолей оказался заброшенным, потому что ушел человек. Переезд и тестирование с 2.8 на на 2.15 занял месяц работы сеньора. Цена зависимости оказалась 7к + невыполненные таски за месяц. Бог с ним с деньгами, но человек реально был оторван от задач отдела почти месяц
LaptevVV
11.11.2023 14:12+1В боевых условиях gpt-программисты выявляются. А в вузе как их выявлять ?
Ведь вся учеба - это фактически развитие мозгов.
А он свои мозги не развивает, а использует искусственные.
И что с этим делать? Типа работает же...dalerank Автор
11.11.2023 14:12+1Адаптировать, давать задачи по силам. Имхо, они используют другие инструменты. Скорее уж обычный программер станет редкостью, как кнопочный телефон
LaptevVV
11.11.2023 14:12+1Мы даем задачи по силам. Любое обучение, и обучение программированию в том числе, происходит от простого к сложному. У нас много заданий, которые постепенно развивают программистские мозги.
Использование чат-гопоты в данном случае сродни использованию калькулятора вместо учения таблицы умножения. И если калькулятор ненароком сломается, то чел ничего посчитать не сможет.
Или "зачем учиться писать (ручкой в тетради), если на компе кнопочки просто нажимать" - примерно то же самое.
В общем, появиласть проблема с реальным обучением
TrykinSchultz
11.11.2023 14:12+2А они не хотят. От слова совсем, ну или почти совсем. 98%. Второй курс, ООП... Не идет. Начинаю разбираться почему, выяснилось, что с трудом применяют базовые конструкции языка. Ну то есть они их знают, но прошлый семестр посчитали слишком простым, опять циклы, опять условия и т.д., лабы сдали в лоб, тренироваться поленились.
Чего то перечитал, чего то заставил переделать, что то усложнил. Уткнулись в полное неумение в базовые алгоритмы: перебрать массив тяжело, сделать по нему поиск какое то запредельное сложное задание. Оказалось, что предмет, где это давали, сдавали копипастой. Отстаем уже на месяц. Какое там ООП. И все из под палки. Лишь бы сдать.
С ужасом думаю, что им в следующем семестре мне им паттерны читать.
Потом придут на хабр, будут плакать как их плохо учили.
З.Ы. Мне только не понятно, как они собеседования преодолевать умудряются?dalerank Автор
11.11.2023 14:12+2Из-за массовой удаленки сломался процесс очного собеса, кмк, гпт только это все ускорил. Когда я учился (2001-07) учились тоже 20% группы, остальные както сдавали лабы. Был например преподаватель по с++, если прога компилилась ставил трояк. Все что выше надо было объяснить словами как работает и поменять на лету, для пятерки надо было найти ошибки в чужой лабе . Нечестно конечно, я пятерку получил всего пару раз, но работало. Плюс была локальная система антиплагиата, один раз написанный код/работа потом детектились на всем универе
gybson_63
11.11.2023 14:12Самое обидное, что они потом работают только за деньги =)
Ваши ожидания от людей сильно завышены.
Leetc0deM0nkey
11.11.2023 14:12З.Ы. Мне только не понятно, как они собеседования преодолевать умудряются?
Что значит "умудряются"? Чтобы пройти нынешний собес, программистом быть и не обязательно даже. Типовой набор теоретических вопросов, типовой набор задачек на лайвкодинге. Всё это аккуратно штудируется и прорешивается. Не повезло не фартануло - просто идём к следующему работодателю. PROFIT!!1
myswordishatred
11.11.2023 14:12А в вузе как их выявлять ?
Задавать вопросы. Просить внести изменения в программу.
Можно вообще с другой стороны зайти и просить найти ошибки в программе, которую сгенерировала нейросеть.
gybson_63
11.11.2023 14:12В 2023 году это какая-то надуманная проблема. Берете профиль человека с
Play with Programming - CodinGame или десятков подобных и просите рассказать как решал задачу. Т.е. вон они элементы тестирования и ранжирования.
sergyalosovetsky
11.11.2023 14:12-1Очень интересно, как вы сможете избавиться от дублирования кода в микросервисах?
Guestishe
11.11.2023 14:12-1Хорошо вам профессиональным разрабам, в нам начинающим энтузиастам приходится выбирать разбираться в коде с нуля или скопипастить что накалякала нейронка(а че, работает ведь).
dalerank Автор
11.11.2023 14:12Так у вас намного больше возможностей, чатгпт офигенный, он сразу дает ответы без нудного копания в интернете, причем распишет еще каждую строку. Такого препода еще поискать надо. Не надо только бездумно копипастить, посмотрел пример - написал руками. Я такой код на уровне нейронки начал писать хорошо если года через три подзатыльников от лида. Не понимаешь как работает, не отправляй на ревью. Разберись с кодом, потрать 2-3 часа если надо, никому не выгодно брать Вас на позицию чтобы уволить через два месяца. Поверьте компания теряет намного больше чем вы в этом случае.
KanuTaH
11.11.2023 14:12+2чатгпт офигенный, он сразу дает ответы без нудного копания в интернете, причем распишет еще каждую строку. Такого препода еще поискать надо.
Лучше не надо. Ответы он конечно дает, и даже каждую строку распишет, как она работает (ну, как чатгпт считает). Только это зачаcтую бывает отборной бредятиной. Например, я своими глазами видел, как чатгпт предлагал итерироваться по кортежу примерно таким образом:
auto t = std::make_tuple(...); std::for_each(std::begin(t), std::end(t), ...);Я нифига не шучу.
Leetc0deM0nkey
11.11.2023 14:12+2Хорошо вам профессиональным разрабам, в нам начинающим энтузиастам приходится выбирать разбираться в коде с нуля или скопипастить что накалякала нейронка(а че, работает ведь).
Это у нас, профессионалов, есть выбор разбираться с нуля, или скопипастить, если с виду и так сойдёт. А у вас, начинающих, нет выбора. Только разбираться в коде с нуля, чтобы по-настоящему понимать как всё устроено и работает.
AnimeSlave
11.11.2023 14:12Вопрос поднят хороший. Но в нём есть множество нюансов. Читая статью я не однократно ловил себя на мысли, что эта статья про сферическую идеальную ситуацию в вакууме. К которой, без сомнения, нужно стремиться. Когда код пишется под конкретный проект, учитываются все его особенности. Но реальность часто бывает не располагающей к правильным, подходящим решениям.
Пример. У меня только на днях закончилась долгая задача. Код был влит в основной репозиторий. И там он стал жить. Предшествовали этому месяца подгонки к коду основного репозитория решения, которое я написал за относительно недолгое время ещё на страте задаи. При чём, я изначально использовал то решение, которое уже было написано не мной, я рефакторил его. То есть по логике статьи, имеющееся решение должно было ускорить работу. Но этого не произошло. И по сути не важно, было бы моё решение именно написано мной с нуля, или же зарефакторено, так как подгонка выявила проблемы, которые я уже в рамках свой задачи решить не мог. Не потому что не хотел, а потому, что не разрешали. Так как исправление требовало дополнительное время, а его не было. Это я к ему, бывает так, что начальное состояние проекта, под которое будет ставится задача - говно. И бывает так, что не важно кто и как будет задачу выполнять, важен результат. И это приводит к тому, что решения, которые принимаются для выполнения задачи могут быть забракованы, потому что требуют много времени на реализацию. Я был неоднократным свидетелем того, когда MVP становилось конечным продуктом. То есть проект не создавался с нуля, с новой правильной архитектурой, с учётом всех выявленных ошибок. Он просто из тестовой группы уходит в прод. И дальнейшее развитие проекта шло уже на том фундаменте, который был построен при разработке MVP. И есть люди, которые по факту учатся на таких проектах. Они получают опыт говно-кода, или, как в названии статьи указано, «Плохо девелопмента». Они по другому просто уже не умеют.
Простите за духоту. Мне кажется у вас слишком идеализированное представление о том, как должен выглядеть коддинг. В этом не ничего плохого. Даже наоборот, это хорошо, когда такое возможно поддерживать. Хорошая высокая планка качества. Но, опять же, не везде такое возможно, что печально
dalerank Автор
11.11.2023 14:12да это понятно, нет идеального кода, как нет идеального продукта. Я просто хотел предупредить ребят, которые ринулись в объятия нейронок, выдавая их решения за свои. Не понимаешь код, не комить его, разберись.
AnimeSlave
11.11.2023 14:12Тогда не совсем понятен посыл статьи по наполнению. С нейронками нам придётся жить. Тут надо смотреть с другой стороны. Проблема же не в самих нейронках, как я понимаю. Я исхожу из той информации, что получил из статьи. И я не знаю ситуации, из-за которой вы решили написать статью.
Я к примеру не пользуюсь нейронками. Я с ними знаком. Я немного их тыкал, когда они хайповали, но не нашёл для себя паттерна их использования. Но как я понимаю, они станут поисковиками 2.0 (или 3.0), если уже не стали. Если раньше (очень давно) поисковики выдавали сайты, где располагались ответы на некоторые вопросы, за что собственно поисковики стали быстро очень популярными. Были тематические форумы. Всякие блоги крутых дядек, которые рассказывали, как они «первопроходили» решения. И поисковики были очень удобным способом найти именно подходящий форум с темами, вопросами, а может даже и ответами, по проблеме. То некоторое время назад, до нейронок, всё изменилось. Появились всякие otvet_mail, reddit, stackoverflow и иже с ними, а тематические форумы скукожились в совсем нишевые темы. На форумах остались только те, кто там давно, и «свежей» крови там стало меньше. Потому что поисковики стали «портить» выдачу. Поиск информации усложнился. Не только из-за того, что поиск «испортился», но из-за того, что информации стало слишком много. И какой-нибудь reddit или stackoverflow стали таким новыми «поисковиками», но не конкретного сайта, а сразу решения на конкретный вопрос. Пользователь бросал вопрос, а через какое-то время ему ответ, да ещё и детально описанный. Это же пытались сделать и всякие компании типа Google, Yahoo, Yandex, но их решения были плохими, так как тогда нейронок не было, а алгоритмы всякие уже были. И reddit или stackoverflow выигрывали за счёт того, что отвечали там живые люди, а не алгоритмы. Вот получается, что сейчас мы пришли к Эре ChatGPT (не хочется так называть, но что есть). Нейронка фактически становится персональным поисковиком. Из неё хотят уже и персонального ассистента сделать. Люди очень легко привыкают к простоте. Потому ChatGPT так легко вошёл в жизнь некоторых людей. Он сильно упрощает для них работу. Не пишет за них код, конечно же, но помогает найти решение.
Я эту портянку выкатил к тому, что так решает проблему ваш специалист. Ему так проще. И это становится нормой. То есть когда-то искали документацию, так как не было форумов с их ответами. Потом стали пользоваться reddit или stackoverflow, потому что поисковики фактически уничтожили суть «поиска». Теперь эволюционно пришли к ChatGPT, который не заставляет ждать ответ
dalerank Автор
11.11.2023 14:12Согласен это так, мой посыл к любому разработчику не копипастить, найти решение да, скопировать решение - возможно (если не хватает своих знаний). Но не брать готовый код выдавая его за свой. Весь рассказ можно уложить пару предложений про двух джунов, которые не хотят учиться. Но такое читать не будут, я и попробовал это облечь в мини советы почему не надо.
AnimeSlave
11.11.2023 14:12...мой посыл к любому разработчику не копипастить, <...> не брать готовый код выдавая его за свой.
А вот тут уже начинаются проблемы. Я наверное опять портянку накину. Предупрежу заранее.
Многие элементарные решения однотипны. Ряд языков имеют свои гайдлайны, которые строго рекомендуют (или вовсе запрещают) определённые действия. Всякие шаблоны (или паттерны) проектирования, типа Банды Четырёх. Это я к тому, что в любом случае будут одинаковые однотипные решения. И опять же, упрощая себе работу, программист будет копировать готовое решение (подгонять или нет будет понятно по факту копипасты). Это норма сегодняшнего дня. Да, в каких-то моментах это плохо выглядит со стороны, но только тогда, когда это решение не выполняет свою функцию, или не соответствует гайдлайнам принятым в компании. Во всех остальных случаях разницы между, сам ли программист написал код, или взял готовое решение не будет. Потому что разные программисты пишут по разному. Только внутренний гайдлайн компании будет удерживать всех в одной общей стилистике. А ещё и код ревью, конечно.
У меня, как C++ программиста постоянно меняется «подчерк», потому что по мере того, как я развиваюсь я замечаю, что некоторые определённые строки кода я не могу писать как раньше, мне лично не нравится, так как я замечаю, что спустя время я перестаю понимать, что я сам написал, или же мне становится неудобно читать свой же код. Я стал более многословным в коде, хотя раньше любил однострочники (сейчас понимаю, что они зло). Но в компании, где я сейчас работаю я так писать не могу, потому что так не принято. Поэтому моё решение в любом случае будет похожим на чужое. То есть проявление индивидуальности нивелируется подходами к разработке внутри компании. Зачем тогда проявлять индивидуальность или уникальность решения? (вопрос риторический)
С другой стороны видится уже настоящая проблема. Зачем учиться, или тратить время на разработку, если есть уже готовое решение. Достаточно потратить время на поиски. Тут уже как раз дилемма. Потратить время на разработку, или на поиски решения и подгонку. Для молодых специалистов первое может быть по времени куда более трудоёмким, нежели второе. В то время, как для специалиста уровнем выше так казаться не будет. И здесь возникает вопрос постановки задачи. Жёсткие ли сроки для выполнения задачи, верно ли они рассчитаны, учитывая возможности исполнителя? Если жесткие или расчёт был сделан неверно в худшую сторону, то нет ничего удивительного в выборе простого пути.
Весь рассказ можно уложить пару предложений про двух джунов, которые не хотят учиться.
Вот это уже похоже на проблему, которую стоило бы осветить в полной мере. Но и тут нужно определиться с понятием «учиться». Учится новому, или учиться кодовой базе? У меня есть пример коллеги, который пришёл из другой компании, где всё было сделано для разработчика. Кодовая база хорошая. Документация отличная. Внутренние юнит тесты. Многоуровневый код ревью. Задачи декомпозируются вплоть до того, что описывается как это задача должна быть сделана. То есть решение уже описано, нужно только написать его в виде кода. И вот пришёл в нашу компанию программист, который привык к такой простоте, и сразу стал отказываться от задач, где ему нужно было думать. А так как документации по многим вещам у нас нет, то отказывался он много от чего. Почему ему это позволяли? Потому что вариантов не было. Его в конечно итоге уволили, но были задачи, с которыми он справился. Потому что он знал как их решать, так как уже делал практически тоже самое на предыдущем месте работы. Возможно он скопировал тот, уже готовый код.
cortl
11.11.2023 14:12Я, конечно же, за всё хорошее, против всего плохого.
Существует экономическая составляющая, которая является основной движущей силой в коммерческой организации.
-
Риск-менеджент, который утверждает, что если вы не делаете ошибок, то вы недостаточно эффективны.
А в итоге разработчик всегда плохой, как минимум по одному пункту.
SerJook
Не та нынче молодежь? Ничего, не будут в геймдеве работать, пойдут в CRUD-ошлёпы. Там всех берут.
dalerank Автор
Молодежь та как раз, пользуется новыми технологиями, а не др...т документацию по неделе. На что у меня уходит два часа, джун тоже делает за два часа. Вопрос, нафига я неделю читал доки? Осталось научить не только промпты писать, но и дебагером пользоваться, ну и чтобы это не приводило к поездке в QA отдел