Здравствуйте, ·, Вы писали:

P>>Предлагаешь взять до кучи роль топ-менеджера и потратить пять лет на выстраивание процесса коммуникации с консумерами что бы закончить фичу?
·>Без хедера фича не работает?

Нет, не работает. К каждой фиче приклеиваются нефункциональные требования — например, мониторинг на обоих сторонах должен обнаруживать проблемы

·>Итак. Получается такая цепочка:
·>0. Ты обнаружил precondontion.
·>1. Код ворнинга
·>2. QA
·>3. Хедер
·>4. Система логгирования
·>5. Мониторинг
·>6. L2 замечает проблему
·>7. L2 расследует
·>8. разработчик-менеджер.

·>Вот теперь объясни зачем нужны шаги 1-7? Это затраты ресурсов и человеческих, и машинных, и на каждом шаге можно сломаться-потеряться и вся цепочка рухнет. Почему бы сразу не перейти к 8му шагу?

Похоже, тебе религия мешает разобраться, зачем нужны ассерты.
Они нужны в момент, как и логи, во время запуска в тч на проде.
Например — выявить, если какаято из 2^100 комбинаций дала подозрительный результат.

P>>·>У тебя нет 2^100 комбинаций.
P>>Есть. Типичный реквест содержит куда больше информации.
·>И что? Мы говорим о конкретном warning, который появится в хедере. Который проверяет вполне конкретную информацию по конкретному алгоритму. Т.е. ровно одна комбинация.

Он проверяет свойство результата, например, или свойство входа. У какой из 2^100 комбинаций эти свойства будут нарушены?

P>>Мы снова говорим о том, что ты не понимаешь роль ассертов. Ассерт используется там, где джира-емейл-тестирование неприменимо. Это механизм того же рода, что и логи.
·>Я о роли ассертов и тестов не рассуждал и вообще ничего не говорил. В данном контексте это неважно.

Наоборот, именно это и важно.

P>>Вот-вот. Ассерты это те же логи, только, только условные. Логи знаешь, а ассерты — нет?
·>И причём тут хедер?

При том, что надо быть дать знать той стороне, что свойства ихнего запроса пудозрительные.

P>>И снова ты пишешь о том, что не в курсе проблемы которую решают ассерты.
·>Мне пофиг какие проблемы решают ассерты. Это к разговору не относится. Я пытаюсь из тебя вытянуть какие проблемы решает хедер.

Ты вроде выяснил — административные, разделяет зоны ответственности."херли вы пользуетесь старой схемой, если год назад мы вам дали новую"

·>Так почему именно хедер с ворнингом надо? Чем другие механизмы не устраивают-то?

Самый простой и дешовый. Другие на порядки дороже.

P>>Тебе все рассказали. Это самый простой способ тригерить сообщения в мониторинг на той стороне.
·>Зачем триггерить мониторинг на той стороне?

Затем, что наши ассерты говорят о том, что у них чего то не то.

P>> у вас там что, секюрити не изобрели? В логах чудовищное количество сенситив инфрмации. Если даешь доступ сотне-тысяче консумеров, это все равно что приговор себе подписать.
·>1. В логах не должно быть сенситив информации. По крайней мере не во всех. На крайний случай заведи лог специально для варнингов и расшарь.

Ога, и так для тыщи консумеров.

·>2. Мы вроде о внутренних консьюмерах говорили.

В данном случае это скорее внешние консумеры.

P>>Тебе уже сказали, что все это уже есть. Снова нечитатель?
·>В том-то и дело, что много чего уже есть. Так зачем нужен ещё и хедер?

Что бы мониторинг на той стороне сработал.

Здравствуйте, ·, Вы писали:

P>>Предлагаешь взять до кучи роль топ-менеджера и потратить пять лет на выстраивание процесса коммуникации с консумерами что бы закончить фичу?
·>Без хедера фича не работает?

Нет, не работает. К каждой фиче приклеиваются нефункциональные требования — например, мониторинг на обоих сторонах должен обнаруживать проблемы

·>Итак. Получается такая цепочка:
·>0. Ты обнаружил precondontion.
·>1. Код ворнинга
·>2. QA
·>3. Хедер
·>4. Система логгирования
·>5. Мониторинг
·>6. L2 замечает проблему
·>7. L2 расследует
·>8. разработчик-менеджер.

·>Вот теперь объясни зачем нужны шаги 1-7? Это затраты ресурсов и человеческих, и машинных, и на каждом шаге можно сломаться-потеряться и вся цепочка рухнет. Почему бы сразу не перейти к 8му шагу?

Похоже, тебе религия мешает разобраться, зачем нужны ассерты.
Они нужны в момент, как и логи, во время запуска в тч на проде.
Например — выявить, если какаято из 2^100 комбинаций дала подозрительный результат.

P>>·>У тебя нет 2^100 комбинаций.
P>>Есть. Типичный реквест содержит куда больше информации.
·>И что? Мы говорим о конкретном warning, который появится в хедере. Который проверяет вполне конкретную информацию по конкретному алгоритму. Т.е. ровно одна комбинация.

Он проверяет свойство результата, например, или свойство входа. У какой из 2^100 комбинаций эти свойства будут нарушены?

P>>Мы снова говорим о том, что ты не понимаешь роль ассертов. Ассерт используется там, где джира-емейл-тестирование неприменимо. Это механизм того же рода, что и логи.
·>Я о роли ассертов и тестов не рассуждал и вообще ничего не говорил. В данном контексте это неважно.

Наоборот, именно это и важно.

P>>Вот-вот. Ассерты это те же логи, только, только условные. Логи знаешь, а ассерты — нет?
·>И причём тут хедер?

При том, что надо быть дать знать той стороне, что свойства ихнего запроса пудозрительные.

P>>И снова ты пишешь о том, что не в курсе проблемы которую решают ассерты.
·>Мне пофиг какие проблемы решают ассерты. Это к разговору не относится. Я пытаюсь из тебя вытянуть какие проблемы решает хедер.

Ты вроде выяснил — административные, разделяет зоны ответственности."херли вы пользуетесь старой схемой, если год назад мы вам дали новую"

·>Так почему именно хедер с ворнингом надо? Чем другие механизмы не устраивают-то?

Самый простой и дешовый. Другие на порядки дороже.

P>>Тебе все рассказали. Это самый простой способ тригерить сообщения в мониторинг на той стороне.
·>Зачем триггерить мониторинг на той стороне?

Затем, что наши ассерты говорят о том, что у них чего то не то.

P>> у вас там что, секюрити не изобрели? В логах чудовищное количество сенситив инфрмации. Если даешь доступ сотне-тысяче консумеров, это все равно что приговор себе подписать.
·>1. В логах не должно быть сенситив информации. По крайней мере не во всех. На крайний случай заведи лог специально для варнингов и расшарь.

Ога, и так для тыщи консумеров.

·>2. Мы вроде о внутренних консьюмерах говорили.

В данном случае это скорее внешние консумеры. Коммуникация то отсутствует, разные подразделения, может оказаться так, что и доступа друг к другу не имеют вовсе. Т.е. разницы со внешними консумерами никакой. Пока менеджмент не договорится, должно быть решение.

P>>Тебе уже сказали, что все это уже есть. Снова нечитатель?
·>В том-то и дело, что много чего уже есть. Так зачем нужен ещё и хедер?

Что бы мониторинг на той стороне сработал.