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