Сообщение Re[68]: Идемпотентность POST - хорошая ли практика? от 13.10.2022 11:41
Изменено 13.10.2022 11:43 ·
Re[68]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, Pauel, Вы писали:
P>>>С чего ты взял, что у них там идеальный порядок?
P>·>Вот именно. Значит шаги 1-7 тоже могут быть сломаны.
P>Смотрим вместе:
P>0. Ты обнаружил precondontion.
P>1. Код ворнинга — это ваша зона ответственности, варнинги должны быть покрыты тестами и пройти код ревью.
P>2. QA — снова ваша зона ответсвенности, qa дают добро на выход в прод
P>3. Хедер — пишется автоматически, ваша зона ответственности, покрыто тестами
P>4. Система логгирования — их зона ответственности
P>5. Мониторинг — это правило для деплоймента, добавляется ровно 1 степ на фильтрацию логов
P>6. L2 замечает проблему
P>7. L2 расследует
P>8. разработчик-менеджер — не абы кто из рассылки, а именно тот, кто отвечает за конкретный продукт
P>Твой вариант — 0..4 тож самое, только в хидеры ничего не пихаете.
Нет. Необходим только 0 (и вообще это не шаг как таковой, а так, начало всего процесса). После этого (в тяжелых случаях) можно добавить логгирование в наш код для инвестигирования проблемы, но в большинстве случаев существующих логов вполне достаточно. Для наших логов QA не нужен, т.к. они наши и их качество — наша внутренняя проблема. Вы же хедер публикуете наружу клиентам, через API. Значит QA необходим, т.к. client-driven тестирование вещь, мягко говоря, не лучшая идея.
P> Вместо 4..5 у тебя
P>1. взять человека, который по request-id будет заниматься роутингом по request-id
Искать по request-id что, откуда, куда, зачем пришло всё равно постоянно приходится. С варнингами и без. С этим справляется любой у кого есть доступ к логам.
P>2. ожидать, что на той стороне люди будут форвардить друг другу письма, тикеты итд
Это то что у тебя на шагах 6-7-8.
P>далее 6,7,8 один в один.
6 не нужно, т.к. проблему ты сообщаешь явно и, в идеале, добиваешься подтверждения у получателя, что проблему начали расследовать.
P>Итого — цепочка примерно та же, только ручной роутинг-форвардинг вносит хаос.
Нет.
>> Уж лучше validation, input check, argument check, precondition, warning, complain, report, fault, defect и т.п. Но причём тут ассерты, вообще неясно.
P>Забавно, что ты перечислил целую кучу разновидностей ассертов
Это в твоей уникальной терминологии.
P>>>С чего ты взял, что у них там идеальный порядок?
P>·>Вот именно. Значит шаги 1-7 тоже могут быть сломаны.
P>Смотрим вместе:
P>0. Ты обнаружил precondontion.
P>1. Код ворнинга — это ваша зона ответственности, варнинги должны быть покрыты тестами и пройти код ревью.
P>2. QA — снова ваша зона ответсвенности, qa дают добро на выход в прод
P>3. Хедер — пишется автоматически, ваша зона ответственности, покрыто тестами
P>4. Система логгирования — их зона ответственности
P>5. Мониторинг — это правило для деплоймента, добавляется ровно 1 степ на фильтрацию логов
P>6. L2 замечает проблему
P>7. L2 расследует
P>8. разработчик-менеджер — не абы кто из рассылки, а именно тот, кто отвечает за конкретный продукт
P>Твой вариант — 0..4 тож самое, только в хидеры ничего не пихаете.
Нет. Необходим только 0 (и вообще это не шаг как таковой, а так, начало всего процесса). После этого (в тяжелых случаях) можно добавить логгирование в наш код для инвестигирования проблемы, но в большинстве случаев существующих логов вполне достаточно. Для наших логов QA не нужен, т.к. они наши и их качество — наша внутренняя проблема. Вы же хедер публикуете наружу клиентам, через API. Значит QA необходим, т.к. client-driven тестирование вещь, мягко говоря, не лучшая идея.
P> Вместо 4..5 у тебя
P>1. взять человека, который по request-id будет заниматься роутингом по request-id
Искать по request-id что, откуда, куда, зачем пришло всё равно постоянно приходится. С варнингами и без. С этим справляется любой у кого есть доступ к логам.
P>2. ожидать, что на той стороне люди будут форвардить друг другу письма, тикеты итд
Это то что у тебя на шагах 6-7-8.
P>далее 6,7,8 один в один.
6 не нужно, т.к. проблему ты сообщаешь явно и, в идеале, добиваешься подтверждения у получателя, что проблему начали расследовать.
P>Итого — цепочка примерно та же, только ручной роутинг-форвардинг вносит хаос.
Нет.
>> Уж лучше validation, input check, argument check, precondition, warning, complain, report, fault, defect и т.п. Но причём тут ассерты, вообще неясно.
P>Забавно, что ты перечислил целую кучу разновидностей ассертов
Это в твоей уникальной терминологии.
Re[68]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, Pauel, Вы писали:
P>>>С чего ты взял, что у них там идеальный порядок?
P>·>Вот именно. Значит шаги 1-7 тоже могут быть сломаны.
P>Смотрим вместе:
P>0. Ты обнаружил precondontion.
P>1. Код ворнинга — это ваша зона ответственности, варнинги должны быть покрыты тестами и пройти код ревью.
P>2. QA — снова ваша зона ответсвенности, qa дают добро на выход в прод
P>3. Хедер — пишется автоматически, ваша зона ответственности, покрыто тестами
P>4. Система логгирования — их зона ответственности
P>5. Мониторинг — это правило для деплоймента, добавляется ровно 1 степ на фильтрацию логов
P>6. L2 замечает проблему
P>7. L2 расследует
P>8. разработчик-менеджер — не абы кто из рассылки, а именно тот, кто отвечает за конкретный продукт
P>Твой вариант — 0..4 тож самое, только в хидеры ничего не пихаете.
Нет. Необходим только 0 (и вообще это не шаг как таковой, а так, начало всего процесса). После этого (в тяжелых случаях) можно добавить логгирование в наш код для инвестигирования проблемы, но в большинстве случаев существующих логов вполне достаточно. Для наших логов QA не нужен, т.к. они наши и их качество — наша внутренняя проблема. Вы же хедер публикуете наружу клиентам, через API. Значит QA необходим, т.к. client-driven тестирование вещь, мягко говоря, не лучшая идея.
P> Вместо 4..5 у тебя
P>1. взять человека, который по request-id будет заниматься роутингом по request-id
Искать по request-id что, откуда, куда, зачем пришло всё равно постоянно приходится. С варнингами и без. С этим справляется любой у кого есть доступ к логам.
P>2. ожидать, что на той стороне люди будут форвардить друг другу письма, тикеты итд
Это то что у тебя на шагах 6-7-8.
P>далее 6,7,8 один в один.
6 не нужно, т.к. проблему ты сообщаешь явно и, в идеале, добиваешься подтверждения у получателя, что проблему начали расследовать.
P>Итого — цепочка примерно та же, только ручной роутинг-форвардинг вносит хаос.
Нет.
>> Уж лучше validation, input check, argument check, precondition, warning, complain, report, fault, defect и т.п. Но причём тут ассерты, вообще неясно.
P>Забавно, что ты перечислил целую кучу разновидностей ассертов
Это только в твоей уникальной терминологии.
P>>>С чего ты взял, что у них там идеальный порядок?
P>·>Вот именно. Значит шаги 1-7 тоже могут быть сломаны.
P>Смотрим вместе:
P>0. Ты обнаружил precondontion.
P>1. Код ворнинга — это ваша зона ответственности, варнинги должны быть покрыты тестами и пройти код ревью.
P>2. QA — снова ваша зона ответсвенности, qa дают добро на выход в прод
P>3. Хедер — пишется автоматически, ваша зона ответственности, покрыто тестами
P>4. Система логгирования — их зона ответственности
P>5. Мониторинг — это правило для деплоймента, добавляется ровно 1 степ на фильтрацию логов
P>6. L2 замечает проблему
P>7. L2 расследует
P>8. разработчик-менеджер — не абы кто из рассылки, а именно тот, кто отвечает за конкретный продукт
P>Твой вариант — 0..4 тож самое, только в хидеры ничего не пихаете.
Нет. Необходим только 0 (и вообще это не шаг как таковой, а так, начало всего процесса). После этого (в тяжелых случаях) можно добавить логгирование в наш код для инвестигирования проблемы, но в большинстве случаев существующих логов вполне достаточно. Для наших логов QA не нужен, т.к. они наши и их качество — наша внутренняя проблема. Вы же хедер публикуете наружу клиентам, через API. Значит QA необходим, т.к. client-driven тестирование вещь, мягко говоря, не лучшая идея.
P> Вместо 4..5 у тебя
P>1. взять человека, который по request-id будет заниматься роутингом по request-id
Искать по request-id что, откуда, куда, зачем пришло всё равно постоянно приходится. С варнингами и без. С этим справляется любой у кого есть доступ к логам.
P>2. ожидать, что на той стороне люди будут форвардить друг другу письма, тикеты итд
Это то что у тебя на шагах 6-7-8.
P>далее 6,7,8 один в один.
6 не нужно, т.к. проблему ты сообщаешь явно и, в идеале, добиваешься подтверждения у получателя, что проблему начали расследовать.
P>Итого — цепочка примерно та же, только ручной роутинг-форвардинг вносит хаос.
Нет.
>> Уж лучше validation, input check, argument check, precondition, warning, complain, report, fault, defect и т.п. Но причём тут ассерты, вообще неясно.
P>Забавно, что ты перечислил целую кучу разновидностей ассертов
Это только в твоей уникальной терминологии.