А какой смысл на daily обсуждать проблемы, которые не могут быть решены командой? Если есть кто-то вне команды, кто может их решить - надо его и дергать, как появилась проблема. Простой чат команды решает ту же задачу, но лучше и быстрее, для автономных команд. Другое дело, что скрам имеет смысл только для слабых команд, которые еще не умеют в автономность и самостоятельность.
Что такое "унарный REST"? В концепции REST ничего такого нет. Почитайте Филдинга. Или хотя бы Ричардсона. REST как концепция (т.е. REST level 2 и выше) предполагает работу с ресурсами с помощью стандартных операций, там нет никаких своих функций. Можно вообще сделать маппинг HTTP verbs прямо на SQL и сделать один хендлер на множество RESTовых ресурсов и это будет вполне корректно. В REST нет никаких функций.
Но да, часто любые вызовы по http называют REST, но это безграмотно и показывает, что автор не знает смысла используемых терминов.
Изначальный текст неплохой, но перевод местами очень кривой, еще и куча опечаток. Перевод лучше бы еще раз вычитать (или хотя бы один раз вычитать, а то есть ощущение, что переводили довольно плохим автопереводчиком, даже не ChatGPT4)
Не совсем. REST предполагает операции над ресурсами и первичны именно ресурсы, в RPC единицей является вызываемый метод. Так что все-таки это разные идеологии. Впрочем, автор статьи, конечно, ничего не знает ни о REST, ни о RPC.
Не надо описывать НФТ в виде user story. Тем более в user story обязательно должна быть мотивационная часть, иначе оно бесполезно. Все указанные в статье user story - таковыми не являются (
Ну, лучше вообще перед описанием ФТ провести EventStorming и сделать описание доменных моделей. То, что описано в статье - просто куча бесполезных строчек, никак не связано с описанием требований, увы.
Очень много сомнительных практик в этом шаблоне. Потеряна мотивация (а описание "зачем" - самое важное, что должен описывать аналитик), очень много техдизайна (плохо описанного) вместо требований, в описании НФТ нет вообще ни одного корректного пункта, нет ничего про UX (а задание на UX делается до задания для дизайнеров. Впрочем, задание для дизайна тоже предполагает бриф, про что не сказано ни слова). Надеюсь, ничего из этого шаблона реально в банке не используется.
Тут довольно мало про описание требований, разве что про User Story, да и то без мотивационной части (что делает их практически бесполезным). Описание API - это не требования, это техдизайн. Как и вообще все, что написано в главе "Бизнес-логика".
А зачем новичку, который даже OpenAPI не может освоить, пытаться описывать API? Проработка программных интерфейсов - сложная инженерная работа, без опыта работы хотя бы миддлом на бэке ее делать категорически не стоит (а по хорошему, это вообще должны писать инженеры, а не аналитики). И OpenAPI - это как раз про документацию, не про код.
Да, конечно, читал и конечно в оригинале. Нет, ресурс - это не запись в БД и не кортеж, это то, что может быть уникально идентифицировано. Иногда это несколько записей в БД (агрегат), иногда вообще не про БД, иногда это может быть отчетом (который не запись в БД, но вполне может идентифицироваться uri) или командой в процессе исполнения или много чем еще.
Мне не очень интересно рассматривать REST, он так же мало применим к реализации API (что, кстати, у Филдинга прямо написано), как и GQL. Тем более не интересно обсуждать какие-то фантазии на тему REST.
Советую все-таки почитать про REST, хотя бы диссертацию Филдинга, где вводится это понятие. И нет, REST никогда не отражение СУБД, он ни в коем случае не должен быть таковым. Ну и в реальности мало кто использует REST, чаще реально используется какой-то RPC с json-over-http, впрочем, это и правильно. Но там не будет никакого отражения СУБД )
Хм, REST не про коммуникацию поверх HTTP и не про сериализацию в JSON. REST - про реализацию гипертекстовых систем на основе идеологии ресурсов и операций с ними. И в этом смысле GQL никак не связан с RESTом, это совсем другая парадигма, гораздо более близкая к двузвенным архитектурам прошлого тысячелетия и повторяющая все те же ошибки, что были совершены тогда. И нет, grpc не эффективнее gziped json-over-http на реальных задачах )
У Huawei лучшие камеры при вменяемой цене. Я когда выбирал камерофон - долго смотрел на P60. Если бы был P70, то может и взял бы его, а не Oppo
Э, какой смысл сравнивать среднюю зарплату до налогов в США и медианную месячную после налогов в РФ?
А какой смысл на daily обсуждать проблемы, которые не могут быть решены командой? Если есть кто-то вне команды, кто может их решить - надо его и дергать, как появилась проблема.
Простой чат команды решает ту же задачу, но лучше и быстрее, для автономных команд. Другое дело, что скрам имеет смысл только для слабых команд, которые еще не умеют в автономность и самостоятельность.
Что такое "унарный REST"? В концепции REST ничего такого нет.
Почитайте Филдинга. Или хотя бы Ричардсона.
REST как концепция (т.е. REST level 2 и выше) предполагает работу с ресурсами с помощью стандартных операций, там нет никаких своих функций. Можно вообще сделать маппинг HTTP verbs прямо на SQL и сделать один хендлер на множество RESTовых ресурсов и это будет вполне корректно.
В REST нет никаких функций.
Но да, часто любые вызовы по http называют REST, но это безграмотно и показывает, что автор не знает смысла используемых терминов.
Изначальный текст неплохой, но перевод местами очень кривой, еще и куча опечаток.
Перевод лучше бы еще раз вычитать (или хотя бы один раз вычитать, а то есть ощущение, что переводили довольно плохим автопереводчиком, даже не ChatGPT4)
А какие еще варианты кроме скрама рассматривали?
И что именно внедрили - скрам или скрамбат?
Не совсем. REST предполагает операции над ресурсами и первичны именно ресурсы, в RPC единицей является вызываемый метод. Так что все-таки это разные идеологии. Впрочем, автор статьи, конечно, ничего не знает ни о REST, ни о RPC.
Не надо описывать НФТ в виде user story.
Тем более в user story обязательно должна быть мотивационная часть, иначе оно бесполезно. Все указанные в статье user story - таковыми не являются (
Ну, лучше вообще перед описанием ФТ провести EventStorming и сделать описание доменных моделей. То, что описано в статье - просто куча бесполезных строчек, никак не связано с описанием требований, увы.
Очень много сомнительных практик в этом шаблоне.
Потеряна мотивация (а описание "зачем" - самое важное, что должен описывать аналитик), очень много техдизайна (плохо описанного) вместо требований, в описании НФТ нет вообще ни одного корректного пункта, нет ничего про UX (а задание на UX делается до задания для дизайнеров. Впрочем, задание для дизайна тоже предполагает бриф, про что не сказано ни слова).
Надеюсь, ничего из этого шаблона реально в банке не используется.
Тут довольно мало про описание требований, разве что про User Story, да и то без мотивационной части (что делает их практически бесполезным).
Описание API - это не требования, это техдизайн. Как и вообще все, что написано в главе "Бизнес-логика".
А зачем новичку, который даже OpenAPI не может освоить, пытаться описывать API? Проработка программных интерфейсов - сложная инженерная работа, без опыта работы хотя бы миддлом на бэке ее делать категорически не стоит (а по хорошему, это вообще должны писать инженеры, а не аналитики).
И OpenAPI - это как раз про документацию, не про код.
По ссылке нет ни одного реального кейса.
Да, конечно, читал и конечно в оригинале.
Нет, ресурс - это не запись в БД и не кортеж, это то, что может быть уникально идентифицировано. Иногда это несколько записей в БД (агрегат), иногда вообще не про БД, иногда это может быть отчетом (который не запись в БД, но вполне может идентифицироваться uri) или командой в процессе исполнения или много чем еще.
Мне не очень интересно рассматривать REST, он так же мало применим к реализации API (что, кстати, у Филдинга прямо написано), как и GQL. Тем более не интересно обсуждать какие-то фантазии на тему REST.
Э, это что за реальный кейс, когда нужно грузить мегабайт вместо килобайта? Можешь привести реальный пример?
Не смог там найти никаких реальных проблем.
Советую все-таки почитать про REST, хотя бы диссертацию Филдинга, где вводится это понятие.
И нет, REST никогда не отражение СУБД, он ни в коем случае не должен быть таковым.
Ну и в реальности мало кто использует REST, чаще реально используется какой-то RPC с json-over-http, впрочем, это и правильно. Но там не будет никакого отражения СУБД )
А в чем проблема отдать лишние поля? Когда это вообще стало проблемой?
Ну да. GQL заставляет разработчика бэка реализовывать полноценную распределенную СУБД уровня YDB, только на коленке. С соответствующим результатом )
Хм, REST не про коммуникацию поверх HTTP и не про сериализацию в JSON. REST - про реализацию гипертекстовых систем на основе идеологии ресурсов и операций с ними.
И в этом смысле GQL никак не связан с RESTом, это совсем другая парадигма, гораздо более близкая к двузвенным архитектурам прошлого тысячелетия и повторяющая все те же ошибки, что были совершены тогда.
И нет, grpc не эффективнее gziped json-over-http на реальных задачах )