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

IT>1. Настоящий индеец прежде всего заходит в меню Debug и в диалоге Exceptions включает галку Thrown на CLR Exceptions для managed языков. Это позволяет сэкономить не просто хучу, а туеву хучу времени при поиске ошибок. Отсюда следствие — настоящие индейцы не используют логику на исключениях, иначе весь кайф пропадает.

Не знаю что там за ошибки такие ловятся, но по крайней мере зверя ContextSwitchDeadLock я буду включать только через свой труп — он мне столько нервов попортил... Находишь с трудом ошибку, доходишь до неё через кучу махинаций с брейкпоинтами, а потом раз и выбрасывается исключение, что мол где-то там в CLR 60 сек. прошло, перезагружай прогу... так и поседеть недолго .


IT>4. Разбиение таких задач на несколько методов, которые используются только один раз не имеет никакого смысла

Согласен, только иногда существуют такие блоки в этих линейных методах, которым очень легко придумать название отдельного метода и оно очень четко функциональность этого блока описывает... В общем в таком случае получается, что дробление метода только увеличивает понятность, т.к. с хранением этих мелких методов почему-то проблем не возникает — их легко находить, а на практике и вообще не надо их находить, т.к. достаточно посмотреть на название метода, чтобы понять, что там делается. И совершенно не важно, кто этот метод вызывает, а кто вызывается им.


IT>6. Автоматическое тестирование. Настоящие индейцы обязательно пишут тесты для тестирования библиотечного кода, который используется другими частями приложения. Прикладной код тоже иногда может автоматически тестироваться, но это может оказаться банально дорого, т.к. тестирование библиотечного кода и например UI — это принципиально разные вещи. Юнит тест для библиотеки не стоит практически ничего, подготовка и периодическое изменение теста для UI может занять больше времени, чем работа над самим UI.

Золотые слова! Только что-то сомневаюсь, что покрытие библиотечного кода юнит тестами будет отлавливать много багов. У меня лично в таком коде очень редко ошибки появляются, а те что появляются — и без ЮТ о себе заявляют очень быстро, т.к. общие методы используются часто. Но, конечно, и создавать тесты для такого кода очень просто.