С чего Вы так решили? Есть какие-то факты, подтверждающие эту идею?
Как думаете, какой процент разработчиков на C++ полноценно знает этот язык? Или в случае C++ корректнее говорить о таких уникумах в штуках, а не в процентах?
Как думаете, хорошо знающий язык разработчик не делает ошибок с тем же = и == просто по невнимательности? Я вот точно знаю, что делает.
Как думаете, кого-нибудь волнует, насколько хорошо знал язык разработчик, допустивший баг, из-за которого пострадали люди?
Есть ли какие-то исследования, как хорошее знание языка влияет на количество багов в релизе? И, главное, насколько именно этот фактор важен, по сравнению с другими - от выбора языка до организации процесса разработки?
Да, интуитивно может показаться, что очень важно хорошо знать используемый язык. Вам так кажется. Мне тоже когда-то так казалось. Но интуиция иногда может подводить. Масса других факторов влияет на конечный результат намного сильнее, чем глубокое знание языка отдельным разработчиком.
У меня нет никакого желания знать JS. Скорее есть желание его вообще не знать, но увы.
Зачем Вы пишете на незнакомом языке? Пишите на знакомо
К сожалению, плагины для KWin на Go не пишут. И PR исправляющий мешающий мне баг в стороннем приложении тоже нужно делать на том языке, на котором написано это приложение, а не на том языке, которые мне нравится и который я знаю.
Это чистая правда. Но это абсолютно не важно. Потому что вторая правда в том, что половина разработчиков не знает полноценно даже те языки, на которых ежедневно пишет код на работе. Когда-то (лет 20-25 назад) мне такое казалось дикостью. Но пришлось это принять, потому что других разработчиков брать негде, а эти, в целом, с работой справляются. Так что, по факту, когда я, со своими 35+ годами опыта пишу вместе с ИИ на незнакомом мне языке, я пишу более качественный код, чем многие из тех, кто этот язык знают. Результат наверняка не идеален, но он определённо good enough. И лучше я сделаю что-то полезное так, чем не сделаю никак - и вот тут решает именно использование ИИ.
Я много на чём писал, и на баше, и даже на Perl. К слову, с башем ИИ не справился - мне для интеграционного тестирования GitHub Actions Workflow понадобилось тесты на баше написать, но в конечном итоге пришлось всё сделать ручками.
Чтобы что? ИИ даёт возможность быстро сделать какую-то мелочь на незнакомом языке. Без ИИ за это никто даже бы браться не стал - ради этой мелочи тратить время на полноценное изучение другого языка просто нет смысла. Например, я так написал плагин для KWin под KDE Plasma 6 на JS (мои собственные знания JS устарели лет на 25 примерно) и пофиксил многолетний баг в стороннем приложении открыв PR на гитхабе. Этот подход даёт новые возможности, и это - круто. А полноценно учить нужно те ЯП, которые используются в основной работе или которые нравятся.
Зависит от. Я пишу на Go, язык такой, что и свой и чужой код выглядит плюс/минус одинаково. Так что конкретно мне ревьювить и потом немного порефакторить до состояния "я бы сам написал именно так" получается намного проще и быстрее.
А если сначала навайбкодить не глядя в код пока оно не заработает, а потом начать смотреть в код (ревью - с целью выявления проблем или просто подчистки кода) - это как называется? А если делать это на незнакомом ЯП?
Линтер я настроил, плюс/минус одинаково для всех проектов, в этом нет проблемы.
Тесты - обычно этот же ИИ и написал. Там бывает лажа, но, всё-равно, когда ИИ пишет и код и тесты то он сам находит и исправляет большую часть ошибок - до того, как я начну сам делать ревью кода.
Люди - это тоже недетерминированный молоток, но это же не мешает. Просто чтобы группа людей вместе успешно работала и создавала большие продукты ими нужно уметь управлять - что является совершенно отдельным навыком, не связанным с программированием. С ИИ примерно та же фигня - чтобы он успешно писал нужный код нужно научиться им управлять: подобрать подходящие процессы, ставить задачи и контролировать результат.
Теперь ты тратишь время, чтобы убедиться, что оно не наглючило
Да, но всё не так плохо. Со временем подбираются подходы, которые решают эту проблему, и, в конечном итоге, результат получаешь намного быстрее. Я вот принципиально не смотрю промежуточные результаты ИИ - пока они не пройдут все тесты и линтеры, - и одно это экономит море времени. Конечно, не всё так плоско, есть нюансы (напр. иногда ИИ начинает нести не в ту сторону, и тогда результатов не дождёшься, поэтому нужно вмешиваться и корректировать на ходу), но в целом подход рабочий. Ну и полное ревью финального результата обязательно, и если код ИИ это ревью сумел пройти, то он ничем не хуже чем любой другой код - твой собственный или твоего коллеги, - и "наглючить" он может ровно с той же вероятностью, что и ручной код прошедший ревью, тесты и линтеры.
Но правда в том, что писать свой код или вместо этого ставить задачу и потом ревьювить чужой - это совершенно разные активности. Но никто же не мешает совмещать - интересное писать или рефакторить самостоятельно, а менее интересное делегировать ИИ.
Лично для меня большой плюс - возможность при разработке сконцентрироваться на проектировании, делегировав ИИ тупой "набор" уже продуманного мной кода и решение технических проблем с падающими тестами если при продумывании что-то было упущено. Для меня разработка в таком стиле выглядит похоже на разницу между ассемблером и языками высокого уровня - как язык следующего за "высоким" уровня. И это очень круто!
ИИ - это инструмент. Молоток тоже можно использовать чтобы стало легче забивать гвозди, а можно и себе по пальцам ударить. ИИ - инструмент однозначно полезный, но вот для каких задач он (не) подходит - очень сильно зависит от использующего его человека. Ну и модели очень сильно друг от друга отличаются, в зависимости от пользователя и задачи могут (не) подойти разные модели.
Безусловно, если быстрее без ИИ - нужно делать ручками. Но часто это только кажется, что без ИИ будет быстрее - и это тоже нужно учитывать.
Что до составления качественного ТЗ, то тут я не соглашусь:
Уметь составлять качественные ТЗ - это ценный навык сам по себе. Причём в эру ИИ этот навык будет цениться намного выше, чем умение написать код ручками. Так что его качать стоит в любом случае.
С написанием ТЗ для ИИ очень неплохо помогает сам ИИ, заметно ускоряя процесс. Но - только помогает, а не заменяет.
Абсолютное большинство задач без ТЗ реализовать невозможно. Даже если это ТЗ нигде формально не записывается и окончательно формируется незадолго до того как будет завершена реализация - оно всё-равно есть. И важный момент в том, что разработать ТЗ заранее обычно в разы дешевле (по времени и усилиям), чем формировать его на ходу, в процессе работы с кодом. Поэтому для любой задачи кроме совсем тривиальных стоит начинать именно с ТЗ. А имея ТЗ проверить его адекватность как раз проще всего передав его ИИ для реализации - вся лажа в ТЗ сразу вылезет. ☺
Ненене! Я же сказал "Для компенсации негативных эффектов вайб-кодинга" - тут речь шла о части статьи "11. Когнитивные и психологические последствия вайб-кодинга". Это не решается пинг-понгом между моделями, нужно свою голову включать.
Возможно, создатели CoPilot специально его убрали, чтобы побудить пользователей переходить на премиум модели.
Это не так. Исходники в опенсорсе, промпты можно почитать. Для GPT 4.1 там действительно есть специфические дополнительные инструкции, но они сводятся к тому, чтобы он не останавливался на каждый чих а продолжал пытаться решить задачу сам. Сложно сказать, помогают ли они - по моим наблюдениям он всё равно постоянно останавливается когда другие модели бы продолжили работу.
По статье - да, в целом всё верно. Уровень получаемого результата очень сильно зависит от того, кто пишет промпты. Ну и следующий фактор - это выбор модели, на моих задачах Claude Sonnet 4 справляется намного лучше других (правда, GPT 5 я ещё не тестировал). GPT 4.1 можно использовать только на простейших задачах, но и там с ним работать очень утомительно - постоянно приходится его "пинать" чтобы он продолжил работу.
Что до вайб-кодинга, то этот подход расширяет возможности квалифицированного разработчика: можно быстро получить прототип на знакомом ЯП чтобы оценить стоит ли вообще делать задачу/делать этим способом, плюс можно делать не очень большие проекты на незнакомом ЯП. Может есть ещё какие-то адекватные применения. Но в большинстве реальных задач даже если прототип решения накидывался вайб-кодингом дальше нужно полноценно вникнуть в абсолютно весь код (и доработать его до обычного для себя "без ИИ" уровня, не важно промптами или вручную), и, очень желательно, в тесты тоже (там нередко дичь попадается).
Для компенсации негативных эффектов вайб-кодинга очень помогает после получения рабочего решения почитать официальную доку по использованным технологиям/подходам/библиотекам и позадавать модели возникающие вопросы а-ля "а почему тут сделал так если в доке сказано что …" - это прекрасно работает даже для незнакомых ЯП. Ну и плюс надавить из общей эрудиции и знания как решаются подобные задачи в других ЯП если код где-то выглядит странно.
Что именно нужно сделать на бэке и насколько это просто/быстро - зависит от используемого инструмента (протокола/фреймворка/кодогенератора/etc.). Выглядит так, что Вы преобразовали GraphQL в аналог такого фреймворка, который ускоряет обновление бэка под новый функционал, вместо того чтобы отменить необходимость обновлять бэк в принципе.
Плюс разрешая любые запросы на дев-среде всегда есть вероятность что-то забыть выкатить на прод из нужных новых запросов. Конечно, это зависит от поставленных процессов, но обычно рано или поздно такие висящие на стене ружья всё-равно стреляют.
P.S. Я в районе 99 года как-то сделал проект довольно схожий с GraphQL - там фронт на бэк передавал куски SQL-запросов. ;-) В принципе оно работало, с безопасностью и производительностью известных проблем не было, но… что-то больше такого делать не хочется. Теряется ощущение контроля, функционал начинает развиваться "не туда" из-за слишком лёгкого и прямого доступа фронта к БД, растворяется довольно полезный слой абстракции в виде конкретного и специализированного API бэка. В общем, получается типичное простое быстрое неправильное решение, которое в будущем всё-равно возьмёт свою цену.
А разве суть GraphQL не в том, чтобы ускорить разработку новых фич на клиенте избежав написания под каждую фичу/изменение соответствующих изменений в API бэка? И разве Вы не убили всё это своим подходом? Я к тому, что сам подход-то, на лично мой взгляд (я не фанат GraphQL из соображений безопасности и производительности с первого дня как про него узнал) вполне здравые, но - а зачем при этом подходе вообще нужен GraphQL?
А направить 1 процент прод трафика на любой стенд это вообще не проблема.
Ну так и я ровно о том же (и география на этот факт особо не влияет). Полноценное зеркало прода в реальности встречается только в мелких проектах, но там это просто игрушка по сути. А в крупных никакого бюджета на это не хватит (точнее он никогда не окупится, поэтому его и выделять не станут). А без этого никакое тестирование до выката в прод не проявит некоторые типы ошибок, которые видны только под большой нагрузкой/на больших данных. Иными словами как не старайся этого избежать, сколько ни откладывай релиз, но тестирование в проде на реальных пользователях всё-равно неизбежно.
Такое вообще в прод попадать не должно.
Не должно. Но и люди и ИИ пишут код с ошибками, они же тестируют его довольно ограничено в меру собственных способностей и бюджета, поэтому кода без багов не бывает. Так что, должно или нет, но оно уже там. В мире есть не так и мало крупных сервисов с кучей девяток - но глючат и временами лежат абсолютно все.
Я не понял, какое в принципе география площадок имеет отношение к тому, что мы тут обсуждаем. А Вы уже не первый раз это упоминаете - к чему? Сколько бы ни было площадок и как бы они ни были разнесены географически - это никак не мешает выкатывать в них по нескольку релизов в день.
Что до инструкций - то это нормальный подход, никто не спорит. Просто он во-первых не единственный адекватный, и во-вторых он тоже не даёт никаких гарантий надёжности - история знает немало примеров багов, которые крешат сервисы после недели или месяца аптайма. И это только креши, что вообще-то мелочь. Гораздо хуже баги, которые приводят к тому, что функционал работает некорректно, или вообще портят данные в БД. И нередко такие баги связаны со сложной логикой или гонками (race condition), которые бывает крайне сложно поймать любыми тестами даже если точно знаешь что баг есть.
В общем, как редко не выкатывай и как не держись за "старое, проверенное временем" - надёжность 100% всё-равно не получишь. Поэтому, как я уже говорил, тут нет единственно верного ответа, нужен специфичный для конкретного бизнеса/проекта/команды баланс. И описываемый Вами вариант этого баланса не самый распространённый, чтобы подавать его как это делаете Вы - единственно верным вариантом если нужна "надёжность".
Это не есть что-то прям обязательное, и не то, чтобы часто используется конкретно на хабре - мой коммент был скорее шутливый, нежели серьёзной рекомендацией. Тем не менее, если погуглить site:habr.com "tl;dr" то находится достаточно примеров. Полезность TL;DR сильно зависит от содержимого статьи - и да, на мой взгляд для данной статьи это было бы полезно.
Ну… одно другому не мешает. Статья интересная, но управление ожиданиями тоже нужная вещь. И наличие TL;DR редко приводит к тому, что статью вообще не читают, разве что из него сразу видно, что тема не твоя - но тогда это к лучшему.
Ещё лично мне большую часть статьи хотелось ругаться на то, что вместо поиска реальной проблемы пошли лепить одну заплатку на другую в надежде что это поможет вместо понимания что происходит и почему. А в самом конце выяснилось, что оказывается реальную проблему всё-таки параллельно искали и таки нашли - вот что стоило это раньше сказать, и я бы читал спокойно. ;-)
Это типичная точка зрения админов, которые не видят что изменилось между версиями, и, соответственно, для них каждая новая версия это чёрный ящик и потенциальная опасность что всё сломается, причём опасность эта имеет для них одинаковую вероятность для любой версии.
Для разработчиков ситуация выглядит иначе: во-первых они видят что изменилось и могут адекватно оценивать вероятность что-то поломать для каждой версии отдельно, и во-вторых для них вероятность что-то поломать растет экспоненциально по мере увеличения времени между релизами (по ряду причин - от недостаточного тестирования до неожиданных результатов взаимодействия вроде бы не сильно связанных между собой изменений), но самое важное - когда релизится каждое мелкое изменение (отсюда и цифра про три релиза в день - по моему опыту вполне реальная, кстати), то становится на порядок проще понять какое именно изменение что-то сломало и как это чинить (что сильно уменьшает вероятность сделать некорректный фикс и снова положить прод из-за этой же проблемы).
Поэтому частые релизы, с точки зрения разработчиков, как раз способствуют увеличению надёжности выкатов, а вовсе не скорости разработки фич. Потому что эти релизы по большей части содержат не новые фичи, а внутренние изменения/рефакторинг/обновления зависимостей/мелкие багфиксы/оптимизации/etc.
Про это как раз в статье пишут. Очень высокая надежность и скорость разработки противоречат друг-другу.
На мой взгляд, в статье говорится совсем другое. Там речь про то, чтобы контролировать SLO путём заморозки релизов до конца текущего периода если значительная часть бюджета текущего периода была потрачена. Это ничего не говорит о том, с какой частотой рекомендуется делать релизы до наступления такого момента. И речь о фичах в этом контексте идёт только потому, что подразумевается, что новые релизы требует именно бизнес, соответственно его нужно уговаривать отложить эти релизы, а на желание разработчиков продолжать часто релизить мелкие изменения можно тупо забить потому что не они тут решения принимают - что не совсем корректно по сути, но в целом понятно.
На самом деле оптимальная стратегия сильно зависит от конкретного проекта, квалификации команд (причём всех отдельно - и разработчиков и админов и тестировщиков), и доступного бюджета (не ошибок, а финансов - напр. на поднятие эквивалентной проду второй площадки куда зеркалируется трафик прода). Универсального ответа подходящего всем - нет, даже если цель одинаковая и соответствует описанной в статье.
С чего Вы так решили? Есть какие-то факты, подтверждающие эту идею?
Как думаете, какой процент разработчиков на C++ полноценно знает этот язык? Или в случае C++ корректнее говорить о таких уникумах в штуках, а не в процентах?
Как думаете, хорошо знающий язык разработчик не делает ошибок с тем же = и == просто по невнимательности? Я вот точно знаю, что делает.
Как думаете, кого-нибудь волнует, насколько хорошо знал язык разработчик, допустивший баг, из-за которого пострадали люди?
Есть ли какие-то исследования, как хорошее знание языка влияет на количество багов в релизе? И, главное, насколько именно этот фактор важен, по сравнению с другими - от выбора языка до организации процесса разработки?
Да, интуитивно может показаться, что очень важно хорошо знать используемый язык. Вам так кажется. Мне тоже когда-то так казалось. Но интуиция иногда может подводить. Масса других факторов влияет на конечный результат намного сильнее, чем глубокое знание языка отдельным разработчиком.
Думаете, достаточно выучить хорошо язык и получится писать код без багов?
У меня нет никакого желания знать JS. Скорее есть желание его вообще не знать, но увы.
К сожалению, плагины для KWin на Go не пишут. И PR исправляющий мешающий мне баг в стороннем приложении тоже нужно делать на том языке, на котором написано это приложение, а не на том языке, которые мне нравится и который я знаю.
Это чистая правда. Но это абсолютно не важно. Потому что вторая правда в том, что половина разработчиков не знает полноценно даже те языки, на которых ежедневно пишет код на работе. Когда-то (лет 20-25 назад) мне такое казалось дикостью. Но пришлось это принять, потому что других разработчиков брать негде, а эти, в целом, с работой справляются. Так что, по факту, когда я, со своими 35+ годами опыта пишу вместе с ИИ на незнакомом мне языке, я пишу более качественный код, чем многие из тех, кто этот язык знают. Результат наверняка не идеален, но он определённо good enough. И лучше я сделаю что-то полезное так, чем не сделаю никак - и вот тут решает именно использование ИИ.
Я много на чём писал, и на баше, и даже на Perl. К слову, с башем ИИ не справился - мне для интеграционного тестирования GitHub Actions Workflow понадобилось тесты на баше написать, но в конечном итоге пришлось всё сделать ручками.
Чтобы что? ИИ даёт возможность быстро сделать какую-то мелочь на незнакомом языке. Без ИИ за это никто даже бы браться не стал - ради этой мелочи тратить время на полноценное изучение другого языка просто нет смысла. Например, я так написал плагин для KWin под KDE Plasma 6 на JS (мои собственные знания JS устарели лет на 25 примерно) и пофиксил многолетний баг в стороннем приложении открыв PR на гитхабе. Этот подход даёт новые возможности, и это - круто. А полноценно учить нужно те ЯП, которые используются в основной работе или которые нравятся.
Зависит от. Я пишу на Go, язык такой, что и свой и чужой код выглядит плюс/минус одинаково. Так что конкретно мне ревьювить и потом немного порефакторить до состояния "я бы сам написал именно так" получается намного проще и быстрее.
А если сначала навайбкодить не глядя в код пока оно не заработает, а потом начать смотреть в код (ревью - с целью выявления проблем или просто подчистки кода) - это как называется? А если делать это на незнакомом ЯП?
Линтер я настроил, плюс/минус одинаково для всех проектов, в этом нет проблемы.
Тесты - обычно этот же ИИ и написал. Там бывает лажа, но, всё-равно, когда ИИ пишет и код и тесты то он сам находит и исправляет большую часть ошибок - до того, как я начну сам делать ревью кода.
Люди - это тоже недетерминированный молоток, но это же не мешает. Просто чтобы группа людей вместе успешно работала и создавала большие продукты ими нужно уметь управлять - что является совершенно отдельным навыком, не связанным с программированием. С ИИ примерно та же фигня - чтобы он успешно писал нужный код нужно научиться им управлять: подобрать подходящие процессы, ставить задачи и контролировать результат.
Да, но всё не так плохо. Со временем подбираются подходы, которые решают эту проблему, и, в конечном итоге, результат получаешь намного быстрее. Я вот принципиально не смотрю промежуточные результаты ИИ - пока они не пройдут все тесты и линтеры, - и одно это экономит море времени. Конечно, не всё так плоско, есть нюансы (напр. иногда ИИ начинает нести не в ту сторону, и тогда результатов не дождёшься, поэтому нужно вмешиваться и корректировать на ходу), но в целом подход рабочий. Ну и полное ревью финального результата обязательно, и если код ИИ это ревью сумел пройти, то он ничем не хуже чем любой другой код - твой собственный или твоего коллеги, - и "наглючить" он может ровно с той же вероятностью, что и ручной код прошедший ревью, тесты и линтеры.
Но правда в том, что писать свой код или вместо этого ставить задачу и потом ревьювить чужой - это совершенно разные активности. Но никто же не мешает совмещать - интересное писать или рефакторить самостоятельно, а менее интересное делегировать ИИ.
Лично для меня большой плюс - возможность при разработке сконцентрироваться на проектировании, делегировав ИИ тупой "набор" уже продуманного мной кода и решение технических проблем с падающими тестами если при продумывании что-то было упущено. Для меня разработка в таком стиле выглядит похоже на разницу между ассемблером и языками высокого уровня - как язык следующего за "высоким" уровня. И это очень круто!
ИИ - это инструмент. Молоток тоже можно использовать чтобы стало легче забивать гвозди, а можно и себе по пальцам ударить. ИИ - инструмент однозначно полезный, но вот для каких задач он (не) подходит - очень сильно зависит от использующего его человека. Ну и модели очень сильно друг от друга отличаются, в зависимости от пользователя и задачи могут (не) подойти разные модели.
Это уже есть - context7.
Безусловно, если быстрее без ИИ - нужно делать ручками. Но часто это только кажется, что без ИИ будет быстрее - и это тоже нужно учитывать.
Что до составления качественного ТЗ, то тут я не соглашусь:
Уметь составлять качественные ТЗ - это ценный навык сам по себе. Причём в эру ИИ этот навык будет цениться намного выше, чем умение написать код ручками. Так что его качать стоит в любом случае.
С написанием ТЗ для ИИ очень неплохо помогает сам ИИ, заметно ускоряя процесс. Но - только помогает, а не заменяет.
Абсолютное большинство задач без ТЗ реализовать невозможно. Даже если это ТЗ нигде формально не записывается и окончательно формируется незадолго до того как будет завершена реализация - оно всё-равно есть. И важный момент в том, что разработать ТЗ заранее обычно в разы дешевле (по времени и усилиям), чем формировать его на ходу, в процессе работы с кодом. Поэтому для любой задачи кроме совсем тривиальных стоит начинать именно с ТЗ. А имея ТЗ проверить его адекватность как раз проще всего передав его ИИ для реализации - вся лажа в ТЗ сразу вылезет. ☺
Ненене! Я же сказал "Для компенсации негативных эффектов вайб-кодинга" - тут речь шла о части статьи "11. Когнитивные и психологические последствия вайб-кодинга". Это не решается пинг-понгом между моделями, нужно свою голову включать.
Это не так. Исходники в опенсорсе, промпты можно почитать. Для GPT 4.1 там действительно есть специфические дополнительные инструкции, но они сводятся к тому, чтобы он не останавливался на каждый чих а продолжал пытаться решить задачу сам. Сложно сказать, помогают ли они - по моим наблюдениям он всё равно постоянно останавливается когда другие модели бы продолжили работу.
По статье - да, в целом всё верно. Уровень получаемого результата очень сильно зависит от того, кто пишет промпты. Ну и следующий фактор - это выбор модели, на моих задачах Claude Sonnet 4 справляется намного лучше других (правда, GPT 5 я ещё не тестировал). GPT 4.1 можно использовать только на простейших задачах, но и там с ним работать очень утомительно - постоянно приходится его "пинать" чтобы он продолжил работу.
Что до вайб-кодинга, то этот подход расширяет возможности квалифицированного разработчика: можно быстро получить прототип на знакомом ЯП чтобы оценить стоит ли вообще делать задачу/делать этим способом, плюс можно делать не очень большие проекты на незнакомом ЯП. Может есть ещё какие-то адекватные применения. Но в большинстве реальных задач даже если прототип решения накидывался вайб-кодингом дальше нужно полноценно вникнуть в абсолютно весь код (и доработать его до обычного для себя "без ИИ" уровня, не важно промптами или вручную), и, очень желательно, в тесты тоже (там нередко дичь попадается).
Для компенсации негативных эффектов вайб-кодинга очень помогает после получения рабочего решения почитать официальную доку по использованным технологиям/подходам/библиотекам и позадавать модели возникающие вопросы а-ля "а почему тут сделал так если в доке сказано что …" - это прекрасно работает даже для незнакомых ЯП. Ну и плюс надавить из общей эрудиции и знания как решаются подобные задачи в других ЯП если код где-то выглядит странно.
Что именно нужно сделать на бэке и насколько это просто/быстро - зависит от используемого инструмента (протокола/фреймворка/кодогенератора/etc.). Выглядит так, что Вы преобразовали GraphQL в аналог такого фреймворка, который ускоряет обновление бэка под новый функционал, вместо того чтобы отменить необходимость обновлять бэк в принципе.
Плюс разрешая любые запросы на дев-среде всегда есть вероятность что-то забыть выкатить на прод из нужных новых запросов. Конечно, это зависит от поставленных процессов, но обычно рано или поздно такие висящие на стене ружья всё-равно стреляют.
P.S. Я в районе 99 года как-то сделал проект довольно схожий с GraphQL - там фронт на бэк передавал куски SQL-запросов. ;-) В принципе оно работало, с безопасностью и производительностью известных проблем не было, но… что-то больше такого делать не хочется. Теряется ощущение контроля, функционал начинает развиваться "не туда" из-за слишком лёгкого и прямого доступа фронта к БД, растворяется довольно полезный слой абстракции в виде конкретного и специализированного API бэка. В общем, получается типичное простое быстрое неправильное решение, которое в будущем всё-равно возьмёт свою цену.
А разве суть GraphQL не в том, чтобы ускорить разработку новых фич на клиенте избежав написания под каждую фичу/изменение соответствующих изменений в API бэка? И разве Вы не убили всё это своим подходом? Я к тому, что сам подход-то, на лично мой взгляд (я не фанат GraphQL из соображений безопасности и производительности с первого дня как про него узнал) вполне здравые, но - а зачем при этом подходе вообще нужен GraphQL?
Ну так и я ровно о том же (и география на этот факт особо не влияет). Полноценное зеркало прода в реальности встречается только в мелких проектах, но там это просто игрушка по сути. А в крупных никакого бюджета на это не хватит (точнее он никогда не окупится, поэтому его и выделять не станут). А без этого никакое тестирование до выката в прод не проявит некоторые типы ошибок, которые видны только под большой нагрузкой/на больших данных. Иными словами как не старайся этого избежать, сколько ни откладывай релиз, но тестирование в проде на реальных пользователях всё-равно неизбежно.
Не должно. Но и люди и ИИ пишут код с ошибками, они же тестируют его довольно ограничено в меру собственных способностей и бюджета, поэтому кода без багов не бывает. Так что, должно или нет, но оно уже там. В мире есть не так и мало крупных сервисов с кучей девяток - но глючат и временами лежат абсолютно все.
Я не понял, какое в принципе география площадок имеет отношение к тому, что мы тут обсуждаем. А Вы уже не первый раз это упоминаете - к чему? Сколько бы ни было площадок и как бы они ни были разнесены географически - это никак не мешает выкатывать в них по нескольку релизов в день.
Что до инструкций - то это нормальный подход, никто не спорит. Просто он во-первых не единственный адекватный, и во-вторых он тоже не даёт никаких гарантий надёжности - история знает немало примеров багов, которые крешат сервисы после недели или месяца аптайма. И это только креши, что вообще-то мелочь. Гораздо хуже баги, которые приводят к тому, что функционал работает некорректно, или вообще портят данные в БД. И нередко такие баги связаны со сложной логикой или гонками (race condition), которые бывает крайне сложно поймать любыми тестами даже если точно знаешь что баг есть.
В общем, как редко не выкатывай и как не держись за "старое, проверенное временем" - надёжность 100% всё-равно не получишь. Поэтому, как я уже говорил, тут нет единственно верного ответа, нужен специфичный для конкретного бизнеса/проекта/команды баланс. И описываемый Вами вариант этого баланса не самый распространённый, чтобы подавать его как это делаете Вы - единственно верным вариантом если нужна "надёжность".
Это не есть что-то прям обязательное, и не то, чтобы часто используется конкретно на хабре - мой коммент был скорее шутливый, нежели серьёзной рекомендацией. Тем не менее, если погуглить
site:habr.com "tl;dr"то находится достаточно примеров. Полезность TL;DR сильно зависит от содержимого статьи - и да, на мой взгляд для данной статьи это было бы полезно.Ну… одно другому не мешает. Статья интересная, но управление ожиданиями тоже нужная вещь. И наличие TL;DR редко приводит к тому, что статью вообще не читают, разве что из него сразу видно, что тема не твоя - но тогда это к лучшему.
Ещё лично мне большую часть статьи хотелось ругаться на то, что вместо поиска реальной проблемы пошли лепить одну заплатку на другую в надежде что это поможет вместо понимания что происходит и почему. А в самом конце выяснилось, что оказывается реальную проблему всё-таки параллельно искали и таки нашли - вот что стоило это раньше сказать, и я бы читал спокойно. ;-)
Это типичная точка зрения админов, которые не видят что изменилось между версиями, и, соответственно, для них каждая новая версия это чёрный ящик и потенциальная опасность что всё сломается, причём опасность эта имеет для них одинаковую вероятность для любой версии.
Для разработчиков ситуация выглядит иначе: во-первых они видят что изменилось и могут адекватно оценивать вероятность что-то поломать для каждой версии отдельно, и во-вторых для них вероятность что-то поломать растет экспоненциально по мере увеличения времени между релизами (по ряду причин - от недостаточного тестирования до неожиданных результатов взаимодействия вроде бы не сильно связанных между собой изменений), но самое важное - когда релизится каждое мелкое изменение (отсюда и цифра про три релиза в день - по моему опыту вполне реальная, кстати), то становится на порядок проще понять какое именно изменение что-то сломало и как это чинить (что сильно уменьшает вероятность сделать некорректный фикс и снова положить прод из-за этой же проблемы).
Поэтому частые релизы, с точки зрения разработчиков, как раз способствуют увеличению надёжности выкатов, а вовсе не скорости разработки фич. Потому что эти релизы по большей части содержат не новые фичи, а внутренние изменения/рефакторинг/обновления зависимостей/мелкие багфиксы/оптимизации/etc.
На мой взгляд, в статье говорится совсем другое. Там речь про то, чтобы контролировать SLO путём заморозки релизов до конца текущего периода если значительная часть бюджета текущего периода была потрачена. Это ничего не говорит о том, с какой частотой рекомендуется делать релизы до наступления такого момента. И речь о фичах в этом контексте идёт только потому, что подразумевается, что новые релизы требует именно бизнес, соответственно его нужно уговаривать отложить эти релизы, а на желание разработчиков продолжать часто релизить мелкие изменения можно тупо забить потому что не они тут решения принимают - что не совсем корректно по сути, но в целом понятно.
На самом деле оптимальная стратегия сильно зависит от конкретного проекта, квалификации команд (причём всех отдельно - и разработчиков и админов и тестировщиков), и доступного бюджета (не ошибок, а финансов - напр. на поднятие эквивалентной проду второй площадки куда зеркалируется трафик прода). Универсального ответа подходящего всем - нет, даже если цель одинаковая и соответствует описанной в статье.