Во-во, сразу видна "рука мастера" : ) Автор сего претенциозного поста элементарно не понимает, что своими "примерами переоцененности" принципов 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 - уже не являются наследниками базового репозитория, тогда зачем он вообще был введен?
В общем - искания автора поддерживаю; представленная реализация - далека от адекватности.
Это нормальная биологическая стратегия выживания : ) Другое дело, что при всем оптимизме, надо понимать, что твои оценки не имеют под собой достаточных оснований, и воспринимать их и работать с ними надо соответствующе, без возложение чрезмерных надежд.
А оптимизм при этом терять не надо : ) Надо всего лишь принять, что нет способа точно предсказать будущее, а если ты себя и не обманываешь этим - то открываются уже новые возможности!
И что с того, что задачи решались много раз кем-то, когда речь про вашу оценку? Это вы много уже раз решали все задачи? Или даже ваши коллеги по компании, которые вам подскажут?
И по-порядку:
Технологий - разных - великое число, и их становится только больше, и спрос на них постоянно растет. Обойтись json'ом и знанием SQL можно только в узкой нише. Да, есть набор технологий, которые присутствуют практическом в каждом проекте, однако это не равно тому, что именно они определяют проект и из них следуют все иные, задействуемые на проектах, технологии. Я не знаю с чем вы там работает, что у вас так славно всё выводится из очень небольшого набора технологий, хотя, вот, то же упоминание стриминга - вы что, серьезно его json'ом передавали? Я сам имел дело с видеостримингом и прекрасно знаю, что без понимания работы кодеков, без понимания строения видеоданных, без понимания специфичных протоколов передачи стрима, никакого видеостриминга не получится, и знания json и SQL тут нерелевантны. Или вам выдали готовую библиотеку с ручками, которую вы и дергали, представляя себе, что вся обработка видео - это не более, чем обращение к API? Так это другой уровень, на котором - да - всё напоминает гвозди json.
И, конечно, легко воображать себя Львом Толстым и знатоком всех технологий, но на практике - если ваша работа действительно разнообразна, а не так как я и писал - имеет более-менее типовой характер, то вы постоянно сталкиваетесь с отсутствием опыта в некоторых областях, который невозможно вывести из вашего иного опыта, ибо при всем том, что действительно в основе все те же биты, но организованы они сильно по-разному, и через это приобретают принципиально иные качества.
Про востребованность технологий я тоже не с потолка беру - сейчас чуть не каждый пятый хочет то аналитическую базу с нехилыми объемами данных, где где реляционные базы данных уже не вывозят, то нейросеть, то свой ГИС-сервис, то еще что. Причем ожидания, само-собой, на уровне качества сервисов ведущих вендоров, представляя себе, по-видимому, как раз как и вы, что сделать такую штуку - как два пальца об асфальт - оно ж "все одно и то же".
Второе - логика. Опять - логика в каком-нибудь, например, сайте - интернет-витрине, и логика в комплексной системе, которая охватывает модули работы с поставщиками, учетные системы, склады, логистику, системы мотивации продавцов, маркетинговые системы, кучу еще модулей и, наконец - собственно интернет-витрину - это две большие разницы. И эта логика диктует и выбор других технологических компонентов, других архитектур, других подходов. Но кроме этой технологической нагрузки и сама логика по сложности своей опять же нелинейно растет, ввиду множества связей между модулями - наивно полагать, что срок разработки сложной многомодульной системы - равен произведению срока разработки одного модуля на их количество, даже будь они примерно одинаково трудоемки - нет, так не выйдет, потому что модули не сами по себе будут работать, они связаны, и вы неизбежно столкнетесь и с задачей интеграции их в единую систему, с задачей управления этим сложным конгломератом - как на этапе разработки, так и в дальнейшем - при сопровождении и развитии этой системы, и, собственно, с задаче согласованной работы всей этой системы.
Так что я вполне обоснованно утверждаю, что, образно говоря, "автомобиль" - это не такая разновидность "лошади", хотя - да, обе как бы могут быть транспортом. Но по этому признаку - использования в качества транспорта - отождествлять их совершенно некорректно. А не образно говоря: ПО другому ПО - рознь. И потому, в том числе, и не существует универсальной и надежной методики расчета срока разработки ПО.
Вы своими словами как бы отрицаете реальность: что, мол, технологии каменного века - суть всё то же самое что и современные нам, "ведь всё ж типовое". Этак вас послушать, так и никакого развития нету, а вы - легко правой пяткой настрочите нам ИИ покруче всех - а чего там, всёж те же самые битики ж туда-сюда перекладываются.
Матерь божья! Да всё просто: если у вас есть формула расчета правильных сроков - будь она хоть стохастической, хоть какой - то, собственно, вопрос манипуляций отпадает сам собой. Потому что есть ОБОСНОВАННАЯ оценка.
А если никто не может назвать и ОБОСНОВАТЬ правильность оценки срока, то все дальнейшие рассуждения - гроша выеденного не стоят по сути. Даже и оценки постфактум - фигня, потому что в процессе разработки не только злонамеренное сачкование может быть, а и масса других факторов, например, проблемы с железом, с документацией, с неизвестными дотоле багами в подключаемых сторонних библиотеках, с непреднамеренными факапами, с затягиванием сроков поставки каких-то ресурсов - схем там процессов, или данных, доступов - да тут просто прорва факторов.
И в конце концов, друзья мои, именно ТОТ СРОК, ЧТО ВЫШЕЛ ПО ФАКТУ - И ЕСТЬ РЕАЛЬНЫЙ СРОК РАЗРАБОТКИ : ) Именно в нем и "учтено" всё то, что могло произойти и произошло таки! А всё остальное - если бы, да кабы.
"Приблизительно ворочать мешки" и "ворочать мешки" - это две большие разницы. Именно здесь чаще всего и возникают недопонимания между заказчиками, которые же приблизительно точно знают чего хотят - и программистами, которые должны уже однозначно точно дать указания компьютеру что он должен делать : ) Впрочем, это лирика. А насчет долженствований - да я просто хотел узнать как именно должна работать ваша идея, ибо в своем приблизительном виде она выглядит для меня наивной по озвученной мной и некоторыми другими участниками нашей беседы причинам. Поэтому надо смотреть "конкретный код", а не оперировать очередными неопределенностями - такая у нас работа.
Как минимум тогда интересно - каким образом вебстриминг, например, и банковская система является типовой относительно друг друга? Вы хотите сказать, что банковские расчеты и логика - это такой вид вебстриминга?
Вы так считаете? На мой взгляд, большинство задач в МИРЕ это у нас есть какие‑то данные, нужно взять типовые инструменты, сделать типовую аналитику с типовым фронтов и с типовым беком, сделать интеграцию типовыми способами и т. д.
Невероятно сильное обобщение. В принципе, все в природе из одних и тех же атомов состоит - значит ли это, что разница между камнем, положим, и человеком - невелика? : )
А я еще раз повторю - чтобы говорить об искажениях оценки надо знать для начала - какая оценка эталонная : ) А когда неизвестно что есть Истина - нельзя сказать и что есть Ложь.
А с чем выплаты связаны? Какова функция расчета раз уж мы тут все такие программисты - нам нужна функция - что на входе и как рассчитывается результат этой функции : ))) А так - это напоминает старинный мем:
Ну да, для типовой разработки это более-менее работает - вот вы пишите типовые конфигурации 1С, к примеру, имеете штат сотрудников, чьи навыки работы с типовыми инструментами 1С экзаменуете периодически - и да, можете вполне адекватно предсказывать разработку. Но это очень далеко не всё, что происходит в разработке ПО - как раз таки подавляющее большинство - это новые предметные области с новыми подходами и новыми требованиями - и здесь, в этой обширнейшей нише расчеты сроков становятся заметно неточными, потому что нет типовых решений.
Вам же объяснили уже, что в большой системе - нелинейные зависимости между входящими данными и результатом. Так же точно происходит с предсказанием погоды - это же уже исследовалось, и даже понятно почему так происходит - погуглите Эдварда Лоренца с его "эффектом бабочки".
Тут вовсе не рассматривается вопрос стимуляции разработчиков, тут именно что вопрос - а как оценить разработку проекта более-менее приемлемо? Эта проблема не только перед заказчиком стоит, но и перед разработчиком.
Усреднение разных оценок не поможет. Разработчики все с разным опытом, да и опыт одного и того же разработчика изменяется со временем. Это раз. Второе - это то, что любая оценка даже опытнейшего разработчика строится на неопределенности - ну то есть в лучшем случае понимает это, а в худшем - занимается самообманом, который выльется в срыв озвученных сроков, что повсеместно и происходит с малоопытными, но - или, скорее - "потому и" - уверенных в своих оценках, специалистами.
Конечно, бывают проекты, в которых требования достаточно точны и даже имеется опыт их реализации - их оценивать легче и можно не перезакладываться сильно на риск, но даже в таких проектах факторы неверных толкований и вероятных изменений не отменяются и создают риск не влезть в неучитывающий их срок.
Конечно, если вы пишите из года в год примерно одно и то же на типовой платформе, плюс как-то научились контролировать грейд специалистов (обязательной сертификацией/аттестацией, например), то статистический подход еще может помочь, но это довольно узкая область разработки ПО. Подавляющее же число разработок ПО слабо походят на друг друга.
И в любом случае, это про те случаи, когда проект небольшой, по большей части состоит из знакомого по опыту функционала и требования прописаны достаточно детально, а часто - ТЗ состоит из дефиниций "хотелок", без каких-либо деталей и/или требуется "запилить" что-нибудь из разряда "как у Гугла" - только вот заказчик не понимает, что Гугл разрабатывал свою машинерию 30 лет огромными командами и сделал кучу неудачных подходов, прежде чем получил результат.
Проблема в том, что даже в адекватно прописанном в ТЗ и знакомом по опыту функционале всегда остается много неопределенности, если даже вам вдоль и поперек знакома фича по предыдущему опыту - это вовсе не означает что вы:
Точно идентифицировали фичу - вполне может быть, что заказчик подразумевает нечто иное.
Фичи практически никогда не бывают одинаковыми - иначе, как и было подмечено, разработчики бы тупо собирали ПО из давно сделанных кирпичиков - но нет, каждый раз свои нюансы.
Практически ни один проект не обходится без внесения изменений в процессе разработки - как бы там ни божился заказчик и как бы опытен ни был аналитик/архитектор.
Из известных мне и более-менее рабочих способов гадания на сроки - это закладка риска: то есть определяешь сколько по твоему мнению на разработку фичи нужно времени и добавляешь на неопределенность еще 15-20% времени - как раз на то, что фичу неправильно понял, фича будет меняться и/или возникнут другие непредвиденные обстоятельства.
В целом это работает, но не в минимум двух случаях:
Нет опыта реализации подобного - соответственно не от чего отталкиваться. Частично решается тем, что проводишь экспресс изучение темы - хотя бы где и что надо узнать из технологий и сколько времени уйдет на уже изучение исходя из объема материала - плюсуешь к времени разработки. Работает плохо, но лучше, чем ничего.
Большие системы подчиняются законам математического хаоса, бишь нелинейны - и все факторы неизвестности в них вызывают мультипликативный рост сложности. Если проект большой - даже при хорошей декомпозиции на задачи это не значит, что общее время выполнения этих задач влезет в те самые 15-20% прибавки на риск - увы, но тут разброс растет в геометрической прогрессии. Поэтому, собственно, рассчитывать на точность оценки крупного проекта вообще не стоит - тут надо идти итерациями, от MVP.
Штат ИТ-специалистов в компаниях повсюду раздут - где-то больше, где-то меньше. Раздут в том смысле, что задачи зачастую на том же уровне качества и в те же сроки могут быть выполнены меньшим составом, а второе - что и количество самих задач можно ощутимо снизить и не пилить всяческую ересь чисто "штоб было" или "позырить че будет". Компании могли себе позволить это расточительство, теперь же включается режим переоценки.
Но это отдельная, от ситуации с Твиттером, штука - тут речь про то, что шашкой махать - не мешки ворочать. Я Маска дураком не считаю, надо понимать, что и сама ситуация доносится до нас в искаженном виде - что там на самом деле происходит я не знаю, но чисто снаружи, по подаваемой информации - поведение Маска выглядит таким образом, что он сознательно (имеет какой-то свой план) или невольно (слишком сильно затянувшись очередным косячком) хоронит Твиттер.
Во-во, сразу видна "рука мастера" : ) Автор сего претенциозного поста элементарно не понимает, что своими "примерами переоцененности" принципов 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 - уже не являются наследниками базового репозитория, тогда зачем он вообще был введен?
В общем - искания автора поддерживаю; представленная реализация - далека от адекватности.
Это нормальная биологическая стратегия выживания : ) Другое дело, что при всем оптимизме, надо понимать, что твои оценки не имеют под собой достаточных оснований, и воспринимать их и работать с ними надо соответствующе, без возложение чрезмерных надежд.
А оптимизм при этом терять не надо : ) Надо всего лишь принять, что нет способа точно предсказать будущее, а если ты себя и не обманываешь этим - то открываются уже новые возможности!
Это рассуждения недавнего школьника, познавшего Силу интегрирования и теперь воображающего себе, что сейчас он и тестикулы Бога проинтегрирует : )
И что с того, что задачи решались много раз кем-то, когда речь про вашу оценку? Это вы много уже раз решали все задачи? Или даже ваши коллеги по компании, которые вам подскажут?
И по-порядку:
Технологий - разных - великое число, и их становится только больше, и спрос на них постоянно растет. Обойтись json'ом и знанием SQL можно только в узкой нише. Да, есть набор технологий, которые присутствуют практическом в каждом проекте, однако это не равно тому, что именно они определяют проект и из них следуют все иные, задействуемые на проектах, технологии. Я не знаю с чем вы там работает, что у вас так славно всё выводится из очень небольшого набора технологий, хотя, вот, то же упоминание стриминга - вы что, серьезно его json'ом передавали? Я сам имел дело с видеостримингом и прекрасно знаю, что без понимания работы кодеков, без понимания строения видеоданных, без понимания специфичных протоколов передачи стрима, никакого видеостриминга не получится, и знания json и SQL тут нерелевантны. Или вам выдали готовую библиотеку с ручками, которую вы и дергали, представляя себе, что вся обработка видео - это не более, чем обращение к API? Так это другой уровень, на котором - да - всё напоминает
гвоздиjson.И, конечно, легко воображать себя Львом Толстым и знатоком всех технологий, но на практике - если ваша работа действительно разнообразна, а не так как я и писал - имеет более-менее типовой характер, то вы постоянно сталкиваетесь с отсутствием опыта в некоторых областях, который невозможно вывести из вашего иного опыта, ибо при всем том, что действительно в основе все те же биты, но организованы они сильно по-разному, и через это приобретают принципиально иные качества.
Про востребованность технологий я тоже не с потолка беру - сейчас чуть не каждый пятый хочет то аналитическую базу с нехилыми объемами данных, где где реляционные базы данных уже не вывозят, то нейросеть, то свой ГИС-сервис, то еще что. Причем ожидания, само-собой, на уровне качества сервисов ведущих вендоров, представляя себе, по-видимому, как раз как и вы, что сделать такую штуку - как два пальца об асфальт - оно ж "все одно и то же".
Второе - логика. Опять - логика в каком-нибудь, например, сайте - интернет-витрине, и логика в комплексной системе, которая охватывает модули работы с поставщиками, учетные системы, склады, логистику, системы мотивации продавцов, маркетинговые системы, кучу еще модулей и, наконец - собственно интернет-витрину - это две большие разницы. И эта логика диктует и выбор других технологических компонентов, других архитектур, других подходов. Но кроме этой технологической нагрузки и сама логика по сложности своей опять же нелинейно растет, ввиду множества связей между модулями - наивно полагать, что срок разработки сложной многомодульной системы - равен произведению срока разработки одного модуля на их количество, даже будь они примерно одинаково трудоемки - нет, так не выйдет, потому что модули не сами по себе будут работать, они связаны, и вы неизбежно столкнетесь и с задачей интеграции их в единую систему, с задачей управления этим сложным конгломератом - как на этапе разработки, так и в дальнейшем - при сопровождении и развитии этой системы, и, собственно, с задаче согласованной работы всей этой системы.
Так что я вполне обоснованно утверждаю, что, образно говоря, "автомобиль" - это не такая разновидность "лошади", хотя - да, обе как бы могут быть транспортом. Но по этому признаку - использования в качества транспорта - отождествлять их совершенно некорректно. А не образно говоря: ПО другому ПО - рознь. И потому, в том числе, и не существует универсальной и надежной методики расчета срока разработки ПО.
Вы своими словами как бы отрицаете реальность: что, мол, технологии каменного века - суть всё то же самое что и современные нам, "ведь всё ж типовое". Этак вас послушать, так и никакого развития нету, а вы - легко правой пяткой настрочите нам ИИ покруче всех - а чего там, всёж те же самые битики ж туда-сюда перекладываются.
Бэкенд-фронтенд - и в продакшн!
Матерь божья! Да всё просто: если у вас есть формула расчета правильных сроков - будь она хоть стохастической, хоть какой - то, собственно, вопрос манипуляций отпадает сам собой. Потому что есть ОБОСНОВАННАЯ оценка.
А если никто не может назвать и ОБОСНОВАТЬ правильность оценки срока, то все дальнейшие рассуждения - гроша выеденного не стоят по сути. Даже и оценки постфактум - фигня, потому что в процессе разработки не только злонамеренное сачкование может быть, а и масса других факторов, например, проблемы с железом, с документацией, с неизвестными дотоле багами в подключаемых сторонних библиотеках, с непреднамеренными факапами, с затягиванием сроков поставки каких-то ресурсов - схем там процессов, или данных, доступов - да тут просто прорва факторов.
И в конце концов, друзья мои, именно ТОТ СРОК, ЧТО ВЫШЕЛ ПО ФАКТУ - И ЕСТЬ РЕАЛЬНЫЙ СРОК РАЗРАБОТКИ : ) Именно в нем и "учтено" всё то, что могло произойти и произошло таки! А всё остальное - если бы, да кабы.
"Приблизительно ворочать мешки" и "ворочать мешки" - это две большие разницы. Именно здесь чаще всего и возникают недопонимания между заказчиками, которые же приблизительно точно знают чего хотят - и программистами, которые должны уже однозначно точно дать указания компьютеру что он должен делать : ) Впрочем, это лирика. А насчет долженствований - да я просто хотел узнать как именно должна работать ваша идея, ибо в своем приблизительном виде она выглядит для меня наивной по озвученной мной и некоторыми другими участниками нашей беседы причинам. Поэтому надо смотреть "конкретный код", а не оперировать очередными неопределенностями - такая у нас работа.
Как минимум тогда интересно - каким образом вебстриминг, например, и банковская система является типовой относительно друг друга? Вы хотите сказать, что банковские расчеты и логика - это такой вид вебстриминга?
Вы так считаете? На мой взгляд, большинство задач в МИРЕ это у нас есть
какие‑то данные, нужно взять типовые инструменты, сделать типовую
аналитику с типовым фронтов и с типовым беком, сделать интеграцию
типовыми способами и т. д.
Невероятно сильное обобщение. В принципе, все в природе из одних и тех же атомов состоит - значит ли это, что разница между камнем, положим, и человеком - невелика? : )
А я еще раз повторю - чтобы говорить об искажениях оценки надо знать для начала - какая оценка эталонная : ) А когда неизвестно что есть Истина - нельзя сказать и что есть Ложь.
А с чем выплаты связаны? Какова функция расчета раз уж мы тут все такие программисты - нам нужна функция - что на входе и как рассчитывается результат этой функции : ))) А так - это напоминает старинный мем:
1. Быстрота
2. .....
3. PROFIT!!!111
Ну да, для типовой разработки это более-менее работает - вот вы пишите типовые конфигурации 1С, к примеру, имеете штат сотрудников, чьи навыки работы с типовыми инструментами 1С экзаменуете периодически - и да, можете вполне адекватно предсказывать разработку. Но это очень далеко не всё, что происходит в разработке ПО - как раз таки подавляющее большинство - это новые предметные области с новыми подходами и новыми требованиями - и здесь, в этой обширнейшей нише расчеты сроков становятся заметно неточными, потому что нет типовых решений.
Вам же объяснили уже, что в большой системе - нелинейные зависимости между входящими данными и результатом. Так же точно происходит с предсказанием погоды - это же уже исследовалось, и даже понятно почему так происходит - погуглите Эдварда Лоренца с его "эффектом бабочки".
Тут вовсе не рассматривается вопрос стимуляции разработчиков, тут именно что вопрос - а как оценить разработку проекта более-менее приемлемо? Эта проблема не только перед заказчиком стоит, но и перед разработчиком.
Усреднение разных оценок не поможет. Разработчики все с разным опытом, да и опыт одного и того же разработчика изменяется со временем. Это раз. Второе - это то, что любая оценка даже опытнейшего разработчика строится на неопределенности - ну то есть в лучшем случае понимает это, а в худшем - занимается самообманом, который выльется в срыв озвученных сроков, что повсеместно и происходит с малоопытными, но - или, скорее - "потому и" - уверенных в своих оценках, специалистами.
Конечно, бывают проекты, в которых требования достаточно точны и даже имеется опыт их реализации - их оценивать легче и можно не перезакладываться сильно на риск, но даже в таких проектах факторы неверных толкований и вероятных изменений не отменяются и создают риск не влезть в неучитывающий их срок.
Конечно, если вы пишите из года в год примерно одно и то же на типовой платформе, плюс как-то научились контролировать грейд специалистов (обязательной сертификацией/аттестацией, например), то статистический подход еще может помочь, но это довольно узкая область разработки ПО. Подавляющее же число разработок ПО слабо походят на друг друга.
И в любом случае, это про те случаи, когда проект небольшой, по большей части состоит из знакомого по опыту функционала и требования прописаны достаточно детально, а часто - ТЗ состоит из дефиниций "хотелок", без каких-либо деталей и/или требуется "запилить" что-нибудь из разряда "как у Гугла" - только вот заказчик не понимает, что Гугл разрабатывал свою машинерию 30 лет огромными командами и сделал кучу неудачных подходов, прежде чем получил результат.
Проблема в том, что даже в адекватно прописанном в ТЗ и знакомом по опыту функционале всегда остается много неопределенности, если даже вам вдоль и поперек знакома фича по предыдущему опыту - это вовсе не означает что вы:
Точно идентифицировали фичу - вполне может быть, что заказчик подразумевает нечто иное.
Фичи практически никогда не бывают одинаковыми - иначе, как и было подмечено, разработчики бы тупо собирали ПО из давно сделанных кирпичиков - но нет, каждый раз свои нюансы.
Практически ни один проект не обходится без внесения изменений в процессе разработки - как бы там ни божился заказчик и как бы опытен ни был аналитик/архитектор.
Из известных мне и более-менее рабочих способов гадания на сроки - это закладка риска: то есть определяешь сколько по твоему мнению на разработку фичи нужно времени и добавляешь на неопределенность еще 15-20% времени - как раз на то, что фичу неправильно понял, фича будет меняться и/или возникнут другие непредвиденные обстоятельства.
В целом это работает, но не в минимум двух случаях:
Нет опыта реализации подобного - соответственно не от чего отталкиваться. Частично решается тем, что проводишь экспресс изучение темы - хотя бы где и что надо узнать из технологий и сколько времени уйдет на уже изучение исходя из объема материала - плюсуешь к времени разработки. Работает плохо, но лучше, чем ничего.
Большие системы подчиняются законам математического хаоса, бишь нелинейны - и все факторы неизвестности в них вызывают мультипликативный рост сложности. Если проект большой - даже при хорошей декомпозиции на задачи это не значит, что общее время выполнения этих задач влезет в те самые 15-20% прибавки на риск - увы, но тут разброс растет в геометрической прогрессии. Поэтому, собственно, рассчитывать на точность оценки крупного проекта вообще не стоит - тут надо идти итерациями, от MVP.
Штат ИТ-специалистов в компаниях повсюду раздут - где-то больше, где-то меньше. Раздут в том смысле, что задачи зачастую на том же уровне качества и в те же сроки могут быть выполнены меньшим составом, а второе - что и количество самих задач можно ощутимо снизить и не пилить всяческую ересь чисто "штоб было" или "позырить че будет". Компании могли себе позволить это расточительство, теперь же включается режим переоценки.
Но это отдельная, от ситуации с Твиттером, штука - тут речь про то, что шашкой махать - не мешки ворочать. Я Маска дураком не считаю, надо понимать, что и сама ситуация доносится до нас в искаженном виде - что там на самом деле происходит я не знаю, но чисто снаружи, по подаваемой информации - поведение Маска выглядит таким образом, что он сознательно (имеет какой-то свой план) или невольно (слишком сильно затянувшись очередным косячком) хоронит Твиттер.