Есть продукт с большим количеством разработчиков и бета-тестеров. У продукта есть параметр commit interval -- периодичность сброса неких вещей на диск.
Хотелось бы иметь значение этого параметра 1 секунда в стабильных официальных билдах, и значение 1 минута в разработческих билдах (для того триггерить баги).
Однако оказалось, что подобное изменение практически невозможно провести через код-ревью.

Как вы относитесь к разному поведению в разных билдах, и в какой форме это можно сделать чтобы пройти код-ревью?

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

W>Как вы относитесь к разному поведению в разных билдах,
Плохо.

W>и в какой форме это можно сделать чтобы пройти код-ревью?
Вынеси в конфиг. Будет новая мегафича.

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

W>Как вы относитесь к разному поведению в разных билдах,
Отрицательно. Debug-код нужен для детальной диагностики проблемы, а не для создания новых

W> и в какой форме это можно сделать чтобы пройти код-ревью?
Использовать ассерты, которые компилируются только в дебаге и прерывают выполнение в момент нарушения ассерта (и падают, если дебаггер не приаттачен).

W>> и в какой форме это можно сделать чтобы пройти код-ревью?
S>Использовать ассерты, которые компилируются только в дебаге и прерывают выполнение в момент нарушения ассерта (и падают, если дебаггер не приаттачен).

в данном случае ассертов мало. Низкое значение commit interval (которое необходимо для стабильного билда) приведет к тому что некоторые проблемы могут оказаться скрыты (это не благое размышление, а реальный факт). А высокое значение недопустимо в стабильных билдах, потому что это будет приводить к тому что при крэшах с большой вероятностью будут теряться данные.

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


W>>> и в какой форме это можно сделать чтобы пройти код-ревью?
S>>Использовать ассерты, которые компилируются только в дебаге и прерывают выполнение в момент нарушения ассерта (и падают, если дебаггер не приаттачен).

W>в данном случае ассертов мало. Низкое значение commit interval (которое необходимо для стабильного билда) приведет к тому что некоторые проблемы могут оказаться скрыты (это не благое размышление, а реальный факт). А высокое значение недопустимо в стабильных билдах, потому что это будет приводить к тому что при крэшах с большой вероятностью будут теряться данные.

Может при крэшах просто делать создавать дампы ?
А то получается что вы не решаете проблему, а откладываете ее появляние до более неподходящего момента.

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

W>в данном случае ассертов мало. Низкое значение commit interval (которое необходимо для стабильного билда) приведет к тому что некоторые проблемы могут оказаться скрыты (это не благое размышление, а реальный факт).
Это как, проблемы "теряются" от того, что сохранение производится чаще? Я бы пометил такой код как ненадёжный и постарался бы от него избавиться в первую очередь, а не тратить время на его поддержку.

W>А высокое значение недопустимо в стабильных билдах, потому что это будет приводить к тому что при крэшах с большой вероятностью будут теряться данные.

Если вам так важны данные, может, стоит использовать готовые решения, удовлетворяющие ACID? Или хотя бы перейти к журналируемому хранилищу, всяко лучше, чем отлаживать гейзенбаги.