Да, несколько раз заказчику "приходил аппетит во время еды", который трансформировался в допсоглашения с допТЗ.
Это уже не "чёткое ИЗНАЧАЛЬНОЕ представление" позволяющее спокойно работать по водопаду. Формально, под вариант с допсоглашениями попадёт любой проект на аутсорсе на условиях fixed price - их тьма и речь явно не о них, верно? Нет, я имел в виду как раз "чёткое ИЗНАЧАЛЬНОЕ представление" - когда заказчик ставит задачу, ждёт завершения водопада, и довольный принимает результат. Можно сказать, что я такое видел на мелких (размером в несколько дней) фрилансерских проектах, но такие микро-проекты мы тут вроде тоже не обсуждаем. А уже на мелких проектах размером хотя бы от 2-3 месяцев мне такое не встречалось.
Ключевое отличие software от hardware как раз в том и состоит, что граница между проектом и процессом размыта до неразличимости из-за мягкости производимого продукта. Можно считать условным проектом процесс разработки до получения минимально необходимого/полезного функционала и первых реальных пользователей, но с этого момента добавление любой новой фичи или значимого изменения можно воспринимать и как проект и как процесс - это мало на что будет влиять. Можно считать проектом каждый релиз коробочного продукта или новых версий мобильного приложения, но для бэкенда и веб-приложений обновляемых практически непрерывно грань опять же полностью размыта. По большому счёту проектом считают ситуацию, когда любой ценой необходимо уложиться в выделенные ресурсы (время/деньги). Что не мешает использовать аджайл, применяя его гибкость не для того, что внезапно добавлять только что придуманные фичи, а для того, чтобы выпиливать на ходу те, на которые не хватило ресурсов.
Одно другому не мешает - жёсткость с заказчиком можно и нужно проявлять в т.ч. при аджайле. Просто степень этой жёсткости будет ниже ("вот эту фичу мы если и будем делать, то в далёком будущем"), чем в водопаде ("на текущем этапе проекта никакие изменения невозможны в принципе"). По большому счёту аджайл прекрасно работает в стиле группы параллельных и последовательных небольших водопадов, позволяя соблюдать баланс и получать лучшее из обоих подходов.
Увеличилось, конечно. Чтобы писать достаточно портабельный код, который запустится в любом окружении, нужна более высокая квалификация, нежели чтобы написать код работающий в единственном окружении - контейнере. Причём одной квалификации мало, нужно ещё и больше времени на реализацию и тестирование. Т.е. это объективно заметно дороже для бизнеса. Контейнеры дают возможность и разработчикам меньше напрягаться, и бизнесу нанимать более дешёвых разработчиков и при этом получать результат быстрее. Качество результата ниже, но, как мы видим, для бизнеса это не критично и окупается другими плюсами. С точки зрения идеального мира - это может и не очень хорошо, но в реальном мире выбор большинства проектов был сделан в пользу контейнеров.
Что до AI - пока всё ещё период хайпа. Реальные плюсы/минусы станут видны со временем. Работать с AI можно разными способами, в т.ч. такими, при которых качество вообще не страдает, удовлетворённость разработчиков выше, продуктивность тоже (хоть и не настолько, как мечтали). Но вряд ли от этого инструмента откажутся полностью, скорее просто выработают правила по его использованию - разные для разных типов проектов с разными требованиями к качеству кода, разумеется. Если посадить писать проект джунов без контроля (а некоторые так делают) - они напишут примерно то же самое, что AI при вайб-кодинге, только намного медленнее и намного дороже чем AI. А если квалифицированный сениор будет адекватно ставить задачи и полноценно ревьювить код, то нет принципиальной разницы, кто этот код написал, джун или AI - сениор всё-равно продавит необходимые изменения для получения качественного результата. Но с AI качественный результат будет получен намного быстрее, что плюс. Правда, при этом не будет обучаться джун, что минус. В общем, поглядим, куда это всё придёт, сейчас пока ещё рано делать выводы про качество кода AI.
Зависит от задачи. Если задача - дать доступ модели к содержимому локальных документов, то да, RAG или агент+MCP. Но в статье задача "дообучить", и тут RAG не поможет.
У любого знания есть цена (как минимум - время на изучение, но далеко не только это) - и не каждое знание стоит свою цену лично для Вас.
А ещё "знание" бывает ложным, даже если этого вообще никто в текущий момент времени не знает. В истории полно примеров того, как не знающие что что-то "невозможно" умудрялись это что-то сделать/изобрести, в то время как опытные-знающие были на это не способны.
А бывает, когда знаний в какой-то момент становится слишком много, и это вызывает аналитический паралич мешая принятию любых решений.
…плюс много других ситуаций, где лишние знания - совсем не благо.
У меня на DO почтовые порты открыты. Серверу, правда, уже несколько лет, может они изменили правила для новых клиентов - а может после обращения в саппорт эти порты открывают (я уже не помню, обращался ли я или сразу было открыто).
А вот на AWS почтовые порты мне открыть уже несколько лет назад не удалось, даже после месяца активной переписки с несколькими саппортами.
Для бэка, который занимается фронтом "немного", есть смысл скорее смотреть в сторону HTMX сотоварищи, с целью иметь на фронте как можно меньше JS в принципе, и фронтовая архитектура при таком подходе будет мало релевантна.
Есть такой механизм авторизации: для всех, у кого есть ссылка. Он не очень сильно защищает данные, но тем не менее предполагается, что он отличается от "для всех кто погуглил ключевое слово встречающееся по ссылке". Браузеры (вроде Chrome, Яндекс Браузер и, вероятно, Edge), подглядывающие ссылки пользователя без разрешения и сливающие их содержимое в свою БД, должны как-то этот нюанс учитывать - напр. игнорируя ссылку если доступ к ней закрыт в robots.txt. А сервисы использующие такой механизм авторизации должны соответственно настроить robots.txt.
AFAIR ChatGPT не настроил robots.txt, из-за чего и возникла эта проблема. Т.е. это вполне честная уязвимость, которую выявили и пофиксили. Другое дело, что после этого фикса было бы хорошо, если бы все такие ссылки из всех популярных поисковиков отозвала сама OpenAI, а не заставляла этим заниматься всех пользователей.
А в чём проблема дать доступ к шеллу вместо всего этого? Разумеется, с поддержкой белого списка команд, которые агент может запускать без подтверждения, и ручным подтверждением остальных, плюс некоторыми дополнительными защитами (таймаут на выполнение, ограничение на размер вывода, etc. - есть MCP сервера которые всё это реализуют, напр. https://github.com/sonirico/mcp-shell).
Будем откровенны: работать с ИИ в режиме ручного контроля каждого шага нет никакого смысла - это настолько утомительно, что обычно быстрее сделать задачу самому чем с помощью ИИ. А как только ИИ получает возможность самостоятельно писать и запускать тесты (а это - самый минимум для эффективной работы с ИИ, избавляющий от необходимость ревьювить кучу промежуточных некорректных изменений кода) - фактически у него уже есть полный шелл-доступ. И ограничивать этот доступ намного эффективнее и надёжнее снаружи - контролем среды, в которой работает ИИ агент, напр. через виртуалку/докер/firejail/….
Да, они будут молча читать Ваши документы и делать вид, что всё поняли. Только это вообще ничего не значит, к сожалению.
У меня на предыдущем проекте был похожий случай. Я отвечал за команду бэка, и согласовывал с лидом фронта изменения API в виде swagger.yml. И он два года молча аппрувил предложенные изменения. А потом случайно выяснилось, что он понятия не имеет, что такое swagger.yml, и даже не считает необходимым для роли лида фронта в этом разбираться. (Ну и, разумеется, никакие кодгены по нашему swagger.yml фронт не использовал.)
Не знаю, что там в чатике было, но могу сказать как считаю я.
Зависит от природы проекта. Бывают проекты, в которых один клик юзера в 99% превращается в один запрос GraphQL. А бывают, в которых один клик может привести к вызову десятка API (в худшем случае, если этот клик запускает тяжёлую операцию). В последнем случае для расчёта RPS обычно используются два подхода: либо считаем худший случай (тот самый десяток API на одного юзера), либо смотрим по метрикам средний RPS на живой системе и берём коэффициент из реальных данных. Но на этапе написания доки по нефункциональным требованиям обычно ещё нет живой системы с метриками, так что вариант остаётся один. А если на этапе написания этой доки нет понимания какой будет API и сколько там будет запросов на юзера - обычно использую коэффициент 5 на одного юзера.
Нет, дело в том, что документ этот пишется для определённой целевой аудитории - и она должна понимать, о чём идёт речь. В случае нефункциональных требований ЦА - это бизнес (который должен понять документ чтобы заапрувить его) и разработчики/девопсы (которые будут всё это внедрять и проверять). Поэтому перегружать его богатой терминологией (пусть и более точной и формально корректной) - не лучшая идея.
В большинстве проектов дока на нефункциональные требования отсутствует в принципе. Если она есть - это уже хорошо. Если она упоминает большинство указанных в статье разделов - это вообще прекрасно. Если её реально читают, пытаются выполнять и за этим кто-то реально следит - просто бомба. Если там явно сказано, что необходим контроль сложности пароля - не важно в каком виде - это однозначно плюс, а не минус, показывающий что об этом по крайней мере подумали. Может, конечно, в конкретном случае подумали не очень удачно - но сам факт что думали уже радует. Раз подумали и даже записали, значит вероятность что это требование в будущем будет улучшено сильно вырастает.
Это всё сильно зависит от природы проекта. В одном потеря качества вполне может быть допустима, в другом нет. Один должен быть резиновым-эластичным, а другой (игровой сервер, например) может иметь фиксированное значение максимального количества пользователей и отказывать в регистрациях/подключениях при превышении этого лимита. И термин масштабируемость для них будет означать очень разное - но в том или ином виде она есть везде. Можно, конечно, ввести уникальные термины для всех этих случаев, но тогда часть из этих терминов не будет иметь смысла во многих проектах. Даже сейчас многие путаются между доступностью и масштабируемостью (в этой статье доступность явно включили в надёжность, хотя это довольно разные вещи). Так что да, давайте ещё эластичность с робастностью сюда добавим, так сразу станет понятнее, ага.
Я сторонник кратких и actionable документов. Если есть несколько приемлемых вариантов решения то стоит описать требования и дать возможность выбрать конкретное решение тому, кто будет его внедрять. Но в некоторых случаях реального выбора просто нет, либо потому, что удовлетворяющее требованиям решение ровно одно, либо потому, что для единообразия этот проект должен использовать те же решения, что и соседние проекты - и тут намного проще сразу указать нужное решение, а не использовать общие фразы, делая вид, что выбор есть.
Ключевое - описать модель угроз. Дальше из неё вывести конкретные требования - и конкретику вроде "защита всех коммуникаций через mTLS", и описание необходимых процессов, которые требуется внедрить (безопасность - это в большей степени процесс).
Это уже не "чёткое ИЗНАЧАЛЬНОЕ представление" позволяющее спокойно работать по водопаду. Формально, под вариант с допсоглашениями попадёт любой проект на аутсорсе на условиях fixed price - их тьма и речь явно не о них, верно? Нет, я имел в виду как раз "чёткое ИЗНАЧАЛЬНОЕ представление" - когда заказчик ставит задачу, ждёт завершения водопада, и довольный принимает результат. Можно сказать, что я такое видел на мелких (размером в несколько дней) фрилансерских проектах, но такие микро-проекты мы тут вроде тоже не обсуждаем. А уже на мелких проектах размером хотя бы от 2-3 месяцев мне такое не встречалось.
Я такого за последние 36 лет работы с кодом не видел ни разу, а Вы?
Ключевое отличие software от hardware как раз в том и состоит, что граница между проектом и процессом размыта до неразличимости из-за мягкости производимого продукта. Можно считать условным проектом процесс разработки до получения минимально необходимого/полезного функционала и первых реальных пользователей, но с этого момента добавление любой новой фичи или значимого изменения можно воспринимать и как проект и как процесс - это мало на что будет влиять. Можно считать проектом каждый релиз коробочного продукта или новых версий мобильного приложения, но для бэкенда и веб-приложений обновляемых практически непрерывно грань опять же полностью размыта. По большому счёту проектом считают ситуацию, когда любой ценой необходимо уложиться в выделенные ресурсы (время/деньги). Что не мешает использовать аджайл, применяя его гибкость не для того, что внезапно добавлять только что придуманные фичи, а для того, чтобы выпиливать на ходу те, на которые не хватило ресурсов.
Одно другому не мешает - жёсткость с заказчиком можно и нужно проявлять в т.ч. при аджайле. Просто степень этой жёсткости будет ниже ("вот эту фичу мы если и будем делать, то в далёком будущем"), чем в водопаде ("на текущем этапе проекта никакие изменения невозможны в принципе"). По большому счёту аджайл прекрасно работает в стиле группы параллельных и последовательных небольших водопадов, позволяя соблюдать баланс и получать лучшее из обоих подходов.
Увеличилось, конечно. Чтобы писать достаточно портабельный код, который запустится в любом окружении, нужна более высокая квалификация, нежели чтобы написать код работающий в единственном окружении - контейнере. Причём одной квалификации мало, нужно ещё и больше времени на реализацию и тестирование. Т.е. это объективно заметно дороже для бизнеса. Контейнеры дают возможность и разработчикам меньше напрягаться, и бизнесу нанимать более дешёвых разработчиков и при этом получать результат быстрее. Качество результата ниже, но, как мы видим, для бизнеса это не критично и окупается другими плюсами. С точки зрения идеального мира - это может и не очень хорошо, но в реальном мире выбор большинства проектов был сделан в пользу контейнеров.
Что до AI - пока всё ещё период хайпа. Реальные плюсы/минусы станут видны со временем. Работать с AI можно разными способами, в т.ч. такими, при которых качество вообще не страдает, удовлетворённость разработчиков выше, продуктивность тоже (хоть и не настолько, как мечтали). Но вряд ли от этого инструмента откажутся полностью, скорее просто выработают правила по его использованию - разные для разных типов проектов с разными требованиями к качеству кода, разумеется. Если посадить писать проект джунов без контроля (а некоторые так делают) - они напишут примерно то же самое, что AI при вайб-кодинге, только намного медленнее и намного дороже чем AI. А если квалифицированный сениор будет адекватно ставить задачи и полноценно ревьювить код, то нет принципиальной разницы, кто этот код написал, джун или AI - сениор всё-равно продавит необходимые изменения для получения качественного результата. Но с AI качественный результат будет получен намного быстрее, что плюс. Правда, при этом не будет обучаться джун, что минус. В общем, поглядим, куда это всё придёт, сейчас пока ещё рано делать выводы про качество кода AI.
Зависит от задачи. Если задача - дать доступ модели к содержимому локальных документов, то да, RAG или агент+MCP. Но в статье задача "дообучить", и тут RAG не поможет.
Не любое знание есть благо.
У любого знания есть цена (как минимум - время на изучение, но далеко не только это) - и не каждое знание стоит свою цену лично для Вас.
А ещё "знание" бывает ложным, даже если этого вообще никто в текущий момент времени не знает. В истории полно примеров того, как не знающие что что-то "невозможно" умудрялись это что-то сделать/изобрести, в то время как опытные-знающие были на это не способны.
А бывает, когда знаний в какой-то момент становится слишком много, и это вызывает аналитический паралич мешая принятию любых решений.
…плюс много других ситуаций, где лишние знания - совсем не благо.
Не почту как таковую, а её федеративность - всех загоняют на крупных провайдеров вроде gmail. И это полный беспредел!
У меня на DO почтовые порты открыты. Серверу, правда, уже несколько лет, может они изменили правила для новых клиентов - а может после обращения в саппорт эти порты открывают (я уже не помню, обращался ли я или сразу было открыто).
А вот на AWS почтовые порты мне открыть уже несколько лет назад не удалось, даже после месяца активной переписки с несколькими саппортами.
Eсть способ "решить" эту проблему: https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme
Для бэка, который занимается фронтом "немного", есть смысл скорее смотреть в сторону HTMX сотоварищи, с целью иметь на фронте как можно меньше JS в принципе, и фронтовая архитектура при таком подходе будет мало релевантна.
Есть такой механизм авторизации: для всех, у кого есть ссылка. Он не очень сильно защищает данные, но тем не менее предполагается, что он отличается от "для всех кто погуглил ключевое слово встречающееся по ссылке". Браузеры (вроде Chrome, Яндекс Браузер и, вероятно, Edge), подглядывающие ссылки пользователя без разрешения и сливающие их содержимое в свою БД, должны как-то этот нюанс учитывать - напр. игнорируя ссылку если доступ к ней закрыт в
robots.txt. А сервисы использующие такой механизм авторизации должны соответственно настроитьrobots.txt.AFAIR ChatGPT не настроил
robots.txt, из-за чего и возникла эта проблема. Т.е. это вполне честная уязвимость, которую выявили и пофиксили. Другое дело, что после этого фикса было бы хорошо, если бы все такие ссылки из всех популярных поисковиков отозвала сама OpenAI, а не заставляла этим заниматься всех пользователей.А в чём проблема дать доступ к шеллу вместо всего этого? Разумеется, с поддержкой белого списка команд, которые агент может запускать без подтверждения, и ручным подтверждением остальных, плюс некоторыми дополнительными защитами (таймаут на выполнение, ограничение на размер вывода, etc. - есть MCP сервера которые всё это реализуют, напр. https://github.com/sonirico/mcp-shell).
Будем откровенны: работать с ИИ в режиме ручного контроля каждого шага нет никакого смысла - это настолько утомительно, что обычно быстрее сделать задачу самому чем с помощью ИИ. А как только ИИ получает возможность самостоятельно писать и запускать тесты (а это - самый минимум для эффективной работы с ИИ, избавляющий от необходимость ревьювить кучу промежуточных некорректных изменений кода) - фактически у него уже есть полный шелл-доступ. И ограничивать этот доступ намного эффективнее и надёжнее снаружи - контролем среды, в которой работает ИИ агент, напр. через виртуалку/докер/firejail/….
В теории или на практике? :)
Да, они будут молча читать Ваши документы и делать вид, что всё поняли. Только это вообще ничего не значит, к сожалению.
У меня на предыдущем проекте был похожий случай. Я отвечал за команду бэка, и согласовывал с лидом фронта изменения API в виде swagger.yml. И он два года молча аппрувил предложенные изменения. А потом случайно выяснилось, что он понятия не имеет, что такое swagger.yml, и даже не считает необходимым для роли лида фронта в этом разбираться. (Ну и, разумеется, никакие кодгены по нашему swagger.yml фронт не использовал.)
Не знаю, что там в чатике было, но могу сказать как считаю я.
Зависит от природы проекта. Бывают проекты, в которых один клик юзера в 99% превращается в один запрос GraphQL. А бывают, в которых один клик может привести к вызову десятка API (в худшем случае, если этот клик запускает тяжёлую операцию). В последнем случае для расчёта RPS обычно используются два подхода: либо считаем худший случай (тот самый десяток API на одного юзера), либо смотрим по метрикам средний RPS на живой системе и берём коэффициент из реальных данных. Но на этапе написания доки по нефункциональным требованиям обычно ещё нет живой системы с метриками, так что вариант остаётся один. А если на этапе написания этой доки нет понимания какой будет API и сколько там будет запросов на юзера - обычно использую коэффициент 5 на одного юзера.
Нет, дело в том, что документ этот пишется для определённой целевой аудитории - и она должна понимать, о чём идёт речь. В случае нефункциональных требований ЦА - это бизнес (который должен понять документ чтобы заапрувить его) и разработчики/девопсы (которые будут всё это внедрять и проверять). Поэтому перегружать его богатой терминологией (пусть и более точной и формально корректной) - не лучшая идея.
В большинстве проектов дока на нефункциональные требования отсутствует в принципе. Если она есть - это уже хорошо. Если она упоминает большинство указанных в статье разделов - это вообще прекрасно. Если её реально читают, пытаются выполнять и за этим кто-то реально следит - просто бомба. Если там явно сказано, что необходим контроль сложности пароля - не важно в каком виде - это однозначно плюс, а не минус, показывающий что об этом по крайней мере подумали. Может, конечно, в конкретном случае подумали не очень удачно - но сам факт что думали уже радует. Раз подумали и даже записали, значит вероятность что это требование в будущем будет улучшено сильно вырастает.
Это всё сильно зависит от природы проекта. В одном потеря качества вполне может быть допустима, в другом нет. Один должен быть резиновым-эластичным, а другой (игровой сервер, например) может иметь фиксированное значение максимального количества пользователей и отказывать в регистрациях/подключениях при превышении этого лимита. И термин масштабируемость для них будет означать очень разное - но в том или ином виде она есть везде. Можно, конечно, ввести уникальные термины для всех этих случаев, но тогда часть из этих терминов не будет иметь смысла во многих проектах. Даже сейчас многие путаются между доступностью и масштабируемостью (в этой статье доступность явно включили в надёжность, хотя это довольно разные вещи). Так что да, давайте ещё эластичность с робастностью сюда добавим, так сразу станет понятнее, ага.
Я сторонник кратких и actionable документов. Если есть несколько приемлемых вариантов решения то стоит описать требования и дать возможность выбрать конкретное решение тому, кто будет его внедрять. Но в некоторых случаях реального выбора просто нет, либо потому, что удовлетворяющее требованиям решение ровно одно, либо потому, что для единообразия этот проект должен использовать те же решения, что и соседние проекты - и тут намного проще сразу указать нужное решение, а не использовать общие фразы, делая вид, что выбор есть.
Ключевое - описать модель угроз. Дальше из неё вывести конкретные требования - и конкретику вроде "защита всех коммуникаций через mTLS", и описание необходимых процессов, которые требуется внедрить (безопасность - это в большей степени процесс).