Ну, в целом да, к тому же эта история из разряда: Я познал ucoz/Wix/вписать_любимое - теперь я зохвотил мир web-разработки. Ниша своя есть у этого, но она где-то там, где говнокода и так хватало с избытком.
Тем не менее, всё же остается надежда на отчаянных парней-менеджеров и в суровом энтерпрайзе, которые проведут операцию Оптимизация, и дадут порулить LLM и в лиге повыше : ) где код не одноразовый.
Так пример-то демонстрирует не упрощение, а нарушения здравого смысла — что я и заметил: смешение ответственности в классе, причём даже при этом класс ничего не делает с Web; конвертация типов в бизнес-логике — это вообще оксюморон.
Ваша мысль про суть классификации — здравая, но подана с ошибками.
Я бы добавил к ней, что именование класса состоит из двух частей: предметной роли и инфраструктурной роли. Например, сервис вычислений логичнее назвать MathService — предметно он работает с математикой, инфраструктурно — это сервис. А то, что вы назвали MathWebService, скорее соответствует MathController: предметно — математика, структурно — контроллер (устоявшееся понятие в веб-фреймворках).
Либо структуру можно выразить через неймспейсы: services.Math, controllers.Math.
За критику извиняйте — писал не для того, чтобы задеть, а чтобы предложить улучшить материал, который, безусловно, не лишён пользы.
За всеми концепциями стоят банальные реальные потребности, в том числе и за Чистым кодом. Для человека, не разбирающегося в реальных движущих силах того или иного инструмента, естественно этот инструмент превращается в фетиш, а действия с ним - в карго-культ.
Смешно читать про противопоставление тестирования и чистого кода. Смешно читать, что чистый код не нужен, потому что он мешает писать программы быстро. Это непонимание чистого кода, его функций - портрет вайбкодера : ) Между тем - Чистый код просто форма борьбы со сложностью кода и закладка фундамента под то, чтобы код был структурирован и его можно было бы развивать. Это актуально для любого интеллекта - хоть человеческого, хоть искусственного: запутанный, плохо структурированный код будет приводить к деградации понимания что происходит и что код выражает экспоненциально с ростом количества кода.
При этом я ничего против LLM не имею. Они просто не справляются на больших проектах - и это факт из моего практического, постоянного и довольно обширного опыта применения LLM для кодинга. В последнее время я стал еще и натыкаться на то, что модели отстают от актуального знания - свежих библиотек - и генерят устаревший код, а зачастую и миксуя несовместимые версии. Плачевно обстоит дело и с рефакторингом крупных проектов - нужно либо продумать этот рефакторинг и описать от и до: где и что поменять конкретно и в полуручном режиме пройтись последовательно по изменяемым программным сущностям вместе с LLM, еще и попутно поправляя ее - но тогда в чем выигрыш?; либо получить взрыв на макаронной фабрике : )
Я не против, если бы LLM могла писать код за меня - и даже знания в прграммировании мне бы не мешали при этом : ) Но - это не работает так, как пишут нам восторженные вьюноши.
Ждем следующую статью: "Будут ли важна булева алгебра в ближайшем будущем" : )
А откуда в сервисах ...WebService слово Web взялось? Эти классы ничего про Web как раз и не знают и знать не должны: им побоку - откуда данные пришли, их дело - вычисления организовать.
Пример плохой ящитаю - он скорее оттолкнет, чем заставит задуматься, потому что конкретно в данном случае - оверинжиниринг с раздуванием кодовой базы на ровном месте, и для начинающего программиста это приведет либо к тому, что он воцерквится и начнет писать так всюду - и где надо, и где не надо - запаривая коллег в случаях, где "не надо"; либо же решит, что всё это вовсе - фигня, и не будет делать этого где как раз "надо".
Конвертация типов опять же внутри Вычислителя - плохо, Вычислитель работает с числами - и его требования к входящим данным как раз должны быть озвучены в сигнатуре, а вот уже тот, кто его вызывает - пусть и конвертит типы. Забавно ведь, если вы внутри программы в другом сценарии тот же вычислитель весов будете использовать, где у вас и так числовые значения веса - так теперь, чтоб воспользоваться вычислением веса вам придется конвертнуть числа в строки чтобы вызвать вычислитель, а тот будет обратно в числа конвертить, а потом еще и вернет вам строку, которую уже вам придется конвертить обратно в число : )
Ну и в целом - лучше всё таки писать проще сначала, если сразу задача не стоит объемная, где уже понятно, что надо выделять классы. Преждевременные архитектурные экзерцисы - это преждевременная архитектурная оптимизация, которая только раздувает код без практического выхлопа.
Само собой - есть задачи, где описанное в статье применимо и адекватно, но не надо превращать это в Золотой молоток.
Вы абсолютно правы в том, что подавляющее большинство вопросов - не соответствуют практике программирования на Python. Но в то же время, если отвязаться от настойчивого желания дать по голове автору такого кода : ) и правильно подать, то эти вопросы таки затрагивают базовые вещи Python.
Первый вопрос не про порядок операций даже, а про приведение типов и то, что в Питоне не переменные, а ссылки на объекты и это порождает ряд особенностей.
Множественное наследование - уже по ответу можно понять, что это потенциальный и неиллюзорный способ выстрелить себе в ногу, вреда от этого множественного наследования больше, чем пользы, тем более, что есть масса других способов сделать то, что требуется, не делая множественного наследования. Но это-то и проверяется этим вопросом : )
Словарь и мутабельный объект как ключ - это тоже скорее вывод на тему хеширования и типов данных в Питоне, само по себе такому коду воспротивится даже интерпретатор, но не всегда... В общем, тут можно почесать языки про хеширование и мутабельность/немутабельность типов, и вот второе - это уже и впрямь база-база.
Пример с генераторами - тут не согласен, для Питона - это базовые и полезные идиомы, странно не знать.
Пример с дефолтным значением аргумента в функции - это совсем детская подстава, поэтому для Сеньора странно не знать, и так же выводит на особенности создания и линковки объектов в Питоне, ведь функция в Питоне - это тоже объект.
Короче говоря, вопросы реально элементарные и, возможно, раздражают скорее тем, что во-первых они как бы сразу ставят кандидата в позицию подозреваемого : ) во-вторых - в рабочем коде они почти все вызовут недоумение : ) Это, наверное, и создает ответную негативную реакцию как на пассивную агрессию со стороны собеседующего - а она вот точно есть: он свое разочарование в кандидатах проецирует без разбора на всех. Это своего рода неуважение без повода с порога - кому это понравится? : ) Я бы вот как минимум бы пометил у себя в голове - а это часом не контора обиженных на мир параноиков? : ) И в чём я был бы не прав? : )
Поэтому, автору - при всех благих намерениях и праведном гневе, стоило бы подумать в первую очередь над своим поведением : ) Тонны говна вылились тут на него в общем-то не просто так и не только от разных неумех. А говоря сухо и алаверды - софт скиллы-то автора статьи похрамывают, выходит?
Ну так "рынок порешал". За что боролись - на то и напоролись. Бизнес сам платит тем, кто делает быстрее, а не надежнее. Фреймворков, инструментов - куча, а порой тот или иной инструмент нужен эпизодически, так что смысла нет - глубоко копаться в нём.
Конечно база Сеньору нужна - языковая, сети, реляционные БД, но часто возникает и диаметрально противоположная ситуация: ты приходишь такой весь прошареный в базе, на которую потратил много времени, а тебе говорят: а как делается вот такая вот элементарная штука в фреймворке Х? А ты с ним не работал; и опа - ты негоден : )
Короче говоря, при том, что я не считаю озвученные вопросы в статье чем-то невменяемым, вместе с тем - это больше похоже не ретроградство и почти пИсанье против ветра. Почти - потому что всё-таки - да, Сеньор-то уж должен был до базы и через практику уже добраться.
Примеры норм, хотя я на первом тоже засомневался - такие конструкции у меня вызывают ступор : ) и негодование : ) Но вообще - автор не перешел всё же черты, за которой начинают требовать ответов на вопросы из разряда WTF Python приправленные еще и какими-то заведомо нишевыми и малоизвестными особенностями каких-то фреймворков, которые встречаются раз в тысячелетие : ) А переходят эту черту нередко.
Ситуация со знанием языков программирования и более общо - компуктер саенс - зачастую аховая, потому что много вайтишников, которые умеют более-менее сносно работать с каким-то конкретным инструментом, но за пределами его - толком ничего не знают. И это... зачастую приемлемая ситуация, ну по-крайней мере до миддловской позиции включительно. Ну а про грейдинг - известная история: в одной компании ты самый умный/опытный - Сеньор, а в другой - уже нет : )
Но в целом - я скорее согласен с автором статьи, что не ответить вменяемо на данные вопросы на уровне Сеньор - это фиаско, потому что это тащем-то действительно основы. Но замечу, что меня бы такие вопросы - насторожили, их и впрямь стоило бы вынести на уровень фильтра первичного собеса с HR, а когда ты приходишь на собес на позицию Сеньора и тебе начинает технический собеседник такие вопросы задавать - слегка теряешься и начинаешь думать: что всё это значит? : )
Я согласен, что описанный мной подход - не универсален и не применим всюду. Опять же шаблонный код и решения - это в моей практике составляет инфраструктуру, а бизнес-логика - каждый раз разная, просто она в своем слое живет.
Ну, насчет "красиво" - это тоже субъективно сильно. Я под Правильным кодом подразумеваю больше шаблонный код - когда от проекта к проекту везде одни и те же структура проекта, архитектура, компоненты, библиотеки, одинаковый DI и т.д. Понятно, что такое, во-первых, даже при примерно одинаковой сфере проекта не совпадает на 100%, но тем не менее - всё же процент шаблонности достигает 70-80%, а во-вторых - можно иметь разные шаблоны на разные классы задач.
Всё это позволяет работать командам предсказуемо с предсказуемым качеством и временем разработки, хотя, понятно, и - гипотетически - можно было бы и "лучше", "красивее", "быстрее" : ) но обычно, из-за как раз таки возникающей непредсказуемости нестандартных подходов всё получается по факту как раз ровно наоборот: плохо, коряво и вдобавок долго : )
Для реально же "особых" случаев - да, придется нестандартные решения вкручивать, но во многих сферах разработки такое встречается очень нечасто, и большую часть проектов выгоднее писать просто правильно, стандартно - и не выеживаться : )
Я код делю на Работающий, Правильный и Эффективный : ) Причем это три разных вида кода.
Работающий - тот что работает. Не важно как - но делает именно то, что должен делать. Это код джуна, который всеми правдами и неправдами добивается, чтобы программа работала.
Правильный код - это код, который следует элементарным правилам: тому же SOLID, паттернам, где они собственно и возникают и т.д. - в целом я не согласен с хитропопыми заявлениями про "понимание, где надо следовать, а где не надо следовать правилам" - это банальный самообман самоуверенности - мол, я-то уж знаю че-почем : ) Это-то и приводит к тому, что пишут все кто в лес, кто по дрова и потом тратится время на разбирательства и проблемы на ровном месте из-за того, что кто-то внезапно решил, что он умнее. Не дано умничать, где без этого можно обойтись : ) KISS в частности и об этом : ) А вот Правильный код - он стандартный, особенно, если в компании есть четкие гайды, и - да, в некоторых местах можно было бы и "срезать путь" - но это будет вносить каждый раз новые неожиданные особенности в код и каждый раз в каждом проекте можно будет встретить что угодно, и разбираться с этим, и воротить дальше еще более непредсказуемые решения. Зачем? Ради чего?
Но, опять же, из-за своей природы, Правильный код хорош в понятности, но не оптимален из-за этого в плане производительности. А иногда производительность - это требование необходимое. И вот тогда и пишут уже Эффективный код - с хаками, с ручным управлением всего и вся, с экономией памяти и многая прочая, что может понадобиться, чтобы уложиться в требования. Тут ПРИДЕТСЯ отступить от правил, потому что по-правильному код работает медленно или в другом смысле недостаточно производительно. В любом случае важно, что Эффективный код пишут не от хорошей жизни, а вынужденно! И вот тут важно этот код постараться максимально изолировать от всего прочего, чтобы сложность не пустила метастазы по всему проекту, а второе - это тщательно задокументировать - что вы тут и для чего были вынуждены наворотить, а так же - как этим пользоваться : )
Во-во, сразу видна "рука мастера" : ) Автор сего претенциозного поста элементарно не понимает, что своими "примерами переоцененности" принципов SOLID - лишь подтверждает их необходимость : )))
Ну не только. Я активно пользуюсь и генерацией гипотез в том, в чем не разбираюсь или разбираюсь слабо - ИИ генерит их быстро и так же быстро, запросами дальнейшими, можно корректировать эти гипотезы и с помощью ИИ "доводить их до ума". Но в целом - да, использование ИИ никак не избавляет от необходимости думать самому : )
Тут ведь речь не про неприятность, а про опасность отсутствия критического отношения к выдаче ИИ, а так же про то, что отсутствие фильтров может и скорее всего запустит наводнение интернета массой скам-контента, который станет попадать уже на вход обучения новым ИИ.
Ну и да - я согласен с автором в том, что если сам не знаешь ответа, то один источник - не истина в последней инстанции, нужно как минимум воспользоваться несколькими, что, опять же, необходимо и когда информация поступает не от ИИ. Опять же ИИ мне лично помогает быстрее справляться с рутиной; а так же и получать гипотезы, которые потом нужно проверить, но нагенерировать быстрее - с ИИ.
Опытному программисту как раз таки часто проще понять где проблема в нагенерированном ИИ коде и точечно исправить, вместо того, чтобы писать всё заново самому. Это и позволяет избавиться от рутины. Более того, опытный программист и задачу по идее должен ставить гораздо точнее - ну если он действительно опытен, в том числе с описанием и того КАКИМИ КЛЮЧЕВЫМИ СПОСОБАМИ должно реализовываться решение - это, разумеется, направляет ИИ в генерации, и код получается, соответственно, гораздо более адекватный, а часто и вовсе не требующий исправлений.
То, что "программисты больше не нужны" - это, конечно, пока бред, потому что как раз таки адекватно ставить задачи ИИ, понимать архитектуру будущего решения, ревьюить код и исправлять его кому-то нужно, человек без программистского опыта сделать это может весьма ограниченно - ваш пример тому иллюстрация. И это при том, что у вас задача была несколько скриптов написать - а в больших проектах проблемы умножаются в разы, и пока ИИ самостоятельно в архитектуру может только очень ограниченно, не хватает ему охвата - он хорошо работает только в локальных областях кода.
Оба полярных мнения - и хайповое, что нейросеть за вас проект напишет, и негативная - что это бесполезная ерунда или того более как в статье - еще и вредная - далеки от реальности. Точнее, в первом случае - нет пруфов или же утверждения делают люди, которые под проектом понимают небольшой скрипт, а во втором случае - чаще всего у пользователя ИИ руки не из того места или же он вообще даже "не читал, но осуждает".
Я - немолодой специалист, работаю в ИТ больше 22 лет и видал еще дискеты и DOS в качестве рабочей ОС - в общем сложно меня заподозрить в стильно-модно-молодежности. ИИ-асситенты использую где-то уже как полтора года - и перепробовал много разных. Вначале они действительно не впечатляли от слова совсем, из всей функциональности было только автодополнение, подсказки были посредственные и годились в подавляющем большинстве только в тривиальных случаях.
Примерно с год назад я впервые подключил в VS Code плагин sorcery - и вот от него уже стала появляться ощутимая польза. Этот ассистент заточен на рефакторинг и зачастую реально давал дельные советы. Помогало это и в плане ревью, и в том, что код можно было набросать быстро не особо заботясь о его архитектурной правильности/эффективности/красивости - главное, чтобы работал правильно, а затем быстро с помощью этого ассистента причесать. Речь, разумеется, идет о коде классов, функций, а не целых модулей или того более - проектов. Но и такое ограниченное применение дает прибавку к скорости. Этот асситент, кстати, мог не только метод отрефакторить, но и, если он был слишком велик - разделить на методы, причем с соблюдением SRP и правильно связать всё между собой. Ошибки, разумеется, встречались, но где-то в пределах не более чем в 25%. Так же не всегда и предлагаемый рефакторинг мне нравился, хоть и был без ошибок - иногда было ненужное усложнение кода и/или слишком уж буквальное следование "лучшим практикам" в местах, где этого и не требовалось - задача тривиальная, а ассистент решает её по всем канонам, так что бойлерплейта становилось в разы больше, чем бизнес-функционала - в общем "из пушки по воробьям" что называется. Но - повторюсь - пользу уже часто можно было извлечь.
ChatGPT - в то время версии 3 - тоже находил мной весьма ограниченное применение в программировании - в задачах, где мне нужен был код по описанию, реализуемый в нескольких связанных классах/функциях. По моему опыту успех таких запросов составлял 50/50, ну то есть ии мог равно подкинуть и годный рабочий вариант, и мог и что-то кривое, а то и полностью нерабочее. Но, в случаях, когда нужны идеи и/или работаешь с чем-то незнакомым - и это вполне помогает, так как дает направление - куда можно порыть. Здесь по поводу той версии ГПТ должна быть та самая картинка с Тиньковым про "сомнительно, но окэй" : )
Дальше, где-то с полгода назад я стал пользоваться еще одним ассистентом - и вот он уже бустит очень ощутимо: и в плане автодополнения, и написания кусков кода по запросу, и при рефакторинге, и для написания тестов, и для генерации гипотез. Слабости тут следующие: в качестве контекста адекватно использует объемы в размере модуля, подсовывание большего контекста работает посредственно, хотя и помогает улучшить результаты генерации. Довольно посредственная генерация решений по описаниям в чате - по-крайней мере сильно уступает ChatGPT версии 4o и Claude Sonnet 3.5, в которых решения процентов в 80 - практически готовые к применению.
Надо так же отметить, что с нейросетями надо уметь работать - ставить перед ними задачи четко, грамотно формировать контекст, корректировать - и счастье будет. Иначе - ровно то же, что и с программистом-человеком: "Какое ТЗ - такой и результат".
Ни одна известная мне система не может написать код целого более-менее среднего размера проекта разом - чем больше взаимодействующих объектов, тем сложнее их генерить. Это, в общем-то, аналогично и для человека. Есть информация, что на такое способна новейшая модель о1, но у меня возможности проверить это еще не представлялось.
Даже и куски нагенеренного кода надо отсматривать и тестировать - в них могут быть упущены важные условия, а то и содержаться ошибки. Но если вы генерите код степ-бай-степ, а не разом просите вам выдать проект на-гора, то и проблемы с проверкой нет - вникнуть и оценить легко. Галлюционировать сети в применении к разработке ПО, кстати, стали значительно реже со времен моих первых опытов.
По итогу, можно сказать, что в умелых руках этот инструмент и работает уже хорошо, и сам инструмент - ии-ассистенты - постепенно развивается и становится и богаче по возможностям, и качественнее. За себя могу сказать, что уже сейчас работа с ии-ассистентами по сравнению с работой в голой IDE сравнима с разницей работы в голой IDE и набором кода в Блокноте. Ну и - да, если использовать ту же IDE исключительно как Блокнот, не разобравшись как и что настроить и иcпользовать - и IDE будет только мешать любителю старины глубокой : )
Ну и чудес - тоже не бывает. Без собственного программистского опыта и с ИИ-ассистентом можно наворотить такого же говнокода, что и без него, и даже больше - ибо быстрее же! : ) Но и это не ново под луной - фуллстаковерфлоу программистов и без ИИ было достаточно.
Эта статья действительно из разряда "Unit Of Work, который мы заслужили" : )
Что, кстати, делать, если нужны запросы, выходящие за пределы CRUD? Расширять базовый репозиторий методами? И в примерах - нет последовательности, те же BookRepository, UserRepository и RentalRepository - уже не являются наследниками базового репозитория, тогда зачем он вообще был введен?
В общем - искания автора поддерживаю; представленная реализация - далека от адекватности.
Ну, в целом да, к тому же эта история из разряда: Я познал ucoz/Wix/вписать_любимое - теперь я зохвотил мир web-разработки. Ниша своя есть у этого, но она где-то там, где говнокода и так хватало с избытком.
Тем не менее, всё же остается надежда на отчаянных парней-менеджеров и в суровом энтерпрайзе, которые проведут операцию Оптимизация, и дадут порулить LLM и в лиге повыше : ) где код не одноразовый.
Это, я считаю, на сегодняшний день заслуживает первого места в номинации «Лучший манифест говнокодинга» : ))
А по ситуации - это прекрасный задел для реальных программистов, когда после волны вайбоподелок придется разгребать последствия : )
Вайбте больше и быстрее, ребята! Больше будет работы в недалеком будущем для тех, кто разбирается в программировании : )
Так пример-то демонстрирует не упрощение, а нарушения здравого смысла — что я и заметил: смешение ответственности в классе, причём даже при этом класс ничего не делает с Web; конвертация типов в бизнес-логике — это вообще оксюморон.
Ваша мысль про суть классификации — здравая, но подана с ошибками.
Я бы добавил к ней, что именование класса состоит из двух частей: предметной роли и инфраструктурной роли. Например, сервис вычислений логичнее назвать
MathService— предметно он работает с математикой, инфраструктурно — это сервис. А то, что вы назвалиMathWebService, скорее соответствуетMathController: предметно — математика, структурно — контроллер (устоявшееся понятие в веб-фреймворках).Либо структуру можно выразить через неймспейсы:
services.Math,controllers.Math.За критику извиняйте — писал не для того, чтобы задеть, а чтобы предложить улучшить материал, который, безусловно, не лишён пользы.
За всеми концепциями стоят банальные реальные потребности, в том числе и за Чистым кодом. Для человека, не разбирающегося в реальных движущих силах того или иного инструмента, естественно этот инструмент превращается в фетиш, а действия с ним - в карго-культ.
Смешно читать про противопоставление тестирования и чистого кода. Смешно читать, что чистый код не нужен, потому что он мешает писать программы быстро. Это непонимание чистого кода, его функций - портрет вайбкодера : ) Между тем - Чистый код просто форма борьбы со сложностью кода и закладка фундамента под то, чтобы код был структурирован и его можно было бы развивать. Это актуально для любого интеллекта - хоть человеческого, хоть искусственного: запутанный, плохо структурированный код будет приводить к деградации понимания что происходит и что код выражает экспоненциально с ростом количества кода.
При этом я ничего против LLM не имею. Они просто не справляются на больших проектах - и это факт из моего практического, постоянного и довольно обширного опыта применения LLM для кодинга. В последнее время я стал еще и натыкаться на то, что модели отстают от актуального знания - свежих библиотек - и генерят устаревший код, а зачастую и миксуя несовместимые версии. Плачевно обстоит дело и с рефакторингом крупных проектов - нужно либо продумать этот рефакторинг и описать от и до: где и что поменять конкретно и в полуручном режиме пройтись последовательно по изменяемым программным сущностям вместе с LLM, еще и попутно поправляя ее - но тогда в чем выигрыш?; либо получить взрыв на макаронной фабрике : )
Я не против, если бы LLM могла писать код за меня - и даже знания в прграммировании мне бы не мешали при этом : ) Но - это не работает так, как пишут нам восторженные вьюноши.
Ждем следующую статью: "Будут ли важна булева алгебра в ближайшем будущем" : )
А откуда в сервисах ...
WebServiceслово Web взялось? Эти классы ничего про Web как раз и не знают и знать не должны: им побоку - откуда данные пришли, их дело - вычисления организовать.Пример плохой ящитаю - он скорее оттолкнет, чем заставит задуматься, потому что конкретно в данном случае - оверинжиниринг с раздуванием кодовой базы на ровном месте, и для начинающего программиста это приведет либо к тому, что он воцерквится и начнет писать так всюду - и где надо, и где не надо - запаривая коллег в случаях, где "не надо"; либо же решит, что всё это вовсе - фигня, и не будет делать этого где как раз "надо".
Конвертация типов опять же внутри Вычислителя - плохо, Вычислитель работает с числами - и его требования к входящим данным как раз должны быть озвучены в сигнатуре, а вот уже тот, кто его вызывает - пусть и конвертит типы. Забавно ведь, если вы внутри программы в другом сценарии тот же вычислитель весов будете использовать, где у вас и так числовые значения веса - так теперь, чтоб воспользоваться вычислением веса вам придется конвертнуть числа в строки чтобы вызвать вычислитель, а тот будет обратно в числа конвертить, а потом еще и вернет вам строку, которую уже вам придется конвертить обратно в число : )
Ну и в целом - лучше всё таки писать проще сначала, если сразу задача не стоит объемная, где уже понятно, что надо выделять классы. Преждевременные архитектурные экзерцисы - это преждевременная архитектурная оптимизация, которая только раздувает код без практического выхлопа.
Само собой - есть задачи, где описанное в статье применимо и адекватно, но не надо превращать это в Золотой молоток.
Тоже про такое подумал, что не помешало бы в конце такого собеса спросить: а эти примеры - они у вас в коде встречаются?
На всякий случай : )
Вы к людям с подозрением в них тупости - они вам алаверды. Всё честно : )
Вы абсолютно правы в том, что подавляющее большинство вопросов - не соответствуют практике программирования на Python. Но в то же время, если отвязаться от настойчивого желания дать по голове автору такого кода : ) и правильно подать, то эти вопросы таки затрагивают базовые вещи Python.
Первый вопрос не про порядок операций даже, а про приведение типов и то, что в Питоне не переменные, а ссылки на объекты и это порождает ряд особенностей.
Множественное наследование - уже по ответу можно понять, что это потенциальный и неиллюзорный способ выстрелить себе в ногу, вреда от этого множественного наследования больше, чем пользы, тем более, что есть масса других способов сделать то, что требуется, не делая множественного наследования. Но это-то и проверяется этим вопросом : )
Словарь и мутабельный объект как ключ - это тоже скорее вывод на тему хеширования и типов данных в Питоне, само по себе такому коду воспротивится даже интерпретатор, но не всегда... В общем, тут можно почесать языки про хеширование и мутабельность/немутабельность типов, и вот второе - это уже и впрямь база-база.
Пример с генераторами - тут не согласен, для Питона - это базовые и полезные идиомы, странно не знать.
Пример с дефолтным значением аргумента в функции - это совсем детская подстава, поэтому для Сеньора странно не знать, и так же выводит на особенности создания и линковки объектов в Питоне, ведь функция в Питоне - это тоже объект.
Короче говоря, вопросы реально элементарные и, возможно, раздражают скорее тем, что во-первых они как бы сразу ставят кандидата в позицию подозреваемого : ) во-вторых - в рабочем коде они почти все вызовут недоумение : ) Это, наверное, и создает ответную негативную реакцию как на пассивную агрессию со стороны собеседующего - а она вот точно есть: он свое разочарование в кандидатах проецирует без разбора на всех. Это своего рода неуважение без повода с порога - кому это понравится? : ) Я бы вот как минимум бы пометил у себя в голове - а это часом не контора обиженных на мир параноиков? : ) И в чём я был бы не прав? : )
Поэтому, автору - при всех благих намерениях и праведном гневе, стоило бы подумать в первую очередь над своим поведением : ) Тонны говна вылились тут на него в общем-то не просто так и не только от разных неумех. А говоря сухо и алаверды - софт скиллы-то автора статьи похрамывают, выходит?
Ну так "рынок порешал". За что боролись - на то и напоролись. Бизнес сам платит тем, кто делает быстрее, а не надежнее. Фреймворков, инструментов - куча, а порой тот или иной инструмент нужен эпизодически, так что смысла нет - глубоко копаться в нём.
Конечно база Сеньору нужна - языковая, сети, реляционные БД, но часто возникает и диаметрально противоположная ситуация: ты приходишь такой весь прошареный в базе, на которую потратил много времени, а тебе говорят: а как делается вот такая вот элементарная штука в фреймворке Х? А ты с ним не работал; и опа - ты негоден : )
Короче говоря, при том, что я не считаю озвученные вопросы в статье чем-то невменяемым, вместе с тем - это больше похоже не ретроградство и почти пИсанье против ветра. Почти - потому что всё-таки - да, Сеньор-то уж должен был до базы и через практику уже добраться.
Примеры норм, хотя я на первом тоже засомневался - такие конструкции у меня вызывают ступор : ) и негодование : ) Но вообще - автор не перешел всё же черты, за которой начинают требовать ответов на вопросы из разряда WTF Python приправленные еще и какими-то заведомо нишевыми и малоизвестными особенностями каких-то фреймворков, которые встречаются раз в тысячелетие : ) А переходят эту черту нередко.
Ситуация со знанием языков программирования и более общо - компуктер саенс - зачастую аховая, потому что много вайтишников, которые умеют более-менее сносно работать с каким-то конкретным инструментом, но за пределами его - толком ничего не знают. И это... зачастую приемлемая ситуация, ну по-крайней мере до миддловской позиции включительно. Ну а про грейдинг - известная история: в одной компании ты самый умный/опытный - Сеньор, а в другой - уже нет : )
Но в целом - я скорее согласен с автором статьи, что не ответить вменяемо на данные вопросы на уровне Сеньор - это фиаско, потому что это тащем-то действительно основы. Но замечу, что меня бы такие вопросы - насторожили, их и впрямь стоило бы вынести на уровень фильтра первичного собеса с HR, а когда ты приходишь на собес на позицию Сеньора и тебе начинает технический собеседник такие вопросы задавать - слегка теряешься и начинаешь думать: что всё это значит? : )
Я согласен, что описанный мной подход - не универсален и не применим всюду. Опять же шаблонный код и решения - это в моей практике составляет инфраструктуру, а бизнес-логика - каждый раз разная, просто она в своем слое живет.
Ну, насчет "красиво" - это тоже субъективно сильно. Я под Правильным кодом подразумеваю больше шаблонный код - когда от проекта к проекту везде одни и те же структура проекта, архитектура, компоненты, библиотеки, одинаковый DI и т.д. Понятно, что такое, во-первых, даже при примерно одинаковой сфере проекта не совпадает на 100%, но тем не менее - всё же процент шаблонности достигает 70-80%, а во-вторых - можно иметь разные шаблоны на разные классы задач.
Всё это позволяет работать командам предсказуемо с предсказуемым качеством и временем разработки, хотя, понятно, и - гипотетически - можно было бы и "лучше", "красивее", "быстрее" : ) но обычно, из-за как раз таки возникающей непредсказуемости нестандартных подходов всё получается по факту как раз ровно наоборот: плохо, коряво и вдобавок долго : )
Для реально же "особых" случаев - да, придется нестандартные решения вкручивать, но во многих сферах разработки такое встречается очень нечасто, и большую часть проектов выгоднее писать просто правильно, стандартно - и не выеживаться : )
Я код делю на Работающий, Правильный и Эффективный : ) Причем это три разных вида кода.
Работающий - тот что работает. Не важно как - но делает именно то, что должен делать. Это код джуна, который всеми правдами и неправдами добивается, чтобы программа работала.
Правильный код - это код, который следует элементарным правилам: тому же SOLID, паттернам, где они собственно и возникают и т.д. - в целом я не согласен с хитропопыми заявлениями про "понимание, где надо следовать, а где не надо следовать правилам" - это банальный самообман самоуверенности - мол, я-то уж знаю че-почем : ) Это-то и приводит к тому, что пишут все кто в лес, кто по дрова и потом тратится время на разбирательства и проблемы на ровном месте из-за того, что кто-то внезапно решил, что он умнее. Не дано умничать, где без этого можно обойтись : ) KISS в частности и об этом : ) А вот Правильный код - он стандартный, особенно, если в компании есть четкие гайды, и - да, в некоторых местах можно было бы и "срезать путь" - но это будет вносить каждый раз новые неожиданные особенности в код и каждый раз в каждом проекте можно будет встретить что угодно, и разбираться с этим, и воротить дальше еще более непредсказуемые решения. Зачем? Ради чего?
Но, опять же, из-за своей природы, Правильный код хорош в понятности, но не оптимален из-за этого в плане производительности. А иногда производительность - это требование необходимое. И вот тогда и пишут уже Эффективный код - с хаками, с ручным управлением всего и вся, с экономией памяти и многая прочая, что может понадобиться, чтобы уложиться в требования. Тут ПРИДЕТСЯ отступить от правил, потому что по-правильному код работает медленно или в другом смысле недостаточно производительно. В любом случае важно, что Эффективный код пишут не от хорошей жизни, а вынужденно! И вот тут важно этот код постараться максимально изолировать от всего прочего, чтобы сложность не пустила метастазы по всему проекту, а второе - это тщательно задокументировать - что вы тут и для чего были вынуждены наворотить, а так же - как этим пользоваться : )
hu yok hu yok - и в продакшн!
Во-во, сразу видна "рука мастера" : ) Автор сего претенциозного поста элементарно не понимает, что своими "примерами переоцененности" принципов SOLID - лишь подтверждает их необходимость : )))
Рановато замахнулся.
Ну не только. Я активно пользуюсь и генерацией гипотез в том, в чем не разбираюсь или разбираюсь слабо - ИИ генерит их быстро и так же быстро, запросами дальнейшими, можно корректировать эти гипотезы и с помощью ИИ "доводить их до ума". Но в целом - да, использование ИИ никак не избавляет от необходимости думать самому : )
Тут ведь речь не про неприятность, а про опасность отсутствия критического отношения к выдаче ИИ, а так же про то, что отсутствие фильтров может и скорее всего запустит наводнение интернета массой скам-контента, который станет попадать уже на вход обучения новым ИИ.
Ну и да - я согласен с автором в том, что если сам не знаешь ответа, то один источник - не истина в последней инстанции, нужно как минимум воспользоваться несколькими, что, опять же, необходимо и когда информация поступает не от ИИ. Опять же ИИ мне лично помогает быстрее справляться с рутиной; а так же и получать гипотезы, которые потом нужно проверить, но нагенерировать быстрее - с ИИ.
Опытному программисту как раз таки часто проще понять где проблема в нагенерированном ИИ коде и точечно исправить, вместо того, чтобы писать всё заново самому. Это и позволяет избавиться от рутины. Более того, опытный программист и задачу по идее должен ставить гораздо точнее - ну если он действительно опытен, в том числе с описанием и того КАКИМИ КЛЮЧЕВЫМИ СПОСОБАМИ должно реализовываться решение - это, разумеется, направляет ИИ в генерации, и код получается, соответственно, гораздо более адекватный, а часто и вовсе не требующий исправлений.
То, что "программисты больше не нужны" - это, конечно, пока бред, потому что как раз таки адекватно ставить задачи ИИ, понимать архитектуру будущего решения, ревьюить код и исправлять его кому-то нужно, человек без программистского опыта сделать это может весьма ограниченно - ваш пример тому иллюстрация. И это при том, что у вас задача была несколько скриптов написать - а в больших проектах проблемы умножаются в разы, и пока ИИ самостоятельно в архитектуру может только очень ограниченно, не хватает ему охвата - он хорошо работает только в локальных областях кода.
Плохому танцору - и тестикулы помеха.
Оба полярных мнения - и хайповое, что нейросеть за вас проект напишет, и негативная - что это бесполезная ерунда или того более как в статье - еще и вредная - далеки от реальности. Точнее, в первом случае - нет пруфов или же утверждения делают люди, которые под проектом понимают небольшой скрипт, а во втором случае - чаще всего у пользователя ИИ руки не из того места или же он вообще даже "не читал, но осуждает".
Я - немолодой специалист, работаю в ИТ больше 22 лет и видал еще дискеты и DOS в качестве рабочей ОС - в общем сложно меня заподозрить в стильно-модно-молодежности. ИИ-асситенты использую где-то уже как полтора года - и перепробовал много разных. Вначале они действительно не впечатляли от слова совсем, из всей функциональности было только автодополнение, подсказки были посредственные и годились в подавляющем большинстве только в тривиальных случаях.
Примерно с год назад я впервые подключил в VS Code плагин sorcery - и вот от него уже стала появляться ощутимая польза. Этот ассистент заточен на рефакторинг и зачастую реально давал дельные советы. Помогало это и в плане ревью, и в том, что код можно было набросать быстро не особо заботясь о его архитектурной правильности/эффективности/красивости - главное, чтобы работал правильно, а затем быстро с помощью этого ассистента причесать. Речь, разумеется, идет о коде классов, функций, а не целых модулей или того более - проектов. Но и такое ограниченное применение дает прибавку к скорости. Этот асситент, кстати, мог не только метод отрефакторить, но и, если он был слишком велик - разделить на методы, причем с соблюдением SRP и правильно связать всё между собой. Ошибки, разумеется, встречались, но где-то в пределах не более чем в 25%. Так же не всегда и предлагаемый рефакторинг мне нравился, хоть и был без ошибок - иногда было ненужное усложнение кода и/или слишком уж буквальное следование "лучшим практикам" в местах, где этого и не требовалось - задача тривиальная, а ассистент решает её по всем канонам, так что бойлерплейта становилось в разы больше, чем бизнес-функционала - в общем "из пушки по воробьям" что называется. Но - повторюсь - пользу уже часто можно было извлечь.
ChatGPT - в то время версии 3 - тоже находил мной весьма ограниченное применение в программировании - в задачах, где мне нужен был код по описанию, реализуемый в нескольких связанных классах/функциях. По моему опыту успех таких запросов составлял 50/50, ну то есть ии мог равно подкинуть и годный рабочий вариант, и мог и что-то кривое, а то и полностью нерабочее. Но, в случаях, когда нужны идеи и/или работаешь с чем-то незнакомым - и это вполне помогает, так как дает направление - куда можно порыть. Здесь по поводу той версии ГПТ должна быть та самая картинка с Тиньковым про "сомнительно, но окэй" : )
Дальше, где-то с полгода назад я стал пользоваться еще одним ассистентом - и вот он уже бустит очень ощутимо: и в плане автодополнения, и написания кусков кода по запросу, и при рефакторинге, и для написания тестов, и для генерации гипотез. Слабости тут следующие: в качестве контекста адекватно использует объемы в размере модуля, подсовывание большего контекста работает посредственно, хотя и помогает улучшить результаты генерации. Довольно посредственная генерация решений по описаниям в чате - по-крайней мере сильно уступает ChatGPT версии 4o и Claude Sonnet 3.5, в которых решения процентов в 80 - практически готовые к применению.
Надо так же отметить, что с нейросетями надо уметь работать - ставить перед ними задачи четко, грамотно формировать контекст, корректировать - и счастье будет. Иначе - ровно то же, что и с программистом-человеком: "Какое ТЗ - такой и результат".
Ни одна известная мне система не может написать код целого более-менее среднего размера проекта разом - чем больше взаимодействующих объектов, тем сложнее их генерить. Это, в общем-то, аналогично и для человека. Есть информация, что на такое способна новейшая модель о1, но у меня возможности проверить это еще не представлялось.
Даже и куски нагенеренного кода надо отсматривать и тестировать - в них могут быть упущены важные условия, а то и содержаться ошибки. Но если вы генерите код степ-бай-степ, а не разом просите вам выдать проект на-гора, то и проблемы с проверкой нет - вникнуть и оценить легко. Галлюционировать сети в применении к разработке ПО, кстати, стали значительно реже со времен моих первых опытов.
По итогу, можно сказать, что в умелых руках этот инструмент и работает уже хорошо, и сам инструмент - ии-ассистенты - постепенно развивается и становится и богаче по возможностям, и качественнее. За себя могу сказать, что уже сейчас работа с ии-ассистентами по сравнению с работой в голой IDE сравнима с разницей работы в голой IDE и набором кода в Блокноте. Ну и - да, если использовать ту же IDE исключительно как Блокнот, не разобравшись как и что настроить и иcпользовать - и IDE будет только мешать любителю старины глубокой : )
Ну и чудес - тоже не бывает. Без собственного программистского опыта и с ИИ-ассистентом можно наворотить такого же говнокода, что и без него, и даже больше - ибо быстрее же! : ) Но и это не ново под луной - фуллстаковерфлоу программистов и без ИИ было достаточно.
Эта статья действительно из разряда "Unit Of Work, который мы заслужили" : )
Что, кстати, делать, если нужны запросы, выходящие за пределы CRUD? Расширять базовый репозиторий методами? И в примерах - нет последовательности, те же
BookRepository, UserRepository и RentalRepository - уже не являются наследниками базового репозитория, тогда зачем он вообще был введен?
В общем - искания автора поддерживаю; представленная реализация - далека от адекватности.